GrumpyOldPizza

The biggest flaw with standardizing on an Arduino Driver lib is precisely because it encourages people to NOT learn about the underlying hardware. As soon as they try to connect up a peripheral with a subtle difference, they get completely frustrated and complain about the lack of support for their particular sensor or application. Not everyone is like this, but it is a generalization of a broad swath of Arduino users.
 
There's nothing wrong with learning how I2C works, or how a PWM works. Once you know how they work on one micro, then you understand the fundamentals enough to code the same thing on totally different hardware.

What you are suggesting is more higher level than driverLib, which IMHO is a macro wrapper layer around the device registers. 
 
The problem with such an approach is that coming up with a good abstraction is very hard. There is no real good one-size-fits-all. A good example is ST's HAL (CubeL4 for example). It assumes some higher level locking that a RTOS could supply. The problem is that if you want to use part of the code in both the ISR and the Task/Threads, this will fall apart, and ... well ... you need something different. The Arduino abstraction is nice, but falls short on asynchronous operations. 
 
The best I have seen up to now (but admittedly not used) is Nordic Semi's SDK for nRF5, which splits up things into a HAL and into a driver layer.

I'm suggesting that they implement the most efficient Arduino API and slam it into ROM.  From what I've seen, I can mostly take any Arduino Library and make it work on most Arduino ports.
 
The problem with the driverlib implementation from my perspective is that it assumes you know a lot about the underlying hardware.  If you know that much about the hardware why would you bother to use the driverlib and worry about how someone else implemented the code or even that the code in ROM is consistent for different parts and revisions.
 
Here is one of the MSP430FR5xxx examples:
#include "driverlib.h" #define TIMER_A_PERIOD 524 #define DUTY_CYCLE 393 void main(void) { //Stop WDT WDT_A_hold(WDT_A_BASE); //P1.2 as PWM output GPIO_setAsPeripheralModuleFunctionOutputPin( GPIO_PORT_P1, GPIO_PIN2, GPIO_PRIMARY_MODULE_FUNCTION ); /* * Disable the GPIO power-on default high-impedance mode to activate * previously configured port settings */ PMM_unlockLPM5(); //Generate PWM - Timer runs in Up-Down mode Timer_A_outputPWMParam param = {0}; param.clockSource = TIMER_A_CLOCKSOURCE_SMCLK; param.clockSourceDivider = TIMER_A_CLOCKSOURCE_DIVIDER_1; param.timerPeriod = TIMER_A_PERIOD; param.compareRegister = TIMER_A_CAPTURECOMPARE_REGISTER_1; param.compareOutputMode = TIMER_A_OUTPUTMODE_RESET_SET; param.dutyCycle = DUTY_CYCLE; Timer_A_outputPWM(TIMER_A1_BASE, &param); //Enter LPM0 __bis_SR_register(LPM0_bits); //For debugger __no_operation(); } How is that abstract? If I go and grab the same example for the MSP430F55xx chips or the MSP430I2xx chips that code isn't going to work. Maybe it will compile but not work properly.  If you are a professional developer working on a project you are probably going to access the registers directly so you don't have to worry about what some chunk of ROM might or might not have.
 
