PropellerForth issue tracker

I've gotten a few blog comments from folks who are using PropellerForth. Yay!

A few comments have reported bugs.

I don't closely follow comments on my blog (though I respond when I have time) -- but I do get a email when someone reports a bug at the PropellerForth issue tracker over on Google Code!

If you're using PropellerForth and find a problem, please report it there. (Please don't post "bugs" like "You haven't released a binary in a few months" or "You haven't imported your Subversion repo." I assure you I'm working on both as time permits, but this isn't my day job.)

Of course, if you're using PropellerForth and haven't found a problem, I'd love to hear about that too! Blog comments are a fine place for that, or send me an email if you can track down my address. ;-)

Trig in PropellerForth

Among many other nice features, the Parallax Propeller microcontroller has a single-quadrant sine table in ROM. This makes implementing sine and cosine fast and simple, for medium-precision (13-bit) work.

Here's a simple port of Parallax's routines to PropellerForth.

hex

\ Address of table in ROM
E000 constant sin-base

\ Computes the sign of an angle.
\ The angle is a 13-bit number (0x1FFF = almost 360 degrees).
\ The result is a 16.16 fixed-point signed integer.
: sin  ( angle13 -- n16_16 )
  dup 1000 and >R   \ Stash a flag for Quadr.3/4 onto the rstack
  dup 0800 and if  negate  then  \ Invert angle for Quadr.2/4
  2* sin-base or  H@   \ Compute word address and fetch
  R> if  negate  then ;  \ Negate result for Quadr.3/4

: cos  ( angle13 -- n16_16 )  0800 + sin ;

With PropellerForth v8.05 this gives a runtime of 1088-1152 cycles for sin, and an additional 240 cycles for cos -- 31x slower than a native implementation. (v8.02 will be slower.)

It can be made slightly faster by (1) replacing the numbers with CONSTANTs and (2) inlining 2*, which is not a primitive, as "1 lshift", for a runtime of 993-1056 cycles -- 28x slower than native, at the cost of a 22 more bytes of space.

Update: Huh. Through some optimizations to the kernel, I can shave off another 100 cycles -- for a runtime of 896-926 cycles. However, it costs 248 bytes in the kernel, and eliminates a hook I was hoping to use for single-step and breakpoints. I'll have to weigh this.

Another PFcam teaser

With the help of the new scope, I wrote a new OV6620 driver that includes chroma support. With the camera reconfigured to run at 25fps, it records 88x72 YUV images at full rate. It's 210 bytes, and integrated into a custom build of PropellerForth.

A few lines of Forth later, I had code to generate PPM images. (PPM is possibly the world's easiest format to produce.) Here are some samples. Forgive the yellow cast and the chroma noise -- my new workbench doesn't have lights yet, and the camera's low-lum performance is poor. That, and I probably have bugs in my YUV matrix code.




Once I'm confident in the design, I'll post the driver and Gerbers for the PCB (and if anyone actually wants one, we can go in on a BatchPCB order).

I've got 8 spare Propeller I/O pins...gotta figure out what to do with 'em. Servo connectors? Debug LEDs? Audio?

Edit: Yes, I did indeed have bugs in my matrix code! They're fixed now.

Better chroma makes engineer happy.

I can see clearly now, the waves are gone

I'm a pretty hardcore guy when it comes to debugging software. I pride myself on my automated tests, I routinely sling debuggers and disassemblers around, and so forth.

When it comes to hardware, though, I've been stuck firmly in the printf era. The printf era is pretty damn powerful, of course, when you've got Forth at your side -- the PropellerForth VGA and NTSC display drivers, for example, were written using only a multimeter and ancient HeathKit frequency counter.

However, I'm not a big fan of making my own life difficult. After many years of fondling scopes at Fry's, I finally gave in and picked up a Tektronix TDS1012B. It's at the high-end of the extreme low-end: decent sampling rates for embedded work and so forth.

A couple weekends ago I taught myself printed circuit board and built the PFcam, the Propeller-based image processing board I mentioned in my last post. I'm not an analog electronics whiz, so the first thing I did with my scope was test the new board.

Sure enough -- here's a capture of some I2C traffic between the Propeller and the camera:


Notice the square waves are wearing hats? The regulator's output was bouncing between 3.3v (the goal) and 5v (the input). A decoupling cap later, my SCCB code (Omnivision-speak for I2C) is much more reliable:


Now all the I2C/SCCB chips play nice together, and nobody wigs out and sees a stop condition where there ain't one.

I'm happy with the scope so far. I'll most more details on the PFcam board later on.

Got tired of my CMUcam.

What embedded machine vision system...

• is easier to interface (and more powerful) than a CMUcam2;


• has eight cores at 96MHz, six of which can perform user-defined image processing;


• can be programmed and debugged interactively in-system using Forth or assembler;


• runs open-source code built using open-source tools;


• costs less than $100 in parts; and


• can be built in an evening with only basic through-hole soldering?

Yeah, I couldn't find one either.




Mmm, 192 MIPS of pixel-devouring goodness. I love my overclocked Propellers.

Edit: What kind of image processing, you ask? How about realtime ASCII art!



I hope to get middle-mass and edge tracking working shortly.