jon1426459908

It's pretty much the bare minimum level of security required for the IoT thing to take off (which only precedes many other considerations!). Now that you have a dedicated crypto engine, there is no [ostensible] extra load on the MCU for encryption, and in turn no reason not to use it for communicating over the net.

I have just started looking into this after receiving the new EXL board. Here's are some tutorials on building the wolfSSL library for TI-RTOS: http://processors.wiki.ti.com/index.php/Using_wolfSSL_with_TI-RTOS https://github.com/wolfSSL/wolfssl-examples/tree/master/tirtos_ccs_examples

Another update, in the form of a feature branch. I used the scatter-gather functionality to consolidate the token, block buffer write, and CRC into a single DMA call. Again, this is pretty experimental and I haven't yet consulted the SD spec to see just how many rules I am breaking, but it works and is cool to see in action. Next on the list (apart from implementing the corresponding read functionality) will be to move the 'buff += 512' for multiblock transmissions out of disk_write() and into the interrupt handler.

I think ultimately it will come down to actual benchmarking numbers, particularly considering the time it takes to set up DMA vs the benefits of not needing the MCU for the transfer. In the case of dma_memcpy, IIRC DMA didn't make practical sense until around 6-8k transfer sizes. I feel the same is true for FatFs, at least for the code in its present state.. but the appeal of (nearly) MCU-less SD card transfers is too great to ignore. I haven't found it in the official spec and haven't tested it personally, but according to ChaN ('Cosideration on Multi-slave Configuration') you can

Hi Thomas, thanks for the response! To be honest, I haven't looked too closely at the existing TI code (mainly just set on getting DMA working), but I'll definitely test your suggestions after I get RX running. That's one omission that I really need to figure out. On a different project (dma_memcpy) I chose to put the control structure within the driver file itself, but it didn't make the software very modular. In this case I have left out the sample test project containing the uDMA control structure (for now), along with the monolithic interrupt vector definitions which is also

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 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

I forgot that there is a similarly-named variable in the CCS Build Variables section, separate from the Linked Resources Path Variables. So in order to update a project which uses Tivaware, both variables need to be updated manually. Fixed now.

Hi all, I just recently updated my dev environment to CCS 5.5 and Tivaware 2.1, which forced me to change the project environment variables accordingly. The variables listed in Linked Resources resolve fine, but this does not carry over to my include paths, which still list the old directories in the project explorer. Does anyone know how to fix this, short of creating an entirely new project? Thanks, Jon

Just bought one last night, the specs look great!

On related note, has anyone encountered the "line 67: error #10099-D: program will not fit into available memory" linker error? I'm trying to build a FreeRTOS-based project which uses FatFS and a few tasks, but something seems amiss.

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

I assume the free license also works for all LM4F MCUs? I worry more about being tied to a particular MCU than dev board As an aside, this thread talks about what I was originally interested in, which compiler people have had the most luck using in continued development-- http://forum.stellarisiti.com/topic/491-which-compiler-i-should-to-use/ Eventually it would be nice to migrate to a bare Eclipse+GCC setup. I have thus been unsuccessful in even getting the CCS plugin to work with an existing Eclipse install, let alone trying to get a completely different compiler up and runnin

Ah, you are correct. I had installed ccs v5.2 only a couple days before v5.3 came out, and don't remember seeing that 'free' license which is now offered in the latest version. Up and running again, thanks! Jon