Working progressively: Part V (Breadboard redux) WP Part VII: BS2sx + Processing Redux

WP Part VI: BS2sx + Processing = true love?

Posted Mon, Apr 18, 2005 at 12:41 AM

(Note: This was originally written in March so I hope the files are the correct ones...)

So for the past few days, I've been playing matchmaker with my Basic Stamp and Processing.

PBASIC: html | download file (.bsx)
Processing: html | download file (.pde)

They make an odd couple; the Stamp's bare components next to Processing's slick interface. And, for the briefest moment, I thought that they would go ahead and elope but.... Alas, it wasn't meant to be anything more than a short-term relationship.

But to be serious, I'm disappointed with the built-in serial communications library currently included with Processing (alpha version 0068). (There appears to be a version 0071 floating around out there with a new serial library but nothing for public download yet.)

Addendum: I asked Casey Reas about this at FITC and he says that the beta version of Processing will be released "soon" with new serial libraries. Apparently they have been working with faculty at the NYU ITP program to help iron out some of the issues so I look forward to the new version...

So a couple of things that threw me off about serial communications between Processing and the Stamp:

1) Incorrect baudmode
- I got that got worked out in my previous post so remember to check (and doublecheck) your calculations or the charts.

2) Data buffering
- When the SEROUT or SERIN commands execute for a Stamp, it can't do anything else but wait for all the data to be sent/received. So I got myself into the frameset of thinking that the world needs to stop for serial data. This is not so for Processing (and computers in general) because they can buffer data.

When sending an array of bytes via serialWrite, it sends the first byte, goes back to looping while still sending data out. This wouldn't be a problem if....

3) The serialEvent() method fires on both SERIN's from the Stamp and serialWrite() in Processing
- In the examples below, I have the Stamp send back a "1" when it's finally finished receiving serial data which lets Processing know that it should call the increment() function.

But what if I actually sent a "1" from Processing to the Stamp? increment() would be called and, thus, mess up the animation for a bit.

Snippet from PBASIC file above:

SERIN SerialPin, Baudmode, [WAIT("A"), STR col\8]
SEROUT SerialPin, Baudmode, ["1"]

Snippet from Processing file above:

void serialEvent() {
if (serial == 49) { //Ascii 1

4) Too many statements in the serialEvent() method, especially println(), and it gets noticeably bogged down.

I hope that I didn't scare everyone away from Processing... Really, this program has been super easy to pick up on and it can only improve.

Working progressively: Part V (Breadboard redux) WP Part VII: BS2sx + Processing Redux
comments comments

hi there,
your project looks ace, been trying to do something similar, well have a play with LED's actually. Was wondering how hard/easy it would be to do something using a wiring board rather than a stamp board? am a bit new to electronics, but am having fun.

kind regards


Posted by: boppyer
August 2, 2005 06:54 AM

Hey B,

By 'wiring board', do you mean a 'breadboard' (prototyping) board? (Those white little rectangular things with holes to quickly test a circuit without soldering?)

My Basic Stamp is actually built to fit into a breadboard. It's technically a 'Basic Stamp Stack' -- which is kind of like a plain Basic Stamp with training wheels. :) You can buy them from HVWTech.

Regardless of which microcontroller you go with, I highly recommend figuring out your circuit on a board first. For the LED part, try making at least a 4x4 grid of LEDs to get the hang of it -- Trying to wire anything bigger than that on a breadboard will make you scream.

If it helps any, I will post additional diagrams for the curcuit tonight or tomorrow.

Posted by: pearl
August 2, 2005 10:33 PM