Atmel AVR assembler
in [ASM]
|
Next: int 10h AX = 4F00h
From: Rene Tschaggelar on 23 Jul 2005 13:14 Herbert Kleebauer wrote: > But how are AVR programs debugged at all? Are there AVR versions > which have support for hardware breakpoints or at least single > step interrupts? The only alternative I see at the moment is, > to add an assembler directive which automatically inserts a call > to a debug routine after each instruction. But this would > double the size of the code to debug. As to debugging. Reserve at least a single pin which can be set and reset, or pulsed by yoour software. A pulse lets you figure out that a certain position in the code has been passed. The next step is to serially shift out data through this pin. With some more resources, use the SPI or the serial as long as they don't interfere with your code. With some other pins to spare you can write parallel. I made a hardware decoder http://www.ibrtses.com/products/debug12.html that lets one decode whatver parallel data. Once you have your hardware running, have some debug commands in your communication. The next step with realtime data is a multichannel DAC on a plugable pcb that lets you write parallel datastreams in realtime to an oscilloscope. And yes, a code change means a new upload of your code to the cpu. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
From: Frank-Christian Kruegel on 23 Jul 2005 13:50 On Fri, 22 Jul 2005 22:38:11 +0200, Herbert Kleebauer <klee(a)unibwm.de> wrote: >> I fail to see what's so unusable about the AVR assembler syntax. Your effort >> resembles 68000 code. Writing a good assembler takes time, are you writing >> it from scratch? I think that's a complete wombat; better invest in learning >> the AVR syntax, which is really not that difficult and not unusual. > >What makes an assembler a "good assembler"? I think a good assembler >should allow you to write bug free code in a minimum of time. And >to do this you don't need a powerful macro system or a high speed >assembler or an integrated development system but you surely need >a well designed instruction syntax. And to write a simple assembler >(without a macro system and which is neither optimized for speed >nor size) isn't a big deal. Yes, you have to spend a few hours to >write the assembler, but this will save you much more time when >you write and debug your assembler programs. Most platforms have rather good C compilers, which is mostly much more efficient in terms of development time and often more than good enough in terms of execution time. When I started ARM programming, I didn't have to care about Assembler syntax at all. Of course, Assembler parts can be linked in where needed, but these parts are mostly small compared to the size of the whole system. I don't think writing a complete new assembler for a given platform being incompatible to the vendor standards makes sense. Using C saves more time and costs. My AVR projects are all >95% C code. Mit freundlichen Grýýen Frank-Christian Krýgel
From: larwe on 23 Jul 2005 14:29 > I can't agree, > CPU/MC-producers actually don't care about sense-making mnemonics. That's probably true but irrelevant. Assembly language is defined by the CPU vendor. Anything you do that deviate from the vendor's spec is writing a new language. This is a semantic issue. I can't call the OP's product an assembler because although what goes in looks like assembly language, it is not in fact assembly language for any known processor.
From: Rich Webb on 23 Jul 2005 14:32 On Sat, 23 Jul 2005 11:53:31 +0200, Herbert Kleebauer <klee(a)unibwm.de> wrote: [snip...snip...] > >When small deviations can have evil consequences, then most probably >small deviations can also have positive consequences. Why not try >to start an evolution to the better side? While I admire your purity of spirit, please do not ever use your "improved" assembler on any project involving another programmer or, most especially, on any project that may require life cycle support for decades. Maintenance programmers have a hard enough time as it is. Being introduced to a project that needs "a few small changes" and being told that, "Oh by the way, the guy that wrote this 17 years ago made up his own assembler directives" is not a happy thought. Have a heart. -- Rich Webb Norfolk, VA
From: larwe on 23 Jul 2005 14:38
> Great logic. Let's use a bad design because we then at least > are compatible to the other bad designs! Why not use a superior > design so you are better than all this compatible bad designs? You're the one with flawed logic here. You say that the vendor's syntax is hard for you to work with. Fine, write a new language with syntax that doesn't offend you. But don't call it an AVR assembler. Saying it's an AVR assembler implies that it assembles AVR assembly language, the syntax of which was defined by Atmel. If you're trying to write a Spanish-to-English translator, and you decide that the syntax of Spanish is inconveniently difficult, and you wind up writing an Esperanto-to-English translator, well that might be a useful product in some scenario, but it is not accepting Spanish input so don't advertise it as such. What you have written is some kind of pseudo-assembler. It might save a small amount of time for *you* to work with this tool *alone*, but for normal AVR users who have to think about maintainability, multi-member teams, integration with other toolsets, etc. it is a time sink. |