I
ian field
- Jan 1, 1970
- 0
Don McKenzie said:have a look at:
http://www.dontronics.com/see.html
this may give you a different slant on assembly.
Don...
It looks to be mostly Parallax - and I've seen their price list!!!!!
Don McKenzie said:have a look at:
http://www.dontronics.com/see.html
this may give you a different slant on assembly.
Don...
Tom2000 said:
ian said:It looks to be mostly Parallax - and I've seen their price list!!!!!
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.
Good reply.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
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.
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.
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
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
john jardine said:Tom2000 said:
[...]
Whenever I come across the phrases "Linker scripts" or "Manifest
constants",
I reach for my revolver
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.
<snip>
Spoken like a true experienced coder in the field of uC. I'm glad
you stepped up to the plate.
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.
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.
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
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.
Eeyore said:I think you're mistaken to imagine everyone uses PICs. It's more of a
joke than reality AIUI.
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?
ian said:Isn't AVR what Atmel would like everyone to use instead of 805x parts?