Forth and Propeller HAT

Rsadeika · 2015-05-16 04:15

I saw an interesting comment in one of the other threads, installing Forth on a Propeller HAT. OK, so what could you possibly gain by doing that?

First, how do use that setup, I think you need a terminal program to access the Forth interpreter. And since the HAT setup is lost once you lose power, you have to redo your whole setup, again and again.

Second, since the HAT will have devices/sensors attached, how would you access those from a program on the RPi(bash,python,C,...,etc)? I do not recall Forth having a command line access to it.

Third, how easy is it to add device drivers to Forth, for instance a sht11 module? Their is probably a dozen more items of inquiry, but this may be a good start.

I am sold on the usability of the Propeller HAT, just have to figure out the best way of incorporating it into the RPi system for the easiest and best use.

Ray

Heater. · 2015-05-16 04:40

Rsadeika,

I am sold on the usability of the Propeller HAT, just have to figure out the best way of incorporating it into the RPi system for the easiest and best use.

Why not just install SimpleIDE and or PropellerIDE on the Pi, for C and Spin respectively, and program the Prop from the Pi as normal.

Or just use the command line tools, prop-gcc and openspin.

I do not recall Forth having a command line access to it.

Sounds like you have never tried a Forth system or read anything about them. The command line interaction is one of the key selling points of Forth that you learn from the very beginning.

I think you need a terminal program to access the Forth interpreter.

Hmmm... on the other hand it ... seems you have the idea.

And since the HAT setup is lost once you lose power, you have to redo your whole setup, again and again.

I'm sure the Forth guys have thought about that and have solutions

But consider this... Your HAT is connected to your Pi. So on every power up or reboot some simple program/script on the Pi can reboot the Prop and send it it's program again. There is no need for even a EEPROM on the Prop.

LoopyByteloose · 2015-05-16 04:55

It all depends of what you want to learn.

If you want to learn C on the Propeller, SimpleIDE might be wisest. After all, you need to acquire an understanding of all those libraries.

If you want to interact and explore with the Propeller in an interpreted mode, Forth is an excellent choice. This may be better if you are starting at a very basic level and just want to control the Propeller remotely. It requies a serial terminal interface, such as Minicom or Terraterm.

If you want to learn SPIN and PASM, SimpleIDE is equalty valid. So are several other IDE solutions. I use BST due to some added features.

Currently, i am using Forth with a Bluetooth module, and either my Smart Phone or Notebook computer in a terminal mode. The actual Propeller board sits in a box that is powered 7/24 and I just log in when I want to play with it.

IOW, there are lots of ways to set up a Propeller that make for a fun learning environment. It is up to you to create the fun as personal learning goals and preferances vary widely.

Heater. · 2015-05-16 05:04

That would be PropellerIDE for Spin and PASM.

BST does not run on a Pi.

Peter Jakacki · 2015-05-16 05:13

Rsadeika wrote: »

I saw an interesting comment in one of the other threads, installing Forth on a Propeller HAT. OK, so what could you possibly gain by doing that?

First, how do use that setup, I think you need a terminal program to access the Forth interpreter. And since the HAT setup is lost once you lose power, you have to redo your whole setup, again and again.

Second, since the HAT will have devices/sensors attached, how would you access those from a program on the RPi(bash,python,C,...,etc)? I do not recall Forth having a command line access to it.

Third, how easy is it to add device drivers to Forth, for instance a sht11 module? Their is probably a dozen more items of inquiry, but this may be a good start.

I am sold on the usability of the Propeller HAT, just have to figure out the best way of incorporating it into the RPi system for the easiest and best use.

Ray

Heater answered this quite well, so I will just fill in some detail FYI.

If you load source code into Forth that's compiled on the Prop it will be sitting in RAM but usually we just backup the image to EEPROM so that it's there on power-up which also includes any AUTORUN directive etc. There's no real need to have a terminal program as such, just the serial port but it depends on how it is being used. So it's possible for the RPi to download "scripts" and source code etc as the "text interpreter" is normally a feature of all but the most bare-bones Forths, if there is such a thing.

