Reputation Activity

Ok so this was an idea that came to mind last night; These datasheets and related documents are huge, and sometimes have surprising & interesting details nestled into their labyrinth-like chapters. Why not start a thread for sharing noteworthy details? No need to be a pack of lone wolves about these things...

Reading through Chapter 2 yesterday, "The Cortex-M4F Processor", a few details stuck out that I hadn't realized before-

1. Didn't realize there is a 16-bit SIMD vector processing unit. How do you access/use it from GCC I wonder?

2. Debug - SWV, Serial Wire Viewer, is a feature where you can export a stream of software-generated messages, data trace, profiling information. Software-generated messages -- How do we access that? I assume we need OpenOCD to use this feature, but is there an API for writing to this debug interface?

3. Like most complicated processors, there is a notion of "privileged" vs "unprivileged" execution modes. The Cortex-M4F extends this further by declaring two operational modes too--"Thread" mode (i.e. normal application runtime, either privileged or unprivileged) and "Handler" mode, exclusively privileged and only available as the context for ISR handlers.

4. Coming from MSP430 land, I'm always looking for analogies to the MSP430 in here. The equivalent for the "GIE" (global interrupt enable) bit is the PRIMASK register; when bit0 is set, it disables all interrupts (of configurable priority, so RESET/NMI/Fault interrupts still fire). This is important for sleep modes below...

5. Interrupt priorities run from 0-7, with *lower* numbers being of "higher" priority. Default priority for all interrupts is 0 (the highest). BASEPRI register declares the minimum priority required to fire, and besides setting 0 (=no exceptions masked), the setting masks all interrupts of that priority and those higher in number ("lower" in priority).

6. The CONTROL register has an interesting bit, "FPCA", which will adjust the latency for entering an interrupt ISR; it determines whether or not the Floating Point Unit's registers should be pushed onto the stack during ISR entry or not. This makes a substantial difference, as seen on page 109; the difference between FPCA=1 exception frame and FPCA=0 exception frame is many-fold. So folks not using floating point would do well to keep that disabled (not 100% sure how GCC handles this yet, i.e. whether there's a builtin, a TivaWare ROM_* function or if you have to do an inline ASM code).

7. Bit-banding is available for everything; flash, SRAM, peripherals. I think TivaWare has some macros to make that easy, need to look into it. It's a feature for doing single atomic writes or reads to a single bit of any byte in the address space, by writing/reading a 32-bit word (0x00000000 for bit 0, 0x00000001 for 1).

8. The Cortex-M4F provides two user IRQs for operating system support; SVCall (Supervisor Call) and PendSV (pendable, interrupt-driven request for system-level service--typically used for context switching).

9. Sleep modes. The Cortex-M4F uses instruction-based sleep entries, but it has some features that allow the MSP430's "event driven" paradigm too.
9a. WFI = Wait For Interrupt, goes to sleep and will wake up only if an unmasked interrupt occurs.
** Sometimes waking requires a common "clean-up" or reinitialization routine to run; to support this, your app would enter WFI inside an idle loop with PRIMASK enabled so that the CPU wakes up, but does not enter the ISR right away; does its cleanup work; then disables PRIMASK so the Cortex immediately jumps to the highest-priority IRQ's ISR.
9b. WFE = Wait For Event, goes to sleep and will wake up if ANY interrupt occurs, even if it's masked; If it is masked, the CPU will not branch to its ISR but just continue from the point where the WFE instruction occurred. If it is unmasked, then the CPU will jump to the ISR immediately.
9c. Sleep-on-Exit; if the SLEEPEXIT bit of SYSCTRL is set, then the CPU will return to sleep mode after servicing ISRs. Similar to MSP430's LPM modes if the ISR does not issue a __bic_SR_register_on_exit(LPMx_bits); type of call.

+1 , its like ... "Hi ... I'm nobody, just create a new hang out place for Tiva C/ Stellaris launchpad community, I don't have anything special to offer, its you that have to contribute first, join us"

I had a 128x64 Noritake VFD display at work, which is currently not being used. Did an extensive search for a driver until I found one by Henri Skippari. Code was ported from a a PIC16F877. Took a couple of hours for me to port and wire it up.

Hello all,
Today I am going to share a library of mine that I just developed it recently. For any inputs/ideas/thoughts/bug reports, I am very welcome . I might also update my library whenever there is any request.
Hardware needed:
1. Stellarpad
2. MAX7219 / MAX7221 system with 8x8 led.
This library interfaces with Maxim integrated MAX7219 whose interface is also compatible with MAX7221. I ve also included two examples. The first one is just to put random pattern on the 8x8 led. The second one is to cycle through all characters that I also included in font.h
I hope this contribution is meaningful
Best Regards,
Eryacard
Example1: Random Pattern

Also in the new datasheet for TM4C123GH6PM (available thru TI site) used in this new Tiva Launchpad, stated it is identical to LM4F230H5QR, go figure. So now it has built in PWM and QEI module that Stellaris Launchpad doesn't have since its using lower end chip LM4F120H5QR.

Just got the 2 new ones , also LX chips.
But i never would have guessed they they were that hancicapped :-(
http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/t/233624.aspx

If you download the full StellarisWare package http://www.ti.com/tool/sw-lm3s you should be easily able to port the usb_dev_mouse example from the EK-LM3S9D90 or EK-LM3S9D92 (for this example they are identical). The primary USB difference between the LM3S9D9x and the LM4F120H5QR is that the LM4F uses muxing on the GPIO / USB pins. The LM3S9D9x had dedicated USB pins. To make the examples work configure the GPIO pin muxing for USB mode near the beginning of your code. Something like the below should get you pretty close.

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); // enable the GPIO port so we can configure it
GPIOPinTypeUSBAnalog(GPIO_PORTD_BASE, GPIO_PIN_4 | GPIO_PIN_5); // setup the port to be in USB analog mode. Routes incoming signals to on chip USB PHY
USBStackModeSet(0, USB_MODE_FORCE_DEVICE, 0); // Tells the USB stack to always be a device. Needed since some Stellaris devices running same software stack can be OTG or Host and this chip doesn't have a VBUS pin.