Jump to content
43oh

dellwoodbu

Members
  • Content Count

    42
  • Joined

  • Last visited

  • Days Won

    2

Reputation Activity

  1. Like
    dellwoodbu got a reaction from Terenceang in Finally, time to learn about the Stellaris LaunchPad!   
    The I2C is available in the same place on the right hand header.  Examine the schematic closely there is a zero ohm that ties some I2C pins over to the right hand outside header at the same place as the MSP430 LaunchPad.
     
    StellarisWare\docs\SW-DRL-UGxxxx.pdf is the API documentation for StellarisWare Driver Library.  It is very helpful. it's designed to work across 5+ different IDE's/Compilers so it is much more independent of the compiler.  Start with the examples in StellarisWare\boards\ek-lm4f120xl and build on them.
  2. Like
    dellwoodbu got a reaction from grahamf72 in Programming LM4F when IDC USB connector destroyed   
    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
  3. Like
    dellwoodbu got a reaction from tripwire in How fast is the IO?   
    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.
  4. Like
    dellwoodbu got a reaction from TheDirty1426459890 in How fast is the IO?   
    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.
  5. Like
    dellwoodbu got a reaction from xpg in How fast is the IO?   
    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.
  6. Like
    dellwoodbu got a reaction from larsie in How fast is the IO?   
    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.
  7. Like
    dellwoodbu got a reaction from bluehash in SD card and Stellaris Launchpad   
    Also look at the examples for the earlier stellaris kits that have an SD card.
     
    EK-LM3S6965, EK-LM3S3748, EK-LM4F232
     
    Examples in the StellarisWare\Boards\<board part number>\ directory of the full StellarisWare download http://www.ti.com/tool/sw-lm3s
     
    TI uses an older version of FATFs open source file system.  I think they even have a example to be a USB Mass storage device using the SD Card.  usb_dev_msc.
  8. Like
    dellwoodbu got a reaction from Rickta59 in [Work-around] Stellaris Launchpad USB Serial example not enumerating correctly   
    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.
  9. Like
    dellwoodbu got a reaction from BravoV in [Work-around] Stellaris Launchpad USB Serial example not enumerating correctly   
    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.
  10. Like
    dellwoodbu got a reaction from bluehash in [Work-around] Stellaris Launchpad USB Serial example not enumerating correctly   
    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.
  11. Like
    dellwoodbu got a reaction from Xtagon in PWM on Stellaris Launchpad   
    Check the LM4F120H5QR Datasheet. The "general purpose" timers have a output mode that can generate simple variable duty cycle square waves (aka PWM). This chip just doesn't have what Stellaris calls motion control PWM which is dead bands, faults and QEI in hardware.
     
    It has a TON of timers. 6 x 32 bit times and 6 x 64 bit timers. Each of those 12 can run in a half wide mode.
     
    Pretty sure some creative folks will find a way to make that drive some motors.
  12. Like
    dellwoodbu got a reaction from bluehash in Stellaris launchpad gcc makefile, startup file and linker script BSD   
    I think TI is listening...
     
     
    http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/t/230468.aspx
     
    Also the Energia folks appear to have worked with TI to resolve some of the other issues...
     
    https://github.com/energia/Energia/blob/stellarpad/hardware/lm4f/cores/lm4f/startup_gcc.c
     
    The linker script energia is using is their own. But may be helpful https://github.com/energia/Energia/blob/stellarpad/hardware/lm4f/cores/lm4f/lm4fcpp.ld
     
    Finally since you mentioned the FIR examples in CMSIS i infer you are wanting the DSP libraries?  Check this app note which is CCS specific but may help some, Also EuphonisTI uses the DSP Library for his stuff.  http://hackaday.com/2012/09/06/frequency-analyzer-built-from-the-new-stellaris-launchpad/
  13. Like
    dellwoodbu got a reaction from Xtagon in Quadrature Encoder Interface on Launchpad?   
    Haven't tried this on the LM4F120 but you should be able to do a software QEI using GPIO interrupts or perhaps the timer capture pins.  
     
    Reading the state of one pin when the other pin transitions will tell you direction.  For example if pin 1 is high when pin 2 goes from high to low, that means either forward or reverse.  If pin 1 were low during the same pin 2 transition that is the opposite direction.  Time difference between edges on either pin should give you velocity. Integrating that to get position usually involves a third pin as an index to help re-zero the position count approximately once per revolution.
     
    Again, haven't done this lately but here is where i would start.
     
    Setup and enable a GPIO interrupt routine for the rising edges of the phase B pin.  START ISR 1 if( read(phase A pin) == high )position++ direction = forward velocity = some simple math based on ticks/revolution, time between now and last tick and perhaps size of the wheel. Using a TImer capture here helps get the best resolution on this. elseposition-- direction = reverse velocity = same math as before * (-1). end ISR 1  
    I would also setup a second ISR for the index pin if it existed and inside manually zero the position counter.  Make position variable a volatile as a minimum safe gaurd against race conditions.
     
    Dexter
  14. Like
    dellwoodbu got a reaction from bluehash in Which chip revision in your EK-LM4F120XL Stellaris Launchpad ?   
    The LX silicon marking means that this is a "preview" device as you can see by looking at the part status on the TI website.  It is a cosmetic indicator of preview status only. The B0 revision is the one intended to go to active status.  I think it is coming some time late Q1.  The preview status (thus the 'x') means that TI has not fully completed their stringent qualification process.  This is pretty typical for silicon companies, bring a preview device out let people play with it start designing products and then intersect the final production version of the device with the customers final board design.  If they waited to give you anything until the part went active your product would be several months behind schedule because you couldn't start prototypes until you got the final revision of the device.
     
    The A3 silicon is very good stuff and is more than suitable for the market the LaunchPad serves.  If I were building a mass market product I would talk to TI and see about using B0.  Building a quad-copter (or anything else) in my spare time i'd use launchpad with the A3 and never think twice. Even building prototypes of my mass market gizmo, i'd have no issue using A3.
     
    The post referenced above by sn00p is in regards to a subset of the LM3 device family that originated with Luminary Micro before TI bought them.  It indeed had issues but the "scary" ones are isolated to the one or two part families on that process node.  The LM4F (or LX4F if you prefer) is a TI part from the start and uses a different process and a different flash.
  15. Like
    dellwoodbu got a reaction from vinodstanur in Couldn't read GPIO pin of stellaris (push buttons)   
    PF0 is on this device shared with an NMI signal. In order to not accidentally trigger NMI Stellaris "locks" this GPIO pin from being changed by default.
     
    Below is the code from StellarisWare\boards\ek-lm4f120xl\drivers\buttons.c which unlocks PF0 so that it can become an input and be read. You may also need to enable the internal weak pullups.
     

    // // Unlock PF0 so we can change it to a GPIO input // Once we have enabled (unlocked) the commit register then re-lock it // to prevent further changes. PF0 is muxed with NMI thus a special case. // HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD; HWREG(BUTTONS_GPIO_BASE + GPIO_O_CR) |= 0x01; HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = 0;
  16. Like
    dellwoodbu got a reaction from bluehash in Couldn't read GPIO pin of stellaris (push buttons)   
    PF0 is on this device shared with an NMI signal. In order to not accidentally trigger NMI Stellaris "locks" this GPIO pin from being changed by default.
     
    Below is the code from StellarisWare\boards\ek-lm4f120xl\drivers\buttons.c which unlocks PF0 so that it can become an input and be read. You may also need to enable the internal weak pullups.
     

    // // Unlock PF0 so we can change it to a GPIO input // Once we have enabled (unlocked) the commit register then re-lock it // to prevent further changes. PF0 is muxed with NMI thus a special case. // HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD; HWREG(BUTTONS_GPIO_BASE + GPIO_O_CR) |= 0x01; HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = 0;
  17. Like
    dellwoodbu reacted to bluehash in E.M.I.'s PERF-ect Board Starter Kit   
    This was in this week's TI news flash.
    PERF-ect Board Header Assembly Kit
     
     
    PCB has the following features: (1) 2X4 inch perfboard area, detachable SMT mounts for (4) SOT23-6, (16) 0805 LED, Resistor, or Capacitor pads, (1) SOIC8, (1) TSSOP8, (1) TSSOP16, (1) SSOP16, (1) TSSOP20, (1) PLCC20, (1) Cap Sensor - Slider, and (1) Cap Sensor - button

  18. Like
    dellwoodbu got a reaction from bluehash in ICDI support in OpenOCD   
    Until openOCD gets direct support (Thank you Spen) there is a post on the TI wiki about how to debug from an external debugger. Any debugger that openOCD already supports and can do ARM M4 should work. This includes the older TI kits with FTDI based debug solutions. Not a perfect solution but hopefully this can help someone.
     
    http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
  19. Like
    dellwoodbu got a reaction from OppaErich in TI Posted Stellaris LaunchPad Workshop   
    www.ti.com/StellarisLaunchPadWorkshop
     
    Hours of video and training for the new kit. Including some for the display booster.
     
    Looks like you can attend live versions or watch most of it as videos online.
  20. Like
    dellwoodbu got a reaction from abecedarian in TI Posted Stellaris LaunchPad Workshop   
    www.ti.com/StellarisLaunchPadWorkshop
     
    Hours of video and training for the new kit. Including some for the display booster.
     
    Looks like you can attend live versions or watch most of it as videos online.
  21. Like
    dellwoodbu got a reaction from bluehash in TI Posted Stellaris LaunchPad Workshop   
    www.ti.com/StellarisLaunchPadWorkshop
     
    Hours of video and training for the new kit. Including some for the display booster.
     
    Looks like you can attend live versions or watch most of it as videos online.
  22. Like
    dellwoodbu got a reaction from abecedarian in Recommended IDE for a noob?   
    Java syntax is not that much different then C. If you can read Java you can probably read C. Writing it will take some time and practice. If you have figured out that many other languages adding C won't be hard. Kernighan and Ritchie's C Programming Language is the defacto standard book that everyone seems to think they need on the shelf. More of a reference than a tutuorial though. See the long list of examples in the StellarisWare download that I linked to before in this thread. Most are one or two files and should help get you started.
     
    There is an effort to get Energia working on the Stellaris LaunchPad which would open up the Arduino language/API but that may be just one more thing to learn that is somewhat limited. Also I don't know what the schedule is for that effort.
     
    As for IDE's: IAR and Keil are both proprietary and limited unless you pay a good chunk of money. The editors and environments are theirs and would require some learning. If you know Java, you may know eclipse. If you know eclipse then i suggest either Code Composer (TI) or Sourcery CodeBench (Mentor Embedded). Both run in an eclipse environment. On previous kits TI has made Code Composer free and unlimited for use with the kit. Only pay if you move to your own design.
     
    Good Luck and welcome to MCU's.
     
    Dellwood
  23. Like
    dellwoodbu got a reaction from bluehash in Noob Question: What kind of OSes can run on Stellaris Launchpad?   
    Regarding FreeRTOS
     
    http://www.ti.com/tool/sw-ek-lm4f120xl Is the software package from TI for the Stellaris LaunchPad. Download one of those packages for the tool chain of your choice. Run the enclosed StellarisWare installer. Find c:\stellarisware\boards\ek-lm4f120xl\freertos_demo. (default directory choice). A simple complete demo for FreeRTOS running on Stellaris LaunchPad.
     
    Building from there should be straight forward.
     
    dellwood
  24. Like
    dellwoodbu got a reaction from bluehash in DSP Libraries for Cortex-M3 and other ARM microcontrollers   
    ARM's DSP Library is highly optimized for the M3 and M4 http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
     
    TI has an app note on how to the above integrate with Code Composer and StellarisWare http://www.ti.com/lit/an/spma041a/spma041a.pdf
  25. Like
    dellwoodbu got a reaction from bluehash in Notes on setting up a Stellaris Toolchain with GCC   
    I found this helpful on Evalbot and Ubuntu https://www.synthetos.com/setup-arm-toolchain-in-ubuntu/ and the follow up https://www.synthetos.com/setup-arm-an-toolchain-in-ubuntu-part-2/
×
×
  • Create New...