You mentioned device drivers like the sht11 module for instance but most of the time these "drivers" just end up being a handful of lines of Forth as in the case of the DHT22 sensors[/url[ I did recently. Even a ping routine that returns with the result in millimetres is only 5 lines of code (no PASM):

#P14			== TRIG
#P15			== ECHO
CLKFREQ #1,000,000 U/	== uscnt
	
: PING ( -- mm )
    TRIG HIGH TRIG HIGH TRIG LOW       --- 10us trigger (dummy cycles)
    (WAITPEQ) (WAITPNE)                --- detect high period
    0 COGREG@ 1 COGREG@ -              --- calculate high period
    uscnt /				--- convert cycles to us
    170145 * 1,000,000 /		--- convert us to millimetres
    ;

So if there is an advantage to having Forth it may well be that rather than having to download a new binary to run new code, you can instead just download the commands or scripts etc to effect the same action perhaps. My Tachyon Forth always compiles words as they are encountered in the text stream so by the time a line terminator is encountered it is ready to execute immediately and also without having to create a temporary word just to run that code just as fast as compiled code including loops and branches etc.

Rsadeika · 2015-05-16 05:59

I am thinking that at some point somebody will come up with a Propeller HAT that will have sensors/devices mounted on the board. So, what will be the easiest way of getting the sensor/device data off of the board? My previous example was a sht11 module, if I have a Forth system that drives the sht11 module, then from a bash,Python, or Perl script I could access the HAT to get a temperature reading? I am using a scripting program example, but it would have to be available to C, Pascal, freeBasic languages as well.

I know that the Propeller HAT is being addressed as a learning tool/method for Spin/PASM, but I am looking ahead to some functional uses for the HAT. So, I am trying to explore the idea that I suggested in another thread: using a scripting language, as an easy method, to get a temperature reading from a sht11 module that is attached to the Propeller HAT, whether it would be Forth, Spin, or PASM that is driving it. Of course the easiest experiment would be to simply turn on/off an LED attached to the Propeller HAT via a script language like bash. I think that when you start getting past the actual, just programming HAT stage, their will be some complexity involved in the setup.

Ray

Peter Jakacki · 2015-05-16 06:14

Rsadeika wrote: »

I am thinking that at some point somebody will come up with a Propeller HAT that will have sensors/devices mounted on the board. So, what will be the easiest way of getting the sensor/device data off of the board? My previous example was a sht11 module, if I have a Forth system that drives the sht11 module, then from a bash,Python, or Perl script I could access the HAT to get a temperature reading? I am using a scripting program example, but it would have to be available to C, Pascal, freeBasic languages as well.

I know that the Propeller HAT is being addressed as a learning tool/method for Spin/PASM, but I am looking ahead to some functional uses for the HAT. So, I am trying to explore the idea that I suggested in another thread: using a scripting language, as an easy method, to get a temperature reading from a sht11 module that is attached to the Propeller HAT, whether it would be Forth, Spin, or PASM that is driving it. Of course the easiest experiment would be to simply turn on/off an LED attached to the Propeller HAT via a script language like bash. I think that when you start getting past the actual, just programming HAT stage, their will be some complexity involved in the setup.

Ray

Once the few lines of code are loaded for the sensor and assuming you haven't loaded any formatted report routines for the sensor you could do something similar to what I did for the DHT22. Sending this string will take a reading and format the reply so that:
DHT@ PRINT" DHT22: " .DECIMAL PRINT" 'C @ " .DECIMAL PRINT" %RH" CR
will return a response in this format:
DHT22: 19.3'C @ 41.5%RH

Of course you could just make a word like "REPORT" out of the reporting action so that is all that is needed to ask for a report.
pub REPORT DHT@ PRINT" DHT22: " .DECIMAL PRINT" 'C @ " .DECIMAL PRINT" %RH" CR ;

Rsadeika · 2015-05-16 08:39

I decided to give this a run, I will test this out using PropForth first. I burned the QS board EEPROM with PropForth, now I noticed that to communicate with it you need a 230400 BAUD setting. Next I have an RPi+ setup in a headless configuration, I will run a connection between the two boards using the UART on the RPi and P31/P30 on the QS board. After I change the UART to run in just plain mode, how do I change the BAUD rate in PropForth to match the RPi? Hopefully some PropForth guys will jump in.

Once I have that taken care of, using a bash script file, how do I turn on/off the P16 LED? To me it looks like bash does not have a way of accessing the RPi UART to make the communication, so I have to use Python serial to link up? If that works, do I just put in the commands '16 pinout' CR, '16 pinhi' CR to do the job, at least to turn on the LED?

By describing the above action, I just narrowed down that the language that you use will have to have a serial component. I guess that means Python, C, Pascal, freeBasic, just too name a few would be able to do the job. Anything that I am missing?

Ray

Heater. · 2015-05-16 09:44

Sure you can access the UART on the Raspi GPIO header with a BASH script. It's just a device that shows up as a file in /dev so:

$ echo "Hello Propeller" > /dev/ttyAMA0

should do it if you have permissions set correctly.

I would not want to use BASH to do this, except as a quick test from the command line.

Just now I'm putting together a webserver that will talk between a web page and the serial port. It's written in JavaScript for node.js. The serial code looks like:

var serialport = require("serialport");

var SerialPort = serialport.SerialPort;

var serialPortStatus = "none";

var sp = new SerialPort("/dev/ttyUSB0", {
    baudrate: 115200,
    parser:   serialport.parsers.readline("\n")
});

function handleSerial (line) {
    // Incomming lines of data will need parsing here.
    // For test we just send the line to the web panel terminal window.
    broadcast('terminalMessage', line);
}


sp.on("open", function () {
    console.log('Serial port open.');
    serialPortStatus = 'open';
    sp.on('data', function (line) {
        console.log('Serial data: ', line);
        handleSerial(line);
    });
});

sp.on("error", function (err) {
    serialPortStatus = err;
    console.log(err);
});

// Writes data and waits until it has finish transmitting to the target serial port before calling the callback.
function writeAndDrain(data, callback) {
    sp.write(data, function () {
        sp.drain(callback);
    });
}

Bill Henning · 2015-05-16 11:29

Why would someone make a specific set of sensors + propeller board unless they had a need for that specific set of sensors?

FYI, sensors need an ADC, which the Raspberry Pi does not have.

Personally, (and not very surprisingly) I prefer RoboPi for my experiments.

Now if you have a specific set of sensors in mind, you could add them to any propeller board, and plug that board into a USB port on the Pi.

Or get a prototyping board large enough for the sensors you want, plus a prop, and mount that on a Pi (I've mounted one of my larger protoboards on Pi's to make a gang EEPROM programmer)

http://www.mikronauts.com/raspberry-pi/raspberry-pi-i2c-eeprom-gang-programmer/

which I use to program the firmware into blank 24LC512 EEPROM's for my RoboPi kits.

Rsadeika wrote: »

I am thinking that at some point somebody will come up with a Propeller HAT that will have sensors/devices mounted on the board. So, what will be the easiest way of getting the sensor/device data off of the board? My previous example was a sht11 module, if I have a Forth system that drives the sht11 module, then from a bash,Python, or Perl script I could access the HAT to get a temperature reading? I am using a scripting program example, but it would have to be available to C, Pascal, freeBasic languages as well.

I know that the Propeller HAT is being addressed as a learning tool/method for Spin/PASM, but I am looking ahead to some functional uses for the HAT. So, I am trying to explore the idea that I suggested in another thread: using a scripting language, as an easy method, to get a temperature reading from a sht11 module that is attached to the Propeller HAT, whether it would be Forth, Spin, or PASM that is driving it. Of course the easiest experiment would be to simply turn on/off an LED attached to the Propeller HAT via a script language like bash. I think that when you start getting past the actual, just programming HAT stage, their will be some complexity involved in the setup.

Ray

prof_braino · 2015-05-16 11:36

Rsadeika wrote: »

PropForth first.....how do I change the BAUD rate in PropForth to match the RPi?

Once I have that taken care of, using a bash script file, how do I turn on/off the P16 LED?

... language that you use will have to have a serial component. I guess that means Python, C, Pascal, freeBasic, just too name a few would be able to do the job. Anything that I am missing?

It might better to change the RPi, as changing baud on linux is very well known and all over the internet. The faster the comms, the faster the system, and the prop is already much slower than the RPi.

To you question, there are a couple ways to change the baud.

1) propforth manual found in

~ /V5.5/doc/propforth.htm

search the manual for baud, find the notes for the "serial" word. Mess with that for 15 minutes, and you should be able to figure it out. If not ask for clarification, I'll get back to you.

2) look in the GettingStartedPropForth.txt file in the same directory where you found the kernel, search for baud. It talks about what I mention in (1), and goes to advanced. The reason its "advanced" is we have to do some cypherin'.

