jon1426459908

Hi guys!
 
So i made a blog. Since i am the only in the robotics club that uses TI devices i was asked to teach about the Tiva. Well, what i can at least. And I'll post in the blog all the codes and tutorials.
 
It's still very early under-construction and will be something i will be doing along the school year. I am teaching it to some colleagues and will before the sessions, post the tutorials and some codes, but also post more codes after as examples. I will post basic info about the peripherals.
 
I hope it helps anyone that needs it. Also any feedback is appreciated, teaching someone live is different and i can forget some details while writing. Also i never done something like this, i usually do give lots of explanations but always live and more exercise driven.
 
Blog:
https://sites.google.com/site/luiselectronicprojects/tutorials

https://github.com/jmagnuson/fatfs-tiva-cm4f/blob/master/src/third_party/fatfs/port/mmc-tiva-cm4f.c
 
It's still a work in progress, but should be a working drop-in replacement for the MMC driver TI provides.  I've only done minimal testing on it thus far, so any corrections or improvements would be greatly appreciated!

https://github.com/jmagnuson/fatfs-tiva-cm4f/blob/master/src/third_party/fatfs/port/mmc-tiva-cm4f.c
 
It's still a work in progress, but should be a working drop-in replacement for the MMC driver TI provides.  I've only done minimal testing on it thus far, so any corrections or improvements would be greatly appreciated!

Have you tried using exclusive load/stores?  Something like:
while(__strex((__ldrex(&events)|EVENTS),&events)); using intrinsics supplied by CCS.. not sure what would be the equivalent for GCC, other than simply inlining the assembly.

As noted in the previous post, a primary value of bit-band for user memory is to record an event in a flag variable without risking a race condition. Finding myself using this idiom inside an interrupt handler where it wasn't necessary I wanted to see whether I was decreasing code size or improving performance by doing so.
 
Compiler: gcc version 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641] (GNU Tools for ARM Embedded Processors)
 
Optimization-related flags: -ggdb -Os -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
 
A Read-Modify-Write update of a single bit in a SRAM variable produces this code:

34:main.c **** events |= EVENT; 36 0002 054A ldr r2, .L2+4 41 0006 1068 ldr r0, [r2] /* BEGIN RACE CONDITION */ 42 0008 40F01000 orr r0, r0, #16 43 000c 1060 str r0, [r2] /* END RACE CONDITION */ which executes in 7 cycles (including 1 cycle overhead reading the cycle counter) on a TM4C123GH6PM. (NB: I removed from the listing the instruction at offset zero that read the cycle counter). 
The bitband update produces this code:

45:main.c **** BSPACM_CORE_BITBAND_SRAM32(events, EVENT_S) = 1; 73 0000 0549 ldr r1, .L5 77 0004 4901 lsls r1, r1, #5 78 0006 01F10851 add r1, r1, #570425344 /* 0x22000000 */ 79 000a 0120 movs r0, #1 which executes in 6 cycles. (Cycle counter read at offset 2 removed from listing.) 
So: No difference in code size, one cycle timing difference. No clear reason to pick one over the other for performance reasons.
 
Full code (which will also eventually show up in BSPACM). There is no performance difference between inline and outline code; both were included to ensure previous use of the address of events within the function didn't affect the timing.

