garygid
Well-known member
MCP2515 has 2 buffer receive and 3 transmit.
Which direction applies to us reading the CAN bus?
Which direction applies to us reading the CAN bus?
Complicated question around replacement stereo...
- Thread starter defiancecp
- Start date
Help Support My Nissan Leaf Forum:
defiancecp
Well-known member
Receive - I said transmit earlier thinking about it from the MCP chip's perspective with regard to the SPI, not to the CAN 
garygid
Well-known member
So, a Message arrives and is put into Buffer 1 of 2 and the "flag" is set (or interrupt bit is set).
If the next two messages are quite closely following (about 100 bits at 500k), each would arrive 0.2 ms later. The 2nd msg would go into Buffer 2. Before the 3rd is captured (an needs a buffer), about 400 us after the first, we need to empty at least one buffer, right?
It taker about 10 or 15 us to get one message over the 8mHz serial interface. Does that hardware require 1 interrupt for each byte received by the uP?
Is there a hardware byte-buffer for the incoming serial data transfer?
Cheers, Gary
If the next two messages are quite closely following (about 100 bits at 500k), each would arrive 0.2 ms later. The 2nd msg would go into Buffer 2. Before the 3rd is captured (an needs a buffer), about 400 us after the first, we need to empty at least one buffer, right?
It taker about 10 or 15 us to get one message over the 8mHz serial interface. Does that hardware require 1 interrupt for each byte received by the uP?
Is there a hardware byte-buffer for the incoming serial data transfer?
Cheers, Gary
defiancecp
Well-known member
There's a buffer on the spi, but it's basically last-byte - once the hardware shift register fills, it dumps the new data in that buffer and the old byte is lost. The avr int0-1-2 handlers would basically just disable the other two interrupts, start the spi transfer, and set a flag so the main routine knows there's incoming data from a particular chip, then return. Probably only needst to be 16 or so instructions (might have to asm it to get it this tight), so say 1us lag. Then the SPI interrupt will trigger when a new byte is in place. That interrupt would determine whether there's more data coming, transfer the byte into its own large software buffer, increment the buffer pointer, then either open the CS and re-enable interrupts or continue pulsing. Probably 10 instructions, which would only be a delay at the end of the data. If the interrupts are written efficiently, it could theoretically be just a couple uS per message of delay due to processor overhead.
So i'm just walking through a couple worst case scenarios - maxed bandwidth from all can channels, two busses with 128-bit messages (can max) and a stream of 44-bit messages coming into the lowest priority (so it has to wait on the 128-ers to finish). Assuming simultaneous message waiting flags, and the 44-bit 2nd buffer begins filling immediately on the low-priority bus, at 500kbits that's going to be 88us for the second buffer to fill up, and another 88us before the MAB fills and needs a buffer to pass to. So, the question is, can the spi bus handle the transfer of two 128-bit can messages and a 44-bit can message in the space of 88us? The read command on the spi bus itself has an 8-bit overhead for instruction time, and there's a minimum frame for the CS pin to be up, so if that gives us about 12 pulses of command overhead, that's 140 clocks each for the 128-bits and 60 for the 44-bit. Total of 340 clocks. At 8 mhz, that's 42.5uS - add 2uS per message for processor-related delays and it's still under 50.
Actually, let's make that even worse - say it's possible that another 44-bit message could come up on each of the high-priority busses - so before it gets to the 3rd it has to get a 44 and a 128 from EACH of the others. That adds another 60 clocks, 7.5uS, as well as another 4uS for processor overhead. Still right at 60uS total (and I haven't done the math but I think this scenario outruns the CAN busses on the top 2 systems anyway )
In other words, It definitely couldn't handle a 1mbit triple-can network, and I'll have to deprioritize all other operations. With a much higher bandwidth on USB, I suspect that portion of the system should have no problem.
So i'm just walking through a couple worst case scenarios - maxed bandwidth from all can channels, two busses with 128-bit messages (can max) and a stream of 44-bit messages coming into the lowest priority (so it has to wait on the 128-ers to finish). Assuming simultaneous message waiting flags, and the 44-bit 2nd buffer begins filling immediately on the low-priority bus, at 500kbits that's going to be 88us for the second buffer to fill up, and another 88us before the MAB fills and needs a buffer to pass to. So, the question is, can the spi bus handle the transfer of two 128-bit can messages and a 44-bit can message in the space of 88us? The read command on the spi bus itself has an 8-bit overhead for instruction time, and there's a minimum frame for the CS pin to be up, so if that gives us about 12 pulses of command overhead, that's 140 clocks each for the 128-bits and 60 for the 44-bit. Total of 340 clocks. At 8 mhz, that's 42.5uS - add 2uS per message for processor-related delays and it's still under 50.
Actually, let's make that even worse - say it's possible that another 44-bit message could come up on each of the high-priority busses - so before it gets to the 3rd it has to get a 44 and a 128 from EACH of the others. That adds another 60 clocks, 7.5uS, as well as another 4uS for processor overhead. Still right at 60uS total (and I haven't done the math but I think this scenario outruns the CAN busses on the top 2 systems anyway
)In other words, It definitely couldn't handle a 1mbit triple-can network, and I'll have to deprioritize all other operations. With a much higher bandwidth on USB, I suspect that portion of the system should have no problem.
garygid
Well-known member
The advantage of using the substantially more expensive AVR-CAN board was that it has hardware buffers in the uP, AND I had working single-channel code.
I have also uses 3 AVR-CAN boards and a 4-port RS232-to-USB adapter to read/log all 3 CAN buses into the PC (or, could be a Mac).
Is there something like Visual Basic for writing applications for the Mac?
Many modern Macs can run a Windows OS. Can yours?
I have also uses 3 AVR-CAN boards and a 4-port RS232-to-USB adapter to read/log all 3 CAN buses into the PC (or, could be a Mac).
Is there something like Visual Basic for writing applications for the Mac?
Many modern Macs can run a Windows OS. Can yours?
defiancecp
Well-known member
dunno, I'm on a PC with windows
And avr-can would definitely simplify things, but since I eventually want this guy hidden in my dash handling i/o for a new audio system permanently, I think 3 stacked AVR-CANs would be a bit overly expensive and larger than I'd want as well. Plus if it works, it gives us all another option
The buffers are definitely a disadvantage as well, but one that can be dealt with in software. Just have to be mindful of priorities of functions.
And avr-can would definitely simplify things, but since I eventually want this guy hidden in my dash handling i/o for a new audio system permanently, I think 3 stacked AVR-CANs would be a bit overly expensive and larger than I'd want as well. Plus if it works, it gives us all another option
The buffers are definitely a disadvantage as well, but one that can be dealt with in software. Just have to be mindful of priorities of functions.
defiancecp
Well-known member
btw - put together a quick expresspcb on the triple version-
low-quantity board printing with solder mask & silkscreening is expensive
low-quantity board printing with solder mask & silkscreening is expensive
garygid
Well-known member
What are the dimensions of your board?
What kind of prices are you getting, for what Quantity?
What kind of prices are you getting, for what Quantity?
defiancecp
Well-known member
I'll confirm the size this afternoon, but I was looking at about $28 each for 3 or $14 each for 12. I could get those prices to drop a lot by increasing quantity or getting them without solder mask/silkscreen....
garygid
Well-known member
I will try to remember the on-line PC board maker
that I used a couple of years back.
that I used a couple of years back.
defiancecp
Well-known member
I did some major refinement and managed to get the board size down to 2.5" x 1.7". At that point, there's very little more than just component space, so it's probably not getting any smaller Was actually able to get the paths on the clock, can lines, rx/tx lines, and spi lines a bit more direct at the same time. That size lets me fit two boards on an expresspcb miniboard layout, or four within the confines of a protopro. So minimum I can get is $85 shipped for 6 prints ($61 if I'm willing to use non-solder masked) or $176 shipped for 16. I'm sure there are other board houses out there that will do small quantities, possibly for less, but that's the cheapest I've found
Anyway, I'm going to shelve the triple board now that I'm pretty satisfied with the layout (in theory) and focus on code.
Was actually able to get the paths on the clock, can lines, rx/tx lines, and spi lines a bit more direct at the same time. That size lets me fit two boards on an expresspcb miniboard layout, or four within the confines of a protopro. So minimum I can get is $85 shipped for 6 prints ($61 if I'm willing to use non-solder masked) or $176 shipped for 16. I'm sure there are other board houses out there that will do small quantities, possibly for less, but that's the cheapest I've found Anyway, I'm going to shelve the triple board now that I'm pretty satisfied with the layout (in theory) and focus on code.
garygid
Well-known member
I just read the http://www.expresspcb.com" onclick="window.open(this.href);return false; website.
It all is reasonable for such quick turnaround times. Thanks.
I am not sure where Chris (see Open EVSE) gets his boards, perhaps less expensive, but a lot longer turn time, I suspect.
I agree, getting the firmware working reliably with the breadboard circuit is first priority.
I should have my USB board early next week. Can you list the links to the exact support/development software you are using, so I can be exactly compatible with your efforts?
Yes, I will try to flash the LED-flasher and button-test first, then the Virtual COMM-Port interface firmware and drivers, since my existing programs all read COMM Ports.
Other suggestions?
Cheers, Gary
It all is reasonable for such quick turnaround times. Thanks.
I am not sure where Chris (see Open EVSE) gets his boards, perhaps less expensive, but a lot longer turn time, I suspect.
I agree, getting the firmware working reliably with the breadboard circuit is first priority.
I should have my USB board early next week. Can you list the links to the exact support/development software you are using, so I can be exactly compatible with your efforts?
Yes, I will try to flash the LED-flasher and button-test first, then the Virtual COMM-Port interface firmware and drivers, since my existing programs all read COMM Ports.
Other suggestions?
Cheers, Gary
defiancecp
Well-known member
I'm using WinAVR with the included gcc compiler&assembler for dev environment and flip for programming.
I should probably start a sourceforge page for this or something... all the projects I've ever done have been either completely personal or had professional involvement of some sort (meaning no interest in open-ness), so I've never actually done something worth sharing work with... Ok, there. Nothing in there yet, but a quick plain-text description of the expected program flows.
https://sourceforge.net/p/trican" onclick="window.open(this.href);return false;
I should probably start a sourceforge page for this or something... all the projects I've ever done have been either completely personal or had professional involvement of some sort (meaning no interest in open-ness), so I've never actually done something worth sharing work with... Ok, there. Nothing in there yet, but a quick plain-text description of the expected program flows.
https://sourceforge.net/p/trican" onclick="window.open(this.href);return false;
garygid
Well-known member
I have WinAVR (portable version) that I use for the Atmel uP on the AVR-CAN board. I compile a hex file and flash using avrdude and a bat file that matches my USB/COMM programmer.
I will see if there is a link to FLIP on the FoundMy web site (their order arrived today).
Until this works reliably, I would not "publish" the alpha code.
I will see if there is a link to FLIP on the FoundMy web site (their order arrived today).
Until this works reliably, I would not "publish" the alpha code.
defiancecp
Well-known member
it's an atmel tool for in-system programming - http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3886" onclick="window.open(this.href);return false;
defiancecp
Well-known member
The HID device implementation was supremely easy Too bad I benchmarked max throughput at 21kB/sec Apparently HID protocol is maxed at 64k, and that's using 64-bit words, so that's not going to work. I backed out of that and restarted using the virtual com port implementation and got nearly 1MB/sec transferred to file; plenty for this. Bad that it requires an external driver, but good that the teensy project already has that driver we can use.
As a note, I've just become aware that the fuse bits cannot be altered with the USB Flip programmer. So the chip on the minimus will have to be ISP'd once to set the CLKO fuse bit to enable the clock output. I'll use avrdude and a super-minimual serial ISP cable (3 resistors and an NPN ) for that.
Also, another tool I'm using, to grab the data from the com port and put it in a file - http://www.eltima.com/products/rs232-data-logger/" onclick="window.open(this.href);return false;
Too bad I benchmarked max throughput at 21kB/sec Apparently HID protocol is maxed at 64k, and that's using 64-bit words, so that's not going to work. I backed out of that and restarted using the virtual com port implementation and got nearly 1MB/sec transferred to file; plenty for this. Bad that it requires an external driver, but good that the teensy project already has that driver we can use.As a note, I've just become aware that the fuse bits cannot be altered with the USB Flip programmer. So the chip on the minimus will have to be ISP'd once to set the CLKO fuse bit to enable the clock output. I'll use avrdude and a super-minimual serial ISP cable (3 resistors and an NPN
) for that.Also, another tool I'm using, to grab the data from the com port and put it in a file - http://www.eltima.com/products/rs232-data-logger/" onclick="window.open(this.href);return false;
garygid
Well-known member
Suggestion:
Program a "CAN-Do Logging-Test" USB "dongle":
Use the Virtual Com Mode to send "test" pseudo-CAN messages to the PC.
Make a timer/interrupt to send an 11-byte "message" every 1.0 ms (1000 per second).
Send:
1. Sync = 0x56
2. MsgID1 (low order) = 0xFE
3. MsgID2 (high order) = 0xFF
4. Eight Data Bytes, as ASCII characters:
Send "TSTnnnnn" where the nnnnn counts from 00000 to 59999 and repeats "exactly" every minute.
That will test dara speed issues, comm buffering delays, and the time-stamping done by CAN-Do.
A great little tool.
What do you think?
Program a "CAN-Do Logging-Test" USB "dongle":
Use the Virtual Com Mode to send "test" pseudo-CAN messages to the PC.
Make a timer/interrupt to send an 11-byte "message" every 1.0 ms (1000 per second).
Send:
1. Sync = 0x56
2. MsgID1 (low order) = 0xFE
3. MsgID2 (high order) = 0xFF
4. Eight Data Bytes, as ASCII characters:
Send "TSTnnnnn" where the nnnnn counts from 00000 to 59999 and repeats "exactly" every minute.
That will test dara speed issues, comm buffering delays, and the time-stamping done by CAN-Do.
A great little tool.
What do you think?
defiancecp
Well-known member
My initial plan was to first try connecting two of these to each other, but you're right, if I've got the timing setup wrong on them both they'd still work I'll still try that test in the short term, and probably try the test you've suggested once that's working.
-Richard
I'll still try that test in the short term, and probably try the test you've suggested once that's working.-Richard
defiancecp
Well-known member
sorry, updates going to slow for a bit. I got good comms over SPI, so now really the only remaining portion is configuration of the MCP chip's internal registers and passing of buffers. Now that I'm digging into the mcp config it's going to take a bit... Not really huge, I just really feel like I need to spend a few hours groking this datasheet, and I'm working in 30-minute bursts of free time - not conducive to really understanding something this complicated Microchip really wanted these little guys to be VERY versatile, but the flipside is that there are a lot of configuration (especially timing) options to choose from and I want to be sure I really fully grasp them all before I go too much further.
Probably next time I'll really be able to do that is Sunday-ish.
Microchip really wanted these little guys to be VERY versatile, but the flipside is that there are a lot of configuration (especially timing) options to choose from and I want to be sure I really fully grasp them all before I go too much further.Probably next time I'll really be able to do that is Sunday-ish.