The number we specify for baud in the propforth.spin kernel is internally multiplied by 4 in propforth. The value of the actual baud is bigger than the memory location that holds the number, so Sal did this funky thing rather than waste memory (as only one other person has asked about this in the last couple years). Anyway,

57_600 means 57600 * 4 = 230400 baud.

So if you want 9600 buad, you figure 9600 / 4 = 2400. so you chnage

dlrS_baud = 57_600        ' $S_baud forth word- the actual baud rate is 4x this parameter

to

dlrS_baud = 2_400        ' $S_baud forth word- the actual baud rate is 4x this parameter

or

dlrS_baud = 2400        ' $S_baud forth word- the actual baud rate is 4x this parameter

(underscore are just formatting and are ignored)

and you get 9600 baud. Save the propforth.spin file, and load to the prop using proptool .

prof_braino · 2015-05-16 11:43

Can you point to the forth on RPi hat thread? I don't think I saw that one. Or did I start it? I don't remember well these days.

msrobots · 2015-05-16 17:49

@prof_braino,

You might know that I admire your efforts of documentation and your regular posts about the importance of having strict formulated goals to keep track of a project.

I really like your posts about that, because I personally lack this skill and try to learn from you.

But this one is really stupid, don't you think?

The number we specify for baud in the propforth.spin kernel is internally multiplied by 4 in propforth. The value of the actual baud is bigger than the memory location that holds the number, so Sal did this funky thing rather than waste memory (as only one other person has asked about this in the last couple years). Anyway

