Jump to content
43oh

spirilis

Members
  • Content Count

    3,399
  • Joined

  • Last visited

  • Days Won

    146

Posts posted by spirilis

  1. I am going through the edX/UT Austin RTOS class using the MSP432 and it's been fun. A great idea for the latter half of the Flash is to implement a simple filesystem.

     

    The Cortex-M4F's big break relative to the MSP430 is probably the possibility for DSP work. Some day I want to do rapid sampling of something (accelerometer probably) and apply some DSP filters to condition the data on the MCU before reporting it. Having an onboard filesystem would allow you to store a good bit of aggregated data remotely and then dump it via USB UART later (perhaps build a command line interface thread for the RTOS which can manage the filesystem).

  2. I know @@energia is working on it.  I have personally dove into the TI-RTOS & CCS stuff (no CCS license needed to use the TI ARM compiler or GCC) and don't have any need for the Energia framework... I suggest it's worth the adventure.  Maybe not as simple as Energia but it's here now (and it's really not *that* bad once you get over the odd XDC framework that TI-RTOS uses for all its software provisions).

     

    Fwiw I wrote a sub-1GHz MAC framework of my own design - https://github.com/spirilis/smac_tirtos - adds more logic (including carrier-sense-before-TX) above what the TI "EasyLink" library provides.

    edit: I should probably get around to documenting how to use the smac library before I post it in public :-)

  3. @@spirilis

     

    Do you think you will apply the RTOS code / techniques developed in this course directly in your own projects or is it more a good educational experience on how things work? Just curious...

    My current projects have all used TI-RTOS since the platform basically requires it and/or is unsupported without it (CC1310), so the course has been mostly educational experience, however, I will pay closer attention to the Clock module and use of hardware timer interrupts for clocking any hard-real-time stuff from now on.  The practical advice on handling DSP process flow was useful and I can see that coming into play, the PID stuff too.  I think the use of some sort of tick or GPIO toggle to indicate task switching/execution bears serious consideration -- if TI-RTOS has a "hook" you can execute upon beginning a task (something I will research shortly), that would be a great place to put a GPIO toggle so I can view my tasks' execution & suspension with a logic analyzer.

     

    So yeah, some of this & that.  Chips without an RTOS or without one I like, I feel like I'm now armed to build my own.

  4. One of the cooler things about the course is the casual introduction to various use-cases, section 4.1 particularly.

     

    4.1.4, "Real-Time Control Systems" had one of the best descriptions of PID control that I've seen as it involved both practical descriptions and math--including casual mention of such scary terms as "Lorenz transforms" (which I still don't understand) but no requirement that you truly grok them, as the page included very practical advice on what the P/I/D segments do.

     

    The 4.1 subsections prior talk about DSP and introduce the MACQ, or Multiple Access Circular Queue, along with tacitly demonstrating an optimization (where you allocate 2X the memory required and maintain 2 copies so that 1 copy can always be walked by simple address incrementing without having to check the circular buffer address boundary).  Having noticed that many DSP oriented chips include hardware support for "circular buffers" (where the address can increment or decrement ad infinitum and the hardware does the modulo/bounds checking for you), I understand now why they're such a big deal.

     

    Cool stuff.

  5. Yes.  I've seen software examples, but they look even more challenging, and present timing issues.

    Having taken time to RTFM, I realize that my TI example for the 2xx side is likely part of the problem.

     

    The only reason for the I2C is that the master is already in a HID "conversation" with the PC, and I'm more or less hijacking that input/output window without the extra connection to the UART and terminal window.

    Yeah in your scenario I think using I2C for this purpose is fine.  Probably makes sense to have a GPIO on the F2013 signal to the F5529 that it has SD16_A data to report (as a matter of flow-control).

  6. I'm doing Lab #2 right now, which is where you write your first RTOS scheduler and make the whole time-slicing scheduled thread concept work for the first time... and I just want to add, this is a ton of fun!!!

     

    Class is taking more time to go through than I thought it would, mostly the lectures, but I'm making time for it here and there.  There are 6 sections to the class and only 1-5 are up right now, #6 I think is the actual communication with the CC2650 Bluetooth Low Energy coprocessor (where you use either the TI CC2650 BoosterPack or the CC2650 LaunchPad in boosterpack mode).  The bulk of the code being run here is already written by the professors in the "BSP" library, e.g. for communicating with the LCD and drawing lines/text, reading the temperature sensor, accelerometer, etc.  Your job is just to learn the specific core facilities that an RTOS provides.

     

    The "magic" of an RTOS and simulating multiple threads on a single CPU wasn't as complicated as I thought, and while the particulars of this course only teach ARM's specific way of context switching I generally understand the analysis required to implement this on another chip:

     

    1. Understand exactly which registers get pushed onto the stack when an interrupt occurs and in which order

    2. Push the remaining registers

    3. Know exactly how to exit an ISR correctly - the actual context "switch" relies on this

  7. I had a somewhat lousy experience with Arrow during the RPi3 promo; while I ended up getting all my goods (although the Pi T-Cobbler adapter I bought evidently was the wrong kind, which wasn't obvious on their site at the time), they shipped it in 4 separate shipments that appeared to come from the same location, thus inflating the shipping costs.  I went along with it anyhow (as the total shipping cost at $16 was still less than a Pi3) thinking they just source from lots of locations but that was not the case.

     

    For kicks, I decided to try the free shipping today (since it's the last day for it).  Got 50 of the Fox FX135A-327 (used with my CC1310 boards, seems like a nice & super compact XTAL).

     

    I used paypal for payment, and Paypal sent me their confirmation email that I was charged, but the Arrow website never produced an Order confirmation page (had a progress bar animation going for 10 minutes before I closed the tab) and I see no evidence of my order in the "Order history" page.

     

    I do have a marketing contact from Arrow who followed up with me on my previous order so I sent her the details and asked her to look into it.  Thankfully Paypal includes the vendor's Invoice ID so she will have a reference# to look up.

    I recall back in August when I ordered a bunch of parts, I could never see the invoice or manifest on their website; when I tried the online chat support to ask why this was so, they seemed to dismiss it rather quickly as a "known issue".  Sounds like a bunch of amateurs running the site's backend who don't have their s**t together IMO.

  8. What?!!  That's not possible.

     

    It could be true but it doesn't make sense.

    Nevermind it's just what bluehash's message said, they're restricting it.  My email domain ends with .net so that must flag TI's order system from allowing me to sample for free.  I remember this change occurred when the TI store started selling individual chips and the free shipping disappeared...

  9. This is pretty much what we're doing already, except the solution is not all in one chip. Connectivity is all via I2C though. Which I still have to work out in code for the msp430, For the board we just did a production run on, we did not use I2C. Just a single GPIO, and a toggle count to enable the watchdog feature. It's actually pretty awesome for me to watch it working, as the very first time I ran it it caught, and dealt with a failed boot on the beaglebone. Which is of course why I came up with this idea to begin with. The rest of the features I added after observing the beaglebone in action for 3 and a half years, while noticing 'minor' flaws. Minor as in they are minor flaws, until you actually need the board to go into a production system. Then they become serious flaws.

     

    The real cool thing is that none of this requires anything special on the beaglebone to function correctly. Software wise. You can even run all of this without any special drivers on the beaglebone side. It's a simple matter of connecting these devices to an I2C bus, and using i2c-tools utilities if the user so wishes. However, Linux also has a 'built-in' driver for the ds3232 RTC, which is fairly handy, and really simple to use too.

     

    Anyway, it is my hope to keep costs below $25 per board if possible. The more features added however . . .will increase the cost, of course. Which is why I think adding power switching circuitry is not necessarily a good idea. Regulating a wide range input, maybe. However, with that said, perhaps something like an 'add-on' could work ? I'm kind of envisioning something like a grove connector, that would allow inexpensive add-ons via an i2c bus( for control ).

     

    EDIT:

     

    @@bluehash I was talkign with a friend of mine about cell phone dongles, and he claims that there are USB dongles that cost less than $20. I have not looked into this myself, but if they truly do exist in this price range. It then becomes a simple matter of "bullet proofing" the software ? I'll look into it.

    I think having specific support on the board for "daughterboards" providing advanced power support is a great idea.  A pinout giving access to 5V, GND, maybe 3.3V, and I2C along with perhaps a GPIO or 2 (maybe for the circuitry to "interrupt" the Sitara without requiring I2C polling?)

  10. I never bothered to follow up with my idea below but I do think a switching regulator for 12V (maybe modifiable to work up to 60Vin for flexibility with different offgrid DC power systems) is a good idea.

     

    I designed and built one copy of a 12VDC PFET power MOSFET cape which had an off-the-shelf 12V (7-36Vin) to 5V out switcher onboard. It worked great. I highly recommend including one for your design.

     

    The idea behind my cape is 12V could be switched on/off to up to four outputs for remotely controlling power for various sub-5A sources e.g. a low flow pump. The beaglebone is powered by the same 12V source obviously.

×
×
  • Create New...