If you take a look at this same "timer_a_pwm_mode" sample from the driverlib sample from the MSP432 version it looks completely different:
/* DriverLib Includes */ #include "driverlib.h" /* Standard Includes */ #include <stdint.h> #include <stdbool.h> /* Timer_A PWM Configuration Parameter */ Timer_A_PWMConfig pwmConfig = { TIMER_A_CLOCKSOURCE_SMCLK, TIMER_A_CLOCKSOURCE_DIVIDER_1, 32000, TIMER_A_CAPTURECOMPARE_REGISTER_1, TIMER_A_OUTPUTMODE_RESET_SET, 3200 }; int main(void) { /* Halting the watchdog */ MAP_WDT_A_holdTimer(); /* Setting MCLK to REFO at 128Khz for LF mode * Setting SMCLK to 64Khz */ MAP_CS_setReferenceOscillatorFrequency(CS_REFO_128KHZ); MAP_CS_initClockSignal(CS_MCLK, CS_REFOCLK_SELECT, CS_CLOCK_DIVIDER_1); MAP_CS_initClockSignal(CS_SMCLK, CS_REFOCLK_SELECT, CS_CLOCK_DIVIDER_2); MAP_PCM_setPowerState(PCM_AM_LF_VCORE0); /* Configuring GPIO2.4 as peripheral output for PWM and P6.7 for button * interrupt */ MAP_GPIO_setAsPeripheralModuleFunctionOutputPin(GPIO_PORT_P2, GPIO_PIN4, GPIO_PRIMARY_MODULE_FUNCTION); MAP_GPIO_setAsInputPinWithPullUpResistor(GPIO_PORT_P1, GPIO_PIN1); MAP_GPIO_clearInterruptFlag(GPIO_PORT_P1, GPIO_PIN1); MAP_GPIO_enableInterrupt(GPIO_PORT_P1, GPIO_PIN1); /* Configuring Timer_A to have a period of approximately 500ms and * an initial duty cycle of 10% of that (3200 ticks) */ MAP_Timer_A_generatePWM(TIMER_A0_BASE, &pwmConfig); /* Enabling interrupts and starting the watchdog timer */ MAP_Interrupt_enableInterrupt(INT_PORT1); MAP_Interrupt_enableSleepOnIsrExit(); MAP_Interrupt_enableMaster(); /* Sleeping when not in use */ while (1) { MAP_PCM_gotoLPM0(); } } /* Port1 ISR - This ISR will progressively step up the duty cycle of the PWM * on a button press */ void PORT1_IRQHandler(void) { uint32_t status = MAP_GPIO_getEnabledInterruptStatus(GPIO_PORT_P1); MAP_GPIO_clearInterruptFlag(GPIO_PORT_P1, status); if (status & GPIO_PIN1) { if(pwmConfig.dutyCycle == 28800) pwmConfig.dutyCycle = 3200; else pwmConfig.dutyCycle += 3200; MAP_Timer_A_generatePWM(TIMER_A0_BASE, &pwmConfig); } } I guess I just don't see the point of implementing a driverlib that can't be used with different chips.  Whereas the Arduino API is pretty consistent across different architectures and simple to use.  Personally, I prefer to use the chips as efficiently as possible and access registers directly.  Providing the Arduino API in rom seems more useful than the current driverlib implementation.
 
-rick

Here my 2 cents (after having used a bunch of the parts going back to the Luminary Micro days).
 
- get rid of the MSP432. It's a mess compared to other Cortex-M4 parts (yes, even low power ones). If you want a good low power part, please use the same peripherals as on TM4C, so that code can be reused.
 
- a TM4C129 Launchpad with the dimensions of the TM4C123 launchpad
 
