Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by spirilis

  1. I find mine is quicker than my particular toaster oven was.


    and I set and forget mine. The profile I have runs for 7 Minutes.


    My workflow goes like this:


    • Apply Solder paste to 4 PCBs
    • PnP components for 1 PCB (manually with vacuum pickup tool, and tape laid out flat)
    • Place PCB in Oven, run cycle
    • Continue to (2) if more PCBs remaining.

    The vacuum pickup tool has halved my manual placement time. Highly recommend over tweezers.


    Note the temperature of IR heating elements isn't ideal for PCB reflow*. Because it's Radiation heating vs Convection heating. The thermocouples generally don't track well with the PCB temperature.

    Once you've tweaked the profile for your PCBs it works great.



    *IR / Radiation heating for PCBs is bad because the temperature rise of the PCB will be related to the emissivity of the PCB. ie a black soldermask PCB will heat more quickly than a green one.

    What solutions would you recommend for the vacuum pickup tool? I've wanted one for a while...
  2. Well you know guys, when I look at that simplified schematic that is using flow chart symbols . . . I can't make head nor tails of it. So, I'll have to take your word on it.




    You're misunderstanding the question. Of course you can only read from one channel at a time. But You can have all 8 channel hooked up simultaneously reading one after the next very quickly. Which is how every SAR module from TI, that I've used so far, works. But, we only want to use one channel of the ADC, and mux the other pins for a different use.

    I think the point is yes, you can do that.
  3. The ACLK will run off the VLO if the LFXTAL isn't present. So you'll configure timers to use SMCLK instead.


    I wanna say it's TASSEL_2 for that (no datasheet in front of me atm as I'm on a phone), but you'll need to implement the clock divider (in TA0CTL) and maybe SMCLK itself should have a divider in place. See BCSCTL2 for that (IIRC).

  4. @@spirilis


    I checked the large amount of MSP430 code you wrote for the nRF.    And the BBQ monitor - quite good stuff.


    QUESTION ---  do you think there would be much problem to port it to the MSP432 (432) Launchpad?


    Please, no need to get too specific, but I'd be interested to hear your opinion.


    Thinking aloud --- I'd like to use an MSP432 LP  plus  a  nRF with the PA + LNA + antenna as a master station.

    Slave stations based on MSP430G2553  plus  nRF  on their low-cost PCBs with the track antenna.


    (alternatively, I have a couple of old Stellaris LPs which I could use as a base station  --   did I see that someone ported to Stellaris?).




    Oh yeah that would be a great way to go.  I was going to do a Tiva/Stellaris port at some point but didn't bother with it.  Haven't done enough with them since to make it worthwhile.  (On to other hobbies these days it seems)

  5. what's a "Basic Timer"?  I don't think the G2553 has it anyhow...


    It has Timer_A and WDT.  MSP430 Wolverine series chips (FR5969) has WDT, RTC, Timer_A and Timer_B... F5529 has similar...


    Basically Energia does give you what you need, although the Timer_A PWM output stuff is done via analogWrite or you can use the timers directly via their SFR registers (TA0CTL, TA0CCTLx, etc) so long as you don't try to use analogWrite at the same time.  WDT is (ab-)used for the millis()/micros() "tick" along with the sleep, sleepSeconds timer.


    So, I've been experimenting with sleep, sleepSeconds, suspend() and wakeup.
    These are AWESOME by the way...
    Here's what I've found.
    suspend() puts the controller into LPM4 which makes it ONLY come back to life after a hardware interrupt is properly handled.
    sleep and sleepSeconds() put the controller into LPM3 which allows it to wake up when the timeout specified in the sleep() or sleepSeconds() calls expires.  You can ALSO wake it up from LPM3 with a hardware interrupt and call wakeup() inside the hardware interrupt handler.
    So, when we are in LPM3 or LPM4 modes, we are not supposed to use delay() or Serial.print() commands.  It has been said on the forums that you need to be sure to call Serial.flush() after a Serial.print() if you plan on going into LPM3 or LPM4 modes.  
    My problem is that even when I do call Serial.flush(), I sometimes have my controller locking up inside the HardwareSerial::write() function:
     size_t HardwareSerial::write(uint8_t c)
         unsigned int i = (_tx_buffer->head + 1) % SERIAL_BUFFER_SIZE;
         // If the output buffer is full, there's nothing for it other than to
         // wait for the interrupt handler to empty it a bit
         // ???: return 0 here instead?
         unsigned int giveup = 0;
         while (i == _tx_buffer->tail);
         _tx_buffer->buffer[_tx_buffer->head] = c;
         _tx_buffer->head = i;
        #if defined(__MSP430_HAS_USCI_A0__) || defined(__MSP430_HAS_USCI_A1__) || defined(__MSP430_HAS_EUSCI_A0__) || defined(__MSP430_HAS_EUSCI_A1__)
         *(&(UCAxIE) + uartOffset) |= UCTXIE;
         *(&(UC0IE) + uartOffset) |= UCA0TXIE;
         return 1;
    The while loop above becomes an infinite loop.  So, is there any way we can perhaps fix this loop so that we don't have it be infinite.  I think that it should just timeout after 2-3 seconds or give up after a certain number of iterations and return 0...  Then, we aren't locked up.  I'd rather have some text undelivered than have my program lock up...
    I've noticed that the lock up occurs when I have a call to Serial.println() immediately after my call to wakeup(), or if I call Serial.println() immediately after a call to sleepSeconds().  
    So, any advice on how to avoid locking up when using sleep, sleepSeconds, wakeup, and Serial.println near each other would be greatly appreciated.



    "I've noticed that the lock up occurs when I have a call to Serial.println() immediately after my call to wakeup()"


    Serial commands should not be run inside ISRs!  ISRs are the only place where you run wakeup().


    A sleepSeconds() command (run from main execution context, i.e. not inside an ISR) shouldn't cause trouble with a Serial.println running afterward.


    Can you post some example sketches where you've run into problems?


    While I do generally agree one should not lock up with an infinite while loop, the implementation is quite space-sensitive (as the G2553 is pretty constrained on memory) so the additional code space to implement a loop there will probably not be welcome.  Maybe not that big a deal to add, but still, a counter will probably be more complex to implement than you might imagine while ensuring valid use-cases don't drop bytes on pending output at low baud rates.

  7. Hmm.  What next...


    I said next I'd do networking.  I think in preparation for that I should remake the gatekeeper task into a C++ class that's semi-encapsulated away (for simplicity's sake and to start down that path), then make it into a task utilizing GPIO SPI chip select management, SPI write/read/read & write, and uDMA.


    After that, the SimpleLink WiFi CC3100 library should be attempted on Tiva.

  8. I guess SPI single-byte transfers usually are ridiculously fast to the point that it's more efficient to busy-wait the CPU than to let the RTOS go through multiple context-switches (via some delay) until the task is ready to write the next byte.  Task switching in RTOS land makes more sense for buffer-at-once (>=4 bytes we'll say) transfers with DMA.


    Not too familiar with the TI-RTOS stuff, but if the AIR430Boost library does large buffer-per-request type of SPI transfers, then semaphore (task-suspend) synchronization is the ideal.


    It's sort've a shame that Arduino/Energia doesn't really have buffer-transactional API functions built in.  There is the .beginTransaction and .endTransaction stuff (not sure if Energia implements it, it didn't for msp430 or Tiva last time I checked) but what I've seen of the implementation has implied that this is more about encapsulating SPI settings and securing the SPI bus against interrupt service routine intrusion (i.e. you still do byte-by-byte transfers that are real-time on the bus with the sketch code's execution, but you can expect any ISRs that have registered the fact they do in-ISR SPI transfers have had their IRQ lines disabled temporarily).

  9. The real problem always boils down to the ownership IMO. Cloud this, cloud that smells offensively to me of greedy entrepreneurs trying to shoehorn a rent-seeking paradigm into something that should be anything but. It's stunting the widespread adoption IMO by keeping it only within the realm of the wealthy and early-adopting type of folks. The terms themself in combination with the verbiage used around it defines the space of what people know and think about, to the marketer's advantage.

  10. Yeah, that part of my signature might become obsolete. delay() used to loop until the set time has elapsed, essentially "burning" CPU time. Better to set a timer and go to low power mode. The low power mode you can use depends on which functions you need to operate while in pow power.

    Newer Energia releases use low power during delay(). Delay cycles still burns CPU time, so you shouldn't use that.

    fwiw, this is something everyone gets a little wrong (and/or make up the details if they didn't already know), but on MSP430's Energia core, delay() always used LPM0 ;-)  Not a terribly "power efficient" sleep but a LPM mode nonetheless.  SMCLK would stay running for proper UART I/O etc.


    It's the new sleep, sleepSeconds, suspend calls that use LPM3/4 or whatever the Tiva, other ARM equivalents have.


    I do believe delay() always ran a busy-wait on Tiva and other ARM platforms though.

  11. Yes, I see. The downside seems to be a major increase in complexity per node.

    michanisani claims in


    that when using




    up to 8 clients can connect to a single CC3200.


    Likewise, "energia" seems to imply in 


    that the "Station mode" might allow such a connectivity. 


    I do not fully understand the low-level details there.


    Is the consensus of those posts, that in principle, peer-to-peer communication with multiple partners is in principle possible on CC3200 apart from the mentioned "bug" in the latter post ?

    Is the possible "bug" still there ?

    Oh, ok, that would be different from what I understood... I thought "Station" mode just means that it's connected to an AP.  The problem here is you're trying to *implement* the AP, per se, along with the fact that your solution is maintaining peer channels to other devices to construct a mesh, correct?


    @@energia am I on the right track that the CC3200 in AP mode only allows 1 client to connect?  Regardless a single CC3200 won't make a "mesh" topology as I believe this application is attempting to do.  Multiple WiFi transceivers will have to be involved for that.

  • Create New...