dellwoodbu

The Stellaris GPIOS connect to the core through both the APB and the AHB busses.  The AHB is faster.
 
Use SysCtlGPIOAHBEnable to enable the port you want.  Then for absolute fastest toggle use HWREG(AHB BASE ADDRESS + (pin mask << 2)) = GPIO_PIN_x; // or zero.
 
The pin mask is a feature of stellaris that allows you to add an offset to the base address which becomes a pin mask.  You can then write a single pin of a GPIO port without doing a read modify write.  The hardware only twiddles the pins that set in the mask value.  The right shift by 2 makes each pin mask a unique 32 bit address to write to.
 
I believe with this method you can get a GPIO state change every 2 system clock cycles.  20 Mhz square wave from an 80 Mhz part.
 
Using the Timers in PWM mode is often a better way to make these high speed signals.
 
Also be aware that Stellaris has selectable GPIO drive strength.  Default is 2 milliamps.  Max is 8mA.  To go this fast you may need to up the drive strength.  I know high drive strength is need when doing very high speed SPI signals on the chip.

Worth noting...
 
The floating point unit is single precision.  C/C++ language defaults to a double for constants in code (that include a decimal point).  Unless you need double precision constants i always suffix all my constants with 'f'.
 
So "3.141f"  is more efficient on this machine than "3.141".  

It also includes support for the new EK-TM4C1294XL Connected LaunchPad.  Out of the box cloud connected.
 
Support with working examples for CC3000 on EK-TM4C123GXL and the new Connected LaunchPad.  
 
NFC support on the boost-dlptrf7970abp with both launchpads
 
Built in support with examples for the QVGA 3.5" Kentec BoosterPack on the new Connected LaunchPad.
 
Built in support and example for the boostxl-battpack Battery Booster.
 
Probably missing some other good stuff that i am currently forgetting as well.
 
 
Dellwood.

It also includes support for the new EK-TM4C1294XL Connected LaunchPad.  Out of the box cloud connected.
 
Support with working examples for CC3000 on EK-TM4C123GXL and the new Connected LaunchPad.  
 
NFC support on the boost-dlptrf7970abp with both launchpads
 
Built in support with examples for the QVGA 3.5" Kentec BoosterPack on the new Connected LaunchPad.
 
Built in support and example for the boostxl-battpack Battery Booster.
 
Probably missing some other good stuff that i am currently forgetting as well.
 
 
Dellwood.

It also includes support for the new EK-TM4C1294XL Connected LaunchPad.  Out of the box cloud connected.
 
Support with working examples for CC3000 on EK-TM4C123GXL and the new Connected LaunchPad.  
 
NFC support on the boost-dlptrf7970abp with both launchpads
 
Built in support with examples for the QVGA 3.5" Kentec BoosterPack on the new Connected LaunchPad.
 
Built in support and example for the boostxl-battpack Battery Booster.
 
Probably missing some other good stuff that i am currently forgetting as well.
 
 
Dellwood.

The transistors have 10 k built in series and pull down resistance.  If you are using PF1 - PF3 as an output no action is required.
 
 If using as an PF1 - PF3 as an input you need to evaluate if your drive signal can overcome the pull down resistance created by the transistor built in resistance.

The Wiki has a how-to document for debugging the board with an external JTAG adapter.  The still working LaunchPad could be used as the JTAG adapter in this case.
 
http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To

Lm flash programmer has an unlock feature. Far right tab. Use fury class for 1968 device.

Spoke with TI on this the other day and they expected to clear the remaining back-orders and have units in stock by early September.
 
Original EK-LM4F120XL shows still in stock at $9.95 on the TI eStore.
 
 
Dellwood

John,
 
This was a known problem with the REV A boards.  On REV B the connector moved out closer to the edge of the board.  The problem was that with the connector mounted in the flare of the SMD connector would float and cause the whole connector to lift in re-flow.  By moving the connector out the whole connector sits more flat to the board and makes a stronger bond.
 
Even on REV B it is not a super strong solder joint care and gentleness encouraged.
 