- add CMSIS-DAP to the ARM Cortex based launchpads. Nobody really wants to see yet another vendor specific protocol like the LMICDI (not that gdb remote serial was not a nice idea, it's just it did not pan out).
 
Not sure what else to say. I fundamentally think TI took the wrong turn with MSP432, which it seems to have left to die a lonely death. Perhaps folks coming from MSP430 see that different, but it's a massive turnoff for everybody coming from more grown up microcontroller.
 
 
- Thomas

Good question. For hobby projects it's probably a non-issue. But if you want to be aggressive with power savings it is an issue. Typically i'd always attach a DMA channel to any I2C RX, and any UART RX/TX, as well as SPI RX/TX (for sensor reading up to 4MHz). For my hobby use (Autonomous Rovers), that would be 5 to 7. So, still within 8 channels, but not a lot of spares for software triggered DMA. Perhaps it's just that 16 feels like a more appropriate number (32 definitively too much).
 
Couple of use cases to illustrate:
 
(1) UART, GPS input. I'd use a ping-pong buffer scheme on RX with a receive timeout. Each of the buffers 16 bytes. This way I get an interrupt only every 16 bytes, or when a sequence of reports is done. At 115200 baud this brings the interrupt rate from about 10000 down to less than 800.
 
(2) I2C sensor reading. DMA on RX (with TI also on TX). That means I take 2 interrupts for a typical "send an index, and then read n bytes of data from a sensor". If this is 16 bytes of sensor data, then without DMA you take 19 interrupts.
 
(3) TFT on SPI. Here a double buffer scheme is nice. In one buffer you generate data for the new scanline you are working on, while using DMA on the other buffer to send over data/commands for the previous scanline that had been already generate. One can nicely overlap CPU and SPI. Of course that is not beneficial for all operations.
 
(4) SD on SPI. If you send more than one 512 byte block and want to use CRC16, then you can let the CPU compute this CRC16 on the next block you are about to send, while DMA takes care of sending the current block without CPU interaction ...
 
 
So a lot of uses, at least for me, mainly centered around communication.

Good question. For hobby projects it's probably a non-issue. But if you want to be aggressive with power savings it is an issue. Typically i'd always attach a DMA channel to any I2C RX, and any UART RX/TX, as well as SPI RX/TX (for sensor reading up to 4MHz). For my hobby use (Autonomous Rovers), that would be 5 to 7. So, still within 8 channels, but not a lot of spares for software triggered DMA. Perhaps it's just that 16 feels like a more appropriate number (32 definitively too much).
 
Couple of use cases to illustrate:
 
(1) UART, GPS input. I'd use a ping-pong buffer scheme on RX with a receive timeout. Each of the buffers 16 bytes. This way I get an interrupt only every 16 bytes, or when a sequence of reports is done. At 115200 baud this brings the interrupt rate from about 10000 down to less than 800.
 
(2) I2C sensor reading. DMA on RX (with TI also on TX). That means I take 2 interrupts for a typical "send an index, and then read n bytes of data from a sensor". If this is 16 bytes of sensor data, then without DMA you take 19 interrupts.
 
(3) TFT on SPI. Here a double buffer scheme is nice. In one buffer you generate data for the new scanline you are working on, while using DMA on the other buffer to send over data/commands for the previous scanline that had been already generate. One can nicely overlap CPU and SPI. Of course that is not beneficial for all operations.
 
(4) SD on SPI. If you send more than one 512 byte block and want to use CRC16, then you can let the CPU compute this CRC16 on the next block you are about to send, while DMA takes care of sending the current block without CPU interaction ...
 
 
So a lot of uses, at least for me, mainly centered around communication.

Actually if you design your software stack the right way, it does mean exactly that (some caveats apply though). If you need to do some CPU work in response to an external stimulus, then a M4 will do that work faster at the same clock than a M0/M0+. Consequently you can put the CPU to sleep earlier for a longer amount of time. This longer sleep time is what saves you most of the power.  The second main trick to save power is to use DMA for IO transfers, so that you can avoid waking up the CPU from a sleep mode as much as possible (there is a nice application note available from ST, which analyses where clock frequencies are the sweet spot for a given voltage range, assuming that you have to spend a fixed amount of CPU clock cycles; their result was that alway the upper limit for the voltage range was the sweet spot ...).
 
So yes the M4F core in the MSP432 make it more efficient than the MSP430 core, which means in theory it should consume less power (yes, AHB and the efficiency of the sleep modes will affect that as well). But MSP432 is missing or hampering the second cruical part, which is adding peripherals that can offload the CPU to do things like batch acquisition (or sleep-walking as Atmel calls it). 
 
It's also quite telling that the current leader in ULPbench, Ambiq Micro also chose a M4 over a M0 (http://www.extremetech.com/computing/198285-new-microprocessor-claims-10x-energy-improvement-thanks-to-subthreshold-voltage-operation this article contains some of their rationale).
 
Back to MSP432. With it's peripherals, one could argue that this is not the same target market as say a STM32L4 as you need fewer peripherals, less horsepower, and such. But that then raises the question, why upgrade the CPU core from MSP430 at all ? 
 
- Thomas

The Cortex-M4 only is not a big grief for me, probably the other way around. I like the FPU over the M3. The M0 is a nightmare, as a lot of the good debugging features that M3/M4 have get deleted on M0. Even fundamental things like the DWT_CYCCNT ... As far as I understand the M4 is also more power-efficient than M0, because it can get work done faster, after which you can put it to sleep longer. The price different, I really don't know. It's my hobby, and a few bucks either way will not hurt me.
 
The MSP430 peripherals, I simply cannot understand. The older Stellaris parts had been designed with HW FIFOs in place, so you could use UART/SPI without DMA. Of course TM4C now has a 32 channel DMA controller, where you can background a lot of the IO handling. And along comes MSP432, which does away with most of the usable HW FIFOs, and just so that the software cannot compensate, reduced the number of DMA channels to 8. If you have one UART (RX DMA), one SPI (RX/TX DMA) and one I2C (RX DMA), and half of your DMA channels are gone ...
 
Just looking at the feature set (not the crummy HW implementation), STM32L0 & STM32L4 seem to be the better choice. Not that I want promote somebody else's product here, it's just that I don't understand where MSP432 fits there (besides the fact that you still cannot buy the chips).
 
So in a nutshell, please TI, focus on TM4C, bring some new parts and launchpads, perhaps a Cortex-M0+ if that saves costs. 
 
- Thomas
 
- Thomas

Just my 2 cents here.
 
MSP432 does not seem to go anywhere, because there is STM32L476. Both devices are fairly similar in power consumption and power saving modes. But MSP432 inherited it's peripherals from MSP430, which just feel very outdated compared to STM32L476 (actually also a massive step back from TM4C). And there is just starts. The TI product goes only up to 48MHz wth 256kB flash, the ST product can go up to 80MHz with 1024kB flash. The ST product has dedicated SAI support was well as a PDM decoder for MEMS microphones ... Ah, and the ST product has a CODE/DATA cache (mislabled IMHO as ART Accelerator ;-)). The only thing that I can see the TI product having going for it is the 14bit SAR ADC. 
 
I simply suspect that either TI went back to the drawing board, or gave up.
 
Ah, and there is this issue. A TM4C123GH6PM costs $6.23 in units of 1000. A similar STM32F401 is to be had for $3.54. That implies that the TI product is probably price wise nowhere near the competition.

Just my 2 cents here.
 
MSP432 does not seem to go anywhere, because there is STM32L476. Both devices are fairly similar in power consumption and power saving modes. But MSP432 inherited it's peripherals from MSP430, which just feel very outdated compared to STM32L476 (actually also a massive step back from TM4C). And there is just starts. The TI product goes only up to 48MHz wth 256kB flash, the ST product can go up to 80MHz with 1024kB flash. The ST product has dedicated SAI support was well as a PDM decoder for MEMS microphones ... Ah, and the ST product has a CODE/DATA cache (mislabled IMHO as ART Accelerator ;-)). The only thing that I can see the TI product having going for it is the 14bit SAR ADC. 
 
I simply suspect that either TI went back to the drawing board, or gave up.
 
Ah, and there is this issue. A TM4C123GH6PM costs $6.23 in units of 1000. A similar STM32F401 is to be had for $3.54. That implies that the TI product is probably price wise nowhere near the competition.

Hi everyone,
 
Just wanted to share my flight controller I wrote some time ago
 
Here is a video of it:
 

 
The code is available here: https://github.com/Lauszus/LaunchPadFlightController.
 
You can read more about it at my blog: http://blog.tkjelectronics.dk/2015/01/launchpad-flight-controller/.
 

 
Regards
Kristian Sloth Lauszus

Yes, the LCD UI was tricky for more than one reason, but also the most rewarding. Last year we had a screwup because the display did not convey enough information. So this year I asked the two race engineers what *should* be displayed, why, how ... So we went throu a whole list of scenarios of how you could diagnose hardware malfunctioning, or software issues (like how do I know the RPM sensor is working ?) It came down to the level of "I cannot see yellow in bright sunlight". 
 
Given that the HW setup was as simple as I could get it, there were a lot of ideas my kiddos could contribute (like placement of components, wireing, io port assignment). While that sounds perhaps simple for us adults (and perhaps us engineers), it's something else for a 10 year old and a 12 year old. 
 
- Thomas

Haven't posted in a while ...
 
So there was AVC 2015. Less successfull for us (with 2 rovers this year). I was relegated to be the SW guy, while my kids actually build and run the rovers. 
 
Anyway, I thought it might be interesting to post a link to the source code that was used (which of course is utterly outdated, probably ;-)).
 
