In the new Arduino boards, the traditional FTDI USB-to-serial chip has been replaced with an Atmel ATmega8U2 chip, which has built-in USB. We'd like to do the same on the next APM board, and use this chip to do double-duty: replace the FTDI chip that's now on the IMU shield, and replace the PPM encoder chip (now an Atmega328) that's on the APM board. This will make smaller, simpler, cheaper APM boards for all going forward. And bye-bye FTDI drivers!
There should be enough memory in the Atmega8U2 for both the OptiBoot bootloader and the PPM encoder code. But we need some help in combining them in a way that each won't interfere with the other. We've got a lot of great programmers here at DIY Drones. Who's up for the challenge? (Free boards for any volunteers)
Here are some starting links.
- A tutorial on reprogramming the Atmega8u2 (you need to log into the Arduino forums to see it)
- The APM PPM encoder source code
- Details on how this chip works with Arduino: The ATmega8U2 firmware source code is available in the Arduino repository. The ATmega8U2 is loaded with a DFU bootloader, which can be activated by connecting the solder jumper on the back of the board (near the map of Italy) and then resetting the 8U2. You can then use Atmel's FLIP software (Windows) or the DFU programmer (Mac OS X and Linux) to load a new firmware. Or you can use the ISP header with an external programmer (overwriting the DFU bootloader). See this user-contributed tutorial for more information.
- The Atmega8U2 datasheet. We can move to the 16k or 32k versions if necessary
Comments
Chris & All,
I just found this thread. I also just spent a few hundred bucks on the current APM & Shield and don't think this ATmega8U2 change has been incorporated (couldn't find the info anywhere - too much of a Newbie to know where to look I guess). My question is (maybe answered multiple times elsewhere already) is the old h/w platform going to continue to be supported as new features are developed on the new platform? Actually, I should just ask the general question: As new h/w platforms come out, are us, soon to be dinosaurs, still going to be supported or will we all have to keep buying new h/w? Please don't take this question the wrong way - I think it's very cool that new h/w and s/w are continually being developed, in fact, I'd like to start working on some things myself and hope to become a valued contributor. But I just want to know what the general model is for supporting legacy equipment we've invested a lot of dough in.
Thanks much,
Dan
yup,
this is also my view.
robert
If i have this right the Bootlaoder is only for boot loading the 8U2 ie to load the usb/serial and PPM code.
The code that need combining is the usb to serial and the PPM Code.
Pete
nice,
i am interested in helping as well.
robert
@robert
The atmega8u2 USB code is designed as a data pipe between the built in USB and UART interfaces. The atmega8u2 UART is connected to the main MCU UART, replacing the FTDI USB to Serial chip used in earlier boards. So the uart is used all the time.
The PPM output generator use Timer1 (hardware PWM). And since Timer1 is unused by the USB code there should not be any conflict. Also since the PPM code is 100% interrupt driven, there is no main() code loop to conflict with the USB code.
The main challenge is both USB and PPM using Timer0 for timing (in different ways). And there and no other timers available beside Timer0 and Timer 1. So you can either try to make the timing compatible, or make the PPM code use Timer1 for both timing and PWM generation. I have a feeling the last option might be the best.
"i have troubles to understand why a lipo and usb port are challenging with regards to transparent communications."
the thing is: when I want to configure the APM I only plug in USB (USB is connected on startup, chip only needs to check once)
some people plug in a LIPO first (USB not connected at startup), so the chip has to check for USB all the time which could cause some timing trouble
@jab
okay,
also a point is the robustness of the build in usb microcode.
may also be a source of problems :)
question, is the ppm timer frequency compatible with the usb one?
maybe it is possible to integrate the functionality using one timer.
will the usart be used for communication with the larger mcu?
robert
-
1
-
2
-
3
of 3 Next