Maker Pro
Maker Pro

PIC Assembler.

D

Don McKenzie

Jan 1, 1970
0
ian said:
It looks to be mostly Parallax - and I've seen their price list!!!!!

If you have a closer look, James Newton of piclist.com, has gone to the
trouble of decoding it into microchip mnemonics. (pure pic assembler)

Don...



--
Don McKenzie

Affiliate Program: http://www.dontronics.com/affiliate
Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
No More Damn Spam: http://www.wizard-of-oz.com

Serial OLED uses standard micro-SD memory cards.
http://www.dontronics-shop.com/product.php?productid=16659
 
J

john jardine

Jan 1, 1970
0
ian field said:
<snip>

Many thanks, the first link is *very* interesting - I may already have the
other 2 saved. The Elmer 160 starts off simple enough but the code examples
quickly get heavy going, I need to go over a lot of simpler code over and
over until I get the hang of it.

It's absolutely essential that you get to write the few lines needed to
flash an LED. If you can get there and can see why you've caused the LED to
flash then -ALL- other PIC programming is downhill.
The "mstracey" link that Richard supplied, will do this, (upto "tutorial
#5") but more importantly, the how's and why's of the individual
instructions are described nicely.

Try and ignore anything written by Microchip.
Sadly though, you may have to make use of Microchip's, bloated, inane piece
of s***, known as "MPLAB", but remember, the hoops it forces you to jump
through, are nothing to do with actual PIC programming but more reflect the
mindset of Microchip's C pogrammers.
 
J

Jamie

Jan 1, 1970
0
Jonathan said:
I am NOT thinking of any particular HLL, since the solution to one of
the problems/cases I have in mind cannot be solved properly in any I
know of. (There are many other cases which cannot be solved in C or
C++, but can in CLU or some other HLL -- but I'm eliminating those
thoughts just in case you happen to be familiar with every HLL I am
familiar with.) The architecture I'm thinking of is the case for most
microcontrollers without branch detection and cache. Even in those
cases, it probably applies, but the detailed answer will depend a
little.

Mostly, my problem with your statement is that it is obviously made
from the perspective of a god, which I know you are not. You don't
have the perspective to say it. And I'm prepared to show you cases
(more than one) which can give the lie to it and demonstrate that you
lack perspective in making it. If you hadn't been so sure of yourself
and had toned down the sweeping nature, I'd have left it be. But you
said what you said and I have a few cases to easily take it down a
notch or two.

I could tell you the upshot of one of the cases, right away, without a
lot of todo. And if you go back and use google to read my posts in
comp.arch.embedded, you will actually find some cases I mentioned
there for exactly this purpose. So you don't have to be caught
flat-footed, if you don't want to be. But they have been examined by
others and I don't recall anyone doing anything but finding the cases
sufficient to make the point. You could be the first to find the
flaws in what I will write, though. And these are actual cases from
real projects I've faced. Not made up school problems.

Jon
Good reply.
Spoken like a true experienced coder in the field of uC. I'm glad
you stepped up to the plate.
 
T

Tom2000

Jan 1, 1970
0
Thanks - that starts off simple enough and is mostly well written, but it
takes off a bit too fast, I've read it through but found on each successive
chapter I was skipping over the code examples and just getting what I could
from the text. Its a great tutorial but I need a little slower curve.

Ian, if you run into anything you don't understand while you're
working through any tutorial, feel free to ask for clarification here.
Lots of us will be more than happy to help you out.

Tom
 
E

Eeyore

Jan 1, 1970
0
Tim said:
In the embedded world we call people with the skill set to go with your
attitude "applications programmers".

It's not a compliment.

'Applications' on an 8051 ?

It seems that the very mention of an HLL has become so inextricably linked to 'C' that
any sensible discussion of the use of a HLL on a uC is no longer possible.

Have you ever even encountered PL/M ?

Just because Intel no longer sell / support it doesn't mean it's not relevant to this
discussion. And furthermore, I often inspect the assembler it produces out of interest.
That's one reason I see no need to code natively in it.

Graham
 
I

ian field

Jan 1, 1970
0
Eeyore said:
'Applications' on an 8051 ?

It seems that the very mention of an HLL has become so inextricably linked
to 'C' that
any sensible discussion of the use of a HLL on a uC is no longer possible.

Have you ever even encountered PL/M ?

Just because Intel no longer sell / support it doesn't mean it's not
relevant to this
discussion. And furthermore, I often inspect the assembler it produces out
of interest.
That's one reason I see no need to code natively in it.

Graham

PL/M isn't relevant to my original question about PIC assy', and when
someday I might progress to making PIC a career boost potential employers
are somewhat more likely to require experience with C PIC HLL than PL/M.
 
I

ian field

Jan 1, 1970
0
Tom2000 said:
Ian, if you run into anything you don't understand while you're
working through any tutorial, feel free to ask for clarification here.
Lots of us will be more than happy to help you out.

Tom

Thanks, at the moment I've got a sizeable collection of stuff I googled that
needs sorting into folders so I can find the useful one's later, there were
some good links posted here yesterday and I also found half a box of front
cover CD/DVDs - about 4 or 5 are PIC related.
 
I

ian field

Jan 1, 1970
0
john jardine said:
It's absolutely essential that you get to write the few lines needed to
flash an LED. If you can get there and can see why you've caused the LED
to
flash then -ALL- other PIC programming is downhill.
The "mstracey" link that Richard supplied, will do this, (upto "tutorial
#5") but more importantly, the how's and why's of the individual
instructions are described nicely.

Try and ignore anything written by Microchip.
Sadly though, you may have to make use of Microchip's, bloated, inane
piece
of s***, known as "MPLAB", but remember, the hoops it forces you to jump
through, are nothing to do with actual PIC programming but more reflect
the
mindset of Microchip's C pogrammers.

Are any of the older versions of MPLAB any less "bloated"?
 
J

Jonathan Kirwan

Jan 1, 1970
0
<snip>
Spoken like a true experienced coder in the field of uC. I'm glad
you stepped up to the plate.

And I doubt Graham will respond to the challenge. He probably has
either read what I've written before or else can, now prodded, think
of a few reasons and evidence that makes his claims clearly false.

Jon
 
E

Eeyore

Jan 1, 1970
0
ian said:
PL/M isn't relevant to my original question about PIC assy', and when
someday I might progress to making PIC a career boost potential employers
are somewhat more likely to require experience with C PIC HLL than PL/M.

If you're hell bent on programming a PIC, PL/M certainly will be of no use to
you. That wasn't my point however.

On the other matter, why are you so interested in PICs (as opposed to 8051
family or any other) ? One nice thing about 8051 is that the basic architecture
doesn't change from model to model. I've also heard that the data on the chips
is more reliable.

Graham
 
E

Eeyore

Jan 1, 1970
0
Jonathan said:
And I doubt Graham will respond to the challenge. He probably has
either read what I've written before or else can, now prodded, think
of a few reasons and evidence that makes his claims clearly false.

I can think of no reason whatever to use a language (assembler) that requires
more than one line of code to even add two numbers, never mind anything more
complex.

Graham
 
I

ian field

Jan 1, 1970
0
Eeyore said:
If you're hell bent on programming a PIC, PL/M certainly will be of no use
to
you. That wasn't my point however.

On the other matter, why are you so interested in PICs (as opposed to 8051
family or any other) ? One nice thing about 8051 is that the basic
architecture
doesn't change from model to model. I've also heard that the data on the
chips
is more reliable.

Graham

Maybe I'm just more comfortable following what everyone else is doing - Who
knows, if I do well at PICs I might even have a look at the AVR.
 
E

Eeyore

Jan 1, 1970
0
ian said:
Maybe I'm just more comfortable following what everyone else is doing - Who
knows, if I do well at PICs I might even have a look at the AVR.

I think you're mistaken to imagine everyone uses PICs. It's more of a joke than
reality AIUI.

Graham
 
A

Anthony Fremont

Jan 1, 1970
0
Eeyore said:
I think you're mistaken to imagine everyone uses PICs. It's more of a
joke than reality AIUI.

You're just being anti-PIC. Do you really think there are more people using
805x parts than PICs? Considering that you have little experience in
programming micros and aparently none with PICs, I'm at a complete loss to
understand why you want to ram PL/M and 805x down everyones throat every
time this stuff comes up. What is it exactly that is so great about PL/M
and so "Bleh" about C?
 
I

ian field

Jan 1, 1970
0
Anthony Fremont said:
You're just being anti-PIC. Do you really think there are more people
using 805x parts than PICs? Considering that you have little experience
in programming micros and aparently none with PICs, I'm at a complete loss
to understand why you want to ram PL/M and 805x down everyones throat
every time this stuff comes up. What is it exactly that is so great about
PL/M and so "Bleh" about C?

Isn't AVR what Atmel would like everyone to use instead of 805x parts?
 
A

Anthony Fremont

Jan 1, 1970
0
ian said:
Isn't AVR what Atmel would like everyone to use instead of 805x parts?

Probably, it's their counterpart to the Microchip PIC. Atmel also makes ARM
processors. Of all the processors I've played with, I think the ARM has the
most beautiful architecture.
 
Top