https://github.com/BizzaBoy/AVC2015-KK
 
There are a couple of interesting pieces that might be of use outside the autonomous rover domain.
 
First off the concept (besides being as cheap as possible) was to take an R/C car, a TI Launchpad, RobG's TFT/SD boosterpack, hook up a GPS, a MPU-9150, a RPM sensor, a 3 channel R/C reveiver, and 2 buttons. The TFT is displaying all status information, which is pretty handy before starting the rover, so one can see whether the GPS is actually working ;-)
 
Here some of the pieces that might be of interest:
 
- the MPU-9150 is samples at 1kHz triggered by the INT output and properly timestamped relative to a wallclock; the builtin AK8975 is sampled at 100Hz; i2c is interrupt driven
 
- the GPS code supports NMEA as well as UBLOX binary; support for GPS+GLNONASS is there; MTK3333, MTK3339, UBLOX6/7/8 are supported; full initializitation at runtime so that this can be used without backup battery or external flash that would store the configuration; ah, and there is proper timestamping via the PPS input
 
- of course there is full speed logging to a microSDHC card ... this time DMA driven to free up more processor cycles
 
- stack checking via the MPU; handy to detect stack overflows (yes, saved my backon ;-))
 
- there is a profiling system in place that buckets cycles spend on various logical tasks (like display, record, navigation ....); very handy to find out how much processor power is still left
 