I am aware that Sal writes the stuff and you are 'just' doing the public side of the stuff. But - honestly - Don't you think this is quite confusing?

How about:

dlrS_baud = 230400 >> 2        ' $S_baud forth word- the actual baud rate needs to be divided by 4

just my two cents.

Mike

prof_braino · 2015-05-17 14:47

msrobots wrote: »
... this one is really stupid, don't you think? .... - honestly - Don't you think this is quite confusing? How about:
dlrS_baud = 230400 >> 2        ' $S_baud forth word- the actual baud rate needs to be divided by 4

Thanks for the comments. You are right this is a bit confusing, and yours is also an effective solution. The real issue is Sal was specifically recovering bytes that day, and reduced the dictionary footprint by half or something. At the time this was deemed worth the fuss. Sal figured the way he did it would be the most straight forward; I reviewed it and agreed, and that's what we released. The decisions are up to the guy spending the money and/or time.

Nobody noticed or complained till now, so I don't think this is a show stopper. Divide by four before we type the value into the code, or include the shift in the source; which ever way feels right is fine as long as it gets the job done. In any case, that is the price of those particular two bytes recovered. A better solution would address the root cause, which is that we don't have much memory on the processor; obviously hardware changes are out of scope for this project.

Again, if messing with the propforth kernel source is too confusing, it may be easier to have the RPi run at 230400 baud.

Gadgetoid · 2015-05-18 01:36

On the Pi, unless I'm mistaken, to obtain UART speeds above 115200 you'd need to adjust the init_uart_clock value in /boot/config.txt.

It should be 16x the max baud rate that you want to obtain, so the value for 230400 should be:

init_uart_clock=3686400

Source: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=73673

Rsadeika · 2015-05-18 04:50

I went ahead and put together a prototype contraption consisting of an RPi+, QS board, and power supply from a USB-TTL cable. I have the RPi+ and QS wired together via Tx/Rx/ground pins, with the QS board having PropForth burned in on the EEPROM.

I also made modifications to the RPi+, "sudo usermod -a -G dialout pi", added "init_uart_clock=3686400" to the /boot/config.txt file. And after all that, when I do an:
$ echo " \n" > /dev/ttyAMA0
I get "Permission denied" error. Even when I do it with sudo, I still get "Permission denied" error. So, their must be more to it on the RPi+ side, to get access to the port.

Ray

Rsadeika · 2015-05-18 05:44