/* BSPACM - misc/bitband demonstration application * * Written in 2014 by Peter A. Bigot <http://pabigot.github.io/bspacm/> * * To the extent possible under law, the author(s) have dedicated all * copyright and related and neighboring rights to this software to * the public domain worldwide. This software is distributed without * any warranty. * * You should have received a copy of the CC0 Public Domain Dedication * along with this software. If not, see * <http://creativecommons.org/publicdomain/zero/1.0/>. */ /* Evaluate performance of a read-modify-write sequence to set a * single bit in an event mask versus a bitband assignment. */ #include <bspacm/core.h> #include <stdio.h> #define EVENT_S 4 #define EVENT (1U << EVENT_S) volatile unsigned int events; unsigned int rmw_set () { unsigned int t0; unsigned int t1; t0 = BSPACM_CORE_CYCCNT(); events |= EVENT; t1 = BSPACM_CORE_CYCCNT(); return t1-t0; } unsigned int bitband_set () { unsigned int t0; unsigned int t1; t0 = BSPACM_CORE_CYCCNT(); BSPACM_CORE_BITBAND_SRAM32(events, EVENT_S) = 1; t1 = BSPACM_CORE_CYCCNT(); return t1-t0; } void main () { unsigned int t0; unsigned int t1; unsigned int cycles; BSPACM_CORE_ENABLE_INTERRUPT(); printf("\n" __DATE__ " " __TIME__ "\n"); printf("System clock %lu Hz\n", SystemCoreClock); BSPACM_CORE_ENABLE_CYCCNT(); events = 0; t0 = BSPACM_CORE_CYCCNT(); events |= EVENT; t1 = BSPACM_CORE_CYCCNT(); printf("Inline RMW %x took %u cycles including overhead\n", events, t1-t0); events = 0; t0 = BSPACM_CORE_CYCCNT(); BSPACM_CORE_BITBAND_SRAM32(events, EVENT_S) = 1; t1 = BSPACM_CORE_CYCCNT(); printf("Inline BITBAND %x took %u cycles including overhead\n", events, t1-t0); events = 0; cycles = rmw_set(); printf("Outline RMW %x took %u cyclesincluding overhead\n", events, cycles); events = 0; cycles = bitband_set(); printf("Outline BITBAND %x took %u cycles including overhead\n", events, cycles); t0 = BSPACM_CORE_CYCCNT(); t1 = BSPACM_CORE_CYCCNT(); printf("Timing overhead %u cycles\n", t1-t0); }

But this is not true. AFSEL is a single register that is not accessed using bitbanding: the TivaWare code that implements the equivalent to the CMSIS operation is:
HWREG(ui32Port + GPIO_O_AFSEL) = ((ui32PinIO & 2) ? (HWREG(ui32Port + GPIO_O_AFSEL) | ui8Pins) : (HWREG(ui32Port + GPIO_O_AFSEL) & ~(ui8Pins))); Which is just as much an RMW operation as the CMSIS version. 
Bit-banding is relevant for operations on a GPIO DATA register, which is (in the CMSIS-based modification I used) declared as an array, and:

GPIOF->DATA[GPIO_PIN_2 | GPIO_PIN_6] = 0xFF does use bit-banding and only affects pins 2 and 6. 
My example showed that CMSIS is smaller and faster, because TivaWare involves function calls into ROM for operations that should be inlined. Thus the price of using the vendor's custom library is code size and execution time.
 
I absolutely think there is a value in vendor-provided functions that go beyond simple peripheral register manipulations to provide higher-level functions. Much of driverlib does not meet this level of functionality, and is simply bloated and obscure.
 
I didn't mean to imply that use of a CMSIS-based peripheral gives you portability across Cortex-M chips; it certainly does not, as peripherals are explicitly open to variation by the silicon vendor. What it does give you is a common programming model that is re-usable: you manipulate Cortex-M peripheral and MCU registers with C language expressions involving pointers to mapped registers, not through vendor-specific function calls. The available registers, and how they're used, are specific to a particular peripheral implementation, but that variation is not nearly so large as whether it's spelled GPIO_PinOutSet(port, pin) as in emlib or GPIOPinWrite(port, pin, value) as in TivaWare.
 
This is the heart of a discussion on this topic elsewhere. The answer is that in most cases yes, you should suck it up and use them, even when they're demonstrably poor, because re-implementing them is a boatload of work and makes you incompatible with other people targeting the same chips. 
But when the vendor is promoting their product as an ARM Cortex-M chip, but does not support the ARM standard interface designed for Cortex-M chips as other vendors do, this is IMO poor practice, and is enough to drive me to vendors that are more willing to cooperate within the ecosystem that they have chosen to join.

As for SIMD, get the CMSIS library from Arm.  It provides intrinsics for SIMD, along with other useful libraries.
 
Also straight from Arm, two essential documents about the Cortex M4 series--
 
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439d/DDI0439D_cortex_m4_processor_r0p1_trm.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf

Is it stable before the Euler conversion?
 
http://www.diydrones.com/forum/topics/madgwick-imu-ahrs-and-fast-inverse-square-root
http://stackoverflow.com/questions/5577334/strange-behavior-with-android-orientation-sensor/5578867#5578867