arrayForth notes #4 - PCF2123 SPI Code

This is brutally tight code. It is not the most efficient code, but it does fit in 1 node (unfortunately, there is no room for "plumbing" -- so it will most likely need to be refactored into 2 nodes).

The code can be exercised (by the IDE), by using "call" to invoke /pcf2123 for initialization, sdt to set the date and rdt to read the date.  Values for "sdt" can be pushed onto the node's stack by using "lit".  I used a logic analyzer to look at the results.

There was a lot of setup to get this going, and I am not going to cover that right now.

I need to get the plumbing (wiring) right. Getting 1 node to talk to another is not as intuitive as I hoped. I also fear that the IDE gets critically in the way (hook et al can wipe out your node's RAM when creating paths).  This will mean that the IDE will be less useful for stuff that is very node position dependent (i.e. GPIO nodes).

I don't fully grok the inter-node comms yet. In particular, I am not sure how to "push" numbers from one node to another.  The IDE does this fine with "lit", but if my node isn't wired by the IDE all I have is "warm/await".  The apparent exemplar for passing values between nodes is to explicitly have the target node "fetch" values from the port. Unfortunately, as you can see from the code below, I am out of room (0x40 max words per node and I am at 0x3d).  I could shrink the code a bit more, but...

this is a brutally simple interface for the cr nxp pcf2123 calendar clock module. cr pin 1 - chip select cr pin 3 - clock cr pin 5 - mosi cr pin 17 - miso cr cr ckwait pauses for an effective rate of 2mhz cr -ckwait asserts the clock line low for 2mhz cr cs asserts the chip select line high cr -cs asserts the chip select line low cr /pcf2123 initializes the pcf2123 clock cr rdt reads date and time sdt sets data and time

850 list todd's simple pcf2123 clock code cr 8 node 0 org cr ckwait 00 4A for unext ; approx. 2mhz cr -ckwait 03 2B !b ckwait ; cs 05 io b! -ckwait ; -cs 07 29 !b ; spiw1 09 if drop 10 then 2F . + !b ckwait -ckw ait ; spiw8 10 b- 80 7 for over over and spiw1 2/ ne xt drop drop ; spir8 17 -b 0 7 for 2* dup or spiw1 @b . -if d rop 1 or dup then drop next 2/ ; /pcf2123 21 cs 10 spiw8 58 spiw8 -cs ; rdt 27 -smhwdmy cs 92 spiw8 spir8 spir8 spir8 spir8 spir8 spir8 spir8 -cs ; sdt 32 ymdwhms- cs 12 spiw8 spiw8 spiw8 spiw8 spiw8 spiw8 spiw8 spiw8 -cs ; cr 3D

arrayForth notes #3 - SPI

I've finally begun to talk to the PCF2123 from the G144A12 eval board.  The SPI code is not space optimized, so just the basics are taking up  almost a full node. (More on that later).
So far, I've got "reset" and a register read working (return data not validated).  I am using Node 8 and it's 4 GPIO lines (for MOSI, MISO, CLOCK and ENABLE/CS).  The PCF2123 is odd in that CS active is high, not low. I've got a tight for unext loop pulse the CLOCK line at around 2Mhz:

In the above Saleae Logic screenshot, I am tracing two CS sessions:  First a "reset" (0x10 and 0x58), and then a request to read register 4. I am not sure the data returned is correct (yet), but the fact that I am getting something must mean that the device is happy with my query.  Unfortunately, my register read isn't returning the value 0x15 yet, but at least I know that my GPIO pin writes are working.

As I said above, just basic support of SPI is taking up precious space (currently the SPI routines take 36 words of RAM!). I am planning on doing some optimizing, but I think that the actual PCF2123 functionality will need to live in a separate node.

I have a business trip planned for the next couple of days, so if I don't get the SPI "read" working correctly tonight it will have to wait until the weekend. However, the plane ride and hotel stay will afford me some time to look into space optimization of the code and perhaps I will finally tackle the simulator.

And, yes! Code will be posted... once the damn thing works.

GreenArrays arrayForth Keyboard cheat sheet

I'm having trouble wrapping my head around the arrayForth editor keyboard layout diagram in section 3.1 of the arrayForth user guide, so I am trying to put together a slightly modified version that more tightly associates the keyboard keys (and position) to function.  I am also dropping the grouping-via-color since I don't have a color printer at hand.  Here is a link to the PDF.

My GreenArrays EVB001 Eval Board Adventure

Okay, so I broke down and purchased an eval board last week. I got my shipment notice last Friday (which included a nice personal note from Greg Bailey mentioning that he saw my last blog post -- thanks Greg) and the board arrived Monday.

Now, to answer my own question (from that post): What to do with 144 cores?  I guess I'm going to have to figure that one out...

I've got a big learning curve ahead of me, and although I'm not the type to post daily updates on "learning experiences", I'll probably post now and then how it is going. If I get an overwhelming burst of energy, then I may even fork my EVB001 adventures to a new blog dedicated to just that.

Anyway, what are my current plans?

1. Learn enough arrayForth (ColorForth) to be dangerous.
2. Work my way around the board (nodes and I/O).
3. Begin world dominating project.

Regarding #1, I have followed ColorForth for years, but I never really used it.  That being said, I am using Charley Shattuck's MyForth on my day job (shhh.. don't tell them)  and that is different enough from ANS Forths that the arrayForth "culture-shock" is low. 

Working around the board (#2) is critical as I have to figure out what my peripheral hook up options are.  I figure that I would try and get the board talking to an accelerometer (or other sensor). This would be a good goal.

Now, world domination (#3) is a bit vague.

Now, here is what I am thinking.... My usual approach of building tiny/simple things that can be replicated (low volume production runs) won't work here.  I simply can't afford to dedicate a $450 eval board to a single task.  Then again, I hate the idea of just using it as a "prototyping" board for various ideas.  I need a more singular goal.  

So, I am viewing the eval board as a "platform".  But, a platform for what?

When someone (for passion) designs and builds their own car, plane or boat, they are creating something unique. They are not making something with the end goal of mass production. They are building a "system" that satisfies their own needs. Now, if that "system" later results in replication due to demand, then that is great. But, it is all about building something unique -- something unlike the other guy's car, plane or boat.

You may see where I am getting... the usual place: Robotics.

But, here I use the word "Robot" in loose terms. I am thinking about building a platform to support the integration of sensors and actuators.  I want to load up the EVB001 with as many sensors as possible and have it collect, correlate and react through the manipulation of actuators.  However, I want to do this within the tightest time constraint possible: I want a tight coupling between sensors and actuators. I want a feedback mechanism. I want... my flocking Goslings (or at least one of them at this point).

Integrating lots of sensors with a single fast running ARM is certainly possible. But this would be interrupt hell (or polling hell or linux process/thread management hell). This is why I (and other sensible people) incorporate tiny 8051s, AVRs and MSP430s into dumb sensors -- to make them independently smarter.  Unfortunately, when you have a bunch of microcontroller enhanced sensors (and actuators) you have a communication nightmare. And you need a separate master CPU to integrate all of the "smart" data and manipulate the actuators.

None of this is new. None of this is rocket science. However, the robot I design would be my bot. It would be unique. 

More deep thoughts later... For now, I just need to figure out how to talk to my new toy ;-)

GreenArrays G144 - What to do with 144 cores?

I've been following the GreenArrays G144 since its inception.  Now a kit is available... programmable in colorforth (and eforth).  Forth chips aren't new to me. I remember devouring the Novix NC4000 back in the mid-80s (I couldn't afford one...).

So, the kit costs $450. I don't really have that kind of money to drop on a dev kit, but... if I did manage to scrape up the cash, what would I do with 144 computing cores?

Seriously, that is a good question for deep thinking. From an embedded computing perspective, what could one do with 144 computing cores?

If I can come up with some good ideas, this kit may be on my birthday wishlist.... ;-)