- lots of interesting code; stared to play with atomics and bitband accesses
 
- the whole system is bare metal, CMSIS based; so if one looks for a CMSIS setup for TM4C123, that might be a good starting point
 
- no RTOS in use; things are either interrupt driven, or timer driver (systick callbacks), or via the PendSV exception as kind of a deferred interrupt; did this, so I could half way explain the system to my son who was running one of the rovers ;-))
 
Here a few pictures, and a link to my son's entry
 
 
 

 

 
- Thomas
 
 
 

Haven't posted in a while ...
 
So there was AVC 2015. Less successfull for us (with 2 rovers this year). I was relegated to be the SW guy, while my kids actually build and run the rovers. 
 
Anyway, I thought it might be interesting to post a link to the source code that was used (which of course is utterly outdated, probably ;-)).
 
https://github.com/BizzaBoy/AVC2015-KK
 
There are a couple of interesting pieces that might be of use outside the autonomous rover domain.
 
First off the concept (besides being as cheap as possible) was to take an R/C car, a TI Launchpad, RobG's TFT/SD boosterpack, hook up a GPS, a MPU-9150, a RPM sensor, a 3 channel R/C reveiver, and 2 buttons. The TFT is displaying all status information, which is pretty handy before starting the rover, so one can see whether the GPS is actually working ;-)
 
Here some of the pieces that might be of interest:
 
- the MPU-9150 is samples at 1kHz triggered by the INT output and properly timestamped relative to a wallclock; the builtin AK8975 is sampled at 100Hz; i2c is interrupt driven
 
- the GPS code supports NMEA as well as UBLOX binary; support for GPS+GLNONASS is there; MTK3333, MTK3339, UBLOX6/7/8 are supported; full initializitation at runtime so that this can be used without backup battery or external flash that would store the configuration; ah, and there is proper timestamping via the PPS input
 
- of course there is full speed logging to a microSDHC card ... this time DMA driven to free up more processor cycles
 
- stack checking via the MPU; handy to detect stack overflows (yes, saved my backon ;-))
 
- there is a profiling system in place that buckets cycles spend on various logical tasks (like display, record, navigation ....); very handy to find out how much processor power is still left
 
- lots of interesting code; stared to play with atomics and bitband accesses
 
- the whole system is bare metal, CMSIS based; so if one looks for a CMSIS setup for TM4C123, that might be a good starting point
 
- no RTOS in use; things are either interrupt driven, or timer driver (systick callbacks), or via the PendSV exception as kind of a deferred interrupt; did this, so I could half way explain the system to my son who was running one of the rovers ;-))
 
Here a few pictures, and a link to my son's entry
 
 
 

 

 
- Thomas
 
 
 

Haven't posted in a while ...
 
So there was AVC 2015. Less successfull for us (with 2 rovers this year). I was relegated to be the SW guy, while my kids actually build and run the rovers. 
 
Anyway, I thought it might be interesting to post a link to the source code that was used (which of course is utterly outdated, probably ;-)).
 
https://github.com/BizzaBoy/AVC2015-KK
 
There are a couple of interesting pieces that might be of use outside the autonomous rover domain.
 
First off the concept (besides being as cheap as possible) was to take an R/C car, a TI Launchpad, RobG's TFT/SD boosterpack, hook up a GPS, a MPU-9150, a RPM sensor, a 3 channel R/C reveiver, and 2 buttons. The TFT is displaying all status information, which is pretty handy before starting the rover, so one can see whether the GPS is actually working ;-)
 
Here some of the pieces that might be of interest:
 
- the MPU-9150 is samples at 1kHz triggered by the INT output and properly timestamped relative to a wallclock; the builtin AK8975 is sampled at 100Hz; i2c is interrupt driven
 
- the GPS code supports NMEA as well as UBLOX binary; support for GPS+GLNONASS is there; MTK3333, MTK3339, UBLOX6/7/8 are supported; full initializitation at runtime so that this can be used without backup battery or external flash that would store the configuration; ah, and there is proper timestamping via the PPS input
 
