While I am wrangling with the appropriate board design, I needed to get started working with the underlying software so I ran up one of the six samples I was able to get from Cascade on a tqfp adapter from measure explorer.
The AtMega32U4 http://www.atmel.com/dyn/products/product_card.asp?part_id=4317 is the midrange model in the atmel usb chipset. It follows a new standard naming convention that atmel is adapting U for Usb 4 is for the 40 pins 32k, there is another 32K part the U6 which has the same pinouts as the 90usb646/647/1286/1287. The U4 does not have a legacy pinout however the q1000 price for this board is around $2 which makes it a very powerful chip for the money.
Dfu-Programmer.
There is a recent release of dfu-programmer (0.4.6) but it seems that they havent read the atmel doc on the signatures for the dfu recently. http://www.atmel.com/dyn/resources/prod_documents/doc7618.pdf recently.
I need to check the memory and eeprom sizes against the datasheets for the parts. However the table in arguments.c should have the following entries; added new parts, corrected 64x and 82 signatures. (I will resubmit this patch).
/* ----- target specific structures ----------------------------------------- */ /* { "name", value, ,device_type, chipID,VID , MemSize,FPSize,abt,ifclass,eepgsz,eepmemsz} */ static struct target_mapping_structure target_map[] = { { "at89c51snd1c", tar_at89c51snd1c, device_8051, 0x2FFF, 0x03eb, 0x10000, 128, false, true, 0, 0 }, { "at89c5130", tar_at89c5130, device_8051, 0x2FFD, 0x03eb, 0x04000, 128, false, true, 128, 0x03FF }, { "at89c5131", tar_at89c5131, device_8051, 0x2FFD, 0x03eb, 0x08000, 128, false, true, 128, 0x03FF }, { "at89c5132", tar_at89c5132, device_8051, 0x2FFF, 0x03eb, 0x10000, 128, false, true, 0, 0 }, { "at90usb1287", tar_at90usb1287, device_AVR, 0x2FFB, 0x03eb, 0x1F000, 128, true, false, 128, 0x0FFF }, { "at90usb1286", tar_at90usb1286, device_AVR, 0x2FFB, 0x03eb, 0x1F000, 128, true, false, 128, 0x0FFF }, { "at90usb647", tar_at90usb647, device_AVR, 0x2FF9, 0x03eb, 0x0F000, 128, true, false, 128, 0x07FF }, { "at90usb646", tar_at90usb646, device_AVR, 0x2FF9, 0x03eb, 0x0F000, 128, true, false, 128, 0x07FF }, { "atmega32U6", tar_atMega32u6, device_AVR, 0x2FFB, 0x03eb, 0x07000, 128, true, false, 128, 0x03FF }, { "atmega32U4", tar_atMega32u4, device_AVR, 0x2FF4, 0x03eb, 0x07000, 128, true, false, 128, 0x03FF }, { "atmega16U4", tar_atMega16u4, device_AVR, 0x2FF3, 0x03eb, 0x03000, 128, true, false, 128, 0x01FF }, { "at90usb162", tar_at90usb162, device_AVR, 0x2FFA, 0x03eb, 0x03000, 128, true, false, 128, 0x01FF }, { "at90usb82", tar_at90usb82, device_AVR, 0x2FF7, 0x03eb, 0x01000, 128, true, false, 128, 0x01FF }, { NULL } };
Then we test.
static dfu-programmer atMega32U4 get bootloader-version --debug 20 target: atMega32U4 chip_id: 0x2ff4 vendor_id: 0x03eb command: get quiet: false debug: 20 device_type: AVR ------ command specific below ------ name: 0 Bootloader Version: 0x00 (0)
(after reading the datasheets for the 3 classes of avr usb chips and looking at the way that the avr-gcc library calls the cpu names there are some changes to the above that I will post later.)
Next up some code.
Tried running up the midiGate software that I wrote last week and found my first bug for the chip in avr-libc
UBRR1 is redefined in iom32u4.h
#define UBRR1 _SFR_MEM16(0xCC) #define UBRR1L _SFR_MEM8(0xCC) #define UBRR0 0 #define UBRR1 1 ...
Which results in lvalue errors errors when trying to set the register to a given value. Setting the bit values as in some of the other registers seems to resolve this issue.
#define UBRR1 _SFR_MEM16(0xCC) #define UBRR1L _SFR_MEM8(0xCC) #define UBRR_0 0 #define UBRR_1 1 #define UBRR_2 2 #define UBRR_3 3 #define UBRR_4 4 #define UBRR_5 5 #define UBRR_6 6 #define UBRR_7 7 #define UBRR1H _SFR_MEM8(0xCD) #define UBRR_8 0 #define UBRR_9 1 #define UBRR_10 2 #define UBRR_11 3
This is a pretty braindead error so I am sure that its been resolved by now. I need to see if it is fixed in 1.6.3 or the current release candidate (since AvrMacPack is out of sync and has 1.6.2) And yes this is the case.
We have a device!!!
Fix(ing) it!
Both of these issues were easy enough to fix within the source of the utilities but to make it possible for everyone else to use the new chips some body needs to Fix it! So I went about looking up the chain to get these issues resolved over the long run.
Dfu Programmer.
dfu-programmer is a source forge project so I logged an error through the sourceforge project page. https://sourceforge.net/tracker2/?atid=767783&group_id=147246&func=browse A new release has been made (0.5.0) which resolves the issue above.
Avr-Libc
Since avr-libc is a savanaha project and so making bug requests is a little different. http://savannah.nongnu.org/bugs/?group=avr-libc Fortunately (sort of) I had already been around the buggier parts of the release in question (1.6.2) when I first ran up the at90usb647. When Eric Weddington released the June rev of WinAvr (with avr-libc 1.6.3) I thought I had seen the last of it as obdev released the coresponding AvrMacPack. The bug noted above was fixed in 1.6.3 and I was able to verify that using my windows vmware session. For some reason this was not the case and AvrMacPack went out with the buggy (for this new chip anyway) libc. I filed a bug report with obdev and followed up with Christian from obdev and Eric until the version descrepency was resolved. The new version of WinAvr just came out and I am waiting to verify that the AvrMacPack version matches WinAvr.
If you are running linux plan on building from source and patching as in the script kept current at avrfreaks (you will need to log in) . http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631&start=0&postdays=0&postorder=asc&highlight= This script has not been updated for the latest winavr but it should at least give you a version above 1.6.2.
lozinski
Could I get a copy of your design files please?
I am new to this whole electronics thing, and I think it would be so much easier to start with an exiting design.
Regards
Chris
don
I am very sorry, This particular work is part of an active product development. However I will post the eagle libraries for the Mega34u4. The schematic above is very straight forward and the minimal components required to make atmel’s avr usb chips makes them very easy to design around.