The OP seems to have jumped from RS485 to Xbee as it is EASY. Using RS422 and Forth might have kept this a wired project.
Nope, I don't want to use Xbee, it's too expensive for what I want to do, I want to stay wired.
This thread has generated a lot of debate! All the discussion about Forth is tempting me to take a look at the language... but maybe I should not, one more language to learn! Gulp!
Having some kind of propeller OS/monitor in one cog would be nice.
Let's say I have 5 prop modules connected on a 2-wire RS485 network with a master Raspberry Pi:
I open a terminal on the rPi and I issue a list network command (propnet-scan)
I then receive reply from prop ID 1-2-4-5 : oops module #3 is not powered/not responding
After that, I could connect to module #2 (propnet-connect 2)
I could read the state of the inputs and force outputs to 0 or 1. I could also see how many cogs are used, stop or start the module.
The module #2 program flashes a LED at a rate of 500ms... I want to change that to 100ms so I open the prop-tool, do my change and issue a command to replace the binary of module #2 with the new one.
Nope, I don't want to use Xbee, it's too expensive for what I want to do, I want to stay wired.
This thread has generated a lot of debate! All the discussion about Forth is tempting me to take a look at the language... but maybe I should not, one more language to learn! Gulp!
Having some kind of propeller OS/monitor in one cog would be nice.
Let's say I have 5 prop modules connected on a 2-wire RS485 network with a master Raspberry Pi:
I open a terminal on the rPi and I issue a list network command (propnet-scan)
I then receive reply from prop ID 1-2-4-5 : oops module #3 is not powered/not responding
After that, I could connect to module #2 (propnet-connect 2)
I could read the state of the inputs and force outputs to 0 or 1. I could also see how many cogs are used, stop or start the module.
The module #2 program flashes a LED at a rate of 500ms... I want to change that to 100ms so I open the prop-tool, do my change and issue a command to replace the binary of module #2 with the new one.
Just my thoughts on monitor functionnality
Too easy, that is with Forth it is too easy. But I know, you don't want to learn another "language", you just want to do it the hard way
Forth is a target resident language and operating environment so it is more like the O/S except it all sits inside the Prop.
Too easy, that is with Forth it is too easy. But I know, you don't want to learn another "language", you just want to do it the hard way
Forth is a target resident language and operating environment so it is more like the O/S except it all sits inside the Prop.
Not really, what I do for FTP etc is to put Forth into a less interactive mode so that it just listens and does without echoing and prompting etc. In the case of RS485 I would just have each unit listening for the select sequence before they continued with the normal Forth console where it accepts "commands". Those commands are nothing special, they are simply words that are either predefined or ones that you define and in fact that can be added to the dicitonary of words that Forth "understands" even from your RPi or whatever over the network.
Assume all "commands" are text separated by at least one space and terminated with a CR.
To read the state of an input you can either use the long form and say 8 PIN@ . which would print the value either as a 0 or a -1, or else define that as P? at some point (and even in situ) by saying : P? PIN@ IF "+" ELSE "-" THEN EMIT ; which when executed will take a number say 8 P? and return a simple + or -, too easy. To set a port pin just say 8 PINSET or 8 PINCLR to set or clear the pin, even this command could be defined to suit.
If you wanted to run a function/word/command in a cog you simply say ' MYFUNC 6 RUN but even that could be redefined so you could simply say RUN: MYFUNC
Changing a variable in Forth is easy, say the name of the variable is rate so you could say 100 rate ! or even define it like this 100 RATE
That's just a very quick rundown on how you might handle it, and from what you are asking it is something I could bash out in under half an hour.
EDIT: here's a quick little demo of reading and setting port pins as per my suggestions (except the output is in full interactive mode with prompts) : P? PIN@ IF "+" ELSE "-" THEN EMIT ; ok 8 P? + ok 7 P? + ok 0 P? + ok 0 PINCLR ok 0 P? - ok 0 PINSET ok 0 P? + ok
A more Spin friendly but identical version of P? could look like this: pub P? ( port -- )
PIN@ IF "+" ELSE "-" THEN EMIT
;
I'm just wondering what kind of tolerance to pain a person has to have before ": P? PIN@ IF "+" ELSE "-" THEN EMIT ;"makes any frikken sense at all.
This makes JavaScript look good. Or even MicroSoft 4K BASIC.
I'm just wondering what kind of tolerance to pain a person has to have before ": P? PIN@ IF "+" ELSE "-" THEN EMIT ;"makes any frikken sense at all.
This makes JavaScript look good. Or even MicroSoft 4K BASIC.
I respect you Heater buddy, but you just can't butt out can you? I think it's your insecurities manifesting itself. If Forth was as bad as you make out you wouldn't take the time to rubbish it. Seeing that you do take the time I can only come to the conclusion that because you can't get your head around it and others can, that you are jealous?
EDIT:
BTW, here's a commented breakdown of that one line definition over many lines with lots of comments, so much more C like this way, isn't it?
[FONT=courier new]
: Add a new definition to the dicionary, name follows
P? the name can use any symbols etc excepting the space character
PIN@ This kernel word accepts a stack parameter as the port number, reads the pin and returns the result as 0 or -1 (all bits set)
IF Unlike "IF <condition> then I will do this", this IF will decide "IF it will do this" simply by the stack parameter supplied beforehand (0 or non-zero)
"+" Place the value for the ASCII + onto the stack (Tachyon allows this form rather than having to look it up)
ELSE What ELSE would you do IF you didn't follow through
"-" in this case I will leave the value for an ASCII - on the stack
THEN after all that THEN continue on
EMIT EMIT the value from the top of the stack out the current I/O device (serial port)
; This marks the end of the definition, an EXIT (return) is compiled and the new name becomes active doing step-by-step what we have defined
[/FONT]
Comments
This thread has generated a lot of debate! All the discussion about Forth is tempting me to take a look at the language... but maybe I should not, one more language to learn! Gulp!
Having some kind of propeller OS/monitor in one cog would be nice.
Let's say I have 5 prop modules connected on a 2-wire RS485 network with a master Raspberry Pi:
I open a terminal on the rPi and I issue a list network command (propnet-scan)
I then receive reply from prop ID 1-2-4-5 : oops module #3 is not powered/not responding
After that, I could connect to module #2 (propnet-connect 2)
I could read the state of the inputs and force outputs to 0 or 1. I could also see how many cogs are used, stop or start the module.
The module #2 program flashes a LED at a rate of 500ms... I want to change that to 100ms so I open the prop-tool, do my change and issue a command to replace the binary of module #2 with the new one.
Just my thoughts on monitor functionnality
Too easy, that is with Forth it is too easy. But I know, you don't want to learn another "language", you just want to do it the hard way
Forth is a target resident language and operating environment so it is more like the O/S except it all sits inside the Prop.
Does Forth has to be modified to do that?
Not really, what I do for FTP etc is to put Forth into a less interactive mode so that it just listens and does without echoing and prompting etc. In the case of RS485 I would just have each unit listening for the select sequence before they continued with the normal Forth console where it accepts "commands". Those commands are nothing special, they are simply words that are either predefined or ones that you define and in fact that can be added to the dicitonary of words that Forth "understands" even from your RPi or whatever over the network.
Assume all "commands" are text separated by at least one space and terminated with a CR.
To read the state of an input you can either use the long form and say 8 PIN@ . which would print the value either as a 0 or a -1, or else define that as P? at some point (and even in situ) by saying : P? PIN@ IF "+" ELSE "-" THEN EMIT ; which when executed will take a number say 8 P? and return a simple + or -, too easy. To set a port pin just say 8 PINSET or 8 PINCLR to set or clear the pin, even this command could be defined to suit.
If you wanted to run a function/word/command in a cog you simply say ' MYFUNC 6 RUN but even that could be redefined so you could simply say RUN: MYFUNC
Changing a variable in Forth is easy, say the name of the variable is rate so you could say 100 rate ! or even define it like this 100 RATE
That's just a very quick rundown on how you might handle it, and from what you are asking it is something I could bash out in under half an hour.
EDIT: here's a quick little demo of reading and setting port pins as per my suggestions (except the output is in full interactive mode with prompts)
: P? PIN@ IF "+" ELSE "-" THEN EMIT ; ok
8 P? + ok
7 P? + ok
0 P? + ok
0 PINCLR ok
0 P? - ok
0 PINSET ok
0 P? + ok
A more Spin friendly but identical version of P? could look like this:
pub P? ( port -- )
PIN@ IF "+" ELSE "-" THEN EMIT
;
I'm having fun so far
This makes JavaScript look good. Or even MicroSoft 4K BASIC.
I respect you Heater buddy, but you just can't butt out can you? I think it's your insecurities manifesting itself. If Forth was as bad as you make out you wouldn't take the time to rubbish it. Seeing that you do take the time I can only come to the conclusion that because you can't get your head around it and others can, that you are jealous?
EDIT:
BTW, here's a commented breakdown of that one line definition over many lines with lots of comments, so much more C like this way, isn't it?
Here's the decompilation: That's 13 bytes of code. Execution time at 230,400 baud is 62us and at 2M baud is 23us, code minus the EMIT takes 11us.