Hello Timothy, The typical reasons and criteria for selection of a high-level language for an embedded project (PIC, 8051, what have you) are: 1. You can afford the cost of a good compiler for the target platform 2. You want reduced development time 3. You want reduced debugging time (page/bank issues, etc.) 4. Your target processor may change somewhat (example: bank and page size changes between parts are just a recompile in C, but a major nightmare in assembly) 5. You feel confident that if you did the project in fairly tight assembly you'd still have 30-40% of your program ROM free. 6. You want to reuse existing C, Java, etc., code with minimal modifications. 7. You want to be able to port a standard library (for example, an IEEE compliant floating-point package) without worrying about the implementation details. 8. You want to be able to port and test the code on another platform (such as a PC) natively. 9. Performance isn't an issue, or at least not a major issue. 10. You have multiple people working on the code at once. 11. You have at least one person on the team who is new to the target assembly language, and at least one other person who rarely comments anything. This is a really strong argument to use a compiler (as well as revision control). Now, that said, not all compilers deliver all those things or have all those requirements on all platforms. For example, not all microcontroller compilers use IEEE floating-point. (Don't buy one that doesn't, by the way, unless you're sure you know what you're doing, or you won't be using floating-point math.) Likewise, typical reasons and criteria to use assembly instead of a high-level language include: 1. You cannot afford the cost of a good compiler for the target platform 2. You're not in a hurry 3. The processor is easy to debug on (NOT necessarily true for the PIC, unless you're already familiar with troubleshooting Page and Bank issues) or already very familiar to you 4. Your target processor is fairly well locked down 5. You're not even sure you're going to be able to cram everything onto the chip in assembly 6. You're writing everything from scratch and don't expect to reuse any of it on another chip 7. You don't care about interfacing with other "standard" functions or protocols, or if you do, you are willing to write or test the implementation yourself 8. You can do all your testing on the device, with an ICE, or with a processor-level simulator. 9. Performance is critical. 10. You're the only one working on it and you can keep track of any "clever" things you do in assembly that optimize down better than they would in C. 11. Your whole team is using a revision-control system, everyone understands the processor well, and all code is well-documented. Regardless of which approach you pick, let me strongly suggest: 1. Acquire, learn to use, and use religiously, CVS, Sourcesafe, or some other revision control system. Even if it's just you, you'll appreciate the ability to roll back. 2. Split projects into multiple modules, instead of having huge, monolithic assembly files. It makes it easier to roll back changes, add new features, and change where things go in memory at link-time. 3. Document the hell out of everything. If you see documentation in your code that is no longer correct, replace it. If you don't have time to do that, at least add an "[OBSOLETE]" above and below it to warn people-- including your future self. 4. Get the best debugger you can afford. If you can't afford an in-circuit emulator (ICE), you should also find a hobby that helps you relieve stress extremely well. Best of luck, Matt Heck ----- Original Message ----- From: "Timothy J. Massey" To: Sent: Wednesday, April 17, 2002 2:42 PM Subject: Re: [PIC]:c interrupts > Hello! > > Am I missing something, or isn't that the whole point of an ISR? To handle > interrupts immediately so the body of your code doesn't have to worry about > it? Why can't your ISR handle the interrupt (or at least jump to a > function that can) in the first place? > > Or is there some limitation of the C compiler you're using? > > Tim Massey > > P.S.: I'm new to PIC's. I understand the value of C compilers on "normal" > computers, especially computers like IBM PC's, with 10 different memory > models, 100 different hardware devices to manage, 1,000 different ASM > instructions and 1,000,000 lines of code. But on a PIC? Why do people > choose C over straight ASM when you're almost always talking about just a > couple of k of code and few hardware devices to worry about? Or am I just > not sophisticated enough yet? > T.J.M. > > > > > > Gordon Varney > E.COM> cc: > Sent by: pic Subject: Re: [PIC]:c interrupts > microcontrolle > r discussion > list > A.MIT.EDU> > > > 04/17/02 05:23 > PM > Please respond > to pic > microcontrolle > r discussion > list > > > > > > > > I'd set a global variable flag in the interrupt service routine and check > > it in the loop, then use break if the flag is set. I assume you'll be > > using something other than goto for your loops... > > > > while (1) { > > while (1) { > > if (FLAG) break; > > } > > } > > > > > No, It will be very important to stop the loop immediately. > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > > > -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads