Basic Serial I/O - program stubs

mindrobots

I didn't write most of this, the rcv code is based on Chip MainLoader and the tx code is pretty much from OzPropDev (Brian)'s code. I just packaged them up as little test programs in case anybody wants to do some I/O before they perfect their own.

Simple single character receives and send through the standard com port (RX_PIN = 63; TX_PIN = 62). Baud is set to 115,200.

The "test code" part of the program just does a loopback.

The stub without _hi runs completely in COGEXEC within one COG (COG0 as it is written).

The stub with _hi runs in HUBEXEC with some data in COG0 COGRAM and all the code in High (>$1000) HUBRAM.

I'm sure there will be better but this might get you going with terminal I/O (thanks to Brian and Chip).

They both seem to work. I've only tested on the 1-2-3 board so far.

If you have enhancements/fixes you want to contribute, please post them!

Rayman

Looks nice thanks.

I wonder if I'm seeing this right:

TX_PIN = 62
setb	outb, #TX_PIN

I imagine that setb only takes pin numbers from 0..31. So, sending it #62 gets reduced to reduced to 5 bits, making it #30. Which, happens to work out.

I guess I would think of the pin as B30 instead of #62, but I guess need to think both ways...

mindrobots

Thanks, I hope it helps!

Brian and Chip both call them by the 6 bit number but the math does work out. I saw another reference to pin 30 of an outb so we will probably see them both ways.

Seairth

Rayman wrote: »

Looks nice thanks.

I wonder if I'm seeing this right:

TX_PIN = 62
setb	outb, #TX_PIN

I imagine that setb only takes pin numbers from 0..31. So, sending it #62 gets reduced to reduced to 5 bits, making it #30. Which, happens to work out.

I guess I would think of the pin as B30 instead of #62, but I guess need to think both ways...

@ozpropdev did the same trick. It's clever, once you realize that bit 6 is effectively indicating INA or INB. In fact, this would be a good candidate for some alias instructions:

CLRP #    => CLRB OUTx, #
GETPC #   => TESTB INx, # WC
GETPZ #   => TESTB INx, # WZ
SETP #    => SETB OUTx, #
NOTP #    => NOTB OUTx, #
POUT #    => SETB DIRx, #
PIN #     => CLRB DIRx, #

(edit: updated to show mapping.)
(edit: added "GET" aliases.)

rjo__

Thank you!!!

I have combined your code with Chip's sin/cos example to transmit the sin/cos values stored in the LUT ram. I am working on a serial graphical utility using Processing.org, which is cross-platform. The skeleton of this works on Window 8.1... I am very interested to know if it will work on other platforms. In the past, the serial libraries sometimes worked on the Mac and sometimes they didn't.

Right now I'm only using the serial libraries of Processing.org. But there is a GUI library(controlP5) here that I will be using as well. This should allow us to load images to the P2 and view contents of HUB RAM as images, and a variety of other ways.

In my set-up the results are viewable in the log window of the serial terminal.

Here is the Processing.org code for the rudimentary serial terminal... called a "sketch":

import controlP5.*;

/**
 * Serial Duplex 
 * modified from original code by Tom Igoe. 
 * 
 * Sends a byte out the serial port when you type a key
 * listens for bytes received, and displays their value in the log window. 
 * This is just a quick application for testing serial data
 * in both directions.   
 * To use with the P2, run the attached P2 code, then start this sketch.  
*  The P2 waits for you to hit a     
*  key and then the P2  transmits LUT contents.  To free up the serial port and exit the terminal, 
*press the escape key.  To use it, download Processing.org and paste the code into a sketch
 */


import processing.serial.*;

Serial myPort;      // The serial port
int whichKey = -1;  // Variable to hold keystoke values
int inByte = -1;    // Incoming serial data
int i = 0;
int  w = 1200;
int  h = 600;
int[] inBytes = new int[1024]; 
void setup() {
  size(1200, 600);
  // create a font with the third font available to the system:
  PFont myFont = createFont(PFont.list()[2], 14);
  textFont(myFont);
  
  // List all the available serial ports:
  printArray(Serial.list());

  // I know that the first port in the serial list on my mac
  // is always my  FTDI adaptor, so I open Serial.list()[0].
  // In Windows, this usually opens COM1.
  // Open whatever port is the one you're using.
  String portName = Serial.list()[0];
  myPort = new Serial(this, portName, 115200);
}

void draw() {
  
  background(0);
  text("Port: " + Serial.list()[0], 10,h-20); 
  text("Last Received: " + inByte, 10,h-60);
  text("Last Sent: " + whichKey, 10, h-40);
  
  line(50, 40,w-50, 40);
  stroke(126);
}

void serialEvent(Serial myPort) {
  inByte = myPort.read();
  println(i+"   " +inByte);
  inBytes[i] = inByte;
  i = i + 1;
 
}

void keyPressed() {
  // Send the keystroke out:
  myPort.write(key);
  whichKey = key;
}

rjo__

There is an issue with my P2 code. My intention was to place the cog in an endless loop...waiting for a byte from the serial terminal... then dumping lut... then waiting again.etc,etc,etc.

It doesn't do that, and I don't know why.

ozpropdev

Rich
If your using PST then the lower byte values $0 to $10 will effect the display.
The code appears to be looping Ok but the random "clear screen" and "cursor position" codes
are giving the illusion of no activity.
Brian

rjo__

Hi Brian,

No, I'm using a diy utility. Right now it is serial transmit and receive only, with no bells or whistles. Nothing is being done with the received bytes(yet), except to echo them to a log window.

Processing 3 is from Processing.org and is an open, cross platform development language/system, built on Java but with simplified language constructs. Processing 3 has the capacity to encapsulate code into stand-alone applications. I have listed the "sketch," because I don't have the correct JRI installed (I am afraid to touch my computer right now... so I haven't tried to update it ... and thus I can't generate applications.)

If anyone wanted to try it, they would have to download Processing 3 from Processing.org and then paste my code into the code window. Hit the run button and you should see a terminal, which you click on and hit any key.... after you run the P2 code.

I looked again at the issue that popped up late last night. It turns out that if I leave my terminal on top.. don't go to the desktop for example... it loops just fine. So, you are correct. The looping in the P2 code is working. The issue is on the other side and seems related to how Processing 3 itself relates to the port. I am going to put that problem to the side and work on the interface.

Rich

p.s. Processing 3 has libraries that make it very easy to access the new Kinect V2, which has a very accurate time of flight (TOF) depth camera. ($100 used at GameStop... requires an adapter cable from Microsoft $50). Processing 3 also has libraries for openCV... So, it should be possible ... for example to loiter a quad-copter at ten feet up and have it choose a clear landing site... or find the best path through a cluttered space... or measure all the objects around itself and transmit the juicy bits to a P1 or P2 bot.

AntoineDoinel

Modified for pseudo full duplex operation on DE0-nano: using COG1 for receive only, while transmit is still inlined in COG0. Also added a send_string subroutine.

I'm using coginit/cogstop to flash LEDs 4..7, like I described in the DE0-nano support thread. This should be ok on other boards too (except it will really start and stop COGs in that case!).

I'm still confused about addresing operators, just hammered on until loopback started to work again.

mindrobots

Thanks for the additions/modifications/upgrades. I'm going to try them on my 1-2-3 in just a bit.