If you have solder equipment a bit of extra solder on the outside of the SMD housing could be a good idea.  Don't use too much or it will flow into the area where the cable goes and then you are out of luck (experience talking).
 
 
dellwood

You can use the LaunchPad to program standalone chips that you purchase and install on your own PCB.  There is a how-to at http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
 
I'd suggest putting a standard ARM connector on any board you create and interface that to the pins on the LaunchPad http://www.keil.com/support/man/docs/ulinkpro/ulinkpro_hw_if_jtag10.htm  This is what the programmers from Keil, IAR and others use this gives you flexibility if you want a different "standard" programmer later.
 
The chip you buy from TI will identical to the chip on the LaunchPad in terms of how you program and how you get code on to it.  See LMFlashProgrammer, This plus the bootloaders in ROM means that production boards (debug not needed) don't need to waste space and money on JTAG connectors.  You can use serial or USB or other interfaces.
 
The TivaWare examples generally use the ROM_ functions.  These are in ROM so no flash space gets used by them.  They also execute at full device speed.  Flash executes at 40Mhz max then you get a read buffer and some minimal performance loss vs the ROM.
 
Yes again, the TM4C1233H6PM is "identical" to the LX4F.  The TM4C is a later revision of the same silicon.  It has a few errata fixes but the base function is the same.
 
Don't be scared by the ROM.  If you don't want to use it at first then you can pretend it is not there and then you just concern yourself with the code you write that goes in flash.
 
The latest builds of openocd now have integrated the support for the ICDI interface on the LaunchPad so lm4flash should not be needed anymore and you can do much more in depth debugging with openocd and gdb.  Tivaware ships with makefiles for GCC as well as the project files for CCS.  I believe Mentor Sourcery CodeBench is also supported in Linux and project files are in TivaWare.
 
 
 
dellwood

You can use the LaunchPad to program standalone chips that you purchase and install on your own PCB.  There is a how-to at http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
 
I'd suggest putting a standard ARM connector on any board you create and interface that to the pins on the LaunchPad http://www.keil.com/support/man/docs/ulinkpro/ulinkpro_hw_if_jtag10.htm  This is what the programmers from Keil, IAR and others use this gives you flexibility if you want a different "standard" programmer later.
 
The chip you buy from TI will identical to the chip on the LaunchPad in terms of how you program and how you get code on to it.  See LMFlashProgrammer, This plus the bootloaders in ROM means that production boards (debug not needed) don't need to waste space and money on JTAG connectors.  You can use serial or USB or other interfaces.
 
The TivaWare examples generally use the ROM_ functions.  These are in ROM so no flash space gets used by them.  They also execute at full device speed.  Flash executes at 40Mhz max then you get a read buffer and some minimal performance loss vs the ROM.
 
Yes again, the TM4C1233H6PM is "identical" to the LX4F.  The TM4C is a later revision of the same silicon.  It has a few errata fixes but the base function is the same.
 
Don't be scared by the ROM.  If you don't want to use it at first then you can pretend it is not there and then you just concern yourself with the code you write that goes in flash.
 
The latest builds of openocd now have integrated the support for the ICDI interface on the LaunchPad so lm4flash should not be needed anymore and you can do much more in depth debugging with openocd and gdb.  Tivaware ships with makefiles for GCC as well as the project files for CCS.  I believe Mentor Sourcery CodeBench is also supported in Linux and project files are in TivaWare.
 
 
 
dellwood

You can use the LaunchPad to program standalone chips that you purchase and install on your own PCB.  There is a how-to at http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
 
I'd suggest putting a standard ARM connector on any board you create and interface that to the pins on the LaunchPad http://www.keil.com/support/man/docs/ulinkpro/ulinkpro_hw_if_jtag10.htm  This is what the programmers from Keil, IAR and others use this gives you flexibility if you want a different "standard" programmer later.
 
The chip you buy from TI will identical to the chip on the LaunchPad in terms of how you program and how you get code on to it.  See LMFlashProgrammer, This plus the bootloaders in ROM means that production boards (debug not needed) don't need to waste space and money on JTAG connectors.  You can use serial or USB or other interfaces.
 
