Monday, January 23, 2012

True Modular computing

I want to tie together my past 3 posts.
In Multi-computers vs multitasking vs interrupts I stated a problem (concurrent processing within the embedded realm) and teased you with a solution (GreenArray's GA144).

In Costs of a multiple mcu system I backed a bit away from the GA144 and wondered if a bunch of small, efficient and cheap MCUs could solve the problem.

In Building devices instead of platforms  I offered a rationale to my pondered approaches.

So, here I sit composing an interrupt for an 8051 to service a GSM modem's UART (essentially to buffer all the incoming data).   And... everything has just gotten complicated.  I've been here before. I am no stranger to such code and the approach I am taking is text book.  This is how code starts to get hairy and unpredictable.

But, really now... maybe I *should* consider breaking my tasks down into hardware modules (with each module consisting of dedicated software).  If I dedicated an 8051 (tight loop, no interrupts) to just talking to  the modem, collecting responses and sending just the relevant information to another 8051 (perhaps through I2C or SPI), then I build that module once, debug it once and be done with it.

This is modular design, isn't it?

So (during design) every time I find a need for an interrupt, I just fork another processor?

(This would work with a single GreenArray's GA144 as well as $3 Silabs 8051 MCUs)


8 comments:

  1. Anonymous8:48 PM

    You could probably use one micro, if you chosed UARTs for interfacing your devices. Nowadays, small micros have several hardware uarts and then you can still do spi in realtime.

    But if you want a really slim design with less parts, use the ga144. There are examples of SPI in colorforth already *check out blocks 1428/1430*

    ReplyDelete
  2. Thanks for the suggestions.
    Asynchronous serial (UART) is fine, but I'm still limited by the Hardware RX buffer sizes (at least in the MCUs I use). Of course, I could use interrupts to feed the bytes into a RAM buffer, but that gets me back to one of my original problems...

    GreenArray's Charley Shattuck pointed me to blocks 404/406 for an example of SPI (used for polyForth block I/O).

    I've bit-banged SPI before, so figuring out how to do it "specifically" is not so hard (the arrayForth code is dense but fathomable). But figuring on how to do SPI on the GA144 "generally" is the tricky bit for me. I've got a bunch of sensors that all use different SPI approaches (clocking,etc).

    Of course, the arrayForth way is NOT to write generalized libraries since you could do each "specific" SPI interface in one or two lines of code. (At least that is my interpretation ;-)

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. You might be interested in the following MCUs (more processors since they don't have onchip FLASH, but they are intended for embedded systems):

    1. XS1 (Transputers successor)
    It’s manufacturer calls it "software defined silicon” (http://www.xmos.com/products). All transistors are yours. Multi-core + excellent interconnect. You can also download (i think GCC based so FLOSS) Compiler Collection (C, C++, XC). It’s power consumption is ~3x higher than ARM Cortex M3 (acording to datasheets). You can also search ‘XMOS’ on youtube. 65nm process. 1600 MIPS total. ~600uA/MHz. Appeared in 2007. Small amount of OTP memory for program decryption. XCore Exchange.

    2. Parallax Propeller
    Propeller Object Exchange Library is good idea, but not useful yet. 8 identical cores of 2kB RAM (for program and data) each + 32kB of shared RAM. 'call' instruction is little tricky (in assembly). Some one said: "they are just bunch of co-processors". Don't have built-in communication hardware. They plan to do similar modification of GCC & Eclipse. 160 MIPS total. Appeared in 2006. ~8$/pc.

    I have heard of Forths for both.

    They both have Wikipedia pages about them.

    ReplyDelete
  5. Anonymous7:47 PM

    propeller: the 8 cores CAN indeed communicate. there is a shared ram which all can access

    ReplyDelete
  6. I'm familiar with the Propeller chip... I have a dev board somewhere in my pile of hardware.

    I've also seen a couple of Forths for it, but they aren't to my liking (no criticism on them, I just don't jibe with their approach). Note: This was a couple of years ago.

    ReplyDelete
  7. I don't think Propeller programming has changed much last 2 years. I was little surprised that Parallax haven't gave up on it. I even saw on their own forums someone saying that Propeller is obsoleted by XS1.

    What about XS1. For example XS1-G4 has 4 cores x 8 threads (barrel processor). Looks just like what you are talking about.

    Ups, sorry about "Don't have built-in communication hardware.". I wanted to say "they don't have something similar to xcore switch which can connect cores even on different chips.".

    GA144's core has less RAM than I have expected.

    ReplyDelete
  8. Different beasts. The XS1 looks interesting. But, like the Propeller, it is a different kind of animal from the GA144.

    The GA144 supports higher grain concurrency. You can have dozens of concurrently running "tasks" (over a hundred if your tasks are really small). You'd design differently for the GA144... As I've mentioned in http://toddbot.blogspot.com/2012/01/ga144-as-low-level-low-energy-erlang.html

    I'm going to get a good feel for just how little RAM (per computer) that the GA144 has soon...

    ReplyDelete