I went ahead, to further test the port, and removed the "init_uart_clock=3686400" from the /boot/config.txt file, then rebooted and did the "echo" thing, now when the port is back to its default state, I can get access without any errors.

For a, quick and dirty, PropForth may not be the one to use. I believe Tachyon is at 115200 BAUD at default, so I may have to give that a try. If worst comes to worst I might have to write a quick PropGCC program for the QS board, just to lite up an LED. Boy, their just does not seem to be any quick and dirty solutions for testing these ideas.

Ray

Electrodude · 2015-05-18 06:11

Or you could just use a spin compiler.

Quick and dirty solution:

PUB main
  dira[0] := 1 ' make pin 0 an output
  outa[0] := 1 ' make pin 0 high

Doing that via serial commands is only an OBJ block, repeat statement, and if statement away.

Gadgetoid · 2015-05-18 06:23

Electrodude wrote: »
Or you could just use a spin compiler.

Quick and dirty solution:
PUB main
  dira[0] := 1 ' make pin 0 an output
  outa[0] := 1 ' make pin 0 high
Doing that via serial commands is only an OBJ block, repeat statement, and if statement away.

Do you mean watching for compiled SPIN code to be sent over serial, dumping it into a pre-determined portion in memory and then loading it into a cog for execution? I'd love to see a working example of this, it's been in the back of my head to try with Propeller HAT since I got started.

Rsadeika · 2015-05-18 06:51

I guess I was wrong about the default BAUD for TACHYON, it is at 230400 also. I guess I will have to leave this too somebody else to mess with the Forth stuff, I do not want to make changes to the source and then recompile and then reload and then reboot...

I will have to load SimpleIDE 0-9-45 to the RPi, make sure it can access /dev/ttyAMA0, write a quick and dirty C program for accessing the P16-P23 LEDs on the QS board. Then I can try some different programs on the RPi for turning on/off the LEDs on the QS board. This should get me in the frame of mind to purchase a Propeller HAT from Parallax, but I am not so sure about that tedious soldering of the headers...

Ray

Gadgetoid · 2015-05-18 07:06

Rsadeika wrote: »

I am not so sure about that tedious soldering of the headers...

It's fine when you only have to do one

But yes, that's a lot of joints that I hope we'll soon have the expertise to wave solder!

Electrodude · 2015-05-18 08:29

Gadgetoid wrote: »

Do you mean watching for compiled SPIN code to be sent over serial, dumping it into a pre-determined portion in memory and then loading it into a cog for execution? I'd love to see a working example of this, it's been in the back of my head to try with Propeller HAT since I got started.

No, I mean he should just load a Spin program into the Propeller from the RPi instead of using Forth.

Spin over serial is actually very possible. I've been wanting to try it for a while now.

Peter Jakacki · 2015-05-18 09:41

Rsadeika wrote: »

I guess I was wrong about the default BAUD for TACHYON, it is at 230400 also. I guess I will have to leave this too somebody else to mess with the Forth stuff, I do not want to make changes to the source and then recompile and then reload and then reboot...

I will have to load SimpleIDE 0-9-45 to the RPi, make sure it can access /dev/ttyAMA0, write a quick and dirty C program for accessing the P16-P23 LEDs on the QS board. Then I can try some different programs on the RPi for turning on/off the LEDs on the QS board. This should get me in the frame of mind to purchase a Propeller HAT from Parallax, but I am not so sure about that tedious soldering of the headers...

Ray

Default baudrate for Tachyon is currently 115200 but to change it and have it lock in you only need to type/send "<mybaud> CONBAUD <cr>". So to change it to 57600 for instance you would send "57600 CONBAUD <cr>" and the baudrate on the next reboot will be locked in at 57600. You can go all the way up to 3Mbaud if you like. Remember that Tachyon compiles "commands" as it encounters them and then executes them in real-time at the end of the line so this provides a very snappy response in this setup.

BTW, the source for the Tachyon kernel is all in one .spin file so even if there were special changes it only needs an "F11" to recompile and burn.

To blink an LED that is on P4 just type:
4 BLINK

To vary the frequency of that blink to 10 HZ just type:
10 HZ

EDIT: I'm not sure why you didn't try Tachyon first when the link to the Tachyon "Explorer" binary is in my sig, and the whole load and go thing is as easy as pie.

Rsadeika · 2015-05-18 10:00

Just to clarify, I burned my QS board with latest binary version of Tachyon. I have the RPi+ and QS board hooked via /dev/ttyAMA0 and P31/P30. When I turned on the contraption, on the QS board, I noticed that the P17 and P23 LEDs were on, I thought maybe it was setup for VGA. On the RPi+ side, when I gave it an echo "\r\n" > /dev/ttyAMA0, there was nothing.

Since you are saying that the default is set for 115200 BAUD, at some point, I will probably give it another try.

Ray

Peter Jakacki · 2015-05-18 10:06

Rsadeika wrote: »

Just to clarify, I burned my QS board with latest binary version of Tachyon. I have the RPi+ and QS board hooked via /dev/ttyAMA0 and P31/P30. When I turned on the contraption, on the QS board, I noticed that the P17 and P23 LEDs were on, I thought maybe it was setup for VGA. On the RPi+ side, when I gave it an echo "\r\n" > /dev/ttyAMA0, there was nothing.

Since you are saying that the default is set for 115200 BAUD, at some point, I will probably give it another try.

Ray

I noticed that the binary image was actually set for 230400 baud but I patched it back to 115200 baud so use the latest version just in case. It shouldn't have any LEDs on as the only thing the Explorer version does on boot is to check the hardware and report, so all the I/O is left as inputs with only P30 (TXD) as an output.

If you don't want it to do a hardware test and report on boot then just issue the command "AUTORUN NONE" after which it will be locked in not to do anything special on boot.

Rsadeika · 2015-05-18 10:55

I downloaded the suggested file, and when I try to open it with Propeller Tool I get "Checksum Error! Binary file is corrupt".

Ray

Dave Hein · 2015-05-18 11:13

That's because the binary was patched without changing the checksum byte. Try the attached binary file that has the correct checksum.

Rsadeika · 2015-05-18 12:28

Thanks Dave. I loaded the QS board EEPROM with the new Tachyon, still having all the hook ups to the RPi+, I tried the 'echo "16 BLINK\r\n" > /dev/ttyAMA0', and I get no joy. I did do a "stty -F /dev/ttyAMA0 115200" just to make sure the port was set at 115200. I am starting to get the feeling that you need a serial terminal program to access Tachyon. It also seems like it is not able to work using command line instruction like 'echo "\r\n" > /dev/ttyAMA0". I guess using some RPi+ script program will not work, unless I am doing something completely wrong.

This is not looking good for the good guys.

Ray

Electrodude · 2015-05-18 13:36

Rsadeika wrote: »

I am starting to get the feeling that you need a serial terminal program to access Tachyon.

A serial terminal program should work just as well as stty and echo/cat/whatever. They both talk to the serial device the same way, and the Linux kernel doesn't care that stty and echo are two separate programs as opposed to just one with a serial terminal program, so there should be no difference.

What's wrong with programming the propeller on your HAT with a spin compiler on the RPi to do stuff at a baud rate that the RPi likes?

ratronic · 2015-05-18 14:37

Ray I have a program I am working on now that uses the Pi's UART to talk to the Propeller. It takes video frames

from the Pi's camera and determines the detected objects x, y screen position and size then sends a 6 byte packet

to the Propeller after each frame. On the Propeller side I use C but have also used Spin to receive the same information.

I'm sure Tachyon or another language that runs on the Propeller could decipher what the Pi is spitting out.

D.P · 2015-05-18 17:28

Rsadeika wrote: »

Thanks Dave. I loaded the QS board EEPROM with the new Tachyon, still having all the hook ups to the RPi+, I tried the 'echo "16 BLINK\r\n" > /dev/ttyAMA0', and I get no joy. I did do a "stty -F /dev/ttyAMA0 115200" just to make sure the port was set at 115200. I am starting to get the feeling that you need a serial terminal program to access Tachyon. It also seems like it is not able to work using command line instruction like 'echo "\r\n" > /dev/ttyAMA0". I guess using some RPi+ script program will not work, unless I am doing something completely wrong.

This is not looking good for the good guys.

Ray

are you getting the tachyon banner but cannot input?

hardware flow control must be off on your TERM/tty

Forth and Propeller HAT

Comments