The TivaWare examples generally use the ROM_ functions.  These are in ROM so no flash space gets used by them.  They also execute at full device speed.  Flash executes at 40Mhz max then you get a read buffer and some minimal performance loss vs the ROM.
 
Yes again, the TM4C1233H6PM is "identical" to the LX4F.  The TM4C is a later revision of the same silicon.  It has a few errata fixes but the base function is the same.
 
Don't be scared by the ROM.  If you don't want to use it at first then you can pretend it is not there and then you just concern yourself with the code you write that goes in flash.
 
The latest builds of openocd now have integrated the support for the ICDI interface on the LaunchPad so lm4flash should not be needed anymore and you can do much more in depth debugging with openocd and gdb.  Tivaware ships with makefiles for GCC as well as the project files for CCS.  I believe Mentor Sourcery CodeBench is also supported in Linux and project files are in TivaWare.
 
 
 
dellwood

You can use the LaunchPad to program standalone chips that you purchase and install on your own PCB.  There is a how-to at http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
 
I'd suggest putting a standard ARM connector on any board you create and interface that to the pins on the LaunchPad http://www.keil.com/support/man/docs/ulinkpro/ulinkpro_hw_if_jtag10.htm  This is what the programmers from Keil, IAR and others use this gives you flexibility if you want a different "standard" programmer later.
 
The chip you buy from TI will identical to the chip on the LaunchPad in terms of how you program and how you get code on to it.  See LMFlashProgrammer, This plus the bootloaders in ROM means that production boards (debug not needed) don't need to waste space and money on JTAG connectors.  You can use serial or USB or other interfaces.
 
The TivaWare examples generally use the ROM_ functions.  These are in ROM so no flash space gets used by them.  They also execute at full device speed.  Flash executes at 40Mhz max then you get a read buffer and some minimal performance loss vs the ROM.
 
Yes again, the TM4C1233H6PM is "identical" to the LX4F.  The TM4C is a later revision of the same silicon.  It has a few errata fixes but the base function is the same.
 
Don't be scared by the ROM.  If you don't want to use it at first then you can pretend it is not there and then you just concern yourself with the code you write that goes in flash.
 
The latest builds of openocd now have integrated the support for the ICDI interface on the LaunchPad so lm4flash should not be needed anymore and you can do much more in depth debugging with openocd and gdb.  Tivaware ships with makefiles for GCC as well as the project files for CCS.  I believe Mentor Sourcery CodeBench is also supported in Linux and project files are in TivaWare.
 
 
 
dellwood

http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/266853/942510.aspx#942510
 
 
TI posted updated code for the MPU9150.

Make the variable scope wide enough to include the interrupt function.  static global or global.  Make it volatile.
 
Make the interrupt handler a dummy function that passes the variables to another sub-function.  This still requires that the int handler have visibility to the variables in  question.

Soldering iron to gently heat and remove best choice. Side cutters will also cut the resistors. Or cut trace (last choice). No side effects.
 
They are there for msp launchpad compatibility. Puts i2c and spi on same boosterpack pin.

http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/overview.page  Tiva MCU overview page.
 
Bluehash, your 43oh blog is not quite accurate.  "The part LM4F230H5QR on the Launchpad is still the same, but now changed to TM4C1233GH6PM." 
 
The Stellaris LaunchPad has a LM4F120H5QR. The Tiva appears to have a TM4C123GH6PM which appears to be equal to the LM4F230H5QR.  This is how Tiva adds motion PWM, QEI and USB host/OTG.
 
Looks like the TI web folks are still tinkering with things, I'd suspect a more formal announcement is coming soon. 
 
Datasheets are up http://www.ti.com/lit/ds/symlink/tm4c123gh6pm.pdf.  Bugs note that the title page says "identical to LM4F230H5QR"  So they are giving us at least some means to compare to previous numbering.

What you want is a USB composite serial plus mass storage.
 
Get a full copy of StellarisWare for all boards.  http://www.ti.com/sw-lm3s
 
