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
Atmel AVR assembler
Started by ●July 21, 2005
Reply by ●July 23, 20052005-07-23
Reply by ●July 23, 20052005-07-23
On Fri, 22 Jul 2005 22:38:11 +0200, Herbert Kleebauer <klee@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
Reply by ●July 23, 20052005-07-23
> 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.
Reply by ●July 23, 20052005-07-23
On Sat, 23 Jul 2005 11:53:31 +0200, Herbert Kleebauer <klee@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
Reply by ●July 23, 20052005-07-23
> 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.
Reply by ●July 23, 20052005-07-23
Op 23 Jul 2005 11:29:27 -0700 schreef larwe@larwe.com:>> 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.You've nevwe programmed in Forth, did you? An assembler in Forth can use the same syntax as a 'normal' assembler, by using the order: opcode, destiny, source like (I assume) the one of AVR does. But it is simpler to implement, and easier to understand (for a Forth programmer) in the order: source, destiny, opcode. Postfix so to speak. I know lots of people that use this syntax and they can program each and every program with it. Coos -- CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
Reply by ●July 23, 20052005-07-23
> > 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. > > An assembler in Forth can use the same syntax as a 'normal' assembler, by > using the order: opcode, destiny, source like (I assume) the one of AVRSo by your definition of syntax equivalency, Yoda speaks normal English?
Reply by ●July 23, 20052005-07-23
Op 23 Jul 2005 12:05:03 -0700 schreef larwe@larwe.com:>>> 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. >> >> An assembler in Forth can use the same syntax as a 'normal' assembler, by >> using the order: opcode, destiny, source like (I assume) the one of AVR > > So by your definition of syntax equivalency, Yoda speaks normal > English?No, but by speaking Reverse Polish he can try to destroy the Force ;-) Coos -- CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
Reply by ●July 23, 20052005-07-23
larwe@larwe.com wrote:> > > 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.You are mixing up terms here. The designer of a processor architecture defines the machine language (i.e. which bit pattern is which instruction). An assembler converts a textual representation of processor instructions (assembly language) to machine language. This means the syntax of an assembler is defined by the writer of the assembler and not by the designer of the processor. I don't know how many assemblers for the AVR architecture exist, but the Atmel AVR assembler is just one of them and in no way something special. There are also many assemblers for the x86 architecture which are all incompatible. Non of them is the "standard". Even if Intel would write it's own assembler, they couldn't say, this is the valid assembler syntax for x86 processors. All they can define is the machine language but not the assembly language. I suppose there is also a GCC port for AVR. Would you also say that the generated GAS code (which I suppose is in AT&T syntax) is not an AVR assembler code?
Reply by ●July 23, 20052005-07-23
> You are mixing up terms here. The designer of a processor > architecture defines the machine language (i.e. which bit > pattern is which instruction). An assembler converts a textual > representation of processor instructions (assembly language) > to machine language. This means the syntax of an assembler > is defined by the writer of the assemblerYou will observe that the mnemonics and operand order are defined in the datasheets provided by Atmel. I would call this a vendor definition of the recommended assembly language, no?> There are also many assemblers for the x86 architecture which > are all incompatible. Non of them is the "standard". Even ifThe differences between, say, TASM and MASM, mostly lie in the pseudo-ops and special instructions that influence segment layout, etc. These aren't part of the instruction set. Besides, weren't you the one saying we shouldn't imitate silly designs? You just pointed out that x86 assemblers are fragmented; why are you now trying to fragment the AVR assembler market? In practical terms, the specific point we're arguing about right now really doesn't matter: the bottom line is that if it doesn't build code out of manufacturers' app notes or from the millions of lines of published sourcecode, it's not very useful.
