atmega32u2 accessing multiple codes

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been working with an atmega32u2 and I have 4 separate projects. Because USB (LUFA)  is not truly dynamic I have to load on an as needs bassists. I'd like to experiment with the idea of having multiple codes from the boot loader. Would I need a custom boot loader and can it access multiple locations based on a jumper config of sorts or can I do this with the avr dfu bootloader? Or maybe I could use LUFA dynamically but I tend to bought that.

Last Edited: Sat. Jan 12, 2019 - 01:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The usual issue with "multiple programs" in one AVR is the vector table - there is only one of these and it's in a fixed location. If you can afford the overhead you can have all the vectors use a RAM based target address then each "program" can fill in the vectors to go to its own copy of the handlers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could one store the vector in eeprom, force a reboot, have the bootloader jump to the normal vector stored in the table, and then jump out to where eeprom says to go?

[dfu boot]->jump to vector location -> read eeprom location ->jump to the location that was read out of eeprom.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I suppose you could but it sounds slow and cumbersome compared to RAM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good point. I guess managing the code size(S) will be a pain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One way to approach this is simply to divide the flash into 4 equal lumps and build each "program" to sit on each boundary. Actually make it 5 lumps because you need a master/control section to handle things like these shared interrupts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah that was my initial thoughts, but some will grow beyond and some may remain short. Though that is unavoidable but what I wonder is shared resources.  For example the LUFA code. However I don't see an easy way to achieve that. I could put some of the USB descriptors in PROGMEM.

 

Another thought is to load the descriptor data in from EEPROM. The main code could copy the versions in and force a reboot to load them. I believe this is all that will change from one code to the next.

Last Edited: Fri. Jan 11, 2019 - 05:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If four programs are sufficient, two bits in range of SBIC could do the trick.

Each program could have to put its vector table in a standard place,

not necessarily contiguous with the rest of it.

Each "real" ISR would consist of 3 skips, 1 RJMP

and four jumps into pseudo-vector tables.

I think it would add up tp 9 cycles to the latency.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I have 5 or 6 codes I need to make work. 

 

usb_N

USB_X1

ISB_X2

USB_P

USB_H

General.

 

The USB codes are all small (maybe 11% tops with the LUFA still working on the sizes. ), the remainder would need to go to the General. 

 

 

32k flash to work with

 

General  ideally needs to be big and may end up going on its own firmware depending on the usb size. 

LUFA+ usb_N ( x + 2k )

LUFA+ USB_X1( x + 3k )

LUFA+ USB_X2( x + 4k )

LUFA+ USB_P( x + 2k )

LUFA+ USB_H( x + 2k ) //unknown but guessing 2

 

Still unsure what LUFA requires but that may add up fast. I did see one guy posted it hit 4k flash with a few lines of example code.  That would put each usb at or under 8k.  Still thinking about the descriptor eeprom thing, that may be my best option. 

 

Are avrs memory pages like other MCU's where you need to use a page 5k, 5k, 5k, 10, 20, 25,  40, or like? I have not looked at the 32u2 memory map yet. I just know working with ARM bootloaders, you have to jump to a page and it gets wasteful fast. 

 

 

 

Last Edited: Sat. Jan 12, 2019 - 01:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The page size granularity is SPM_PAGESIZE and is 32, 64 or 128 bytes in most AVRs