The old EK-LM3S9D92 kit has a composite example that is a HID with serial.  Find that example in C:\StellarisWare\boards\ek-lm3s9d92\usb_dev_chidcdc\ port it to the LM4F120.  The port should be only to configure the USB Port D Pins as USB mode not GPIO during your init code.  The rest should work. almost straight away.  Once you have that working on the LM4F120 remove the HID stuff from the example and replace it with mass storage.  Look for usb_dev_msc in the DK-LM3S9D96 board directory.  From that you can get an idea how to setup a mass storage controller stellaris device.  The DK has a lot of graphics and extra stuff in it that you will want to strip out.
 
Dexter

What you want is a USB composite serial plus mass storage.
 
Get a full copy of StellarisWare for all boards.  http://www.ti.com/sw-lm3s
 
The old EK-LM3S9D92 kit has a composite example that is a HID with serial.  Find that example in C:\StellarisWare\boards\ek-lm3s9d92\usb_dev_chidcdc\ port it to the LM4F120.  The port should be only to configure the USB Port D Pins as USB mode not GPIO during your init code.  The rest should work. almost straight away.  Once you have that working on the LM4F120 remove the HID stuff from the example and replace it with mass storage.  Look for usb_dev_msc in the DK-LM3S9D96 board directory.  From that you can get an idea how to setup a mass storage controller stellaris device.  The DK has a lot of graphics and extra stuff in it that you will want to strip out.
 
Dexter

What you are asking doesn't sound like "standard" practice.  Can you give us a bigger picture of why you want this behavior?
 
Instead of us trying to help implement a single possible solution, if you first help us understand the bigger problem you want to solve chances are good that someone has seen this before and may have a different approach that you had not considered which is likely more elegant.
 
If you really want to implement this particular solution, i'd suggest using a general purpose timer.  Set it to interrupt on the threshold.  Do not enable the timer to count automatically.  Then use the timer value register to hold the variable "flag" that you want to test.
 
 
 
Dellwood.

This was done for MSP430 compatibility on those pins.  PB6 and 7 provide SSI functions.  PD0 and PD1 provide I2C function.  The MSP has a module that provides both on the same MCU pin.  The Stellaris requires using two pins to match the MSP functionality.
 
Dexter

UARTprintf does not yet support floats directly.
 
A couple of options exist.  
 
1) use sprintf or similar from the standard 'C' libraries to do the float to string conversion into a character array and then use %s with UARTprintf to put the float (which is now stored as a string in the array) on the UART.
 
2) Do a little bit of casting and multiplying.  cast the float to a integer.  Call this the integer part.  multiply the float by something like 1000 to get three decimal points of precision.  cast this new number to an integer again and now subtract off the integer part * 1000. Call this the fraction part.  Then with UARTprintf do "%d.%03d", IntegerPart, FractionPart.
 
Dexter

UARTprintf does not yet support floats directly.
 
A couple of options exist.  
 
1) use sprintf or similar from the standard 'C' libraries to do the float to string conversion into a character array and then use %s with UARTprintf to put the float (which is now stored as a string in the array) on the UART.
 
2) Do a little bit of casting and multiplying.  cast the float to a integer.  Call this the integer part.  multiply the float by something like 1000 to get three decimal points of precision.  cast this new number to an integer again and now subtract off the integer part * 1000. Call this the fraction part.  Then with UARTprintf do "%d.%03d", IntegerPart, FractionPart.
 
Dexter

UARTprintf does not yet support floats directly.
 
A couple of options exist.  
 
1) use sprintf or similar from the standard 'C' libraries to do the float to string conversion into a character array and then use %s with UARTprintf to put the float (which is now stored as a string in the array) on the UART.
 
2) Do a little bit of casting and multiplying.  cast the float to a integer.  Call this the integer part.  multiply the float by something like 1000 to get three decimal points of precision.  cast this new number to an integer again and now subtract off the integer part * 1000. Call this the fraction part.  Then with UARTprintf do "%d.%03d", IntegerPart, FractionPart.
 
Dexter