Can anyone recommend something like a text book on AVR programming?
I am looking at putting some kind of file system on SD cards, and this would seem to require writing a bootloader using gas. Searching around the web is great fun and all, but I keep running into apparently authoritative statements that contradict each other (eg, AVRdude can/cannot program the eeprom), or clearly refer to different versions (SPM can/cannot be executed outside the bootloader).
If there is something on the web like MIT's OpenCourseware that would also be nice.
Good book on AVR?
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Good book on AVR?
avrdude can program eeproms
different fuses control where SPM can read/write
different fuses control where SPM can read/write
-
- Posts: 67
- Joined: Sun Apr 05, 2009 11:29 am
Re: Good book on AVR?
Well, perhaps to clarify the situation, I was raised Big-Endian with von Neumann machines, and AVR is Little-Endian Harvard Architecture. I lack detailed knowledge and my reflexes are wrong.
In the case of avrdude, I had seen that the wire protocol supported eeprom programming in the ATMEL manual, but had seen conflicting statements as whether the software could do this.
In the case of SPM, I there seemed to be a restriction on where it could be executed -- anywhere in older parts, and only in the bootloader for 328P. I'll have another look at the fuses...
So, I seek something like a text book and/or online course materials as an alternative to unleashing a horde of "stupid" questions.
In the case of avrdude, I had seen that the wire protocol supported eeprom programming in the ATMEL manual, but had seen conflicting statements as whether the software could do this.
In the case of SPM, I there seemed to be a restriction on where it could be executed -- anywhere in older parts, and only in the bootloader for 328P. I'll have another look at the fuses...
So, I seek something like a text book and/or online course materials as an alternative to unleashing a horde of "stupid" questions.
-
- Posts: 49
- Joined: Tue Jan 02, 2007 5:48 pm
Re: Good book on AVR?
avrfreaks has an excellent tutorial section for user-contributed stuff. Not sure but I'm guessing you want something more detailed and thorough.
-
- Posts: 67
- Joined: Sun Apr 05, 2009 11:29 am
Re: Good book on AVR?
Yeah, comprehensive and on paper is the game. AVRFreaks seems to have some good stuff, but AVR is wholly new to me. So many I/O latches!
I can slog away at my doc8025.pdf from ATMEL, and while I can (eventually) locate specific bits, I have no overall sense of the processor.
For instance, I ran down the SPM question to page 277, where in 24.3.1 it says:
That in turn raises the question of whether it is possible to return to the bootloader after running an application without doing a hard reset, or do I have to resort to a hideous kludge like the one used in 286 machines to get back to real mode from virtual86. I have no idea where to run that down yet.
Ah well, onward through the fog!
I can slog away at my doc8025.pdf from ATMEL, and while I can (eventually) locate specific bits, I have no overall sense of the processor.
For instance, I ran down the SPM question to page 277, where in 24.3.1 it says:
I take this to mean that if I'm going to load code from an SD card, I have to write a bootloader.The Application section can never store any Boot Loader code since the SPM instruction is disabled when executed from the Application section.
That in turn raises the question of whether it is possible to return to the bootloader after running an application without doing a hard reset, or do I have to resort to a hideous kludge like the one used in 286 machines to get back to real mode from virtual86. I have no idea where to run that down yet.
Ah well, onward through the fog!
- westfw
- Posts: 2008
- Joined: Fri Apr 27, 2007 1:01 pm
Re: Good book on AVR?
Yes.I take this to mean that if I'm going to load code from an SD card, I have to write a bootloader.
Interesting question. The bootloader code certainly appears in the main application address space even after it's done running, and you should be able to CALL to functions there without any trouble. I guess your question is along the lines of whether you can fetch a block of memory in your application section, and call bootloader section code to write it to write that to the application-section flash?That in turn raises the question of whether it is possible to return to the bootloader after running an application without doing a hard reset, or do I have to resort to a hideous kludge like the one used in 286 machines to get back to real mode from virtual86. I have no idea where to run that down yet.
I suspect that this is "arcane knowledge" and not the sort of thing you'd find in any general purpose AVR book anyway; you'll have to search Atmel for app notes specifically about bootloaders. Better yet, get an arduino or a butterfly or other simple development system and just try it out...
Only if you want to copy from SD-card to AVR application program memory. And you shouldn't need assembler to write a bootloader; the arduino bootloader is written mostly in C (except for the SPM part itself, and there's a latter version that uses SPM capabilities defined in C include files so you don't even have to do that.)I am looking at putting some kind of file system on SD cards, and this would seem to require writing a bootloader using gas.
AVRdude is a CLI application that talks to a large variety of different programmers and/or bootloaders. Whether it can write to EEPROM is dependent on many things outside of AVRdude itself. (For instance, the Arduino bootloader had a bug that prevented AVRdude from writing to Arduino EEPROMs via the arduino bootloader. The bug has been fixed in more recent versions, and it was always possible to write to the arduino eeprom using the ICSP connector and a "real" programmer like stk-500...)statements that contradict each other (eg, AVRdude can/cannot program the eeprom)
-
- Posts: 67
- Joined: Sun Apr 05, 2009 11:29 am
Re: Good book on AVR?
Thanks for the reply westfw.
--
My thought was that I could check for a card present on initial boot, and if I found one I could verify it had a boot block, then read the card byte serially instead of reading from the USART. (Thus the question about AVRdude and eeprom). Basically, a bit of hand-waving and switch input devices. I have source for the current bootloader, and there is a note that one should use gcc 3 as gcc 4 generates code that is too large. So, perhaps sufficient bytes can be scrounged in assembler. And there is nothing like assembly coding to get a real sense of the processor.
Re-entering the bootloader looks to be the easiest way to load a later program (chain load, or from a selected file). Certainly so if one has to carry the overhead of FAT, though I was looking back into the mists of time at something like Forth screens. Not being a Windows user, I believe I can format with dd, and I remember that old Linux distros had a tool for writing disk images to floppies that may be adaptable. One could even go for Baroque and concatenate a FAT image in front to give normal systems something to look at.
But that is long-range. I have some arduinos and the wave shield kit. In due course UPS will bring a tinyISP, the smell of rosin will fill the air, and I shall start on the path to nerdvana...
That would explain the eeprom issue.For instance, the Arduino bootloader had a bug that prevented AVRdude from writing to Arduino EEPROMs via the arduino bootloader.
--
My thought was that I could check for a card present on initial boot, and if I found one I could verify it had a boot block, then read the card byte serially instead of reading from the USART. (Thus the question about AVRdude and eeprom). Basically, a bit of hand-waving and switch input devices. I have source for the current bootloader, and there is a note that one should use gcc 3 as gcc 4 generates code that is too large. So, perhaps sufficient bytes can be scrounged in assembler. And there is nothing like assembly coding to get a real sense of the processor.
Re-entering the bootloader looks to be the easiest way to load a later program (chain load, or from a selected file). Certainly so if one has to carry the overhead of FAT, though I was looking back into the mists of time at something like Forth screens. Not being a Windows user, I believe I can format with dd, and I remember that old Linux distros had a tool for writing disk images to floppies that may be adaptable. One could even go for Baroque and concatenate a FAT image in front to give normal systems something to look at.
But that is long-range. I have some arduinos and the wave shield kit. In due course UPS will bring a tinyISP, the smell of rosin will fill the air, and I shall start on the path to nerdvana...
Please be positive and constructive with your questions and comments.