Post by feilipu on Jan 18, 2014 17:18:10 GMT -8
I've built an alternative library for driving the Gameduino2, derived from the example C driver code provided by FTDI.
The library is available as part of my AVR ATmega freeRTOS code base, which can be found on AVRfreeRTOS on Sourceforge.
Why do this? Well many reasons, many of which are related to the power and simplicity of the freeRTOS code model.
freeRTOS is a high integrity RTOS, that can be used by anyone with Arduino hardware, and is completely Open Source.
The Arduino code as an "operating system" is flawed, as it lack functionality (tasks, queues, semaphores, non-blocking timers, etc).
Specifically to the Gameduino2, FTDI have provided drivers that cleanly layer the code into
Some things I've removed from the FTDI drivers, such as the Command Buffer Optimisation code. The ATmega SPI bus runs at SYSCLK/2, which means there is little gain from assembling commands into a buffer before transmitting them on the SPI bus. Also, there is typically not enough RAM in an ATmega to justify a 4kB command buffer.
The code is very usable for a first release.
I've made a short video showing some of the APIs being exercised by an example application.
The hardware I'm using as a platform is the Goldilocks 1284p. Which is an Arduino Uno compatible device with an ATmega1284p MCU.
This MCU has 16kB of RAM and 128kB of flash and, most importantly, supports the Pre-R3 Uno SPI pins.
This means Gameduino2 works without any hacking or soldering.
The library is available as part of my AVR ATmega freeRTOS code base, which can be found on AVRfreeRTOS on Sourceforge.
Why do this? Well many reasons, many of which are related to the power and simplicity of the freeRTOS code model.
freeRTOS is a high integrity RTOS, that can be used by anyone with Arduino hardware, and is completely Open Source.
The Arduino code as an "operating system" is flawed, as it lack functionality (tasks, queues, semaphores, non-blocking timers, etc).
Specifically to the Gameduino2, FTDI have provided drivers that cleanly layer the code into
- a HAL, which I have optimised to use multi-byte SPI transfers and utilise the RAM saving PROGMEM capabilities of avr-libc wherever possible,
- a FT800 Command layer, which is almost identical to the FTDI provided code, for easy maintenance,
- and example API code, also provided by FTDI, which can be added or deleted from individual builds depending on which APIs are needed.
Some things I've removed from the FTDI drivers, such as the Command Buffer Optimisation code. The ATmega SPI bus runs at SYSCLK/2, which means there is little gain from assembling commands into a buffer before transmitting them on the SPI bus. Also, there is typically not enough RAM in an ATmega to justify a 4kB command buffer.
The code is very usable for a first release.
I've made a short video showing some of the APIs being exercised by an example application.
The hardware I'm using as a platform is the Goldilocks 1284p. Which is an Arduino Uno compatible device with an ATmega1284p MCU.
This MCU has 16kB of RAM and 128kB of flash and, most importantly, supports the Pre-R3 Uno SPI pins.
This means Gameduino2 works without any hacking or soldering.
