Jump to content
43oh

USWaterRockets

Members
  • Content Count

    81
  • Joined

  • Last visited

  • Days Won

    8

Reputation Activity

  1. Like
    USWaterRockets got a reaction from Fmilburn in MSP432P4111: What do we know about it so far?   
    I am hopeful there will be USB connectivity. This is all I have been able to uncover:
    Core ARM Cortex-M4, FPU MPU 48 MHz
     
    Processor:Cortex-M4, FPU MPU 48 MHz
    Cryptographic Engine:128.256 -bit HW accelerated AES Encryption Engine
     
    Memory 512 kB RAM, 2 MB ROM
     
    ROM:2 MB
    ROM:32 kB
    RAM:256 kB
    RAM:256 kB
     
    Clock & Power 1.62 V .. 3.7 V, 48 MHz
    Supply Voltage:1.62 V .. 3.7 V Operating Voltage
    Maximum Clock Frequency:48 MHz,
     
    Communication Other
    Other:4 x UART or SPI
    Other:4 x I2C or SPI
     
    Timer/Counter/PWM 4 x 16-bit Timer, 2 x 32-bit Timer
     
    Timer/Counter:4 x 16-bit Up to 4 timers/PWM/CCP
    Timer/Counter:2 x 32-bit GP Timers
     
    Analog 24-channel 14 bit ADC, 2 x Analog Comparator
    Temperature Sensor:1 x
    2 x Analog Comparator
     
     
  2. Like
    USWaterRockets got a reaction from yyrkoon in UART - Sending 3 bytes per start/stop bit sets.   
    Why don't you just set up a timer interrupt and implement the fancy 16/24 bit UART using software running in the interrupt?
     
    If you're using 1200baud, that's 1 bit every 833uS. On a MSP430 running at 8MHz, that's one interrupt every 6000 clock cycles (8000000/1200 = 6000). If your interrupt routine takes an average of 100 cycles to complete, you're using 1.5% of the CPU cycles for the UART (((1200 * 100) / 1000) = 0.015).
     
    Recall that the original MSP430 LaunchPad shipped with the MSP430G2231 which does not have a hardware UART peripheral, so all the serial port examples for it were using a bit bang driver. It should be very trivial to look through the existing examples for software UARTs for the LaunchPad and find one you like that you should then be able to modify the bit counter to send 16 or 24 bits instead of 8.
  3. Like
    USWaterRockets got a reaction from spirilis in UART - Sending 3 bytes per start/stop bit sets.   
    Why don't you just set up a timer interrupt and implement the fancy 16/24 bit UART using software running in the interrupt?
     
    If you're using 1200baud, that's 1 bit every 833uS. On a MSP430 running at 8MHz, that's one interrupt every 6000 clock cycles (8000000/1200 = 6000). If your interrupt routine takes an average of 100 cycles to complete, you're using 1.5% of the CPU cycles for the UART (((1200 * 100) / 1000) = 0.015).
     
    Recall that the original MSP430 LaunchPad shipped with the MSP430G2231 which does not have a hardware UART peripheral, so all the serial port examples for it were using a bit bang driver. It should be very trivial to look through the existing examples for software UARTs for the LaunchPad and find one you like that you should then be able to modify the bit counter to send 16 or 24 bits instead of 8.
  4. Like
    USWaterRockets got a reaction from dubnet in UART - Sending 3 bytes per start/stop bit sets.   
    Why don't you just set up a timer interrupt and implement the fancy 16/24 bit UART using software running in the interrupt?
     
    If you're using 1200baud, that's 1 bit every 833uS. On a MSP430 running at 8MHz, that's one interrupt every 6000 clock cycles (8000000/1200 = 6000). If your interrupt routine takes an average of 100 cycles to complete, you're using 1.5% of the CPU cycles for the UART (((1200 * 100) / 1000) = 0.015).
     
    Recall that the original MSP430 LaunchPad shipped with the MSP430G2231 which does not have a hardware UART peripheral, so all the serial port examples for it were using a bit bang driver. It should be very trivial to look through the existing examples for software UARTs for the LaunchPad and find one you like that you should then be able to modify the bit counter to send 16 or 24 bits instead of 8.
  5. Like
    USWaterRockets got a reaction from tripwire in MSP-EXP432P401R Pre-Production (black PCB) LaunchPad to be Phased Out   
    I heard some rumors about new parts coming, and some new features which were a surprise to me. Definitely not something I can prove easily, but it ties back to something I wanted a while ago. I hope we hear something more solid soon. 
  6. Like
    USWaterRockets got a reaction from Fred in MSP-EXP432P401R Pre-Production (black PCB) LaunchPad to be Phased Out   
    I heard some rumors about new parts coming, and some new features which were a surprise to me. Definitely not something I can prove easily, but it ties back to something I wanted a while ago. I hope we hear something more solid soon. 
  7. Like
    USWaterRockets got a reaction from spirilis in MSP-EXP432P401R Pre-Production (black PCB) LaunchPad to be Phased Out   
    I heard some rumors about new parts coming, and some new features which were a surprise to me. Definitely not something I can prove easily, but it ties back to something I wanted a while ago. I hope we hear something more solid soon. 
  8. Like
    USWaterRockets got a reaction from dubnet in SD card reader Sleep   
    An SD card once initialized will automatically go into sleep mode when there is no activity on the clock line. In sleep mode a SD card will draw between 100 and 200 microamps. Depending on the interval of your powerup/initialize/log sequence, you may be wasting more power re-initializing the card on every power-up than you would be to just let it sleep and not having to initialize it each time you write.
     
    It's always good to have the FET control of the SD card power, because that's the only way to reset it if it somehow locks up, but you need to do a careful analysis of power use to find out the best way to save over time.
  9. Like
    USWaterRockets got a reaction from LIJsselstein in Have feedback for TI? Please share here.   
    USB and Low Power are indeed a very much desired set of coupled features. For example, making a portable device that runs from a small battery or solar cell that you want to configure or extract logged data from at the end of the day or something. Perhaps the battery recharges via a USB connection as well. So, having USB to communicate to the device when charging is a definite feature worth having. It can be low power when not connected to USB.
  10. Like
    USWaterRockets got a reaction from tripwire in Have feedback for TI? Please share here.   
    When your main competitor has super cheap uCs with a handful of I/Os that have USB built-in, adding a FTDI part that costs as much as their whole uC does is really not helping us much. Now, if they think USB is obsolete because of IoT or something, then make a MSP432 with a built-in wireless bridge that's simple to use and doesn't require the user build and link the stacks.
     
    I'd really love to do something with the SensorTag, but the software and documentation are a mess, and the part is not low cost unless you buy 10 billion of them.
  11. Like
    USWaterRockets got a reaction from chicken in Have feedback for TI? Please share here.   
    USB and Low Power are indeed a very much desired set of coupled features. For example, making a portable device that runs from a small battery or solar cell that you want to configure or extract logged data from at the end of the day or something. Perhaps the battery recharges via a USB connection as well. So, having USB to communicate to the device when charging is a definite feature worth having. It can be low power when not connected to USB.
  12. Like
    USWaterRockets got a reaction from OpalApps in How to protect your free code from companies predating on it ?   
    I'm not quite sure the best way to explain this, but I don't agree with this idea. If you shared something with the good intention of teaching others as an example, then the mission was accomplished, but what happens later with the code can still be important to you.
     
    Perhaps you feel very strongly about teaching others, and are strongly against plagiarism as a matter of principle. The fact you shared with people who learned does not negate the fact that someone else took the work as their own, which could be an affront to your lifelong beliefs.
  13. Like
    USWaterRockets reacted to tripwire in [FIXED!] JTAG interferes with SensorTag external flash access   
    Good news! This issue is fixed in the TI Emulators 6.0.228.0 package, which contains the version 2.3.0.1 firmware for XDS110.
     
    TI have added support for 2-wire cJTAG debugging, which only uses the TMS and TCK lines. In the 2.3.0.1 firmware they also stopped the emulator from driving TDO, which was blocking access to the SPI. It looks like 2-wire cJTAG is the default mode now too, so debugging SPI flash code should just work like you'd expect.
  14. Like
    USWaterRockets got a reaction from Fmilburn in Have feedback for TI? Please share here.   
    This is very interesting. We were discussing the rationale for the MSP432, and this interesting video came out from Mike Szczys, the senior editor of Hackaday. He discusses the feud between the 8-bit and 32-bit camps and after watching the video, I can get an appreciation for why TI has created the MSP432.
     
    https://youtu.be/kz0yCrikZBE
     
    The feeling I get is that the MSP432 fills the gap or bridges between an 8-bit device, with their simple and easy to learn peripherals, and a 32-bit design with their complex peripherals that are intimidating and confusing to a person just starting out.
     
    You get the speed and benefits of a 32-bit CPU core, but easy to program peripherals that also likely keep the die size lower and the chip costs down.
     
    Think of it more like taking a MSP430 and making the clock speed faster, adding an FPU, and giving it a 32-bit BUS. The rest remains simple and easy to learn, or migrate to.
  15. Like
    USWaterRockets got a reaction from GrumpyOldPizza in Have feedback for TI? Please share here.   
    The biggest flaw with standardizing on an Arduino Driver lib is precisely because it encourages people to NOT learn about the underlying hardware. As soon as they try to connect up a peripheral with a subtle difference, they get completely frustrated and complain about the lack of support for their particular sensor or application. Not everyone is like this, but it is a generalization of a broad swath of Arduino users.
     
    There's nothing wrong with learning how I2C works, or how a PWM works. Once you know how they work on one micro, then you understand the fundamentals enough to code the same thing on totally different hardware.
  16. Like
    USWaterRockets got a reaction from dubnet in Have feedback for TI? Please share here.   
    The biggest flaw with standardizing on an Arduino Driver lib is precisely because it encourages people to NOT learn about the underlying hardware. As soon as they try to connect up a peripheral with a subtle difference, they get completely frustrated and complain about the lack of support for their particular sensor or application. Not everyone is like this, but it is a generalization of a broad swath of Arduino users.
     
    There's nothing wrong with learning how I2C works, or how a PWM works. Once you know how they work on one micro, then you understand the fundamentals enough to code the same thing on totally different hardware.
  17. Like
    USWaterRockets got a reaction from tripwire in Have feedback for TI? Please share here.   
    The biggest flaw with standardizing on an Arduino Driver lib is precisely because it encourages people to NOT learn about the underlying hardware. As soon as they try to connect up a peripheral with a subtle difference, they get completely frustrated and complain about the lack of support for their particular sensor or application. Not everyone is like this, but it is a generalization of a broad swath of Arduino users.
     
    There's nothing wrong with learning how I2C works, or how a PWM works. Once you know how they work on one micro, then you understand the fundamentals enough to code the same thing on totally different hardware.
  18. Like
    USWaterRockets got a reaction from bluehash in Need a buck switching power supply design   
    I've had good luck with the TI Nanomodules. I've used the LMZ21700 in a project to get 5V @ 650mA from a 4S LiPo battery.  I've been working on another design using the TPS81256.
     
    I know these parts don't meet your exact requirements, but I'm just pointing out that I've been happy with the experience I have had with the TI nanomodules I've used so far. Take it for what that's worth.
  19. Like
    USWaterRockets got a reaction from tripwire in Have feedback for TI? Please share here.   
    It seems like an awful lot of work went into designing the MSP432 and integrating it into the MSP430-centric ecosystem. Migration documentation and tools and all of that take a lot of effort to produce. It seems to me like there must be a reason for all of that effort, and somehow all that work had to be justified. So, perhaps there is a method to their madness, and ultimately it will all make perfect sense when the scope of the plan has been revealed?
  20. Like
    USWaterRockets got a reaction from zeke in Need a buck switching power supply design   
    I've had good luck with the TI Nanomodules. I've used the LMZ21700 in a project to get 5V @ 650mA from a 4S LiPo battery.  I've been working on another design using the TPS81256.
     
    I know these parts don't meet your exact requirements, but I'm just pointing out that I've been happy with the experience I have had with the TI nanomodules I've used so far. Take it for what that's worth.
  21. Like
    USWaterRockets got a reaction from tripwire in Have feedback for TI? Please share here.   
    A couple of quick comments.
     
    1) Loved the $4.30 Original Launchpad/ Too bad it had to go up in price. I guess I can understand why.
     
    2) I wish there was some kind of roadmap for MSP432. It looks like they made one part a year ago and then abandoned the idea. I like the part a lot and wish there were other variations.
     
    3) The wireless stuff is great, but the software and tutorials for the wireless are a mess. I got the CC2650 sensortag a year ago and a debugger devpack. Code samples didn't build, and putting the original firmware back in caused features (accelerometer) to quit working. A super part with a lot of promise left a really bad customer experience. I put it in a drawer out of frustration.
     
    4) CCS is great, and having a real debugger is awesome. Should find a way to make this work completely with Energia, or find ways to steer Energia users to CCS for the debug facilities.
     
    5) TI should make a 3D Printer control board reference design, with all of their fancy parts on it, and all the right software. Maybe a Tiva or MSP432 for the CPU, or a AM335x with PRU assist for realtime stuff. Competitors have gotten footholds in 3D printers and quadrotors and TI could really get a lot of smart people using their stuff by introducing reference designs to build upon.
  22. Like
    USWaterRockets got a reaction from spirilis in Have feedback for TI? Please share here.   
    A couple of quick comments.
     
    1) Loved the $4.30 Original Launchpad/ Too bad it had to go up in price. I guess I can understand why.
     
    2) I wish there was some kind of roadmap for MSP432. It looks like they made one part a year ago and then abandoned the idea. I like the part a lot and wish there were other variations.
     
    3) The wireless stuff is great, but the software and tutorials for the wireless are a mess. I got the CC2650 sensortag a year ago and a debugger devpack. Code samples didn't build, and putting the original firmware back in caused features (accelerometer) to quit working. A super part with a lot of promise left a really bad customer experience. I put it in a drawer out of frustration.
     
    4) CCS is great, and having a real debugger is awesome. Should find a way to make this work completely with Energia, or find ways to steer Energia users to CCS for the debug facilities.
     
    5) TI should make a 3D Printer control board reference design, with all of their fancy parts on it, and all the right software. Maybe a Tiva or MSP432 for the CPU, or a AM335x with PRU assist for realtime stuff. Competitors have gotten footholds in 3D printers and quadrotors and TI could really get a lot of smart people using their stuff by introducing reference designs to build upon.
  23. Like
    USWaterRockets reacted to bluehash in Important SensorTag Debug DevPack Bulletin   
    Good on TI for recognizing and doing something about it. Read on:
     
    TI has received reports that the CC-DEVPACKDEBUG sometimes gets hot when connected with the CC2650STK while either EVM is powered. Depending on the usage mode and power-up process, the overheating may cause deformation of the black plastic on the CC2650STK.
     
    Material/Devices Affected (
    swru454.pdf
  24. Like
    USWaterRockets reacted to spirilis in My time with FreeRTOS on the TM4C   
    TivaWare examples usually have a lot of #include's.  This looks like a decent minimal list for doing sysctl configuration (e.g. system clock and enabling peripherals) and GPIO:

     
    The TARGET_IS_TM4C123_RB1 #define we put in the project's symbols enables correct use of the MAP_ and ROM_ version of the various driverlib calls.  Proof is in driverlib/rom.h:
    //***************************************************************************** // // Macros for calling ROM functions in the ADC API. // //***************************************************************************** #if defined(TARGET_IS_TM4C123_RA1) || \ defined(TARGET_IS_TM4C123_RA3) || \ defined(TARGET_IS_TM4C123_RB1) || \ defined(TARGET_IS_TM4C123_RB2) || \ defined(TARGET_IS_TM4C129_RA0) || \ defined(TARGET_IS_TM4C129_RA1) || \ defined(TARGET_IS_TM4C129_RA2) #define ROM_ADCSequenceDataGet \ ((int32_t (*)(uint32_t ui32Base, \ uint32_t ui32SequenceNum, \ uint32_t *pui32Buffer))ROM_ADCTABLE[0]) #endif #if defined(TARGET_IS_TM4C123_RA1) || \ defined(TARGET_IS_TM4C123_RA3) || \ defined(TARGET_IS_TM4C123_RB1) || \ defined(TARGET_IS_TM4C123_RB2) || \ defined(TARGET_IS_TM4C129_RA0) || \ defined(TARGET_IS_TM4C129_RA1) || \ defined(TARGET_IS_TM4C129_RA2) #define ROM_ADCIntDisable \ ((void (*)(uint32_t ui32Base, \ uint32_t ui32SequenceNum))ROM_ADCTABLE[1]) #endif rom_map.h wraps those calls in MAP_ prefixes so that if it's discovered that a certain Tiva silicon release had a bug in its ROM driver code, updated TivaWare editions may choose to use a source-compiled version of the driverlib function instead of the ROM_ version.  We'll use MAP_ for all our driverlib calls.  There is one exception IIRC, I think it's IntRegister(), that can never use the ROM version but we aren't going to touch it during this example.
     
    Note that the exact TARGET define, e.g. TARGET_IS_TM4C123_RB1, should actually be doctored to coincide with the exact silicon you're using.  RB2 is the very latest revision as of March 2016, but if you're building this for an earlier release of the Tiva chip, it might be prudent to investigate the actual CPU revision you're running (see the chip's datasheet - should be gleaned from reading the markings on the chip but you can figure this out programmatically) and use the correct TARGET_IS_TM4C123_Rxy setting.  (I actually think mine is older than RB1, but it's not a big problem for this example).  Anyway, the available versions can be found by examining driverlib/rom.h and then look at the Tiva chip's datasheet + errata sheet for more details on versions, bugs, etc.
     
    Here's our original main.c, reworked to use TivaWare just to properly configure the CPU clock:
    /* * main.c */ #include <FreeRTOS.h> #include <task.h> #include "inc/hw_types.h" #include "inc/hw_ints.h" #include "inc/hw_memmap.h" #include "inc/hw_gpio.h" #include "driverlib/gpio.h" #include "driverlib/pin_map.h" #include "driverlib/rom.h" #include "driverlib/rom_map.h" #include "driverlib/sysctl.h" void NullTaskFunc(void *); // prototype so we can include it in main while the code is underneath int main(void) { MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN); // Prototype for xTaskCreate: // // BaseType_t xTaskCreate( TaskFunction_t pvTaskCode, // const char * const pcName, // uint16_t usStackDepth, // void *pvParameters, // UBaseType_t uxPriority, // TaskHandle_t *pvCreatedTask); if (pdTRUE != xTaskCreate(NullTaskFunc, "Null Task", 32, NULL, 4, NULL)) { while (1) ; // Oh no! Must not have had enough memory to create the task. } vTaskStartScheduler(); // Start FreeRTOS! // Should never get here since the RTOS should never "exit". while(1) ; return 0; } // Our RTOS "task" - does absolute jack squat void NullTaskFunc(void *pvParameters) { while (1) { vTaskDelay(10000); // With this task always delaying, the RTOS Idle Task runs almost all the time. } } This configures the PLL with correct crystal speed, enabling the crystal oscillator, to land us at 80MHz.
     
    Note that in main.c, if you forgot to include stdbool.h, some of the driverlib .h files will complain:

     
    Also, driverlib imports a file called "epi_workaround_ccs.s" which won't compile under GCC, so we should delete it:

     

     
    Now it builds correctly:

     
    Our FreeRTOS project thus far doesn't do anything visibly different from the last time we built it, besides the CPU clock running at the correct frequency, so we'll skip running it for now.  Next, we're going to create another task that blinks an LED, and I'll include logic analyzer output validating the cadence of the blink.
  25. Like
    USWaterRockets got a reaction from gsutton in ESP8266 with MSP430G2553 launchpad   
    I suspect you may have to check the jumpers on the upper right of the Launchpad. By default I believe they ship with the TX and RX jumpers going in up/down like this || for compatibility with the software UART driver from the original MSP430G2231 launchpad.
     
    To use the hardware UART, you want the jumpers to be set horizontally, like this =
     
    Alternatively, you can just swap the TX and RX lines going to the wifi module, and give that a try.
×
×
  • Create New...