- of course there is full speed logging to a microSDHC card ... this time DMA driven to free up more processor cycles
 
- stack checking via the MPU; handy to detect stack overflows (yes, saved my backon ;-))
 
- there is a profiling system in place that buckets cycles spend on various logical tasks (like display, record, navigation ....); very handy to find out how much processor power is still left
 
- lots of interesting code; stared to play with atomics and bitband accesses
 
- the whole system is bare metal, CMSIS based; so if one looks for a CMSIS setup for TM4C123, that might be a good starting point
 
- no RTOS in use; things are either interrupt driven, or timer driver (systick callbacks), or via the PendSV exception as kind of a deferred interrupt; did this, so I could half way explain the system to my son who was running one of the rovers ;-))
 
Here a few pictures, and a link to my son's entry
 
 
 

 

 
- Thomas
 
 
 

Haven't posted in a while ...
 
So there was AVC 2015. Less successfull for us (with 2 rovers this year). I was relegated to be the SW guy, while my kids actually build and run the rovers. 
 
Anyway, I thought it might be interesting to post a link to the source code that was used (which of course is utterly outdated, probably ;-)).
 
https://github.com/BizzaBoy/AVC2015-KK
 
There are a couple of interesting pieces that might be of use outside the autonomous rover domain.
 
First off the concept (besides being as cheap as possible) was to take an R/C car, a TI Launchpad, RobG's TFT/SD boosterpack, hook up a GPS, a MPU-9150, a RPM sensor, a 3 channel R/C reveiver, and 2 buttons. The TFT is displaying all status information, which is pretty handy before starting the rover, so one can see whether the GPS is actually working ;-)
 
Here some of the pieces that might be of interest:
 
- the MPU-9150 is samples at 1kHz triggered by the INT output and properly timestamped relative to a wallclock; the builtin AK8975 is sampled at 100Hz; i2c is interrupt driven
 
- the GPS code supports NMEA as well as UBLOX binary; support for GPS+GLNONASS is there; MTK3333, MTK3339, UBLOX6/7/8 are supported; full initializitation at runtime so that this can be used without backup battery or external flash that would store the configuration; ah, and there is proper timestamping via the PPS input
 
- of course there is full speed logging to a microSDHC card ... this time DMA driven to free up more processor cycles
 
- stack checking via the MPU; handy to detect stack overflows (yes, saved my backon ;-))
 
- there is a profiling system in place that buckets cycles spend on various logical tasks (like display, record, navigation ....); very handy to find out how much processor power is still left
 
- lots of interesting code; stared to play with atomics and bitband accesses
 
- the whole system is bare metal, CMSIS based; so if one looks for a CMSIS setup for TM4C123, that might be a good starting point
 
- no RTOS in use; things are either interrupt driven, or timer driver (systick callbacks), or via the PendSV exception as kind of a deferred interrupt; did this, so I could half way explain the system to my son who was running one of the rovers ;-))
 
Here a few pictures, and a link to my son's entry
 
 
 

 

 
- Thomas
 
 
 

Why ? I needed a file system for a SDCARD where I could do low latency logging for some of my projects. There did not seem to be one fitting the bill. 
 
What ? RFAT is a FAT file system that is mean to be robust and fast, rather than to focus on the smallest possible size.
 
 
Here the quick link to the source for the impatient: https://github.com/BizzaBoy/RFAT
 
 
Now to some details. The source includes a port for the TM4C123GXL Launchpad, along with support for RobG's Color TFT BP. There is a simple, trivial example included that writes out 32MB of data to a file in 512 byte chunks, giving about 2MB/sec throughput with a 20MHz SPI bus.
 
The system makes full use of the CRC checking available, which means the communication path to the SDCARD is fully protected, along with logic to retry faulted transfers again. There is a transaction safe mode which makes the file system power fail safe. Of course there is VFAT support (i.e. long file names), plus UTF8 file names, if needed. The memory consumption is nicely controllable via various FAT/DIR/DATA cache options from 512 bytes to 2048 bytes. Besides the TM4C123 port, there is a simulation path, so that the API along with a SDCARD can be simulated on say a Linux host. Statistics counters are included to allow detailed analysis and cache finetuning. 
 
For low latency logging one can pre-allocate files, which means that during the real logging there are no further SDCARD accesses other than the data write accesses.
 
The API is modeled after the ANSI-C library and mirrors various commercial and freely available alternatives.
 
 
- Thomas
 
 

