Hmmm, now that would be nice [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
I wanted to use the microchip MCP2525 SPI CAN controller, but it may be that
the software SPI of the propeller is too slow, as it only does 2.5 Mbits (in assembler).
A SJA1000 would be much faster, but would need at least 12 pins.
I think Parallax should integrate a UART into every cog. One that it able to do
RS232, I2C and SPI with a little help of software, like the USI's that Atmels
ATTiny have.
I wish you great success. I ran into problems with the can bus in my car and the locals seemed to fix the thing but who knows? Is 9000 mile tire life to be expected?
AND the number of sensors, actuators, motors and controllers that would become cheaply available for robohobbyists is astounding.
Won't the bandwidth problem go away with the nextProp?
What is the problem with having the functionality of a Uart spread over 3 cogs?
10 Mbit would be nice, but how do I do it?
In http://forums.parallax.com/forums/default.aspx?f=25&m=162743&g=162974#m162974
Beau Schwabe said that 2.5Mbit (using assembler) is the maximum.
I don't think that this is fast enough for 1Mbit CAN, because you additionally have to
transfer the data from/to hub RAM.
I had some time to draw a schematic.
(Only a draft for my experiments).
The MCP2515 is supplied by 3.3V, so it can be directly connected to the propeller.
In this case you have to use a CAN transceiver with a separate logic supply.
I used the TLE6250 G V33. It may be that this part is not easy to get for hobbyists.
The rest of the boards consists of a propeller and interfaces for keyboard, mouse and
VGA. It could be used as a CAN monitor or test generator. One of my ideas is to use
it to trigger an oscilloscope to a specified CAN id or message content.
Together with an SD card, it could be used as a CAN logger.
The graphics capabilities of the propeller are usable for applications like simulation or
visualisation of vehicle equipment.
www.elmelectronics.com/ has a whole line of IC's designed to interface with both OBD2 and CAN bus automotive applications. The propeller could be be used to simply read and write serial data to one of those chips, provide a user interface, and/or data logging. I've thought about someday using one of these in a project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
Take a look at the sdspi routines in the fat16 drivers (see the object repository, or http://tomas.rokicki.com/fat16work) for some
clues on how to make SPI faster. In particular, look at sdspiqasm. You can make it even faster than this.
Getting nearly 10mbit/s transmissions are pretty easy; just put the data into one phase register, use the other counter to generate
the clock, and shift that phase register. (Of course, this does potentially 32 bits at 20mbit/sec, and then there's a delay while you
reload the next 32 bits but you should be able to get more than 10mbit/sec without a problem.)
For receiving, you need two instructions per bit (the clock is generated by a counter so all you need to do is test an input bit
and then set the corresponding bit in the input word). The sdspiqasm does this for eight bits, but it's pretty easy to extend to
32 bits if you want. The burst rate is 10mbit/sec, but the aggregate read throughput using eight bits is probably closer to
5mbit/sec but it can be improved.
Since CAN peaks at 1mbit/sec, I don't see why you need such high speed anyway.
JoannaK said...
Remy: it's one of thinse things I thought that might be feasible to do .. It would take some ams coding, but I htink it's quite realisitic to have.
I would do it, if I had any direct use for it... Sadly I always have more ideas than time.
the problem is that you have to write and read at the the same time.
I think that the phase register and the counter are not of much use here.
And: After reading a message, (up to 13 Bytes), you have to transfer it to
the hub ram, so other cogs can read and process it.
This needs some time. In between, the next message may arrive.
The controller has a read buffer, but it has to be read out completely
before the next message is completely received.
The controller needs additional commands via SPI, and you have to read out the
status continuously.
Therefore you need a SPI clock that is significantly higher than the CAN bitrate.
Reading is the critical part, as you have to read out received messages in time,
or you'll loose some.
Writing is not critical, if you don't need the maximum data rate. You have all the time
you want to write the message into the send buffer.
If you just use the bus to connect some sensors to your weather station, all this is not a
problem.
But if you want to use the bus for something more professional, like a CAN monitor,
you must not loose any message.
I personally do not like software driven high speed SPI. It's not reliable.
I still don't think it's much of a problem. For concurrent read/write you should be able to do bursts at
three instructions per bit, so that's 6.7Mbit/sec burst. The overhead of control and reading/writing
hub ram should not be sufficient to cause underrun if the controller chip has any buffering whatsoever.
I mean, 6.7Mbit/sec is a *lot* faster than 1Mbit/sec no matter how you slice it.
But I don't have the hardware, and I don't have much interest (yet) in the CAN bus, so I'm not going
to implement it.
I'm not sure why you think software driven high speed SPI is any less reliable than hardware SPI.
Maybe it is in the world of interrupt-driven CPUs, but by dedicating a cog you have all the
determinism of dedicated hardware.
We'll see.
If it doesn't work, I'll use the SJA1000 CAN controller instead.
It would need at least 11 I/O pins of the propeller, but I'm sure
that it'll work.
We'll see.
If it doesn't work, I'll use the SJA1000 CAN controller instead.
It would need at least 11 I/O pins of the propeller, but I'm sure
that it'll work.
Seeing this thread again last month inspired me to finish up a OBD-II terminal object I'd been hacking away on for a while, and now I think it's finally ready.
Using just two IO pins, two cogs, and a Microchip MCP2551 CAN transceiver IC to handle level shifting and line driving, I'm able to consistently and reliably get on-board diagnostic information from my 2009 Chevy Cobalt. This object is specifically designed for OBD-II, so it's hard-coded to transmit and receive at 500Kbps, and the reader routine rejects any messages that don't meet a bunch of criteria (correct Identifier, correct byte count, correct Mode and PID bytes...) which was necessary to filter out unrelated messages and make things run smoother. While everything seems to be working fine in this version, a much earlier version caused my dashboard instrumentation to go haywire till I disconnected the Prop.
ausdj
Posts: 5
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
I wanted to use the microchip MCP2525 SPI CAN controller, but it may be that
the software SPI of the propeller is too slow, as it only does 2.5 Mbits (in assembler).
A SJA1000 would be much faster, but would need at least 12 pins.
I think Parallax should integrate a UART into every cog. One that it able to do
RS232, I2C and SPI with a little help of software, like the USI's that Atmels
ATTiny have.
cheers
Karl
I wish you great success. I ran into problems with the can bus in my car and the locals seemed to fix the thing but who knows? Is 9000 mile tire life to be expected?
AND the number of sensors, actuators, motors and controllers that would become cheaply available for robohobbyists is astounding.
Won't the bandwidth problem go away with the nextProp?
What is the problem with having the functionality of a Uart spread over 3 cogs?
For advanced work... with defined executive functions and a network of props, why not something like:
http://www.fpgajournal.com/news_2006/06/20060619_05.htm
$20 and all you would have to add is the administrative glue.
Rich
How fast do you need it?
I agree that it would be nice if the counters would support a UART mode or something like that.
10 Mbit would be nice, but how do I do it?
In http://forums.parallax.com/forums/default.aspx?f=25&m=162743&g=162974#m162974
Beau Schwabe said that 2.5Mbit (using assembler) is the maximum.
I don't think that this is fast enough for 1Mbit CAN, because you additionally have to
transfer the data from/to hub RAM.
(Only a draft for my experiments).
The MCP2515 is supplied by 3.3V, so it can be directly connected to the propeller.
In this case you have to use a CAN transceiver with a separate logic supply.
I used the TLE6250 G V33. It may be that this part is not easy to get for hobbyists.
The rest of the boards consists of a propeller and interfaces for keyboard, mouse and
VGA. It could be used as a CAN monitor or test generator. One of my ideas is to use
it to trigger an oscilloscope to a specified CAN id or message content.
Together with an SD card, it could be used as a CAN logger.
The graphics capabilities of the propeller are usable for applications like simulation or
visualisation of vehicle equipment.
Post Edited (Kloss) : 3/6/2007 4:04:20 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
-- Remy
clues on how to make SPI faster. In particular, look at sdspiqasm. You can make it even faster than this.
Getting nearly 10mbit/s transmissions are pretty easy; just put the data into one phase register, use the other counter to generate
the clock, and shift that phase register. (Of course, this does potentially 32 bits at 20mbit/sec, and then there's a delay while you
reload the next 32 bits but you should be able to get more than 10mbit/sec without a problem.)
For receiving, you need two instructions per bit (the clock is generated by a counter so all you need to do is test an input bit
and then set the corresponding bit in the input word). The sdspiqasm does this for eight bits, but it's pretty easy to extend to
32 bits if you want. The burst rate is 10mbit/sec, but the aggregate read throughput using eight bits is probably closer to
5mbit/sec but it can be improved.
Since CAN peaks at 1mbit/sec, I don't see why you need such high speed anyway.
-- Remy
the problem is that you have to write and read at the the same time.
I think that the phase register and the counter are not of much use here.
And: After reading a message, (up to 13 Bytes), you have to transfer it to
the hub ram, so other cogs can read and process it.
This needs some time. In between, the next message may arrive.
The controller has a read buffer, but it has to be read out completely
before the next message is completely received.
The controller needs additional commands via SPI, and you have to read out the
status continuously.
Therefore you need a SPI clock that is significantly higher than the CAN bitrate.
Reading is the critical part, as you have to read out received messages in time,
or you'll loose some.
Writing is not critical, if you don't need the maximum data rate. You have all the time
you want to write the message into the send buffer.
If you just use the bus to connect some sensors to your weather station, all this is not a
problem.
But if you want to use the bus for something more professional, like a CAN monitor,
you must not loose any message.
I personally do not like software driven high speed SPI. It's not reliable.
three instructions per bit, so that's 6.7Mbit/sec burst. The overhead of control and reading/writing
hub ram should not be sufficient to cause underrun if the controller chip has any buffering whatsoever.
I mean, 6.7Mbit/sec is a *lot* faster than 1Mbit/sec no matter how you slice it.
But I don't have the hardware, and I don't have much interest (yet) in the CAN bus, so I'm not going
to implement it.
I'm not sure why you think software driven high speed SPI is any less reliable than hardware SPI.
Maybe it is in the world of interrupt-driven CPUs, but by dedicating a cog you have all the
determinism of dedicated hardware.
If it doesn't work, I'll use the SJA1000 CAN controller instead.
It would need at least 11 I/O pins of the propeller, but I'm sure
that it'll work.
did it work?
http://obex.parallax.com/object/314
Using just two IO pins, two cogs, and a Microchip MCP2551 CAN transceiver IC to handle level shifting and line driving, I'm able to consistently and reliably get on-board diagnostic information from my 2009 Chevy Cobalt. This object is specifically designed for OBD-II, so it's hard-coded to transmit and receive at 500Kbps, and the reader routine rejects any messages that don't meet a bunch of criteria (correct Identifier, correct byte count, correct Mode and PID bytes...) which was necessary to filter out unrelated messages and make things run smoother. While everything seems to be working fine in this version, a much earlier version caused my dashboard instrumentation to go haywire till I disconnected the Prop.
OBD-II Terminal using CAN bus