Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by spirilis

  1. Of course in hindsight I am probably stepping on some copyright rules by having this printed, but I don't think anyone's going to complain about that... it's a developer's manual and I am using it for developing with TI parts after all.

  2. I decided "for the hell of it" to print out the MSP430 chip family User's Guide, all 676 pages of it (slau445).  Total cost was ~$70 altogether including the $10 binder from Staples.  I used bestvaluecopy.com for the printing - printed in B&W, with a thicker color cover sheet, 3-hole drilled, shrink-wrapped, and put it in my own binder.

    Reading the more esoteric parts of the book - like the PMM, SVS and CS systems - is actually much nicer in print I found.  Just more comfortable to sit down at the table and *look* at the diagrams and text and hold my left hand under the page with the schematic/diagram while reading the details & refer back and forth.  Underrated way to consume these documents IMO.  I need to get some sticky notes or small sticky tabs (dunno why I didn't think to buy them when I was at Staples) to bookmark the important chapters (eUSCI peripherals, etc).

    The BestValueCopy order was $37.31 for the book (676p double-sided), $19.88 for shipping, then the Staples 400-page binder was ~$12 with tax IIRC.  For the smaller documents like the per-chip datasheet, I might have them do a comb-binding or similar.  Only issue is that shipping cost.  So I need to compare that with local services like staples or fedex kinkos..



  3. I may have posted about this a long time ago, but I had written a library to utilize the Nokia 1202 cellphone parts LCDs - there are a couple BoosterPacks we made years ago using this and I have at least 1 working board in my bin of parts.


    The library includes "msp430_spi.c", which provides an implementation of SPI for several chips including some of the FRAM chips (FR5969 and FR2433 iirc).  As the Nokia 1202 LCD does not break out the D/C line, it requires 9-bit SPI, and the "spi_transfer9()" function is defined for those chips (for all the eUSCI_A0/A1/B0/etc instances).  This one is tricky because it requires code written directly for your specific chip, toggling GPIOs between the USCI peripheral mode and standard GPIO mode so the 9th bit can be "simulated" using GPIO, then switched back to SPI mode and the remaining 8 bits transmitted using the traditional 8-bit spi_transfer() function.

    The library includes "ste2007.c" for driving the LCD, and a basic font set (font_5x7.h) including the TI logo at character 0x81+0x82 (print those 2 side-by-side in that order).

    You have to provide a function for driving the Chip Select line of the LCD, and edit ste2007.c to set your function's name for the STE2007_CHIPSELECT #define.

    Under terminal/ and terminal_lite/ you'll find a few implementations of a 16x8 character display, with printf-style display supported along with a cursor - and in the terminal/ subfolder, "msp430_stdio.c" actually implements the TI cl430 compiler's STDIO interface, so you can use the TI optimizing C/C++ compiler's actual printf() and other C stdio functions against this display.

  4. Kicking off my MSP430FR2433 hobby effort I looked into the RTC peripheral, which amounts to a really simple stupid counter, the likes of which I often used WDT for back in the day.

    It just counts up to RTCMOD and then fires the ISR.

    So without the fancy date tracking that RTC_B did on the Wolverine chips, I had to up the ante a bit and write myself a library to convert "epoch" seconds format (# of seconds since Jan 1 1970 midnight UTC) into a "struct tm" year/month/day/hour/minute/second/etc. structure and vice versa.  I looked around for other implementations and found some inspiration from an Arduino/AVR forum, but no real code I found of use.

    So I present msprtckit - https://github.com/spirilis/msprtckit

    It can provide the RTC_ISR for you (for chips defining __MSP430_HAS_RTC__ like the FR4xxx/2xxx chips), or you can ignore that and implement the counter yourself, then use rtc_interpret() and rtc_epoch() to convert the timestamp into useful formats.  It corrects for leap years, and only supports dates starting 1973. (made it easier to begin after the 1st leap year after the start of the epoch)

    The use of unsigned long means over 4 billion seconds will elapse before rolling over, so it might have a Y2.1K problem but we'll be long gone by then...

    At some point I want to implement timezone interpretation too.


    If you use the RTC_ISR that comes with the library, it will manage several things for you-

    1. rtcepoch (you need to initialize this yourself somewhere to match current time)

    2. rtcalarm0 & rtcalarm1 - epoch timestamps for 2 supported alarms

    3. rtcalarm0_incr & rtcalarm1_incr - if > 0, these will tell the ISR to auto-increment the appropriate rtcalarm0 or rtcalarm1 when it triggers so you don't have to re-set the alarms in your code

    4. These variables (rtcepoch/rtcalarm*) by default live in .infoA, which is FRAM.  You do need to have the DFPW write protection disabled for this to work & to allow the RTC ISR to update them:

    // Disable FRAM write protection for .infoA section, but keep enabled for program memory

    5. rtc_status is checked by your code upon wakeup to see if RTC_TICK bitfield is set, RTCALARM_0_TRIGGERED or RTCALARM_1_TRIGGERED.

    6. By default the processor will not wake up every time the RTC tick occurs, but you can tell it to do so (rtc_status |= RTC_TICK_DOES_WAKEUP after rtc_init() accomplishes this)


    Anyway you can probably guess this is a project I banged out in preparation for doing a clock in the future.

  5. Finally getting back into it.  No workbench yet, but I start a 4-week sabbatical after next week, so one task on my plate is to revamp the basement with new shelving + bigger work from home office & workbench.

    In the meantime, I noticed the older TI SimpleLink hardware seems to be deprecated - the latest SimpleLink SDKs no longer support them & it halts with PG1.x hardware (requires PG2.0+).  So I threw all those launchpads away.  I guess I'm getting old or maybe wise enough to realize when something isn't worth the effort...

    So my focus now is the MSP430FR2433 - the Value-Line FRAM launchpad and chip.  I'm just using CCS and the TI cl430 compiler, no more GCC for me.  Keeping it simple & fun, and as focused as possible.  I think that's the best way to roll, having too many options really distracts one and prevents you from really accomplishing personally rewarding stuff, so I'm narrowing my processor down.

    I was considering the FR2355, which I have a launchpad for as well - more pins & fancier peripherals.  But I kept thinking, you know, I'm never going to use all that stuff and it's probably wiser to (re-)start smaller.

    Compared to the original value-line chips, the MSP430FR2433 is pretty nice.  eUSCI_A0, A1, and B0 - 16KB FRAM and *4KB* SRAM - Not too shabby.  Even has a (quite laughably basic) RTC peripheral.  Available in some tiny packages should I ever build my own gadgets without the launchpad.

    Only thing I don't see in its hardware setup is Capacitive sensing support like the old G2553 had, where you set the PxSEL bits a certain way... I'll have to look deeper though.  That was a cool feature of the G2553.


  6. 7 hours ago, bluehash said:


    Looks like a nice space to spread your stuff.

    The last year was tough, but got through it. All my work is at home now, no active side projects... however I'm going to pick up an old powerwheels jeep for cheap and fix it up for my kid's birthday 😀

    Ha that is cool!  I guess one side project I need to pick up "at some point" (code phrase for "sometime next century if I'm still alive") is DIY electrification of our bicycles.  My son especially needs some motorized motivation... we moved to an area that's quite hilly!

  7. 1 hour ago, Rei Vilo said:

    Nice to see you back!

    I've terminated the embedXcode project (it is now under LTS). I'm switching away from Apple and transitioning to Debian.

    Many projects on IoT and displays, as usual, and starting to investigate AI with edge computing.

    AI and edge?  That sounds fancy... what kind of edge hardware?

  8. HI folks-

    Old time forum member here, but been away from the microcontroller hobby for a few years... sold my old house, moved to a rental for a year, now finally in a new "permanent" house for hopefully a long time.  The basement is an utter mess but I have all my electronics parts, soldering equipment, an entire bin dedicated to TI launchpads, stored in my crawlspace (w/ dehumidifier) for when I clean up this mess of a basement & set up my new workbench.

    So what's everyone working on these days?

  9. 1 hour ago, adalloul said:

    Yeah I am using VC0706 camera from adafruit link below, which uses Serial1 over P3_4 and P3_3. My GPS needs to communicate over UART same as the camera. However, for the GPS, I defined a tx pin and rx pin using the digital pins with SoftwareSerial (rx,tx) and it didn't work. The weirdest thing is the gps works perfectly with an arduino uno and mega.  

    camera link : https://learn.adafruit.com/ttl-serial-camera?view=all 

    gps link : http://www.kr4.us/venus-gps-logger-with-sma-connector.html?gclid=Cj0KEQjwmv7JBRDXkMWW4_Tf8ZoBEiQA11B2fqGRPuhktNFPyvZaPYk_xLK_ySCHRx9g-1Z_8A5RvboaAorz8P8HAQ

    I haven't messed with energia in a while but I am pretty sure SoftwareSerial doesn't work on that chip... it was meant for the really small MSP430G2452 and similar which didn't have a hardware UART.  Arduino handles softwareserial better.  Maybe someone else has a better softwareserial implementation around here, I don't know though.

  10. 2 hours ago, adalloul said:

    I have a GPS module from Sparkfun that uses Rx and Tx.. Can I use Serial1 same as the camera? man these MSP's are pain

    Bringing back threads from the dead!

    Can you provide more context here?  The GPS shouldn't use the same UART as another device (camera? what kind?) but otherwise yeah, Serial1 should work...

  11. I gotcha... I haven't personally used Energia with this chip.  I do know that in CCS, it's not good enough to set a #define somewhere for that, I have to make it a compiler directive using the project properties compiler predefine option.  So it's highly probable that Energia's not building it with CCFG_FORCE_VDDR_HH=1 correctly.

  12. For 14dBm, EasyLink might tell you 12dBm but only because the RF register setting for 12dBm is identical to the setting for 14dBm, the only difference is the CCFG_FORCE_VDDR_HH=1 which boosts the power to the RF stage internally a bit.

    Likewise, if you set it to 0dBm with CCFG_FORCE_VDDR_HH=1, your actual transmit power should (theoretically) be a little higher.  EasyLink's way of determining this won't tell you though.

  13. The typical use-case for the CC1350 (as opposed to the CC1310, or CC2640/2650) is as a local Sub-GHz to BLE gateway (helping to get sub-GHz information to a nearby cellphone).  So the idea here would be to have a CC1350 radio gateway in the vicinity of your cellphone, and a CC1310 (or 1350, but the 2.4GHz path wouldn't be used) inside the greenhouse transmitting the information long-haul over sub-GHz.

    Alternately, if antennas permit, you could scrap the whole thing and use the CC2650STK with an external antenna or something and hope your cellphone can receive BLE at that distance.  The one thing I'm leery of is the CC1350's support for two frequency bands, because they appear to share the same radio pins and so the radio hardware inside the chip is probably optimized for one frequency band but not the other (or it's a compromise for both).

  14. On 4/25/2017 at 9:57 AM, Medsimo said:

    my code is : 


    #include "NDEF.h"
    #include "NDEF_TXT.h"
    #include <RF430CL.h>
    #include <Wire.h>
    #define RF430CL330H_BOOSTERPACK_RESET_PIN  8
    #define RF430CL330H_BOOSTERPACK_IRQ_PIN    12
    double randomDouble(double min, double max, int numCasas){
      long _min = min * pow(10, numCasas) + 0.1; 
      long _max = max * pow(10, numCasas) + 0.1;
      return (double) random(_min, _max) / pow(10, numCasas) ; 
            double Freq = randomDouble(10.71, 10.79, 2)+1839755.00;
            double voltage_1 = randomDouble(0.82, 0.88, 2);
            double temperature = randomDouble(18.30, 20.00, 2);
            double vol = randomDouble(3.10, 3.29, 2);
    void setup() {
      Serial.println("Initializing I2C and RF430CL330H-");
      Wire.begin();                                                              // Initialize I2C subsystem
      nfc.begin();                                                              // Format RF430CL330H, prepare for data
      attachInterrupt(RF430CL330H_BOOSTERPACK_IRQ_PIN, wake_up, FALLING);      // Register interrupt to wake MCU when RF430CL330H INTO (IRQ) line triggers
      Serial.println("Creating NFC NDEF_TXT object-");
      String Value = "El valor actual de F_Tiva es de "; 
      Value = Value + (Freq/1000000) + " MHz. El V_Tiva detectado es de " + voltage_1;
      Value = Value + ", la temperatura_Nodo1 es" + temperature + ", el voltaje_Nodo1 es" + vol;
      Value = Value + ", la temperatura_Nodo2 es" + temperature + ", el voltaje_Nodo2 es" + vol + ". El informe de estado del equipo ha terminado. Hasta pronto.";
      Serial.println("Posting to RF430CL330H-");
      size_t ndef_size;
      ndef_size = Value.sendTo(nfc);                                       // Write NDEF data to NFC device memory
      nfc.setDataLength(ndef_size);                                            // Inform NFC device memory how much data is there
      Serial.println("Activating RF430CL330H RF link-");
      nfc.enable();  // Now we're live!
    void loop() {
      if (nfc.loop()) {
        if (nfc.wasRead()) {
          Serial.println("Something has read the NFC device!");
        if (nfc.available()) {
          Serial.println("Something has re-written the NFC device!");
        nfc.enable();  // If nfc.loop() returns true, it will have disabled the RF link as a side-effect.
      Serial.println("<low power sleep>");
      Serial.flush();  // wait for unsent UART data to flush out before going into low-power sleep
      suspend();  // Enter indefinite sleep (LPM4 on MSP430, DEEPSLEEP on ARM)
      Serial.println("<wake up>");
    void wake_up()
      wakeup();  // Signal Energia to wake the MCU upon IRQ exit

    I've errors .... 

    nfc_1.cpp: In function 'void setup()':
    nfc_1.cpp:40:21: error: 'class String' has no member named 'sendTo'
       Value = Value + (Freq/1000000) + " MHz. El V_Tiva detectado es de " + voltage_1;

    Allocate an NDEF_TXT object first instead of just composing your "Value" variable and trying to send it directly over the NFC:

    NDEF_TXT t("es", Value.c_str());
    int ndef_size = t.sendTo(nfc);

    Note the first string in the NDEF_TXT constructor is the language code describing the language used for the text.

  15. Aand. .. Arrow's still doing free shipping, no code needed.  $50 minimum for international orders.  I'm guessing they're pushing hard to gain a presence in the small-order online commerce arena, but that's good for us! (for now, while shipping is free :D )


    For the most part their online ordering process has improved since last August when I found much to gripe about, and they gave me a contact who manages the web development and I've written him once or twice to report issues I've seen.

  16. I was going to go with MKE04Z8VTG4 (48MHz, 5V, TSSOP16, $0.60,) but a) had some issues with their tools, B) latency is 15/?, c) don't really want to deal with complexities of ARM (my code is super simple.)


    RL78/G12 sounds like a winner, I will look into it.

    Not sure what the JTAG tools run for those, although I think they have a serial bootloader of sorts (the big brother RX series do anyway), and the arch is a modern evolution of the Z80 (taken from NEC when NEC sold their semiconductor division to Renesas) from what I gather.  Not important for a smaller chip but, for larger RL78/G14's and such with >64KB flash and/or SRAM, the architecture still uses a 16-bit address bus but with special paging that requires the compiler use "trampoline" code to switch pages as needed (should be transparent to the developer though but adds latency to function calls)..... but, for a super simple program on a small chip, you'll never encounter this.


    edit: For JTAG, the Renesas E1/E20/etc series of emulators are specified, the cheapest variety is the E2 emulator Lite which is ~$65ish.

  • Create New...