Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by spirilis

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

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

  3. I'm a little embarrassed to admit, but, I had no idea the Linux 'sleep' command could take a decimal point..... always thought it had to use integers.


    Turns out it takes suffixes for 's' (seconds, the default), 'm' (minutes), 'h' for hours and 'd' for days too!

           Pause  for  NUMBER  seconds.  SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days.  Unlike most implementa?
           tions that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number.  Given two or more arguments, pause for the  amount
           of time specified by the sum of their values.
  4. Thanks for the great feedback @@spirilis - I have to agree that the CC2650 is attractive.  BLE would allow for a nice interface with a smart phone as well.  I did promise $10  a  unit but since it is only 10 kids including my granddaughter I could subsidize it.  The other issue with the CC2650 though is that it won't be supported by Energia.  One of the moms is familiar with Arduino and CCS has a learning curve not everyone is willing to pursue.  Certainly it reduces the amateur users in the artsy community given the foothold that Arduino has. 


    I haven't tried the smaller nRF24 in my photo yet so I do have some concerns about reception.  What I can do is progress both of them for a while before making a decision.


    The "Dot" that Trey has on his site is a great example of how tiny and yet powerful these things have become.


    EDIT:  I don't know that I am ready for 0402 :blink:  Do you use a microscope?

    Nope magnification visor w/ extra loupe I can swing down. I think viewing in stereo helps.
  5. Regarding making your own PCB with RF, one nice thing about the TI parts is the TI reference designs, I've used their 2-layer (0.8mm thick) ref design to build a few CC1310 boards of my own, and they work great but the RF passives are all 0402 and require a stencil for solder (OSHStencils stainless works great for this). 0402 is a bear and the absolute lower limit I will go.


    That said, one of TI's partners made a module for the CC2650 with LGA pads underneath IIRC. That makes the chip far more accessible. Trey German formerly from TI started a small company (Polymorphic Labs) building tiny gadgets based on that module. The CC2650 "BoosterPack" package includes a sample or 2 of that module. But of course all of that is probably over your budget :(

  6. Well whatever you use, 2.4GHz is best due to PCB antenna size. It is a shame the CC26xx series is too expensive since its high sensitivity would help make the distance even with sketchy small PCB antennas.


    Also for nRF stuff, I wouldn't bet on those actually making 10m at 2Mbps, but it should at 250Kbps. The issue is the human body and how it may reflect/refract RF as the wearer moves around.

  7. Without having any way of seeing your breadboard adapter socket soldering job and where the passives are, my first assumption is you probably did something wrong with the chip's layout; FYI this isn't a chip you can casually "solder to an adapter" and expect it to work.  It has several passives including an inductor, multiple values of decoupling capacitors, a 24MHz XTAL without load caps (load caps are internal) along with a 32.768KHz XTAL with load caps that are expected (earlier revisions of the CC1310 chip couldn't run without the 32.768KHz XTAL).  I've been successful in rolling my own boards by designing them from scratch but closely following the layout decisions demonstrated by TI's own reference designs.

  8. That confirms some suspicions many have had... the CCS license bundling w/ launchpads was a clever way to sell some hardware.


    Why would the TI ARM compiler go away? I haven't done an exhaustive analysis on it but I have to imagine TI built it for a reason. The real news here is the MSP430 optimizing compiler having no code limit (I assume...)


    Of course maybe a bit too late now that msp430-elf-gcc has been around a while.

  9. Answering some of my own questions (for posterity):


    Turns out that all I need to do to port most TI-RTOS drivers to another OS is to provide an interface to five headers.  So that's good news for Energia-MT.


    Here's a link, describing more.  You can see the driver support matrix, but scroll down to the "Driver Ports" section to see the specific method for attacking a port job.  I tip my hat to TI, they did a nice thing, here.

    Drivers: TI-RTOS Full Driver API Reference

    That's awesome, I didn't know about that.

  10. I think #1 is going to make a handful of folks happy, and practically might work for a lot of people, but it's not "sexy" in my opinion.  That said I am doing my own Network Processor interface firmware but only for the "base station" application--hooking it up to a Raspberry Pi 3 in my instance.  The remote nodes will all run firmware directly on the CC1310.


    I'm curious if there's any interpreted languages worth considering, like Forth or Lua.  Never used either of them personally but the "era of tiny programmable radio nodes" is really upon us with the tech enabled by these chips.


    My own stuff will be C atop TI-RTOS for now.

  11. I am happy I used a couple opportunities (when I had more surplus cash than originally budgeted) to buy these kinds of tools... a Saleae Logic16 about 3yr ago, and a DS1054z this past July. Cause I hear @@yyrkoon 's dilemma, it's a pain to have the need for these tools while one is constrained on cash.


    Moral of the story: Sometimes it *does pay* to make seemingly frivolous investments in quality tools when you don't appear to need them. It's a gamble every time but certain tools are worth having. Like my 22gal air compressor in the garage, it's not strictly necessary for DIY car work but oh does it make certain situations palatable to deal with.

  12. As luck would have it. Wulf already designed the board with the two P1 TA.x pins in mind, Intentionally ? I don't know . . . but going back to what you mentioned either about TXD. From what I've read, one does not need this functionality for TXD. I'm not sure the person I read this from said why, but I figured since we have full control of TXD already ( not arbitrary like RXD per se ), one would not need this functionality. But hey . . . I'm newb . . . Seriously.

    yeah, I can imagine you don't need the timer for output, since the CPU can time its execution as needed based on interrupts or polling a timer and just manually flip the GPIO.

  13. Hi Zeke,


    The problem is not whether to bit-bang or not. The question is how. The project we're using involves Linux, and a bunch of software all tied together with much of it being "busy". So it's not something that could done reliably or even should be done in user space. I'm not even convinced that it would be wise to do this in kernel space. As is would also use CPU time.


    So we're talking some sort of external processor( a pure hardware solution ). As it stands I'm pretty sure I'm simply going to make a uart bit conversion buffer with a 2553. Linux interface will be dead simple, with nothing extra to write driver wise. It'll be connected to the harware UART pins on the G2553. Dead simple RS232 connection to UART4.


    The only thing I'm not 100% sure of right now, is *if* I need to use specific pins for my software UART. Last night I was thinking it had everythign setup fine, but this morning I was reading an article where someone said that you need a capture pin ? I figured GPIO interrupts would be fine, and maybe it is ? For receive that is. TX should not present a problem.

    The idea is to have the RX pin just happen to be one of the pins with a Timer_A association capable of doing capture, preferably a TA0.1 or TA0.2 or TA1.1 or TA1.2 type of thing.  Not sure if it would work with TA0.0 or TA1.0.  Then you can use the timer to capture the moment of transition for that pin which should assist in detecting pulses.


    I've never written a software UART myself so I'm not sure what all is involved, but that one little piece I do know.  It might also be beneficial to have the TX pin going to another TA0.[1+] or TA1.[1+] pin too for output but I'm not 100% sure.

  14. As an addendum, I suspect the MSP430's interrupt features such as the ability to determine return LPM status (__bic_SR_register_on_exit()) and its small size firmly plants the MSP430 in the realm of that which doesn't need an RTOS and where an RTOS is probably not desirable.  Its small size and specific feature sets make it optimal for simpler systems where "real time constraints" are enforced either by peripheral features or by individual interrupts, and the main execution thread is the lowest-priority "idle" task.  The use of volatile variable flags (semaphores if you will) to synchronize features inside your main execution thread can be used to run background post-processing operations off a while() loop inside your main(), after which an LPM mode is entered to save power.

  15. Loved the edX/UT Austin RTOS & Bluetooth course (mostly about RTOS, one token lab on bluetooth by dipping your toes into the TI NPI protocol for configuring a CC2650 running a special network processor firmware from afar, but not terribly deep into bluetooth or BLE itself)


    For the most part, RTOS's aren't rocket science (although I guess they are used in a lot of rockets), the main criticism I have is TI's TI-RTOS is a convoluted pain in the ass due to its superstructure being based on that "XDC" stuff which adds layer upon layer upon layer upon layer of crap.  Definitely over-engineered beyond comprehension.  Like anything though, you can live with it if you put enough time in...


    An RTOS at a high level involves several key features:


    1. Multiple managed stacks which delineate separate threads of execution (since registers are pushed onto the stack using native instructions, and return addresses also get stored on the stack, the stack is the essence of the logical concept of a "thread").  From here on "task" refers to a thread (which has its own stack and a Task Control Block (TCB) entry in the scheduler's linked list).


    2. The multiple tasks are switched between in a preemptive manner, not cooperative--cooperative multitasking is possible of course but does not support the "real time" nature of a system, i.e. it does not support guaranteed minimum latency & jitter constraints for specific operations--this preemptive task switching typically involves a timer but can also involve innate operations, e.g. "posting" a semaphore is an event that might make a real-time constrained task eligible for execution thus it should run code that checks whether the scheduler should be executed to preempt the current task which posted the semaphore.  Generally hardware interrupts of some type drive the context switch, that is, the act of "halting" the current thread and finding another thread to execute.


    3. OS-managed semaphores, the exact data structure is not necessarily provided by the OS but there must be a "post" and "pend" function where, at some point, an attempt to "pend" on a semaphore puts the task doing the pending into a blocked state.  The edX RTOS course had an "OS_Signal" (post) and "OS_Wait" (pend) function which took a pointer to an int32_t, any time the semaphore value went negative, the current task was blocked (in its Task Control Block, we had a field "blocked" which was a pointer to the exact int32_t semaphore that blocked us).  When OS_Signal was run from another running task, if the semaphore became <=0 after incrementing it, a code routine would check all the Task Control Blocks to see if anyone was pending on it, and if so, unblock it & perform a context switch.  Only 1 would be unblocked for any 1 run of OS_Signal, and it was first-come first serve.  There are probably other considerations that needed to be made here.


    4. Priority system for tasks.  Real-time constraints necessarily requires that certain tasks have precedence over others, such that a scheduler can make a simple and deterministic decision to execute a real-time task exactly when it becomes eligible for execution, to the exclusion of lower-priority tasks without any ambiguity.  A common idiom is that a hardware interrupt might either handle some of the real-time execution itself (interrupts are, in a sense, impromptu "tasks" borrowing the current stack temporarily) but usually it just posts a semaphore that the real-time handler task is waiting on; after the interrupt completes the context switch will be forced right away, ensuring the high-priority now-eligible-for-execution real time task is switched to without any intermission by the previous task that was running before the interrupt occurred.


    5. A "softer" but typical requirement is that tasks must be able to sleep, that is, become ineligible for execution for some time.  This sleep operation causes immediate preemption (context switch) with a timer in the system maintaining the countdown for each sleeping thread and making it eligible for execution when a sleeping thread's timer reaches 0.  The alternative to such a managed sleep is to busy-wait until the timeslice finishes; this may be satisfactory but it's fundamentally a waste of CPU resources.


    Beyond this, an RTOS may provide other facilities as needed e.g. File systems, Network drivers, coherent date & time with timezone interpretation, logging, whatever.  The basic RTOS task concept provides a neat platform for assembling more complex software layers and since the semaphore system is used to synchronize tasks in an ad-hoc manner, a variety of complex communication methods can arise e.g. managed FIFO ring buffers, mailboxes & queues, etc.  It's important to logically separate the "core RTOS" features from the "extras and/or fluff" that any particular RTOS solution offers.  FreeRTOS for the most part is a barebones RTOS without the fluff, so that you may implement the fluff from scratch in a manner appropriate to your specific platform.  Obviously there are pros & cons with that approach.


    An interesting idiom we learned in the edX course is the concept of circular DSP signal buffers.  This is a type of ring buffer where the "head" pointer location is only updated by the producer, e.g. the hardware interrupt collecting ADC data or whatever, and the whole buffer is read by any other tasks as needed.  Sort've a dynamic write-once, read-many concept where the buffer is read in its entirety each time it's "consumed"--as would be the case with many DSP algorithms (FIR, IIR filters et al).  DSP-optimized processors typically include hardware supported circular buffers to make the addressing within these extremely simple, otherwise a number of CPU cycles are expended every time the circular buffer is written to which can affect the amount of CPU time available to process the data.


    Anyway, lots more to talk about, for now I am diving into CC1310 work to get a personal star network IoT system up and running (now that I have 5 end nodes built + a Raspberry Pi CC1310 hat), but eventually I'd like to tinker with some more FreeRTOS examples for the purpose of this thread.

  • Create New...