Jump to content
43oh

spirilis

Members
  • Content Count

    3,399
  • Joined

  • Last visited

  • Days Won

    146

Posts posted by spirilis

  1. That's great!  I bought a 2nd one expressedly for that purpose although I haven't used it yet (don't have my soldering equipment out of storage yet so the debug header isn't mounted yet).  Do you have any links or guides on how to use this with Arduino?  (does it come with GDB and is there a GUI or is it all CLI driven GDB usage?)

  2. I'll admit I'm a little embarrassed that I didn't look into other offerings, like the Feather.  Probably would've skipped the Pico.  Alas, I have 2 of them now so might as well proceed with what I have.

    edit: Although, I see the Feather doesn't have castellated pins like the Pico and knockoffs do, so that's a factor.  Maybe not though.  Soldering castellated pins means you can't use the board space under the Pico for SMD parts, while through-hole gives you a small amount of clearance for some low-profile SMD parts.

  3. I'm also aware of this: https://www.tindie.com/products/invector/challenger-rp2040-lte/

    RP2040 board with 4G LTE, that would be so nice.  I am going to try to make WiFi work for me for now though.  Key here is to have public wifi access points programmed in so it can "opportunistically" check in while on the go, if possible.  Otherwise just having it attach to my home wifi, which is on the opposite side of the basement wall from the driveway, is great for me.

  4. For those following along, here's a few good links to bookmark:

     

    RP2040 Datasheet: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf

    Pico datasheet (the board): https://datasheets.raspberrypi.com/pico/pico-datasheet.pdf

    RP2040 Hardware Design recs: https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf

    Pico Pinout diagram: https://datasheets.raspberrypi.com/pico/Pico-R3-A4-Pinout.pdf

    Earle Philower's Pico core for Arduino: https://github.com/earlephilhower/arduino-pico

    Documentation for Earle's Pico core: https://arduino-pico.readthedocs.io/en/latest/

     

    The RP2040 has an interesting programmable I/O controller called PIO.  Here's a video on it: 

    It's also a DUAL CORE Cortex-M0+ that Arduino supports.  Here's a video on the dual core aspects: 

     

     

    A

     

  5. Previously I indicated I was going to hunker down with a nice warm cup of MSP430FR2433, and I still love that chip & will keep it in reserve for future "small" projects, but it turns out I have a big project I need to tackle soon, particularly jarring since I'm not "in the zone" with MCU development & electronics, if you know what I mean.

    I've heard somewhere around February 2022, AT&T is shutting down its 3G cell network in the USA - https://www.att.com/support/article/wireless/KM1324171/

    Unfortunately many "connected" vehicles built in the past 10 years depend on 3G for their remote management features, not the least of which include both of my Ford electrified vehicles (2017 Ford Focus Electric, 2017 Ford C-Max Energi).

    Ford has sent out a service notice to all their customers indicating they have 4G replacement modems available for these vehicles.  Ford will cover the labor for installation, however, the customer must buy the modem, and I haven't checked yet but others online state it's around $400.  The app you use to remotely manage the car changes, and the new app (FordPass) does not support many of the advanced features these EVs have (such as GO Times, a way to tell the car to preheat or pre-cool itself entirely using EV Charging Station power).

     

    So you know where I'm going with this..... I need an OBD-II attached remote management platform.  I'm not sure if the diagnostic OBD-II port in the car gives me the kind of access I need, but I'm willing to replace the telematics control unit (modem) in the trunk and connect to its OBD-II bus if need be to get it going.  In any case, I want to build a board that can run off 12V, supports WiFi, and CAN bus.  I'm also just getting back into this game and want to make sure my platform is "widely supportable", and to me, that means Arduino.

    It also means using off-the-shelf hardware that's easily available and less obscure than some of TI's offerings.  Also RPi has a certain amount of street cred in the maker market, so that's a plus.  I've decided to standardize on the RPi Pico and build a hardware platform around it.

     

    Thus far I'm playing with this, an ESP8266 WiFi AT-command processor: https://www.waveshare.com/wiki/Pico-ESP8266

    Writing software to properly manage AT commands in an Arduino C++ environment is a bit alien to me, and I haven't bothered going out looking for other libraries that support it; I want to write my own.  I want to use my own knowledge to perfect this top to bottom.  Eventually going to write, or rip off & modify, someone else's MCP2515 library for the CAN bus support (assuming that works; I do have a CAN bus boosterpack I designed which I could hotwire with jumper wires to test CAN bus out on the Pico, but eventually I want to build my own, and oh by the way, the "supply chain issues" have made CAN bus chips a bit hard to come by, but I have a small stash in my bins, so I'm going to use what I have here)

    That said, I've already made some progress-

     

    The default Pico "SerialUART" library in Arduino was crap and didn't employ either the ARM PrimeCell UART FIFOs or IRQs of any kind.  So I ripped it off & redid it- https://github.com/spirilis/PicoHWUART

    I also wrote a Command CLI processor that uses a generic Stream object, such as a Serial port (genericized so in theory I could run this CLI over a TCP socket, through the ESP8266, once I have developed a high level Stream-implementing library to handle TCP connections over that stack).  https://github.com/spirilis/CommandInterface

  6. 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.

  7. 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..

    20210608_162220.jpg

    20210608_211740.jpg

  8. 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.

    https://github.com/spirilis/msp1202

    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.

  9. 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
    
    SYSCFG0 = FRWPPW | PFWP;
    

    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.

  10. 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.

     

  11. 7 hours ago, bluehash said:

    Hello!

    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!

  12. 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?

  13. 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?

  14. 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.

  15. 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...

  16. 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.

  17. 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.

  18. 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).

  19. 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
    
    RF430 nfc(RF430CL330H_BOOSTERPACK_RESET_PIN, RF430CL330H_BOOSTERPACK_IRQ_PIN);
    
    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.begin(115200);
      delay(1000);
      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.flush();
        }
        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);
    nfc.setDataLength(ndef_size)

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

×
×
  • Create New...