Link to the lab description

I know that the microcontroller is waiting to get the ascii 65 from the computer before it sends out the value of the pots on the analog channels but I can control foregound color, xpos, and ypos of the circle without sending any character. Why is that? ...
Actually, I think I figured it out. Processing is sending a port.write(65) at the start of the code and at the end to request new sensor readings. I thought I had to manually type the character. Never mind...
Adam

You got it.
tigoe

--- I've been in lab and I know it has been difficult to get processing and the PIC to talk for some people. It was for me, but Vincent gave me these two pieces of code that are clear and work. Just wire Pots at A0 and A1, and a photoresister at A2 on your pic and then use the code below. Should work! Pic Code first and then Processing Code (Jeff):

Both of these examples are available on my code site. Here's the Processing code and here's the Pic code so I cut them here for brevity's sake.
tigoe

--- Quick question about sending data from the PIC. I was sending out data using serout from my PIC that was 0-255 into the processing code below and getting only values about 48 to 55. When viewing the incoming data in hyperterm it was fine. Now I realize the ASCII codes for numbers fall in that range so is that the problem? In that case I think I should not use the DEC modifier. I haven't gotten a chance to try it yet, but was wondering.

Thanks, Jeff

That's correct. The DEC modifier outputs the vraiable's value as ASCII-encoded decimal characters. In other words, "0" through "9", or ASCII 48 through 57.
tigoe

Simple serial: Datalogger

There is a problem with the given code in the Serial Call and Response exercise. The communication between the two devices is out of sync. After the first '65' that is sent, it seems like both processing and the PIC are waiting for the other to make the next move. Playing with the pause function solved the problem. I finally got it to work. You can check out my code, just look at the processByte function.

Gilad

Not quite true. Processing sends out a byte in the setup() when it starts up. Also note that if the variable firstContact is false at startup, and is only set true when there's data available from the serial port. If firstContact is false, the following if statement kicks in:

 // If there's no serial data, send again until we get some.
  // (in case you tend to start Processing before you start your 
  // external device):
  if (firstContact == false) {
    delay(300);
    port.write(65);
  } 

in other words, if there hasn't been any data from the PIC, Processing waits 300 milliseconds and sends out again. You might want to modify the 300ms value, but this has always worked for me to make sure that Processing is the initial sender.
tigoe

Actually, a little from here, a little from there, I made everyting worked luckily after 3 hours. What I wonder is the logic behind the processByte function in the processing code. I tried to println the inByte variable to see what is going on there, and it traced `t`. I also understand that we are just filling our arrays spaces with this variable in processByte function although I didn't really get why we do have an if statement inside processByte function no matter we are sending more than 2 bytes. Isn't serialInArray[] just getting values with inByte with this line already:

 serialInArray[serialCount] = inByte;

what is the reason behind using the below again:

if (serialCount > 2 ) { xpos = (float)serialInArray[0]; ypos = (float)serialInArray[1]; fgcolor = (color)serialInArray[2];

ilteris

''The if statement you're asking about takes the values from the serial array and assigns them to the x and y position of the ball and the forground color of the ball. Without this statement, you're not doing anything with the incoming data. The reason you wait for serialCount to be greater than 2 is that if you don't have all three bytes, you don't have accurate data.

As I mentioned in class, processByte() was written when Processing was in Transition, and it's no longer necessary to do it in quite so complex a way. I've updated that example online without processByte.
tigoe''

Here is the code I was talking about in class today that made the PIC reset twice and stop. Any thoughts?
Andrew

you don't have a main loop in the code, so when it gets to the end of the subroutines, it stops. You always have to have a main loop.
tigoe

A link to my lab here
Alice

oh this PHYSICAL world!!! i'll never get used to it! somebody send me back through the screen.

are there telephone ring sensors? seems like all they'd do really is just tell when a small voltage comes from the RJ# on a land line (before there's talk, it's gotta ring)? hardly would seem to require real sensing per se. thus would you essentially be sending a boolean (digital input) to processing by calling some number, 4 bit = 4 lines? (theoretically) would make a web page do something by calling it (from anywhere). (forget actually talking to it for now. though even if the sound were just unpredictable values, might look neat when used literally. like setting freqs to RGB vals, answering the line is a whole other problem.)

i'd be interested in making it so no single caller could deliver the whole 1111 message. but 4 callers, working together, though probably not intentionally, could. Not a lot of practical uses, but a neat artsy thing. (maybe could sell it to Jerry Lewis?)

is there a format to know, that gets sent/understood over phone lines when they ring (like a pulse/frequency versus a steady DC stream)? i have a few commercial gizmos (deaf household utilities), one detects phone ringing. but the crucial parts are sealed tight, goes through a maze of resistors?)

judson?