Jump to content
43oh

solipso

Members
  • Content Count

    23
  • Joined

  • Last visited

Reputation Activity

  1. Like
    solipso reacted to monsonite in Energia for FRAM and other new MSP430 Devices?   
    Hi All,
     
    Would there be sufficient interest in some of the new FRAM parts to warrant an update of Energia to support these?
     
    The $16 MSP430FR5994 LaunchPad is remarkable value, and an ideal platform for datalogger/low power sensor applications with 256Kbytes of FRAM, a microSD card, and 68 lines of I/O.
     
    The MSP430FR2433 is also a neat little part, and if you need 4 x 24bit ADCs for instrumentation or energy monitoring the MSP430i2041 is one of the cheapest solutions for independent 24 bit ADCs around.
     
    I would be interested to know if there is a plan for Energia to support these recently released new parts?
     
     
    Ken
     
     
    London
  2. Like
    solipso reacted to chicken in Chrome for portable UI development (serial, USB)   
    Here's a tutorial on programming a graphical UI in Google Chrome to display data received over serial
    http://www.lucadentella.it/en/2016/06/07/chrome-app-e-comunicazione-seriale/
    via Dangerous Prototypes.
     
    I meant looking into this topic for a long time. For serial communication like in this tutorial, but also USB for a portable upgrade application via a custom USB BSL implementation.
     
  3. Like
    solipso reacted to Fmilburn in TI Tuesdays   
    There is a new series of YouTube postings that uses Texas Instruments parts and microcontrollers by Peter Oakes. I have started watching it and have found it interesting. It seems pitched at the hobbyist level (pretty basic at times), but goes beyond just a recipe to make something work and he even pulls out the datasheet!: https://www.youtube.com/playlist?list=PL_atu5RtEPi5I5YWx_wb_j9erZGCvnpvW
     
    EDIT: I have watched a few more of these and apparently they are TI sponsored.
  4. Like
    solipso reacted to GrumpyOldPizza in Have feedback for TI? Please share here.   
    Here my 2 cents (after having used a bunch of the parts going back to the Luminary Micro days).
     
    - get rid of the MSP432. It's a mess compared to other Cortex-M4 parts (yes, even low power ones). If you want a good low power part, please use the same peripherals as on TM4C, so that code can be reused.
     
    - a TM4C129 Launchpad with the dimensions of the TM4C123 launchpad
     
    - add CMSIS-DAP to the ARM Cortex based launchpads. Nobody really wants to see yet another vendor specific protocol like the LMICDI (not that gdb remote serial was not a nice idea, it's just it did not pan out).
     
    Not sure what else to say. I fundamentally think TI took the wrong turn with MSP432, which it seems to have left to die a lonely death. Perhaps folks coming from MSP430 see that different, but it's a massive turnoff for everybody coming from more grown up microcontroller.
     
     
    - Thomas
  5. Like
    solipso got a reaction from jazz in Have feedback for TI? Please share here.   
    As an independent designer I stopped to use TI parts unless inevitable because of their sampling rules. They had gladly sent me whatever I needed for my development, then they stopped. Then I stopped to design using their parts and consequently my customers stopped to buy TI components for their production runs. It is that simple.

    I also teach microcontroller courses on a local Secondary school of EE. We used to use MSP430/Tiva launchpads as a teaching platforms. After the insane $21 shipping was introduced, the 16bit course was cancelled (It would had been anyway) and the ARM course migrated to STM32.

    So as for me, TI can do anything they want. I do not care anymore.

     
  6. Like
    solipso reacted to spirilis in My time with FreeRTOS on the TM4C   
    Let's revisit that taskYIELD thing.  So we know if we use taskYIELD, it guarantees a context switch if there's another runnable thread.  But these two tasks are running at the same priority.  What if they weren't?  Perhaps xSemaphoreGive will perform a context switch if the semaphore makes a higher priority task runnable (theoretically this is known as a "priority inversion" when a lower-priority task can lock a higher priority one, so we will experiment to see that xSemaphoreGive does indeed context switch.)
     
    First thing I'll do is add another parameter to the spiTaskParams struct - an unsigned int indicating how many milliseconds to pause between semaphore give and take.  One task will have 0 (no delay), the other (higher priority task) will wait 5ms.
     
    main.c code (showing the new parameter inside spiTaskParams and removal of taskYIELD):
    /* * main.c */ #include <FreeRTOS.h> #include <task.h> #include <semphr.h> #include <queue.h> #include <stdint.h> #include <stdbool.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" #include "driverlib/ssi.h" // for SPI #include <string.h> // for strlen() // Data structure featuring a string and mutex for arbitrating SPI I/O. typedef struct { xSemaphoreHandle spiMutex; // this is just a pointer FYI. char * str; unsigned int delay; } spiTaskParams; // Declaring the space for these inside main() causes corruption, so make them global? spiTaskParams task1_Params, task2_Params; void Task_SPI_Transfer(void *); int main(void) { MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN); MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2); // SSI2 on PB4/PB6/PB7 MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB); // Need this to configure PB for SSI usage while (!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_SSI2)) ; while (!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOB)) ; // Configure PB4, PB6, PB7 as SSI pins MAP_GPIOPinTypeSSI(GPIO_PORTB_BASE, (GPIO_PIN_4 | GPIO_PIN_6 | GPIO_PIN_7) ); MAP_GPIOPinConfigure(GPIO_PB4_SSI2CLK); MAP_GPIOPinConfigure(GPIO_PB6_SSI2RX); MAP_GPIOPinConfigure(GPIO_PB7_SSI2TX); // Init SSI2 MAP_SSIClockSourceSet(SSI2_BASE, SSI_CLOCK_SYSTEM); // System CPU clock used MAP_SSIConfigSetExpClk(SSI2_BASE, MAP_SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 8000000, 8); // 8MHz SPI, mode 0, 8 bits MAP_SSIEnable(SSI2_BASE); // SPI peripheral is now live. xSemaphoreHandle spiMutex; spiMutex = xSemaphoreCreateMutex(); task1_Params.spiMutex = spiMutex; task1_Params.str = "The quick brown fox"; task1_Params.delay = 0; xTaskCreate(Task_SPI_Transfer, "Task1", 32, (void *)&task1_Params, 4, NULL); task2_Params.spiMutex = spiMutex; task2_Params.str = "bluehash runs a great forum"; task2_Params.delay = 5; xTaskCreate(Task_SPI_Transfer, "Task2", 32, (void *)&task2_Params, 5, NULL); // Higher priority vTaskStartScheduler(); // Start FreeRTOS! while(1) ; // Shouldn't get here. return 0; } void Task_SPI_Transfer(void *pvParameters) { spiTaskParams *params = (spiTaskParams *)pvParameters; const char *str = params->str; const size_t slen = strlen(str); size_t i = 0; xSemaphoreHandle spiMutex = params->spiMutex; while (1) { xSemaphoreTake(spiMutex, portMAX_DELAY); // Suspend this task indefinitely until the mutex is available { // Transmit the whole string before giving up the mutex i = 0; while (i < slen) { // Wait for SPI peripheral to stop transmitting while (MAP_SSIBusy(SSI2_BASE)) ; while (MAP_SSIDataPutNonBlocking(SSI2_BASE, str[i]) > 0) { i++; if (i >= slen) { break; // Quit stuffing FIFO once we're done } } } } xSemaphoreGive(spiMutex); if (params->delay != 0) { vTaskDelay(params->delay / portTICK_PERIOD_MS); // Suspend for a parameter-specified delay } } } Yep, as suspected.  When xSemaphoreGive runs, if this makes a higher priority task runnable, it will context switch.
     
    Start of program:
    b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x Somewhere in the middle (every 5ms, in fact; note up above in main() for task2 we used task2_Params.delay = 5, and task2 runs at priority 5 vs. task1 running at priority 4):
    T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x You can tell the SSIBusy delays, and the context switches, based on the timing:

  7. Like
    solipso reacted to Rei Vilo in [Energia Library] RTOS Libraries for MSP432 on Energia MT   
    I've submitted three projects at Hackters.io about Energia Multi-Tasking and the Galaxia library.
    Multi-Tasking with Energia MT with Galaxia Library   How to run multiple tasks on a LaunchPad? We're using two different solutions, one standard and another based on the Galaxia library. By Rei Vilo .   
    Manage Single Resource with Energia MT and Galaxia     How to manage a single resource across multiple tasks? Semaphores come to the rescue. By Rei Vilo .    Send Data Across Tasks with Energia and Galaxia     How to send data across tasks? Mailbox can help! By Rei Vilo .    Feel free to click on Respect Project!
  8. Like
    solipso reacted to monsonite in New MSP430FR2311 Launchpad   
    I think this new '2133 chip is targeted at smoke alarm applications.
     
    The TIA is just what is needed to convert the nano-amps from the ionisation chamber into a detectable change of voltage.
     
    At $0.60 in 1000off it's clearly aimed at high volume disposable products.
     
    I think you could just about run a Forth in 3.75K of FRAM
     
    Today I have just started looking at the MSP430i2041  which has 4 x 24 SD ADCs  - aimed at 3 phase electricity metering applications.   It's only $1.20 in 1000+  and makes the ideal smart analogue front end for loadcells, strain gauges, pressure sensors, altimeters  or  accelerometers.
     
    My only gripe is that I have to buy another schmartboard adaptor every time I want to use a TI chip in a breadboard.  And very few of them share the same pin-outs. Its like you have to start all over again, each time you want to evaluate a new device. 
     

     
     
     
    Ken
  9. Like
    solipso reacted to M-atthias in LDMIA & Interrupts Silicon Bug   
    Dear TI geeks,
     
    Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble.
     
    Matthias
     
     
      LDMIA and some other opcodes with a register list can be interrupted and
      continued afterwards in M3 and M4 cores.

      Unfortunately, there seems to be a silicon bug in some chips / core revisions
      that causes an interrupted LDMIA opcode to fail.

      The error has already been observed in LM4F120, TM4C1294, STM32F407
      when using the multitasking example. M0 chips and EFM32GG990 are fine.

      It could affect other M4 chips and maybe M3, too.

      So if you get mysterious crashes when using Interrupts on M3/M4,
      try disabling preemption capabilities with this workaround:

      1 $E000E008 !

      Drawback is that this increases interrupt latency.

      Manual snipplets:

      B1.5.10 Exceptions in LDM and STM operations

           In order to allow implementations to have the best possible interrupt response, an interrupt can be taken
           during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or
           STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on
           page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is
           IMPLEMENTATION DEFINED.
           The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM
           or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not
           supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM,
           STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base
           register writeback update) during execution.

      M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html
      M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html
     
      Address     Name   Type  Required privilege  Reset value  Description
      0xE000E008  ACTLR  RW    Privileged          0x00000000   Auxiliary Control Register

      Auxiliary Control Register

      [0]    DISMCYCINT     Disables interruption of multi-cycle instructions.
             This increases the interrupt latency of the processor because load/store and
             multiply/divide operations complete before interrupt stacking occurs.

      M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html
      Does not have this bit.
     
  10. Like
    solipso got a reaction from jazz in TI-EStore New Year   
    Shipping to the Czech Republic is also $21. The difference between $7 to Germany and $21 to neighbouring CZ is insane. I can buy 7 pcs of STM32F103 devboards delivered from China for that $21, shipping included.
  11. Like
    solipso got a reaction from yosh in TI-EStore New Year   
    Shipping to the Czech Republic is also $21. The difference between $7 to Germany and $21 to neighbouring CZ is insane. I can buy 7 pcs of STM32F103 devboards delivered from China for that $21, shipping included.
  12. Like
    solipso got a reaction from RROMANO001 in TI will no longer accept .edu addresses for samples   
    This is the exact board we choose as our learning platform. It's a small world!
  13. Like
    solipso reacted to Rickta59 in USCI patch for parity   
    I was trying to port a sketch that used the Serial port with non standard UART parity and character length to Energia.  I noticed that the UART port isn't setup to handle anything except 8-N-1.  While the code below can't do all the combinations that are available to the atmega, it can do 7/8 bit, even/odd parity and 1/2 stop bits.  I created a patch that will at least fix it for the chip I am using (msp430g2553).  It will need some work for other chips. Apply the attached patch to the source of the latest Energia source tree. (as of 11/11/2015)
     
    -rick
     
    (See new optional second parameter https://www.arduino.cc/en/Serial/Begin )
    parity.patch
  14. Like
    solipso got a reaction from yyrkoon in TI will no longer accept .edu addresses for samples   
    Well, of course it had to be thought out, but as for the unreliability of sourcing - we ordered a boatload of MSP430 and TM4C launchpads from the TI e-store during years and invested into building courses around these boards .
    We had to re-think the term "reliability of sourcing" as soon as the prohibitive shipping of $21 came into account: Launchpads are made exclusively by TI. On the other side, STM32 boards are being made by many producers in China.
    As for the development/production costs, it is not the subject of these classes. For instance we use the free Keil MDK as our IDE. I doubt that any of our students will work with a code size limited IDE at their work. Moreover, I do not know any major hardware developer company here in the CZ using TI's Cortex M. As far as I am aware of, the vast majority uses ST, Freescale and NXP parts in their designs, therefore I see no point to stick with TI when teaching students some ARM programming basics.
    Also the experience of breadboarding with bare target board and stand-alone debugger will probably more resemble the real life of an EE.
  15. Like
    solipso got a reaction from tripwire in TI will no longer accept .edu addresses for samples   
    Well, of course it had to be thought out, but as for the unreliability of sourcing - we ordered a boatload of MSP430 and TM4C launchpads from the TI e-store during years and invested into building courses around these boards .
    We had to re-think the term "reliability of sourcing" as soon as the prohibitive shipping of $21 came into account: Launchpads are made exclusively by TI. On the other side, STM32 boards are being made by many producers in China.
    As for the development/production costs, it is not the subject of these classes. For instance we use the free Keil MDK as our IDE. I doubt that any of our students will work with a code size limited IDE at their work. Moreover, I do not know any major hardware developer company here in the CZ using TI's Cortex M. As far as I am aware of, the vast majority uses ST, Freescale and NXP parts in their designs, therefore I see no point to stick with TI when teaching students some ARM programming basics.
    Also the experience of breadboarding with bare target board and stand-alone debugger will probably more resemble the real life of an EE.
  16. Like
    solipso reacted to Rickta59 in TI will no longer accept .edu addresses for samples   
    I just noticed some inexpensive m0 boards the other dayhttp://www.ebay.com/itm/STM32F030F4P6-ARM-CORTEX-M0-Core-Mini-System-Development-Board-for-Arduino-/252101099984?
  17. Like
    solipso got a reaction from Taggsladder in Learning transistors and I have a problem :)   
    Hello,
     
    Forget relay, just whack an 1k resistor between the G of the Q4 and C of the Q2 and put a 10V zener across that 10k resistor and the Vgs of the Q4 is OK. Use a N-FET instead of the Q1 & D5 and you are ready to go.
     
    In fact, I would replace the Q4 with an N-FET too, just as a good practice. If MOSFETS cost half a penny each, why we still use BJTs? You can fly to the Jupiter just using the base currents of all those misused BJTs.
     
    Cheers,
     
    -=solipso=-
  18. Like
    solipso reacted to SvdSinner in Question about I2C, DriverLib and MSP-EXP430F5529LP   
    Schematic Issues:
    1)  No pull-up resistors.  Start by adding 10k pull-ups to both lines.  (Shouldn't matter which side of the level shifter you add them, but I'd try the 5v side first.)
    2)  No decoupling capacitors.  Add in caps between the 3v & 5v lines and GND.  Otherwise a spike/lull cuased by your LED matrix can cause all sorts of wierd issues.  Better safe than sorry.
    3)  You have no way to reset your slave device.  I'd recommend you use a GPIO with a transistor (high side switch) to allow your program to power-cycle the LED driver.  I haven't used that specific device, but I've seen other I2C devices get stuck holding down the SCL, and if you can't  power cycle it, it will block all I2C communications.  Remember that your slave doesn't reboot each time you restart your program.  Ideally, put the pull-up resisters after the switch, because some devices can function with the juice from the data lines long enough to not reset when you cut their Vcc line.
    4)  Consider adding points on your line to put an I2C sniffer.  (Hopefully, you have access to a logic analyser)  What you don't want is to have your lines getting wiggled every time you hook-up/remove testing tools.  
     
    Suggestions:***
    1)  Make sure everything is held securely while you get it working.  I use a chunk of cardboard and hot glue everything down to it.  You want to make sure nothing unexpected gets pulled out when things get bumped and cords get swapped.
    2)  Don't assume ANYTHING is working like you think it is.  Test your wiring connections for continuity.  Test all four lines with a VMM.  Test any pins/sockets/headers to make sure every pin has good contact. Huge amount of "problems" with I2C are just basic wiring problems.  
    3)  If you are starting from scratch, I'd recommend using the Energia code base and it's port of wire.h for I2C.  The TI I2C libraries are quite buggy (There are function in the driver library that simply don't work on an MSP430F5529 and will hang your program) and have an over-complicated programming model.  I'm currently trying to get wire.h to compile with the TI compiler, because I have some code that uses it 
    4)  Unit test every I2C call you expect to make.  Make a project that atomically does each function so you can prove the basics work before you integrate them into your code.  It is a bit of work, but much less work than trying to debug a program when you don't know which of the components are actually doing what you think they are.
    5)  Document every time things work correctly, preferably with source control.  If/when you break something as you add to the code, you want a clear place to return to if you don't like how your change turned out.
    6)  If you find a loose connector, etc.  Toss it out and use a better one.  Just because you can wiggle it and get it to work again for the moment, doesn't mean you won't spend more time & effort testing and wiggling it than it is worth.  (This advice might be more for me than you.  Can't tell you how many times I've been dumb enough to throw a bad connecter back into my parts bin so that I get to have the same problems again the next time I pull it out.)
     
    ***These suggestions mostly come from experiencing the pain of not using them.  Hope they help.  Troubleshooting I2C can be maddeningly complex if you don't work hard to ensure that your building blocks are solid.
     
  19. Like
    solipso got a reaction from zeke in RandomElectrons LP10062   
    Nice!
    But staring at the free space on the board, I would consider adding footprints for a couple of different M430s, for instance M430F2274 (which I like a lot) and M430G2955. That would make your nice design a lot more versatile.
     
    Regards, Tomas
×
×
  • Create New...