I respect James' opinion. However, I also respectfully disagree with some of his premises. I have specialized in assembly languages throughout my programming career. In 1968, my boss at Boeing told me to get into high level languages 'cause my days as an assembler language programmer were numbered ( I was a "Systems Programmer" on mainframes). He was absolutely convinced by the trade journals that all computers would end up being programmed using HLL - even for system functions - in a matter of a few short years. That was 35 years ago! In reality, things are not much cifferent today. There are STILL things that are best done in assembly. Likewise, there are still things that are MUCH better done in HLL, such as statistical analysis, etc. But aren't we really talking about a middle ground here? Each application should be reviewed by all salient factors, such as timing (if an issue), complexity, size and power of the desired platform, etc., in order to make a decision of the best way to go - HLL, assembly, or a hybrid. You cannot make such a decision unless you have a firm grasp of the tools at your disposal - and assembly language is a vital tool on something as limited as even the most powerful PIC (personal opinion here!). Some of the C compilers I've looked at are very good at optimization, but I still find occasion where assembly is the best choice - even if it's just a module! Assembly forces you to understand the architecture of the chip, whereas a HLL removes much of that need. That's mostly a good thing, but to really write a bulletproof PIC application, knowledge of the hardware is frequently invaluable. I vote for learning assembly first. To me, a RISC arhitecture such as the PIC is one of the easiest to learn (although maybe harder to master). You might want to minimise the pain by learning the 18F series first. Be aware, I'm not advocating "mastering" assembly before moving on to HLL, just become proficient enough to write a decent program, THEN move on if you wish. That way, you have the advantage of choosing the best tool for a particular job, rather than limiting yourself to force fitting every application into the HLL you know. It's like the saying - when all you have is a hammer, everything else had better be a nail! That's strictly my opinion for what little it's worth! Dennis ----- Original Message ----- From: "James Caska" To: Sent: Monday, January 20, 2003 8:47 PM Subject: Re: [PIC]:PIC custom component module for ExpressPCB/ExpressSch? > Hi All, > > I just thing there is a really good reason we don't program with punchcards > anymore.. its called productivity. > > Lets just face it, regardless of what proprietry macro's you come up with > projects written in assembly are a nightmare to maintain and even worse to > code review. Forcing the developer to think like a micro not a programmer, > relying on special features of the processor like unbanked special general > purpose code sections with the only way to really see the code is to single > step and look at things as they happen. > > While I agree that small systems increase the need for this type of low > level understanding... its just a wee bit over the top to expect someone to > wait 4 years to gain the type of knowledge needed to come from bottom up. > Hey, by then the kid has lost interest in flashing LED's and has gone and > got a job as a java programmer earning double his embedded counterpart. > > Assembly is a necessary evil for sure, and yes it is mandatory for the > embedded professional but like the rest of the computing world, over time > assembly is sinking to the bottom of the food chain. Those trying to keep it > on the top of the heap will eventually loose their battle. > > However, there is no 'silver bullet' in embedded. These are all just tools > in the toolbox, assembly and high level languages should be used in the > optimal configuration for the job at hand and yes, that often depends most > significantly with what a specific developer has used in the past and has > code templates for. But this is a very developer specific mindset and what > is good for one developer is not necessarily the best for the rest of the > world. > > My time on the 'soapbox' has come to and end ;-) > > Cheers all, > > James Caska > www.virtualbreadboard.com > www.muvium.com > uVM - 'Java Bred for Embedded' > > > > > -----Original Message----- > > From: pic microcontroller discussion list > > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Mike Singer > > Sent: Tuesday, January 21, 2003 10:56 AM > > To: PICLIST@MITVMA.MIT.EDU > > Subject: Re: [PIC]:PIC custom component module for > > ExpressPCB/ExpressSch? > > > > > > Kinda posts that get me silent on the List for a while. > > Thing usually are not covered in datasheets :-) > > Things that could affect the way I think. > > > > Mike. > > > > Olin Lathrop wrote: > > > > >Even if someone > > > > > ends up using a higher level language once they get going, the > > insight > > > > > gained from doing a few assembler projects will be valuable. > > > > > > > > Why doesn't this same theory apply to Macs, Solaris, Windows, or > > Linux > > > boxes? > > > > What is it about small systems that turns this on its head? > > > > > > Because those systems have infinite resources for the purpose of most > > > programs, and all the processor and peripheral details are abstracted > > thru > > > drivers and interface libraries. It's all just software layered on > > more > > > software, and a few extra cycles or memory locations don't matter. > > You can > > > write large useful programs without having a clue how a computer > > really > > > works, although on rare occasions at the edges of the architecture it > > can be > > > an advantage to understand how the compiler is using the stack, for > > example. > > > The abstractions and generalizations by and large work. If your > > program is > > > a pig, no problem. For a few 10s of $$, you can add another 128Mbyte > > of > > > memory. No big deal when the system costs $1,000 in the first place. > > > > > > I also disagree somewhat that the theory of learning bottom up doesn't > > apply > > > to large systems. Bottom up learning in most subjects generally takes > > > longer to produce "cool" results, but in the end produces better > > results. > > > It therefore makes sense to use that approach for the truly motivated > > and > > > those that need to really understand. > > > > > > If you aked me to teach an accountant how to program so that he could > > write > > > his own programs for adding up lists of numbers, I would show him a > > high > > > level language. If you asked me to teach freshman computer science > > students > > > with the end result measured 4 years later, I would absolutely start > > with > > > the low levels on simple systems and work up. Each step of the way I > > would > > > have them discover for themselves the motivations for things like > > > assemblers, linkers, device drivers, operating systems, compilers, > > etc. > > > Four years later they'd be able to jump into any system anywhere and > > pick up > > > new information easily. > > > > > > You also have to take into account different learning styles. Some > > will > > > want instant gratification. They just want to get a job done and > > > superficial knowledge is good enough. They might delve into the > > details > > > later. Frankly I've seen these types of people produce useful results > > and > > > get good but never great. They get stumped more and end up getting > > help > > > from the guru. However, the truly interested will feel "naked" until > > they > > > understand what is really happening. Working top down will frustrate > > them. > > > Teaching them bottom up is how you create the next generation of > > gurus. > > > > > > > -- > > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body > > > > > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu