No specific reason for the clock speed to be 1MHz. I know that I have changed it multiple times during development of the initial module, and often run it very low (as it is easier to get complete logic analyser captures, and store more capture data, at lower clock speeds). I suspect the 1MHz choice was a compromise between performance and being able to store more than a couple of seconds of logic analyser capture.

I think our circuit should be able to cope with 10MHz. MAX7317 is good for up to 26MHz. MCP2515 should be ok up to 10MHz. Espressif documentation says:

While in general, speeds up to 80MHz on the dedicated SPI pins and 40MHz on GPIO-matrix-routed pins are supported, full-duplex transfers routed over the GPIO matrix only support speeds up to 26MHz.

Clock should be fine at 10MHz.

Can you try it (simple fix in ovms_peripherals.cpp lines 118 and 120)?

MAX7317 is at line 93 and probably worth setting to the same speed, although I don’t think it matters much if they are different as control is on the CS lines anyway. That said, we have to drive the MISO line on MAX7317 via a tri-state on the CS pin, so that will be speed limited via the tri-state.

If it works ok for you at that speed, I’ll put it on an oscilloscope later this week and just verify the signals still look clean. I did that on the original board design, and they seemed ok.

Regards, Mark.

On 17 Jan 2018, at 1:59 AM, Michael Balzer <dexter@expeedo.de> wrote:

Greg, Mark,

I'm having two basic issues with this:

a) This will limit the TX speed achievable on the mcp interfaces. I generally hate not fully utilizing available hardware capabilities. And this is SPI, filling
a TX buffer is expensive.

b) It again feels like fixing without understanding. I really think we should first understand how the reported race condition of the mcp interrupt signal
affects our driver design, and we should check the effect of level interrupts before resorting to limiting the speed.

The mcp SPI interface is running at 1 MHz, so a TX will … wait a moment, why is it running at 1 MHz? According to the data sheet, it can do 10 MHz?

Mark, is there some scaling done in the spinodma module, or is there a reason (other than typo / copy-paste) for this?



Am 16.01.2018 um 09:47 schrieb Greg D.:

Hi Mark,

Yes, absolutely.  In fact, I just thought of a corner case while nodding
off to sleep (hate it when that happens!).  Fixed, verified, and pushed
to my branch.  Anxiously awaiting review from Michael...

Greg


Mark Webb-Johnson wrote:

I think best for @michael to review. A single tx buffer is certainly easier to manage.

Regards, Mark.

On 16 Jan 2018, at 1:59 PM, Greg D. <gregd2350@gmail.com> wrote:

Mark Webb-Johnson wrote:

In vino veritas.

Indeed!

Fixes look good (can't seem to kill it).  Pushed to my fork on Git Hub,
along with removal of the delays in the obd2ecu.cpp code.

This was done on the older tool chain; wanted to be sure the fix was
real before upgrading and potentially hiding the issue with a slight
change in timing.  Will upgrade the toolchain tomorrow and verify.

Greg

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev