Jump to content
43oh

spirilis

Members
  • Content Count

    3,399
  • Joined

  • Last visited

  • Days Won

    146

Posts posted by spirilis

  1. @@zeke

    On the topic of TI-RTOS, for which I am slowly drinking the koolaid droplet by damned droplet .... I highly recommend starting HERE: http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer

     

    Once you've wrapped your head around RTSC XDC, TI's old excuse-for-not-using-C++-by-inventing-an-OOP-layer-on-top-of-C-probably-ancient-from-the-old-days-when-C++-compilers-were-unstable-or-didn't-exist-even-though-shit's-different-now-and-they-should-just-scrap-the-damned-thing-and-use-C++-in-earnest-but-I-get-it-I-really-do-they-just-have-too-much-time-and-effort-invested-in-it-to-give-it-up-oh-and-many-professional-embedded-developers-still-don't-trust-C++, much of the TI-RTOS components start to make a little bit of sense.

  2. Works fine under Linux too ? I seem to recall people having the odd problem with it, but maybe I'm thinking of the other gcc compiler ?

    Works great under Linux, never heard of any issues with it.  Yes you may be thinking of the RedHat-developed msp430-elf-gcc compiler although TI releases the binary builds of that these days with patches and all.

  3. I could always just connect a pin in input (they are input by default) to the reset pin and set it to output and digital low/high (don't remember but I think it's low) when you want a reset

    ?There are registers you can use to make a reset like greeeg said but I don't remember them on the top of my head

    One thing I've wondered about this is how reliable it is - i.e. does the gpio stay in output long enough to satisfy the minimum reset pulse requirements. You'd think so since the gpio won't release until reset actually takes effect, but I wonder if that's "long enough" for a clean reset.

     

    Some type of external logic or RC timed circuit would help with that.

  4. I bought two of the Hercules RM57L launchpads. I wonder why these aren't popular? At 330 mhz they could almost emulate an MSP430 and they look pretty classy.

    Almost way too overpowered, and the dev environment is a bit unconventionally restrictive - you have to use HALCoGen to generate projects and CCS for the coding/building/debugging.  Not too bad for folks already comfy with the CCS toolchain et al, but it's still quite esoteric.  Probably 99% of hobbyist projects have no need for the power too... although there's a "Jan Cumps" on twitter from Belgium who's adopted the Hercules as his pet MCU of choice for giggles.

     

    This is all mostly due to its "safety critical" nature, which shapes everything about how TI supports it.  TI's own TI-RTOS (aka SYS/BIOS aka DSP/BIOS) doesn't even support it, they include project generation for FreeRTOS for those who want an RTOS on the chip.  FreeRTOS does have safety critical "support" via their SafeRTOS variant.

     

    OTOH the fact they have an all-in-one project generation tool that supports all the peripherals including the fascinating custom-VLIW instruction set "HET" timer is a bit envy-worthy; most TI MCUs just don't have such an "all in one" configurator.

     

    Anyway I recommend you roll with it regardless!  There's probably a lot of cool stuff you can do with those with the right motivation.

  5. Well, it seems that the "SimpleLink Starter" Android app is finally available. It's still quite SensorTag focused, but does support the CC2650 Launchpad. It also references the as yet unavailable WiFi SensorTag.

     

    I've still not done much with the LaunchPad. When Google open-sourced their Thread protocol I thought it might be possible to link a launchpad up to a Nest mesh network, but that doesn't look likely any time soon according to TI employees over on e2e. Even the documentation and support on 6LoWPAN seems lacking for the CC2650 right now.

    Yeah my understanding was OpenThread was targeting sub-GHz anyhow (CC26xx is 2.4GHz IIRC)

     

    CC1310 will probably be the platform for OpenThread. I have two of the CC1310 LP's, even they feel a little "green" on the examples and code so far. Seems like an awesome chip so far though. Tiva-like peripherals and all.

  6. Maybe the wiring is wrong?  I have no issues talking to a MAX31855 with my Tiva LP fwiw.  I don't know anything about the MAX31865 but I'd be shocked if it worked much different...

     

    Be sure the Chip Select line is left in a HIGH state when inactive and pulled low before any SPI comms.

     

    e.g. if the MAX31865 CS line is connected to pin 4,

    void setup() {
      pinMode(4, OUTPUT);
      digitalWrite(4, HIGH); // set INACTIVE
      SPI.begin();
      Serial.begin(115200);
    }
    
    void loop() {
      // Read from the chip
      digitalWrite(4, LOW);  // MAX31865 is now ACTIVE and will clock out bytes
      uint8_t fourbyte[4];
      fourbyte[0] = SPI.transfer(0);
      fourbyte[1] = SPI.transfer(0);
      fourbyte[2] = SPI.transfer(0);
      fourbyte[3] = SPI.transfer(0);
      digitalWrite(4, HIGH);  // Deactivate MAX31865 so it releases MISO line for other SPI devices.
    
      Serial.print("Output: ");
      int i;
      for (i=0; i < 4; i++) {
        Serial.print(fourbyte[i], HEX);
        Serial.print(' ');
      }
      Serial.println();
      delay(1000);  // wait 1 second then do it again
    }
    
  7. Ahhh...

     

    From page 965 of the TM4C123GH6PM manual:

    15.4 Initialization and Configuration
    
    To enable and initialize the SSI, the following steps are necessary:
    
    ... blah blah ...
    
    For each of the frame formats, the SSI is configured using the following steps:
    
    1. Ensure that the SSE bit in the SSICR1 register is clear before making any configuration changes.
    
    

    The problem here is I was running MAP_SSIEnable(SSI2_BASE) in main() (which sets SSICR1.SSE), but my gatekeeper task does custom reconfiguration of the SSI peripheral for each request to configure which DMA request lines it cares about (TX but only optionally RX), along with what speed & bitrate will be used.  Removing that and doing:

                    MAP_SSIEnable(spi_base);
                    MAP_uDMAChannelEnable(udma_tx_chan);  // BOOM! Off to the races.
                    // Pend on binary semaphore for SSITx IRQ to signal uDMA completion
                    xSemaphoreTake(irq_swi_trigger, portMAX_DELAY);
                    // Deactivate GPIO CS
                    if (do_gpiocs) {
                        MAP_GPIOPinWrite(currentReq.cs_gpio_base, currentReq.cs_gpio_pin, currentReq.cs_gpio_pin);
                    }
                    MAP_SSIDisable(spi_base);
    
    

    inside the gatekeeper task's main loop instead solves it.  Only "SSIEnable" the peripheral when we're ready to roll, then disable it after.  Got a working waveform on a TX-only test so far, will test TX/RX later.

     

    In my previous (non-C++) example, the SPI speed was never modified by the gatekeeper i.e. the client tasks could never "request" a different speed or bitrate so that was configured before the init function's MAP_SSIEnable() call.  That's what changed here.

  8. Ahh, but the uDMA control word's XFERMODE was still set to BASIC.  uDMA is supposed to set that to NONE when it's completed.

    So it's not completed, but clearly it has advanced?  So maybe the SSI peripheral is frozen... but I'm still not sure what I did wrong there.  More digging

  9. Okay, whatever this problem is, it's an odd one.  The SSI2 IRQ isn't firing.  From what I can gather, the uDMA is doing its thang seeing as the control structure's source address appears to be advanced to the end by the time I pause the debugger and look, but the SSI2 FIFO is empty.  I have the SSI2 peripheral configured to send TX info to the uDMA so I don't know what's wrong.  The uDMA CHIS register is still 0 so maybe that's why the IRQ didn't fire.  But my logic analyzer isn't seeing any change in levels either.

     

    So I'm stumped.  I'm sure it's a software issue since my previous example (pre-C++) worked, but, reverse engineering what's happened here is taking some patience.

  10. Unless you are going to build a bunch, isn't $9 for each C110 Boosterpack board a good deal?  You get a FCC certified Anaren C110L module, the PC board, passives and a MSP430G2553 you can place on the boosterpack to make a standalone node.  The Anaren A110LR09A module by itself is $10+ in single quantities.

    Yeah putting it that way, it's cheaper than I realized.  Just gotta add power and boom!

  11. @spirilis  I have played with those.  Was able to achieve a pretty decent range in a building comprised of concrete and steel.

    That's pretty cool.  Long-term I want to build my own CC110L based boards to drive the cost down, IIRC someone here rolled a CC110L-from-scratch board and said the passives and PCB design was quite easy, workable with 2-layer PCBs and all.  It's probably the cheapest "TI" option for proliferating sub-GHz house networks (along with a CC1310 type of chip for the base station with its awesome RX sensitivity).  Assuming they actually do work together at the RF protocol level...

×
×
  • Create New...