I also use 4-wire phone cable for powering RS485 networks as the actual current and voltage drop and very minor at 24V or more. My current setup doesn't even use twisted pair which you would think is a must but for this project I'm using 10-way ribbon cable with the 2 center conductors for RS485 and double grounds on either side then another 2 for power. At 24V each node despite the DC-DC converters and other things on it, it only draws 30ma at 24V and I've powered the network reliably down to 7V just as a test.
Seeing that 1-wire circuits are used for longer distances too where noise immunity is not a problem there is no reason that simple 1-wire half-duplex circuits can't be used for networks either. Of course I always like to put in a small series resistor in that pin just to help to protect the pin and limit the fault current. I'm using 1Mbit as a medium speed as this allows any full-duplex 115k baud to operate without problems, regardless of the traffic in either direction. But I am allowing the driver to be initialized with the clock ticks too that a system needs so you can run it real slow over much longer distances or up to 4Mbit for really low latency especially when you need to talk to lots of nodes constantly. It is quite possible to carry on multiple simultaneous independent full-duplex connections over the network reliably.
Neat stuff Peter! On my farm I have various equipment that I would like to hook up all together:
Automated pressure vessels, aquaponics, greenhouse controllers, cheese and meat curing controllers, automated distillation controllers and a chicken door and hen counter!
Could you post a simple module of two props boards hooked up with schematic and sample module for us in the slower lane please when you have time. First time for "RS485" for me.
Neat stuff Peter! On my farm I have various equipment that I would like to hook up all together:
Automated pressure vessels, aquaponics, greenhouse controllers, cheese and meat curing controllers, automated distillation controllers and a chicken door and hen counter!
Could you post a simple module of two props boards hooked up with schematic and sample module for us in the slower lane please when you have time. First time for "RS485" for me.
RS485 is super easy and I normally use chips that are 1/8 loading full fail-safe rather than the ancient 176s or even MAX485s. The newer chips don't require line biasing as this is a problem for when there are no transceivers driving the line it is possible for receivers to pickup noise. One other problem is when a line is shorted or "over-terminated" which causes receivers to see an active signal which ends up looking like a break or lots of null characters (with framing errors). RS485 chips only require 2 I/O from the Prop as the rx and tx are combined and also the /RE and TE.
You don't need to worry about how fast the network runs but you can adjust the speed as you may need to run at slower rates anyway for longer runs. There is nothing special you need to do for the slave nodes but the master effectively disables the slave part and after issuing an address character ends up looking like a point-to-point full-duplex connection. So if you wanted to address slave 23 and send the command to turn on a couple of sprinklers it might look like this in your code:
23 CONNECT PRINT" ON 3 SPRINKLER ON 4 SPRINKLER" CR
So CONNECT simply selects RS485 as the streaming channel and encodes 23 as $97 and sends this over the network to select the unit after which a connection is established. Any further data is handled the same as a direct console connection as if you typed in ON 3 SPRINKLER ON 4 SPRINKLER<cr>. If you are sending this interactively from the master you will need to add CON to the end of that to bring you back to the console.
( Terse mode example command would simply be: N3SN4S )
...
So CONNECT simply selects RS485 as the streaming channel and encodes 23 as $97 and sends this over the network to select the unit after which a connection is established. Any further data is handled the same as a direct console connection as if you typed in ON 3 SPRINKLER ON 4 SPRINKLER<cr>. If you are sending this interactively from the master you will need to add CON to the end of that to bring you back to the console.
...
Wow really easy and if there are Words for actions and such on the slave this is a RPC, tachyon style.
Have a look at such ones as the 65hvd08x chips as they have excellent specs and a good price and you can run your chip from 3.3 or 5V although if you use 5V you just need a resistor from the data rx/tx to the Prop. I use tiny MSOP8 packs and just allow for a resistor or ferrite bead in the bus A&B lines although in most instances you won't need this.
The chips also have an internal pull-down on TE so there is no need to add one to make sure the chip doesn't glitch while the Prop is still booting and there is a pull-up on the rx line too.
Great found them in DIP8 for easy prototyping (IC TXRX RS-485 3.3V 8-DIP), $5.01 each at Digikey. Going to use the 3.3V version as a start.
Thanks
The SN65HVD75DGK I'm using in this current project are in a tiny VSSOP8 package and only cost around $1 in reel quantities but even 100 off price is only $2. There is usually no need to use 5V parts but sometimes if that's all you've got then just make sure to include the current limit resistor otherwise stick with the 3.3V parts.
The SN65HVD75DGK I'm using in this current project are in a tiny VSSOP8 package and only cost around $1 in reel quantities but even 100 off price is only $2.
Heads up on this part!
This part does generate a 50-320ns glitch on the receive data line when TE goes low which doesn't bother my software but sure does upset the logic analyser's decode. I'm using this part with /RE and TE tied together as well as the tx and rx data tied together and it may be that this glitch only shows up in this configuration. It seems someone on the STM32F4xx forum complained about this same chip too except the glitch did bother the UART immensely. I will probably be looking at a suitable replacement although I will see if what happens with /RE tied low (very awkward).
BTW, V2.9 is available in the dropbox and includes pingpong networking. By default no network is assigned but use PPCFG ( tr te baud adr -- ) from EXTEND to set it. If transmit and receive data pin is on 14 and transmit enable on 15 we can set the unit to 2Mbit as unit 5 like this:
14 15 2,000,000 5 PPCFG
The configuration is locked into EEPROM and becomes active on the next reboot. To disable networking or if the board is a master just:
OFF PPCFG
The full-duplex part of the protocol doesn't play that nice with baud rates that are slower than the console output as that would require buffering or slowing down console output.
I've been successful in downloading source code over the network to nodes and in fact you can select all units and blindly load them all together at once.
The slave ping-pong driver is built into V2.9 but needs to be configured before using for the first time. Once EXTEND is loaded you can use PPCFG in this manner:
<tx/rx data pin> <tx enable pin> <baud> <address> PPCFG
So using 14 and 15 for tr and te at 1M baud and setting the unit address to 5 ($85):
14 15 1,000,000 5 PPCFG
This setting becomes active after the next reboot when the serial driver is loaded automatically. You can then deploy the Prop on the network without even loading your application yet as you can also address all the nodes globally and load them all up with your app in one hit.
If you need to disable a node or use it as a master just type OFF PPCFG and reboot.
Here's a couple of analyser screenshots, first one just shows the unit responding to its address and the second is a response to the .VER command where you can see the "-TACH" part this command:
.VER Propeller .:.:--TACHYON--:.:. Forth V29160607.1620
I had to slow down the master polling just to make sure the capture wasn't overly cluttered.
As part of efficiently processing commands over the RS485 network there is a terse command mode which can be easily entered and exited as required. All printable characters are processed as soon as they are encountered and look-up an execution vector table and if a vector exists it will be called. This also includes 0 to 9 although they have the same processing vector.
An example of running the equivalent of 0 256 DUMP is 0,256D where the comma or space etc do not have a vector but cause any new digits to push the old number down on the stack and start again. A CR is normally required for verbose mode but there is no terminator required when in terse mode nor is there any echo either, just do. Any control character will terminate terse mode and return back to the normal "verbose" mode, that is, the Forth text interpreter.
To enter terse mode just use ~ followed by a space or tab or CR.
The code is very simple and requires only 285 bytes including the 96 word table.
--- TERSE MODE ---
{ Terse mode allows for very compact and fast parsing of parameters and commands in a flexible manner
Each printable ASCII character is mapped to an execute vector which is executed immediately the character
is accepted. All decimal digits are automatically accumulated with multiple numbers entered when a
non-digit precedes a digit.
Example of running the equivalent of 0 256 DUMP is 0,256D
}
--- table of execution vectors for all printable characters
96 WORDS tcodes
--- table building word
: AS ( ch -- ) IMMEDIATE
[COMPILE] ' [COMPILE] GRAB SWAP BL - 2* tcodes + W!
;
--- redefine some VM opcodes as hub executable words
: PLUS + ; : MINUS - ; : STORE ! ; : FETCH @ ; : MUL * ;
--- define some terse commands --- just add in the same manner
'.' AS .
'+' AS PLUS
'-' AS MINUS
'*' AS MUL
'/' AS /
'S' AS .S
'V' AS .VER
'D' AS DUMP
'P' AS PPCFG
'R' AS REBOOT
'!' AS STORE
'@' AS FETCH
LONG tkeys --- maintain history of last few characters
--- Accumulate this digit but push old one if previous character was not a digit
: +DIGIT tkeys 1+ C@ "0" "9" WITHIN NOT IF 0 THEN 10 * tkeys C@ "0" - + ;
--- just fill in the digit codes automatically at compile time
0 10 ADO ' +DIGIT I $10 + 2* tcodes + W! LOOP
--- enter terse mode after a terminator such as a CR or SPACE or TAB - any control key exits
: ~ IMMEDIATE
BEGIN WKEY DUP BL => WHILE tkeys @ 8<< OVER + tkeys ! BL - 2* tcodes + W@ ?DUP IF CALL THEN REPEAT
DROP CR
;
Great!
Just for information (not complaining) italian keyboard does not have some characters often used by programmers, like: ~ { }
Well I made an oops on top of that as well since ~ is already used as an equivalent to Spin's ~ to clear a variable. Looks like I will use a ^ caret instead of a ~ wet spaghetti strand
btw, since the terse mode has such a small footprint I've added it to EXTEND.
I have written various drivers for SPI Flash but for the life of me I am having a brain fog day. I've searched my files and can't see them or maybe they are buried in an app but in the process I've compiled a quick list of devices that have been interfaced into Tachyon. Most of these drivers are quite full-featured too. So help me to find all the other ones I'm missing or just make a suggestion for some that haven't been done yet while I keep scouring my 20 plus Terabytes of hard-drives!!!
okay then, don't, I've found the driver sitting in the version of Tachyon I did for the P2. So since I had it there I converted it across for the P1 as well. It was a cinch with the SPI instructions.
I started a port of your LCD drivers to a QVGA 320*240 ILI9341based display. It shows good signs of life - but due to lack of free time optimizatons are currently shelved.
--- table building word
: AS ( ch -- ) IMMEDIATE
[COMPILE] ' [COMPILE] GRAB SWAP BL - 2* tcodes + W!
;
Can you explain and show the construction of this table please
tcodes 96 DUMP
This is not revealing much.
It is really quite simple, as the very best things are. The tcode table is comprised of 16-bit execution vectors corresponding to all printable characters $20 to $7F so that as each character is received the non-zero vector associated with it is executed. Simple! Digits have a common vector and simply build up as the top stack item and pushed by an initial zero as soon as a new digit is detected preceded by any non-digit. In fact this is what happens on the first digit encountered too.
The AS word finds the code address of the following word using the tick ' but of course Tachyon always compiles but then GRAB executes what has just been compiled temporarily so effectively "grabs" these parameters and puts them on the stack. So now we have the value for the character and the execution address. Do a SWAP to get the character value but remove the $20 offset so that $20..$7F becomes $00..$5F or 96 distinct values which we use as an index into 16-bit vectors, therefore the 2*. Add that index into the base address of the table with tcodes + then store the 16-bits at that hub address with W!.
Here's a quick list of active vectors from my test system:
.tcodes
21 ! ~!
2A * ~*
2B + ~+
2D - ~-
2E . PRINT
2F / /
30 0 +DIGIT
31 1 +DIGIT
32 2 +DIGIT
33 3 +DIGIT
34 4 +DIGIT
35 5 +DIGIT
36 6 +DIGIT
37 7 +DIGIT
38 8 +DIGIT
39 9 +DIGIT
40 @ ~@
44 D DUMP
50 P PPCFG
52 R REBOOT
53 S .S
56 V .VER
63 c .TS
69 i ID
6C l LED
70 p PULSE
73 s SCR
74 t TRIG
76 v .VOLTS ok
This ping-pong network protocol is getting pretty interesting. Not only have I hooked up about 14 modules with the current project but I've also loaded up older boards including my Pixie VGA board which has 2x RS485 plus PS/2 (via USB connector) keyboard as Tachyon has a VGA driver built-in. There's also a whole ton of boards including LCD displays, motor controllers, etc. I have three VGA monitors hanging off the bus and I will probably roll a special graphics version with a very cut down version of Tachyon as the graphics chews up most of the hub RAM.
But you don't have to wait to fit RS485 to use this networking as a single I/O pin can be the network. Just add a series resistor of around 100 ohms or so simply for pin protection and join all your Tachyon boards together after assigning pins, baud rate, and a node ID with PPCFG. At the moment it assumes you have both the transmit/receive (TR) data pin and a transmit enable (TE) pin but I will update that so you can put in a non-valid number such as -1 for the TE.
There is a small MASTER chat program I am using from one of the disabled nodes to communicate with the network. I can talk to the Forth console on any individual node or all of them all at once albeit without echo which is very handy for updating software. This also means you can be connected to a node, type the brutal COLD command to wipe out everything except the precompiled kernel and it will still talk to you. The chat software resends the address on every CR so even though you may reset the Prop it will connect again automatically. This will probably be updated to automatically reconnect on loss of response instead but these are still early days.
The break detection that is built into Tachyon's normal serial receive routine that resets the Prop on a break is also employed in the ping-pong network so you can force all the nodes to reset by issuing a break for a few milliseconds (at 1Mbit). I'm sure I can get the software to run possibly up to 4Mbit too and the protocol automatically handshakes due to the way the data ping pongs back and forth. The terse command mode is also very handy and invaluable for fast response to network commands.
sonds like a great infrastructure for home, barn, factory or similar type of system automation.
I've always found all these RS485 protocols very limited and fixed, they might work fine for what they were intended for but they also get quite complicated too. As for me I just like to keep it simple and super flexible at the same time. I think this way of doing it achieves that very nicely as I can enhance the protocol on the fly. Certainly I will be using it more and more in my projects, even just Prop to Prop(s) using single I/O connections.
I have a whole string of boards hooked up and I wanted a quick visual way (using WS2812 RGB LEDs) of checking that they were correctly addressed so I addressed them globally "111 chat" and pasted this simple one liner:
3 rxpars EC@ $7F AND 300 * ms VERY RED 300 ms 3 seconds LIGHT GREEN
and I get a very colorful chaser that lights up the boards in sequence and eventually resets the colors back in sequence too. That 3 rxpars EC@ $7F AND could be reduced to MYID I guess as that would be useful (so I did).
@Peter
in my 4-wire phone cable network I run 5V, GND, 1-wire
and was thinking to use the free 4th line as a half duplex line to run your NW without the RS485 HW.
50 meters will be enough for the core NW and maybe 150 to reach most peripherals - rest I can do wireless.
I don't have a very electrically noisy environment here,
so maybe with reduced baudrate it could work??
Well that's something you can experiment with easily as you could start off slow and progressively command a remote unit to change baud rate until it doesn't work But I would cheat and put in some code that would reset the baud rate after a couple of bus resets in a row. It would be interesting to see how it works but you would be running the Prop I/O directly. 5V is a bit low to use for bus power though. Anyway I might play with this too and hook it up to the scope to see how well it fares.
Currently a bit off topic for you RS 485 networkers but I got the HC06 part to do some bluetooth communication for my fire truck project.
Here the steps I want to do:
1. configuration of HC06 by Linux-PC: find a Tachyon suitable baudrate via AT commands. I don't know wether 115200 Baud is possible via Bluetooth.
2. Set the compatible baudrate for the Tachyon via serial interface. This implies possible adaption of minicom settings so serial comm is compatible between minicom and HC06.
3. Replace "minicom" rx/tx from propplug by HC06 rx/tx
4. reset propeller and talk Forth via bluetooth :-)
I would appreciate if you could correct me if I'm wrong.
PS: I have a problem with my lenovo debian complaining about missing firmware for bluetooth. So no bluetooth device is given by linux. Tips for this issue are also welcome.
thanks in advance, proplem
As long as the HC06 and Tachyon are set to the same baudrate it doesn't matter about minicom as it is using an rfcomm device so the baudrate is not utilized. The main thing is to setup the HC06 in the first place to the correct baudrate but since they all seem to be set to a miserable 9600 baud you could always set Tachyon to a really slow 9600 and after establishing communications write a little bit of code to to change the HC06 baudrate.
Not sure about missing bluetooth but you will have to pair your bluetooth device before being able to use them. Use your bluetooth manager in your setting or on your panel. Then I bind that device to an rfcomm channel and service like this:
sudo rfcomm bind 3 00:12:03:10:22:81 1
Where it gets bound to rfcomm3 using serial port service 1. In minicom in serial port setup I set the device as /dev/rfcomm3.
All the binds I have in a bash script for my devices but there might be a better way. See how you go but you can also try serial connection from your phone using BlueTerm or something similar, you only need to pair and then connect. Remember the 9600 baud trick to get started - 9600 CONBAUD and reset.
This 485 topic is interesting, but outside my experience. Peter tried to get me to consider 485 instead of tcp/ip on a project some time ago, and I am starting to come around.
but first ...
1) If I understand the ping/pong it is a send/confirm approach, byte by byte. What would the estimated byte/sec throughput be at say 115200 baud? 1M?
2) do you generally hard code the device address in code or use on-board jumpers to id a propeller ?
3) with the glitchy chips in mind, what would be a recommended 485 interface chip in a DIP format?
4) Is the master set by who starts the conversation?
5) Are the 4-wire TELCO runs limited to 1 A/contact? Is there any advantage to using cat5?
Thanks!
This 485 topic is interesting, but outside my experience. Peter tried to get me to consider 485 instead of tcp/ip on a project some time ago, and I am starting to come around.
but first ...
1) If I understand the ping/pong it is a send/confirm approach, byte by byte. What would the estimated byte/sec throughput be at say 115200 baud? 1M?
2) do you generally hard code the device address in code or use on-board jumpers to id a propeller ?
3) with the glitchy chips in mind, what would be a recommended 485 interface chip in a DIP format?
4) Is the master set by who starts the conversation?
5) Are the 4-wire TELCO runs limited to 1 A/contact? Is there any advantage to using cat5?
Thanks!
RS485 itself is very basic, it is simply using balanced lines to achieve noise resistant signaling speed and distance over a shared half-duplex bus. It's the protocols that are used that can become rather complex but PP is not so.
1. It is not a send/confirm except in the case of an individual address select whereas all selected slave traffic is essentially receive something then send something back to implement full-duplex over half-duplex lines. What is received can often be a null simply to elicit more data which in itself might be a null, none of which are passed as data. Imagine a full-duplex line, even when the receive line is idle we can still send something back or nothing. The nulls are the equivalent of an idle "ball", you can't bounce the ball back until you've got it and vice-versa. Each character received is like a clocking signal to send a character back. On a fully utilized line you can expect the full-duplex speed to be around 43% of the bus speed but a future enhancement to the protocol may allow bulk transfers too increasing that figure close to the bus speed.
2. ID jumpers are too bulky and a hardware hog for most of my designs but the PP network is disabled on a fresh kernel load and is only activated after a PPCFG command where you can specify the address which is locked into EEPROM. Of course your design could use jumpers somehow if you want and your software could read these then set the address via PPCFG.
3. Apparently it is only these 20Mbit 65HVD75 chips that have the glitch but the software works with these anyway so no problem. But I do recommend that you always use full fail-safe chips as RS485 lines can be troublesome otherwise. Just please don't use the ancient 75176 bipolar chips that some places still try to sell you along with the free layer of dust.
4. Slaves don't speak until they are spoken to and the master initiates all communication and is responsible for handling "lost balls". It is possible later on that I will introduce multi-master but most applications only use a single master which also keeps everything nicely regulated.
5. Telco connectors are just plain bulky too plus you need two on every board but this also creates a discontinuity in the transmission path increasing ringing and limiting speeds. The ideal is to have every node connect onto a line without breaking it or adding a lengthy stub, the shorter the stub the better. But of course you can use anything you like etc. I use switching regs on my nodes and supply 24V so you are only talking tens of milliamps per node.
Cat5 is handy but it's also a relatively bulky cable to wire directly to my nodes although I have used it. I mostly prefer the proper telco grade phone cable, the copper is single-core but soft and corrosion resistant, very easy to work with. Both of these cables are twisted pair which is what you want, but make sure you actually use a pair that is twisted. You can though get away with non-twisted pair cable depending upon the application and my current project uses continuous 10-way ribbon with RS485 as the inner pair surrounded by ground pairs and a 24V pair on one outer. Because it is limited to several meters it has lots of advantages such as very short stub lengths due to the IDC crimped inline without disturbing the cable and allowing nodes to intimately tap into the bus.
However don't overthink RS485, it's not complicated and if you look back at my glitch thread you will see a very simple RS485 layout.
After downloading the dropbox files I struggled with compiling and writing a new kernel on a device (eval board). I was searching for a (long) while and found:
less ./prj/tachyon/20160616/Tachyon\ V2.9.spin
"./prj/tachyon/20160616/Tachyon\ V2.9.spin" may be a binary file. See it anyway?
And then I remembered - some time ago the same happened to me. Solution was:
file ./prj/tachyon/20160616/Tachyon\ V2.9.spin
./prj/tachyon/20160616/Tachyon V2.9.spin: Little-endian UTF-16 Unicode text
./20160616/Tachyon V2.7.spin: Little-endian UTF-16 Unicode text, with CRLF line terminators
./20160616/old/Tachyon V2.5.spin: Little-endian UTF-16 Unicode text
./20160616/old/Tachyon V2.2.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.4.spin: Little-endian UTF-16 Unicode text
./20160616/old/Tachyon V2.6.spin: Little-endian UTF-16 Unicode text
./20160616/old/Tachyon1v1-VGA.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.1.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.3-23_140305,1330.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.3.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/testing/Tachyon V2.4.spin: Little-endian UTF-16 Unicode text
./20160616/Spin files/VGA_512x384_Bitmap.spin: Little-endian UTF-16 Unicode text, with CRLF line terminators
./20160616/Tachyon V2.8.spin: Little-endian UTF-16 Unicode text
./20160616/conflicts/Tachyon V2.7 (peter-P2212T's conflicted copy 2015-07-16).spin: Little-endian UTF-16 Unicode text
./20160616/conflicts/Tachyon V2.7 (peter-P2212T's conflicted copy 2015-07-29).spin: Little-endian UTF-16 Unicode text
./20160616/Tachyon V2.9 (linux-g7rw's conflicted copy 2016-06-12).spin: Little-endian UTF-16 Unicode text
Comments
Seeing that 1-wire circuits are used for longer distances too where noise immunity is not a problem there is no reason that simple 1-wire half-duplex circuits can't be used for networks either. Of course I always like to put in a small series resistor in that pin just to help to protect the pin and limit the fault current. I'm using 1Mbit as a medium speed as this allows any full-duplex 115k baud to operate without problems, regardless of the traffic in either direction. But I am allowing the driver to be initialized with the clock ticks too that a system needs so you can run it real slow over much longer distances or up to 4Mbit for really low latency especially when you need to talk to lots of nodes constantly. It is quite possible to carry on multiple simultaneous independent full-duplex connections over the network reliably.
Automated pressure vessels, aquaponics, greenhouse controllers, cheese and meat curing controllers, automated distillation controllers and a chicken door and hen counter!
Could you post a simple module of two props boards hooked up with schematic and sample module for us in the slower lane please when you have time. First time for "RS485" for me.
RS485 is super easy and I normally use chips that are 1/8 loading full fail-safe rather than the ancient 176s or even MAX485s. The newer chips don't require line biasing as this is a problem for when there are no transceivers driving the line it is possible for receivers to pickup noise. One other problem is when a line is shorted or "over-terminated" which causes receivers to see an active signal which ends up looking like a break or lots of null characters (with framing errors). RS485 chips only require 2 I/O from the Prop as the rx and tx are combined and also the /RE and TE.
You don't need to worry about how fast the network runs but you can adjust the speed as you may need to run at slower rates anyway for longer runs. There is nothing special you need to do for the slave nodes but the master effectively disables the slave part and after issuing an address character ends up looking like a point-to-point full-duplex connection. So if you wanted to address slave 23 and send the command to turn on a couple of sprinklers it might look like this in your code:
23 CONNECT PRINT" ON 3 SPRINKLER ON 4 SPRINKLER" CR
So CONNECT simply selects RS485 as the streaming channel and encodes 23 as $97 and sends this over the network to select the unit after which a connection is established. Any further data is handled the same as a direct console connection as if you typed in ON 3 SPRINKLER ON 4 SPRINKLER<cr>. If you are sending this interactively from the master you will need to add CON to the end of that to bring you back to the console.
( Terse mode example command would simply be: N3SN4S )
What chip then?
The chips also have an internal pull-down on TE so there is no need to add one to make sure the chip doesn't glitch while the Prop is still booting and there is a pull-up on the rx line too.
Thanks
The SN65HVD75DGK I'm using in this current project are in a tiny VSSOP8 package and only cost around $1 in reel quantities but even 100 off price is only $2. There is usually no need to use 5V parts but sometimes if that's all you've got then just make sure to include the current limit resistor otherwise stick with the 3.3V parts.
Heads up on this part!
This part does generate a 50-320ns glitch on the receive data line when TE goes low which doesn't bother my software but sure does upset the logic analyser's decode. I'm using this part with /RE and TE tied together as well as the tx and rx data tied together and it may be that this glitch only shows up in this configuration. It seems someone on the STM32F4xx forum complained about this same chip too except the glitch did bother the UART immensely. I will probably be looking at a suitable replacement although I will see if what happens with /RE tied low (very awkward).
BTW, V2.9 is available in the dropbox and includes pingpong networking. By default no network is assigned but use PPCFG ( tr te baud adr -- ) from EXTEND to set it. If transmit and receive data pin is on 14 and transmit enable on 15 we can set the unit to 2Mbit as unit 5 like this:
14 15 2,000,000 5 PPCFG
The configuration is locked into EEPROM and becomes active on the next reboot. To disable networking or if the board is a master just:
OFF PPCFG
The full-duplex part of the protocol doesn't play that nice with baud rates that are slower than the console output as that would require buffering or slowing down console output.
I've been successful in downloading source code over the network to nodes and in fact you can select all units and blindly load them all together at once.
The slave ping-pong driver is built into V2.9 but needs to be configured before using for the first time. Once EXTEND is loaded you can use PPCFG in this manner:
<tx/rx data pin> <tx enable pin> <baud> <address> PPCFG
So using 14 and 15 for tr and te at 1M baud and setting the unit address to 5 ($85):
14 15 1,000,000 5 PPCFG
This setting becomes active after the next reboot when the serial driver is loaded automatically. You can then deploy the Prop on the network without even loading your application yet as you can also address all the nodes globally and load them all up with your app in one hit.
If you need to disable a node or use it as a master just type OFF PPCFG and reboot.
Here's a couple of analyser screenshots, first one just shows the unit responding to its address and the second is a response to the .VER command where you can see the "-TACH" part this command:
.VER Propeller .:.:--TACHYON--:.:. Forth V29160607.1620
I had to slow down the master polling just to make sure the capture wasn't overly cluttered.
As part of efficiently processing commands over the RS485 network there is a terse command mode which can be easily entered and exited as required. All printable characters are processed as soon as they are encountered and look-up an execution vector table and if a vector exists it will be called. This also includes 0 to 9 although they have the same processing vector.
An example of running the equivalent of 0 256 DUMP is 0,256D where the comma or space etc do not have a vector but cause any new digits to push the old number down on the stack and start again. A CR is normally required for verbose mode but there is no terminator required when in terse mode nor is there any echo either, just do. Any control character will terminate terse mode and return back to the normal "verbose" mode, that is, the Forth text interpreter.
To enter terse mode just use ~ followed by a space or tab or CR.
The code is very simple and requires only 285 bytes including the 96 word table.
--- TERSE MODE --- { Terse mode allows for very compact and fast parsing of parameters and commands in a flexible manner Each printable ASCII character is mapped to an execute vector which is executed immediately the character is accepted. All decimal digits are automatically accumulated with multiple numbers entered when a non-digit precedes a digit. Example of running the equivalent of 0 256 DUMP is 0,256D } --- table of execution vectors for all printable characters 96 WORDS tcodes --- table building word : AS ( ch -- ) IMMEDIATE [COMPILE] ' [COMPILE] GRAB SWAP BL - 2* tcodes + W! ; --- redefine some VM opcodes as hub executable words : PLUS + ; : MINUS - ; : STORE ! ; : FETCH @ ; : MUL * ; --- define some terse commands --- just add in the same manner '.' AS . '+' AS PLUS '-' AS MINUS '*' AS MUL '/' AS / 'S' AS .S 'V' AS .VER 'D' AS DUMP 'P' AS PPCFG 'R' AS REBOOT '!' AS STORE '@' AS FETCH LONG tkeys --- maintain history of last few characters --- Accumulate this digit but push old one if previous character was not a digit : +DIGIT tkeys 1+ C@ "0" "9" WITHIN NOT IF 0 THEN 10 * tkeys C@ "0" - + ; --- just fill in the digit codes automatically at compile time 0 10 ADO ' +DIGIT I $10 + 2* tcodes + W! LOOP --- enter terse mode after a terminator such as a CR or SPACE or TAB - any control key exits : ~ IMMEDIATE BEGIN WKEY DUP BL => WHILE tkeys @ 8<< OVER + tkeys ! BL - 2* tcodes + W@ ?DUP IF CALL THEN REPEAT DROP CR ;Just for information (not complaining) italian keyboard does not have some characters often used by programmers, like:
~
{
}
Massimo
Wow neat Peter, this has been a burst of 485 goodness, waiting for my chips so I can hook up the bots.
Well I made an oops on top of that as well since ~ is already used as an equivalent to Spin's ~ to clear a variable. Looks like I will use a ^ caret instead of a ~ wet spaghetti strand
btw, since the terse mode has such a small footprint I've added it to EXTEND.
I have written various drivers for SPI Flash but for the life of me I am having a brain fog day. I've searched my files and can't see them or maybe they are buried in an app but in the process I've compiled a quick list of devices that have been interfaced into Tachyon. Most of these drivers are quite full-featured too. So help me to find all the other ones I'm missing or just make a suggestion for some that haven't been done yet while I keep scouring my 20 plus Terabytes of hard-drives!!!
*** Basics in EXTEND ***
- I2C - 400kHz
- SPI - fast 4MHz opcodes
- SERIAL - PBasic style - 400K speeds
- RS485 - "PING-PONG" full-duplex multidrop networking
- CHARACTER LCD - full streaming support + big digits + rolling digit mode
- GRAPHIC LCD - SSD2119 ST9720
- VGA - text mode with big digits + line drawing (1 COG)
- PING - distance in millimetres or microseconds
- DHT22 family - humidity and temperature
- WS2812 RGB LED
- PWM - 32 channel 8-bit 7.6kHz (1 COG) - also flexible waveform generation
- I2C EEPROM
- RTC - DS3231/DS1302/PCF8563/etc MCP79410 SEIKO or soft
- MCP3208 A/D
- RCDAC - Uses duty-mode and RC
- RCTIME
*** Extras ***okay then, don't, I've found the driver sitting in the version of Tachyon I did for the P2. So since I had it there I converted it across for the P1 as well. It was a cinch with the SPI instructions.
This is not revealing much.
It is really quite simple, as the very best things are. The tcode table is comprised of 16-bit execution vectors corresponding to all printable characters $20 to $7F so that as each character is received the non-zero vector associated with it is executed. Simple! Digits have a common vector and simply build up as the top stack item and pushed by an initial zero as soon as a new digit is detected preceded by any non-digit. In fact this is what happens on the first digit encountered too.
The AS word finds the code address of the following word using the tick ' but of course Tachyon always compiles but then GRAB executes what has just been compiled temporarily so effectively "grabs" these parameters and puts them on the stack. So now we have the value for the character and the execution address. Do a SWAP to get the character value but remove the $20 offset so that $20..$7F becomes $00..$5F or 96 distinct values which we use as an index into 16-bit vectors, therefore the 2*. Add that index into the base address of the table with tcodes + then store the 16-bits at that hub address with W!.
Here's a quick list of active vectors from my test system:
This is what I needed to see as well.
Restore the BL offset, doh.
This ping-pong network protocol is getting pretty interesting. Not only have I hooked up about 14 modules with the current project but I've also loaded up older boards including my Pixie VGA board which has 2x RS485 plus PS/2 (via USB connector) keyboard as Tachyon has a VGA driver built-in. There's also a whole ton of boards including LCD displays, motor controllers, etc. I have three VGA monitors hanging off the bus and I will probably roll a special graphics version with a very cut down version of Tachyon as the graphics chews up most of the hub RAM.
But you don't have to wait to fit RS485 to use this networking as a single I/O pin can be the network. Just add a series resistor of around 100 ohms or so simply for pin protection and join all your Tachyon boards together after assigning pins, baud rate, and a node ID with PPCFG. At the moment it assumes you have both the transmit/receive (TR) data pin and a transmit enable (TE) pin but I will update that so you can put in a non-valid number such as -1 for the TE.
There is a small MASTER chat program I am using from one of the disabled nodes to communicate with the network. I can talk to the Forth console on any individual node or all of them all at once albeit without echo which is very handy for updating software. This also means you can be connected to a node, type the brutal COLD command to wipe out everything except the precompiled kernel and it will still talk to you. The chat software resends the address on every CR so even though you may reset the Prop it will connect again automatically. This will probably be updated to automatically reconnect on loss of response instead but these are still early days.
The break detection that is built into Tachyon's normal serial receive routine that resets the Prop on a break is also employed in the ping-pong network so you can force all the nodes to reset by issuing a break for a few milliseconds (at 1Mbit). I'm sure I can get the software to run possibly up to 4Mbit too and the protocol automatically handshakes due to the way the data ping pongs back and forth. The terse command mode is also very handy and invaluable for fast response to network commands.
I've always found all these RS485 protocols very limited and fixed, they might work fine for what they were intended for but they also get quite complicated too. As for me I just like to keep it simple and super flexible at the same time. I think this way of doing it achieves that very nicely as I can enhance the protocol on the fly. Certainly I will be using it more and more in my projects, even just Prop to Prop(s) using single I/O connections.
I have a whole string of boards hooked up and I wanted a quick visual way (using WS2812 RGB LEDs) of checking that they were correctly addressed so I addressed them globally "111 chat" and pasted this simple one liner:
3 rxpars EC@ $7F AND 300 * ms VERY RED 300 ms 3 seconds LIGHT GREEN
and I get a very colorful chaser that lights up the boards in sequence and eventually resets the colors back in sequence too. That 3 rxpars EC@ $7F AND could be reduced to MYID I guess as that would be useful (so I did).
in my 4-wire phone cable network I run 5V, GND, 1-wire
and was thinking to use the free 4th line as a half duplex line to run your NW without the RS485 HW.
50 meters will be enough for the core NW and maybe 150 to reach most peripherals - rest I can do wireless.
I don't have a very electrically noisy environment here,
so maybe with reduced baudrate it could work??
Here the steps I want to do:
1. configuration of HC06 by Linux-PC: find a Tachyon suitable baudrate via AT commands. I don't know wether 115200 Baud is possible via Bluetooth.
2. Set the compatible baudrate for the Tachyon via serial interface. This implies possible adaption of minicom settings so serial comm is compatible between minicom and HC06.
3. Replace "minicom" rx/tx from propplug by HC06 rx/tx
4. reset propeller and talk Forth via bluetooth :-)
I would appreciate if you could correct me if I'm wrong.
PS: I have a problem with my lenovo debian complaining about missing firmware for bluetooth. So no bluetooth device is given by linux. Tips for this issue are also welcome.
thanks in advance, proplem
Not sure about missing bluetooth but you will have to pair your bluetooth device before being able to use them. Use your bluetooth manager in your setting or on your panel. Then I bind that device to an rfcomm channel and service like this:
sudo rfcomm bind 3 00:12:03:10:22:81 1
Where it gets bound to rfcomm3 using serial port service 1. In minicom in serial port setup I set the device as /dev/rfcomm3.
All the binds I have in a bash script for my devices but there might be a better way. See how you go but you can also try serial connection from your phone using BlueTerm or something similar, you only need to pair and then connect. Remember the 9600 baud trick to get started - 9600 CONBAUD and reset.
but first ...
1) If I understand the ping/pong it is a send/confirm approach, byte by byte. What would the estimated byte/sec throughput be at say 115200 baud? 1M?
2) do you generally hard code the device address in code or use on-board jumpers to id a propeller ?
3) with the glitchy chips in mind, what would be a recommended 485 interface chip in a DIP format?
4) Is the master set by who starts the conversation?
5) Are the 4-wire TELCO runs limited to 1 A/contact? Is there any advantage to using cat5?
Thanks!
RS485 itself is very basic, it is simply using balanced lines to achieve noise resistant signaling speed and distance over a shared half-duplex bus. It's the protocols that are used that can become rather complex but PP is not so.
1. It is not a send/confirm except in the case of an individual address select whereas all selected slave traffic is essentially receive something then send something back to implement full-duplex over half-duplex lines. What is received can often be a null simply to elicit more data which in itself might be a null, none of which are passed as data. Imagine a full-duplex line, even when the receive line is idle we can still send something back or nothing. The nulls are the equivalent of an idle "ball", you can't bounce the ball back until you've got it and vice-versa. Each character received is like a clocking signal to send a character back. On a fully utilized line you can expect the full-duplex speed to be around 43% of the bus speed but a future enhancement to the protocol may allow bulk transfers too increasing that figure close to the bus speed.
2. ID jumpers are too bulky and a hardware hog for most of my designs but the PP network is disabled on a fresh kernel load and is only activated after a PPCFG command where you can specify the address which is locked into EEPROM. Of course your design could use jumpers somehow if you want and your software could read these then set the address via PPCFG.
3. Apparently it is only these 20Mbit 65HVD75 chips that have the glitch but the software works with these anyway so no problem. But I do recommend that you always use full fail-safe chips as RS485 lines can be troublesome otherwise. Just please don't use the ancient 75176 bipolar chips that some places still try to sell you along with the free layer of dust.
4. Slaves don't speak until they are spoken to and the master initiates all communication and is responsible for handling "lost balls". It is possible later on that I will introduce multi-master but most applications only use a single master which also keeps everything nicely regulated.
5. Telco connectors are just plain bulky too plus you need two on every board but this also creates a discontinuity in the transmission path increasing ringing and limiting speeds. The ideal is to have every node connect onto a line without breaking it or adding a lengthy stub, the shorter the stub the better. But of course you can use anything you like etc. I use switching regs on my nodes and supply 24V so you are only talking tens of milliamps per node.
Cat5 is handy but it's also a relatively bulky cable to wire directly to my nodes although I have used it. I mostly prefer the proper telco grade phone cable, the copper is single-core but soft and corrosion resistant, very easy to work with. Both of these cables are twisted pair which is what you want, but make sure you actually use a pair that is twisted. You can though get away with non-twisted pair cable depending upon the application and my current project uses continuous 10-way ribbon with RS485 as the inner pair surrounded by ground pairs and a 24V pair on one outer. Because it is limited to several meters it has lots of advantages such as very short stub lengths due to the IDC crimped inline without disturbing the cable and allowing nodes to intimately tap into the bus.
However don't overthink RS485, it's not complicated and if you look back at my glitch thread you will see a very simple RS485 layout.
Is there a possibility to avoid this in future?
I'm using bstc.linux which doesn't get managed with this.
Thanks, proplem
BTW further candidates:
find ./20160616 \( -iname '*.fth' -o -iname '*.spin' \) -exec file {} \;./20160616/Tachyon V2.7.spin: Little-endian UTF-16 Unicode text, with CRLF line terminators./20160616/old/Tachyon V2.5.spin: Little-endian UTF-16 Unicode text
./20160616/old/Tachyon V2.2.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.4.spin: Little-endian UTF-16 Unicode text
./20160616/old/Tachyon V2.6.spin: Little-endian UTF-16 Unicode text
./20160616/old/Tachyon1v1-VGA.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.1.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.3-23_140305,1330.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/old/Tachyon V2.3.spin: Little-endian UTF-16 Unicode text, with very long lines
./20160616/testing/Tachyon V2.4.spin: Little-endian UTF-16 Unicode text
./20160616/Spin files/VGA_512x384_Bitmap.spin: Little-endian UTF-16 Unicode text, with CRLF line terminators
./20160616/Tachyon V2.8.spin: Little-endian UTF-16 Unicode text
./20160616/conflicts/Tachyon V2.7 (peter-P2212T's conflicted copy 2015-07-16).spin: Little-endian UTF-16 Unicode text
./20160616/conflicts/Tachyon V2.7 (peter-P2212T's conflicted copy 2015-07-29).spin: Little-endian UTF-16 Unicode text
./20160616/Tachyon V2.9 (linux-g7rw's conflicted copy 2016-06-12).spin: Little-endian UTF-16 Unicode text