 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Adding CAN to CGCOLORMAX
  Page 2 of 5   |
|||||
| Author | Message | ||||
donmck Guru  Joined: 09/06/2011 Location: AustraliaPosts: 1313 |
Interesting but I don't see it as a logical path for a MaxiMite. Price starts at $55, and the expansion board at $72 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_P AGE&nodeId=2615&dDocName=en535444 Sure, you could make up your own expansion board for it, but compared to a UBW32 at $39 plus Mick's adapter board, or Rob's full ColorMax currently at $50-ish, I can't see it in the mix. Don... https://www.dontronics.com |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
RS232 needs a driver line that goes on with the start bit and then off with the end of the last stop bit. I can test RS485. I think I can test CAN. Micromites and Maximites! - Beginning Maximite |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
It looks as though the USB and CAN run without expansion, I agree a custom board is probably more useful for MM though. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_P AGE&nodeId=2615&dDocName=en535536 |
||||
| TinkersALot Regular Member  Joined: 20/11/2012 Location: United StatesPosts: 72 |
Just a couple of questions related to use of Arduino pins: Are there potential compatibility issues with various "other arduino cards". It seems there might be because of "sites like this": http://shieldlist.org/ Would another approach be to define a "addessable system bus" from some of the other 20 I/O pins on the device so that other devices are concieved, as long as they know the rules of the bus compatibility issues could be held at bay? and then there is this (there may be others -- I just stumbled on this by accident): http://shieldlist.org/skpang/canbus |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Sorry Rob, This escapes me.. what `driver line' do you mean? Unless you mean CTS/RTS etc.. If so these can be RS485 driven as well, they are hardware handshake lines.. I am not trying to criticise, I really am interested in where the MM side (the TTL side) would differ between RS232 and RS485. Software wise I feel that they would be the same. I have been using Rs485 (4 wire, 2 for Tx and 2 for Rx) ... actually 8 wire as we have 2 channels, for 27 years at work, I have been using RS232 for as long as I can remember.. I have always fed whichever Tx driver chip with the TTL input signals and at the other end the Receiver chip spat out TTL.. The 232/485 was the transport mechanism with Rs232 being a single line that swings between minus (3v-25v) and positive (3v-25v) with 12v the norm so a signal level was either -12v or +12 or tri-stated off. RS485 is a dual wire (twisted pair) transmission that has 1 wire swing high and the other swing low (0-5v swings, ie if one wire is LOW the other would be High) so any voltage spike appeared on both wires and the differential between the 2 wires was maintained.. In fact in my job I have made many converters between the 2 standards and the TTL side was always the same (just connect up the relevant driver/receiver chips) RS232 has a max distance of about 150m (or was that feet) RS485 can transmitted a lot further, 4km I think, (we have runs of up to 1.5km). Don might shed a bit more light as he has had the same exposure to both as I have Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| donmck Guru Joined: 09/06/2011 Location: AustraliaPosts: 1313 |
From what I can remember RS-232 was 50 feet, yes the old system in Australia when I got into it, and RS-485 was 3KM. We used a pair of TI 75107s and 75110 rx/tx pairs to drive dual diff in parallel from dual DEC VAX systems. I know these ICs had enable signals applied to the gates, but it is too many years ago for me to remember if we hooked up to RTS/CTS type of UART signals. I would need to look at the schematics of your current driver boards to give an opinion on this Mick, as I can't remember any gate enabling at all. Which basically is what you have just said. Still I am 13 years out of the game, and I don't have schematics of anything but a few old 1930-1945 systems we had, that I thought were worth saving. 
Don... https://www.dontronics.com |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Yes that is the way we run 16 Terminals on the same line... They all tri-state their Tx drivers and listen for a command that is for them (the address is embedded in the message from the Master system) and when they are asked for a response (called POLLing) they then enable their Tx driver and send the response back to the master. So at any one time you will have 16 Terminals receiving the same data and a max of ONE sending at a time. As to RTS/CTS we didnt use it in our setup but there is no reason that I can see that it cant be used as well. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
I should really have said something like "implement the control signal for RS485". I am not exactly sure what it is used for but I think that it is used to turn the receiver into a transmitter on a non duplex link. It seems important to Rob and he has explained exactly what is needed so I thought I should help him out. In fact I promised that it would be in V4.1 so I am running late on this also. Geoff Geoff Graham - http://geoffg.net |
||||
| Keith W. Senior Member  Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Hope this helps. Regarding RS422 and RS485. RS422 is typically unidirectional, i.e. data travels from a transmitter to a receiver via a twisted pair (balanced 100 ohm) cable, two pairs for a bidirectional system. With RS485, data may travel bidirectional on the same cable pair. This is achieved by enabling/disabling the driver at each station on the cable with a polling or addressing system to control the flow of data, with a master station in control. The standard stipulates that up to 32 transceivers may be used on a cable with RS485, perhaps modern chips exceed this. To enable the bidirectional data flow the driver chips (which often also houses a receiver) has an enable pin that is controlled by the communication software, effectively disconnecting the driver from the line. RS422 and RS485 are much more robust than RS232 and work over extended distances at high speed, the data rate may be reduced for extreme distances. It is necessary that the twisted pair line be biased (and usually terminated at the ends) to hold the line in the correct state when no drivers are enabled. The receiver chip only requires a differential signal of some millivolts (50?) for correct operation, while also capable of nulling out some volts of common mode signal. A suggested universal system would be usable for RS422. i.e two pair cable, or RS485 with a single pair cable, with a jumper to select between receive signals to the CPU. The electrical specs for RS422 and RS485 are a little different; however RS485 drivers and receiver chips I think exceed the RS422 spec.National Semiconductor had an excellent application note regarding RS485 and RS422 terminating and biasing etc but I will have to search for it again. Maximites could now operate with RS485 transceivers connected to the comms serial ports and utilize an existing output pin to control the RS485 driver. The driver to be enabled before a complete transmission and then disabled. RS422 would also be applicable for SPI comms. Keith W. |
||||
elproducts Senior Member Joined: 19/06/2011 Location: United StatesPosts: 282 |
I keep seeing the MCP2551 listed for the hardware. You might want to do a little searching on this since the PIC32 is 3.3v and MCP2551 is 5v based. Here is one thread where someone when through the numbers. http://www.microchip.com/forums/m621312-print.aspx If you need a simple board to test this out, here is one I've found: 
I've also seen mention of the Arduino CAN shield that uses the MCP2515 -MCP2551. CAN shield This is typically for devices that don't have a CAN peripheral like Arduino. The 2515 handles all the hard stuff. This just needs a SPI connection using the D10-D13 Arduino pins. Since MMBASIC can drive SPI on these pins has anybody tried to run CAN with this shield? I'm not sure I see the advantage to using the CAN peripheral on the PIC32 vs this external 2515 CAN chip option. Seems like the MMBASIC software will get more complicated and use up more memory to implement something rarely used. While a software implementation using SPI is an optional add-on routine for those that need it. What is the advantage to all this tear-up? Seems like SPI to CAN could be implemented now with a CAN shield. This is one of the reasons I pushed early on for Arduino Shield compatibilty. It allows the Maximite to expand with simple plug in shields but keeps the core Maximite simple to build and lower cost. What am I missing? www.elproducts.com |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
It's very simple on the Olimex Duinomite-Mega. Such simplicity is far cheaper than a shield. They often strike me as grossly overpriced. I expect direct interfacing can be a lot faster, too. John |
||||
| donmck Guru Joined: 09/06/2011 Location: AustraliaPosts: 1313 |
All of that rings a bell Mick. I should have remembered. As you know, I wrote a comms monitor program about 25 years ago, to better interpret line usage. All done in 8086 assembly. I think it is still used today in some circles. Don... https://www.dontronics.com |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Ok Thanks Geoff, Rob said a `control line for RS232' which confused me hence my extended messages. Whilst I think that is good to implement and probably important for 2 wire, 1 pair, RS485 (which I admit to no experience with but I have extensive experience with 4 wire, 2 pair, RS485). I admit that I did think that (the control line) would be just a simple I/O line that the user would set or clear as needed and wasn't needed to be implemented as part of the MMBasic command. I can see that it certainly would have some merit (and would probably be very useful in 2 wire RS485). I assume that if RS232 was selected that the I/O pin that would be used for this control pin would still be free for general use? If using 4 wire RS485 the control line is not needed unless you have more than 1 device on the same line as the MASTER's Tx would connect to The SLAVE's Rx and Vice Versa. Regards, Mick PS. I am not being negative, in fact I am quite excited by all that as it is something I use on a daily basis at work. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Hi Keith, You have made me re-visit life itself... I did a bit of researching (Dr Google) RS232, RS422 & RS485 and it seems that what we use at work is an uncommon 4 wire form of RS485.. I remember in the dim dark ages (about 1992) when we changed the driver chips from what was called RS422 to RS485 because of the new terminal being installed.. but we always had 16 SLAVE terminals so we originally had a non-standard RS422 (which stipulates a max of 10 slaves) which we converted to an unusual (but not incorrect) 4 wire RS485 version... Rs485 being typically a 2 wire circuit, needing the control line for even 2 device connections. All very interesting and exciting.. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
Yes, I was planning a simple option on the end of the open command (like the option for open collector outputs). When not used the I/O pin would be free for other use. Because MMBasic buffers serial transmit data and sends it in the background it is difficult for a BASIC program to know when to raise and lower this signal. This is why it must be implemented in firmware. Whatever turns you on! 
Geoff Geoff Graham - http://geoffg.net |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Thank you Geoff. Your post explaining that communication is performed in the background informs us the reason why driver control for RS485 must be incorporated into the comms software, not use a pin under control by a simple MMBasic program. Wow, the OPEN command is already powerful. Although now in the past my experience with RS485 encourages me to join Bigmick in finding this exciting. Keith W. |
||||
| CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
"RS232 needs a driver line that goes on with the start bit and then off with the end of the last stop bit." Sorry about all of that. My keyboard was possessed. I meant to type RS485. The oft-used 2-line RS485 needs control over the driver, to enable the driver when you are transmitting and disable to receive. The timing of this needs to happen on the sub-bit time level. If I send 2 bytes to the serial port from within code, the bytes are put into a buffer very quickly and then slowly transmitted out the port line that is the serial port. If I were to watch the contents of that buffer, one then the other byte would disappear from that buffer as they are being moved to transmit out. The trouble is that the last byte could still be slowly serial transmitting out when I think it is gone/done. RS485 driver control is best done from a low level the same way that adding one vs. two stop bits is best done from a low level. Micromites and Maximites! - Beginning Maximite |
||||
| greybeard Senior Member Joined: 04/01/2010 Location: AustraliaPosts: 161 |
It's also very handy if you make the preamble and postamble times of the transmit conrol configurable. If they are then it is quite esy to use the 'rs485' funtionality to control a radio link transmitter as well. Which if you stand back a bit and just have confgurable RTS on the RS232 setup you've got pretty much all you need. ie: assert RTS ( RS485 TX on ) wait a bit send all of the TX data wait a bit till TX data has been sent deassert RTS ( RS485 TX off ) Flush RX buffer ( as typically it is now full of the TX data that has been echoed ) wait for real RX data ( if any ) and process. |
||||
| CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
assert RTS ( RS485 TX on ) wait a bit send all of the TX data wait a bit till TX data has been sent deassert RTS ( RS485 TX off ) I'd stop here, as far as automatic action of firmware is concerned. Leave it up to the end user to ignore the echoed message, as verifying the echo can be a form of collision detection and bus integrity check. Flush RX buffer ( as typically it is now full of the TX data that has been echoed ) wait for real RX data ( if any ) and process. Micromites and Maximites! - Beginning Maximite |
||||
| greybeard Senior Member Joined: 04/01/2010 Location: AustraliaPosts: 161 |
my bad, I'd leave the rx buffer flushing to the end user as well. I didn't distinguish between the overall functionality and the embedded RTS /TX control logic.  |
||||
| Page 2 of 5 |
|||||
 Print this page |