Why ? I needed a file system for a SDCARD where I could do low latency logging for some of my projects. There did not seem to be one fitting the bill. 
 
What ? RFAT is a FAT file system that is mean to be robust and fast, rather than to focus on the smallest possible size.
 
 
Here the quick link to the source for the impatient: https://github.com/BizzaBoy/RFAT
 
 
Now to some details. The source includes a port for the TM4C123GXL Launchpad, along with support for RobG's Color TFT BP. There is a simple, trivial example included that writes out 32MB of data to a file in 512 byte chunks, giving about 2MB/sec throughput with a 20MHz SPI bus.
 
The system makes full use of the CRC checking available, which means the communication path to the SDCARD is fully protected, along with logic to retry faulted transfers again. There is a transaction safe mode which makes the file system power fail safe. Of course there is VFAT support (i.e. long file names), plus UTF8 file names, if needed. The memory consumption is nicely controllable via various FAT/DIR/DATA cache options from 512 bytes to 2048 bytes. Besides the TM4C123 port, there is a simulation path, so that the API along with a SDCARD can be simulated on say a Linux host. Statistics counters are included to allow detailed analysis and cache finetuning. 
 
For low latency logging one can pre-allocate files, which means that during the real logging there are no further SDCARD accesses other than the data write accesses.
 
The API is modeled after the ANSI-C library and mirrors various commercial and freely available alternatives.
 
 
- Thomas
 
 

After a half way successful entry in the AVC 2014 competition I finally have the time to write a few words.
 
The rover is build upon a rather cheap RC car, that however is a very reasonable platform for the project, the Turnigy 1/16 Monster Beetle.
 

 
The core computing platform is a Stellaris Launchpad with RobG's excellent LCD booster pack, which doubles for me as LCD and microSD unit.
 
There is a GY-87 IMU, which consists of a MPU6050 Accel/Gyro and a HMC5883L Magnetometer, plus a BMP180 Bario (which I did not use, regrettably). The SW on the LM4F120 is able to read the MPU6050 at 1Khz and the HMC5883L at 75Hz (which is more than 50% of the I2C bus bandwidth). 
 
There is also a uBlox6 based GPS uint, the VK16U6 (in case you are wondering). It' operates at 4Hz update rate. Why 4Hz ? The ublox6 has an advertised max update rate of 5Hz. However at 5Hz SBAS/WAAS is not working, at least for me, and not with 12 satellites in perfect view, plus either PRN133 or PRN137 (if I recall correctly). Going back to 4Hz solved that ;-)
 

 
There is a 13 state EKF on board that is run at 250Hz (in the pre-race configuation). The path follower is a simple "Pure Pursuit", with position input, and using the magnetometer for heading estimation. The steering is done via rather simple poportional control derived from the steering error, rather than a PID ... mainly because I ran out of time programming/tuning the PID, and because it turned out to be good enough. 
 

 
The vehicle was tested at 20Mph speed and finetuned for that upper boundary. The contollering mechanism did not try to adjust the speed other than an initial gradual ramp up to top speed, and the breaking at the end. Experiments showed that flipping the vehicle in gradual turns was not an issue, and that the slippage compensated for the high speed good enough.
 
In the AVC 2014 race config we dialed the speed back to 12Mph and 15Mph respectively. We did one run using the EKF, and the subsequent runs using GPS only (with forward predicition). 
 
The downside was a mechanical failure which causes us to fail on one of the 3 rounds. He an image as to what the underlying issue was:
 

 
The vehicle jumps, but still tries to navigate in mid-air. In one of those jumps the front left C-Bracket got nuked, as the front wheels were pointing all the way left ...
 
Perhaps next year, at AVC 2015 there are more entrants using a TI Tiva ;-)
 
- Thomas
 
 

Pretty cool. Working on that for my own FAT File System as well (after I figured out why I get every now and then a 200ms delay from the SDHC Card I am using).
 
Couple of questions/comments:
 
(1) You might want to use SSI_FRF_MOTO_MODE_3. The way MODE_0 works causes an extra clock cycle to get the SCLK/MOSI lines back to idle signal levels. Hence you are running at 88% of the max throughput.
 
(2) Where does the ROM allocate the space for the uDMA control structs ? Hardcoded, or dynamic throu some wrapper ?
 
(3) Keep the drive strength at 4mA. The SD spec would actually lead you to use 8mA to get the steeper signal edges, but I have found a lot of SDHC Cards just won't work.
 
