[avr-gcc-list] gcc-avr/avr-libc wiki
Hi, I've stuck up a main page and some stub articles on the avrwiki.com AVR wiki site, at: http://avrwiki.com/wiki/index.php/AVR_GCC To set some example of contributing (rather than just whining about lack of doco), I've stuck up a page on debugging using ddd: http://avrwiki.com/wiki/index.php/AVR_GCC_Debugging If everyone reading this message can stick up just one page each, we'll have one nice, healthy growing wiki that will truly welcome other AVR converts, and lend a lot of support to existing AVR users. Let's get some really great and complete gcc-avr/avr-libc doco. Cheers David ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] avr-gcc 'documentation'
> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Joerg Wunsch > Sent: Wednesday, February 28, 2007 3:57 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] avr-gcc 'documentation' > So far, the best > international resource is still avrfreaks.net, but they don't have a > Wiki. Maybe we should convince them of introducing one? I think that they are, or will be, introducing one. I can't find it on the Freaks site at the moment, but I will make some inquiries. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc 'documentation'
On Wed, 2007-02-28 at 23:57 +0100, Joerg Wunsch wrote: > I don't mind, as long as it's really "live". I know the Wiki from > www.mikrocontroller.net is, but that's German only. Which is great for German speakers, but overall it alienates more than 95% of people. > So far, the best > international resource is still avrfreaks.net, but they don't have a > Wiki. Maybe we should convince them of introducing one? But that > could become hard, as I can imagine Atmel (as the company hosting the > service) wouldn't want to be held responsible for the contents when > anyone on earth could modify that contents. Atmel are legally exposed, so one could understand their reluctance. > So it's simply the other way 'round: as soon as www.avrwiki.com offers > enough value/contents that people find it worth the while, it could > deserve a link on the avr-libc pages. I realize that's some kind of > barrier or critical mass situation, but it certainly doesn't make much > sense to place links to something that could eventually perhaps maybe > become a reasonable resource of knowledge some day. It's more of a 'chicken and egg' situation. It's not going to get populated till it's publicised, and waiting till it gets populated before publicising will ensure it will never get populated. I could suggest writing on the AVR main page something like: "AVR/GCC users/developers are strongly encouraged to share their knowledge on the http://www.avrwiki.com/avr-gcc";>AVR wiki". It would only take a main page with category links to stub pages before some people will actually start populating it. For example, I've just had some success debugging my asm/C code on linux with the graphical ddd debugger, which happens to work seamlessly with gdb-avr and simulavr, and I would happily write a page on that. Cheers David ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc 'documentation'
David McNab <[EMAIL PROTECTED]> wrote: > WormFood on the irc.freenode.net#avr kindly tossed me a link to the > gnu 'as' manual. But he did mention that it was buried deeply on the > gnu site, and that it took him/her several attempts and searches to > find it. Well, if you've got WinAVR, it comes there for free. If you've got any kind of Unix distribution that includes the GNU assembler, one should hope it also ships a copy of the GNU assembler info pages. > If there's no AVR-specific toolchain doco, then I could see the libc > doco as a good temporary place to put it. > But sooner or later, the doco does need to be separated between > toolchain programs and libraries. It basically is. The lack of the AVR-specific details in the assembler manual has been a bug. Other architectures did go and document their specific stuff in the GAS manual. I think this has historical reasons: when AVR-GCC was started by Denis Chertykov, he made it emit code for another assembler that was already available by that time, so he didn't have to port GNU binutils to the AVR as a prerequisite. When the port of GNU binutils was done later (either by Denis or by Marek Michalkiewisz, I don't know for sure), they've got plenty of things to do, and eventually forgot to also add the target- specific documentation. Again, as most people are interested in the C part of the game, the assembly stuff could be seen as some kind of "private negotiation" between the compiler and the assembler, since most people wouldn't even look at the generated assembly code at all. So it's at least understandable the missing documentation has never raised too many questions about it. I guess those who really wanted to know eventually figured it out by looking at the GCC-generated code. (Generating documentation index) > It's easy to cut a python/perl/ruby script to spider the doxygen > pages and generate a master index. I could do a Python one, if > anyone could assure me that it would be taken up. Well, building the documentation already has such a large number of prerequisites, another one (like a scripting language interpreter) wouldn't matter at all, at least as long as it's a commonly used one like the languages you mention. Personally, I've been using Perl for maybe 15 years now, so I never really got a need for another scripting language, but as Ted Roth left us some Python code, and some guys in my job also prefer that language, I can live with that one as well. (My only gripe with Python is that they made white space a syntactically significant element. This one is really stupid.) >> > - there's no definitive list of assembler macros >> What kind of macros are you talking of? > lo8(), hi8(), pm() etc - that is, if there's any more where these > have come from. Ah, OK, technically that's not macros but operators. And yes, these belong to the target-specific parts of GAS that used to lack documentation so far. I hope that has been fixed now (but didn't look at it myself yet). > I've also bumped into a few assembler macros such as FUNCTION(). Are > these officially supported? No, they must come from whatever environment you've been looking at. avr-libc uses a few of these internally. Their definition files are in the common/ subdirectory. However, they are purely meant for library internal use, and are not being exported. >> Having said this, I'm always all ears for ideas for more example >> projects. > One idea - a 'bar graph' which regularly reads an ADC pin, shifts > the 10-bit analog value down to 3 bits, then lights one of 8 LEDs. That should be simple, yes. Code attached (tested for an ATtiny26). > This could be done in several versions - one in pure C, then > successive versions which replace more and more of the C with > assembler routines. But what's the purpose? The code already takes just 162 bytes, or about 8 % of the smallest processor where this demo could be run at, the ATtiny26. It cannot be run on an ATtiny13 because it lacks enough IO pins to drive the LEDs. Even on the ATtiny26, you'd have to blow the RSTDISBL fuse in order to access the 8th LED. The generated assembly code is about as tightest as possible, so the only thing you could really save is the C startup code. But then, will you get any money back from Atmel for not using the entire flash ROM? ;-) So this is rather a typical example for why one would *not* want to resort to assembly, if C could do the job adequately, and within *way* less of development time. (I wouldn't have written you the example in assembly within those last 10 minutes it took me to prepare the C one. OK, it will/would take another hour or two to prepare the documentation for it.) That's what I meant with real-world examples. The existing assembly demo at least had a real "story" behind it: to get around the fairly limited resources of the ATtiny13 that has been the original target, namely its lack of a second timer. Btw., the bargraph demo wouldn't touch the
[avr-gcc-list] avrdude: Using debugWire to program flash
The avrdude man page indicates that debugWire doesn't support an explicit flash erase command, but that the erase is handled implicity by the JTAG ICE mkII during a write operation. debugWire is working well, but the erasing part of the programming doesn't seem to be working. avrdude 5.3.1 JTAG ICE mkII AT90PWM3B Thanks, Shaun $ avrdude -Pusb -cjtag2dw -ppwm2b -B9 -u -U/tmp/pwmdriver.bin avrdude: AVR device initialized and ready to accept instructions Reading | ## | 100% 0.00s avrdude: Device signature = 0x1e9383 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: Chip erase not supported in debugWire mode avrdude: reading input file "/tmp/pwmdriver.bin" avrdude: input file /tmp/pwmdriver.bin auto detected as raw binary avrdude: writing flash (5474 bytes): Writing | ## | 100% 3.11s avrdude: 5474 bytes of flash written avrdude: verifying flash memory against /tmp/pwmdriver.bin: avrdude: load data flash data from input file /tmp/pwmdriver.bin: avrdude: input file /tmp/pwmdriver.bin auto detected as raw binary avrdude: input file /tmp/pwmdriver.bin contains 5474 bytes avrdude: reading on-chip flash data: Reading | ## | 100% 0.63s avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x0018 0x25 != 0x09 avrdude: verification error; content mismatch avrdude done. Thank you. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc 'documentation'
On Wed, 2007-02-28 at 15:21 +0100, Joerg Wunsch wrote: > David McNab <[EMAIL PROTECTED]> wrote: > > > - avr-as pseudo-ops - there seems to be no thorough list of > > these. For example, I had to look through list archives to learn > > how to declare a buffer in SRAM via the '.skip' pseudo-op > > That's available in the GNU assembler manual. Note that the GNU > assembler manual does not document each target's native instruction > set, as that is supposed to be published by the vendor. Everything > else ought to be there. WormFood on the irc.freenode.net#avr kindly tossed me a link to the gnu 'as' manual. But he did mention that it was buried deeply on the gnu site, and that it took him/her several attempts and searches to find it. > As for the AVR-specific operators (like lo8 and hi8 and such), their > documentation has been lacking so far, but I've been told it has been > added into the binutils tree meanwhile, so they are supposed to be > documented with the next release. For the time being, the avr-libc > documentation tried to fill that gap. If there's no AVR-specific toolchain doco, then I could see the libc doco as a good temporary place to put it. But sooner or later, the doco does need to be separated between toolchain programs and libraries. > > - a good part of the C API is well documented via doxygen, but > > there is no consolidated global index of everything. Such an index > > would prove a huge boost > > If you know how to convince doxygen to produce that index, your > patches are more than welcome! That's a lamentable limitation in doxygen. Most of the other source-code-markup doco systems have an index feature, such as epydoc, javadoc etc. It's easy to cut a python/perl/ruby script to spider the doxygen pages and generate a master index. I could do a Python one, if anyone could assure me that it would be taken up. Another option is to feed the doxygen pages and ancillary hand-written pages into a cacne and search engine combo such as WWWOFFLE plus ht://dig; throw 'wget -r' at it and you'd end up with one really nice database and index. But that's not appropriate for distribution. > > - there's no definitive list of assembler macros > > What kind of macros are you talking of? lo8(), hi8(), pm() etc - that is, if there's any more where these have come from. I've also bumped into a few assembler macros such as FUNCTION(). Are these officially supported? > Btw., most people using the GNU tools don't focus on assembly language > at first, that's why the major part of the avr-libc documentation > concentrates on C rather than assembly. Some folks, however, would quickly turn their minds to the C+assembler angle, especially when they throw a bit of pure C at the toolchain, look at the code size and think 'yikes!' at the prospect of fitting it all into a 2k MCU. > > - I can count the code examples on my left hand. There really need > > to be several dozen examples shipped in /doc/examples in the > > avr-libc distribution, ranging from the simplest to the more > > complex > > Well, the avr-libc examples are meant as some kind of "getting > started" only (but then, they are maintained by the avr-libc > maintainers, so with new releases, they are usually kept well up to > date). Once you've got the first steps behind you, there's plenty of > examples that can be found on the Internet. E.g. you could go to the > "Academy" of avrfreaks.net. Forums are only as good as their search engines. Even if a forum has a good search engine that allows google-like binary expressions and full-text search, there's still a degree of mental labour involved. > Having said this, I'm always all ears for ideas for more example > projects. One idea - a 'bar graph' which regularly reads an ADC pin, shifts the 10-bit analog value down to 3 bits, then lights one of 8 LEDs. This could be done in several versions - one in pure C, then successive versions which replace more and more of the C with assembler routines. > It's a bit of work to craft them, but it's also some fun. > If you've got something you'd really like to see, tell me about it. > I'm most interested in realistic examples, rather than anything that > sounds too much "artificial". I'm working on a bytecode interpreter, which executes a combination of bytecode functions and primitive C functions. If I get that working to my satisfaction, I'll submit that as well, since it it's low to medium complexity and demonstrates some issues of C assembler interfacing. > > To give an example of great microcontroller compiler doco, consider the > > PIC CCS C compiler manual: > > Sure, a commercial vendor usually has a different focus here. After > all, there's usually a single team who produces the software and > documentation, while we have three major teams (binutils, GCC, > avr-libc). Out of these, only the latter is focused on the AVR, and > thus the avr-libc documentation aims to be something like the bracket > to summarize every
Re: [avr-gcc-list] howto: accurate fast usart with IntRC clock and OSCCAL
David McNab <[EMAIL PROTECTED]> wrote: > So it occurred to me that, if accurate timing for other > functionality is not critical, and if one is using the internal > clock, one can tune OSCCAL to get very close to the real target > baudrate. > If one wants good timing, one can recompile the code with: > #define F_CPU 7372800 > and end up with reasonable timing with the delay function IIRC, 7.3728 MHz is guaranteed to be in the range that can be tuned with OSCCAL, I guess what reasons the engineers might have had in mind when they spec'ed it that way. ;-) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc 'documentation'
David McNab <[EMAIL PROTECTED]> wrote: > - avr-as pseudo-ops - there seems to be no thorough list of > these. For example, I had to look through list archives to learn > how to declare a buffer in SRAM via the '.skip' pseudo-op That's available in the GNU assembler manual. Note that the GNU assembler manual does not document each target's native instruction set, as that is supposed to be published by the vendor. Everything else ought to be there. As for the AVR-specific operators (like lo8 and hi8 and such), their documentation has been lacking so far, but I've been told it has been added into the binutils tree meanwhile, so they are supposed to be documented with the next release. For the time being, the avr-libc documentation tried to fill that gap. > - a good part of the C API is well documented via doxygen, but > there is no consolidated global index of everything. Such an index > would prove a huge boost If you know how to convince doxygen to produce that index, your patches are more than welcome! > - there's no definitive list of assembler macros What kind of macros are you talking of? Btw., most people using the GNU tools don't focus on assembly language at first, that's why the major part of the avr-libc documentation concentrates on C rather than assembly. > - I can count the code examples on my left hand. There really need > to be several dozen examples shipped in /doc/examples in the > avr-libc distribution, ranging from the simplest to the more > complex Well, the avr-libc examples are meant as some kind of "getting started" only (but then, they are maintained by the avr-libc maintainers, so with new releases, they are usually kept well up to date). Once you've got the first steps behind you, there's plenty of examples that can be found on the Internet. E.g. you could go to the "Academy" of avrfreaks.net. Having said this, I'm always all ears for ideas for more example projects. It's a bit of work to craft them, but it's also some fun. If you've got something you'd really like to see, tell me about it. I'm most interested in realistic examples, rather than anything that sounds too much "artificial". > To give an example of great microcontroller compiler doco, consider the > PIC CCS C compiler manual: Sure, a commercial vendor usually has a different focus here. After all, there's usually a single team who produces the software and documentation, while we have three major teams (binutils, GCC, avr-libc). Out of these, only the latter is focused on the AVR, and thus the avr-libc documentation aims to be something like the bracket to summarize everything, but obviously, it cannot (and should not) replace the more detailed (but not AVR-specific) documentation for binutils and GCC. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