(4) In DESELECT, you might want to wait for the SSI to be idle (NOT BUSY I think was the bit to poll). There is also the other issue is that 7.5.1.1 states that the card drives the DO line at least one more clock cycle after CS goes H. So if you share the SPI bus, you need to send an extra byte after driving CS to high (RobG's TFT/SD booster pack comes to mind). Latter part is partly in the code, but it would be wise to move it into DESELECT so that after sending the dummy byte you also can wait to SSI to be idle.
 
(5) In the equivalent of disk_initialize, I found that some cards will not respond to CMD0 right away, because the SD CARD might be in a state where it is perhaps still reading or writing (due to a MCU reset). So I added a loop to allow a few retries for it to answer.
 
(6) In xmit_datablock() ... one needs to write the 16 bit CRC (or dummy it). Given that the card ignores it, and given that the last few bytes of the RAM are taken by the stack, one could simply write 514 bytes, rather than 512 ... 
 
- Thomas

Here some quick and dirty I2C/MPU6050 files. I am using bare metal, so there is not a lot of overhead. The interrupt handler and the enable/priority assignment is done by the RTOS I am using, so it's missing here. The only other RTOS feature used is that the ISR wakes up the calling task (wai_flg/set_flg). I could read the data off the MPU6050 with 1kHz sample rate.
 
Perhaps that will got you going quickly faster.
 
- Thomas
 
 
 
lm4f120_i2c.c
lm4f120_i2c.h
mpu6050.c
mpu6050.h

This code only works with TM4C1294XL launchpad, don't try it in the older TM4C123 
 
 
Hi guys so i bring you more a basic example code about peripherals. this one i also had some trouble fiding info on how to use it but notigh beats checking out the source files
If you think i should keep geting this simple but handy (i think they are) examples, tell me since i alredy have to make them for some people i know
Hope it helps someone:
/* Code made with energia-0101E0012 This code is suposed to help clarify anyone with doubts of how to use very basic fuctions of the RTC in the hibernation peripheral and also the hardware calendar mode. Any sugestions and improvements are always welcome This example only changes and show hour, minutes and seconds but there's: psTime->tm_min psTime->tm_sec psTime->tm_mon psTime->tm_mday psTime->tm_wday psTime->tm_year psTime->tm_hour */ #include "driverlib/hibernate.c" void HibernateHandler(void) { //Use this to reset interrupt flag uint32_t ui32Status = HibernateIntStatus(1); HibernateIntClear(ui32Status); //Place here code to execute every second, ex: LCD or 7 segment display //Altough it should be as fastest as possible //To keep the interrupt hapening every second you need this HibernateRTCMatchSet(0,HibernateRTCGet()+1); } /*It's need a struct pointer of the type "tm" so i use new to do that. This type of struct is defined in the driverlib/hibernation you could also create it like this: tm temp; and then use &temp and temp.values in the fuctions */ tm *temp = new tm; void setup() { Serial.begin(9600); // put your setup code here, to run once: //Enable Hibernate peripheral. I'm using Energia so i use F_CPU for geting the clock frequency HibernateEnableExpClk(F_CPU); HibernateRTCEnable(); //We set a interrupt for the RTC after second. You can change the value HibernateRTCMatchSet(0,HibernateRTCGet()+1); HibernateIntRegister(HibernateHandler); HibernateIntEnable(HIBERNATE_INT_RTC_MATCH_0); //Set up calender mode. HibernateCounterMode() is always needed but can be set to 12hr mode HibernateCounterMode(HIBERNATE_COUNTER_24HR); HibernateCalendarSet(temp); //<-- the struct declared //We change the hour, minutes and seconds temp->tm_hour= 23; temp->tm_min=59; temp->tm_sec = 50; //This fuction below is what actualy updates the values inside the peripheral. //if you don't use it, the value changes above won't do anytigh HibernateCalendarSet(temp); } void loop() { //This is to take the "live" values that the RTC keeps updating into our struct HibernateCalendarGet(temp); Serial.print(temp->tm_hour); Serial.print(':'); Serial.print(temp->tm_min); Serial.print(':'); Serial.println(temp->tm_sec); delay(1000); }

I've finally gotten around to documenting the Cardboard Hovercraft build to such a detail that anyone else can build one.

Since it has a bluetooth/wireless control component, I'll be documenting it at hackaday.io