[Ovmsdev] SWCAN

Mark Webb-Johnson mark at webb-johnson.net
Wed Jun 22 09:17:50 HKT 2022


We’ve made some (slow) progress on this. The approach we are taking is to build a combo expansion board, to support multiple bus types on one board. The issue, of course, is limited GPIO. We have quite a few EGPIO available, but only two GPIOs (EXT_1 and EXT_2). We can’t run complex protocols like SPI or ASYNC over EGPIOs.

We could wait for ESP32-S3, with extra GPIOs, but that would be quite a jump and require new hardware for all our users out there.

We could use hardware dip switches, but bizarrely those are completely unavailable in China at the moment. Also, that approach limits us to only use one of the expansion bus types without opening up the module and re-configuring things.

I’ve found what seems to be a better solution. The 74HCT4052 is an analog multiplexor IC. It contains two inputs channels that can each be switched to one of four outputs (or the other way round). The switching can be done by two EGPIO select lines, and a third ENABLE EGPIO. This allows us to dynamically switch EXT_1 and EXT_2 to any of four alternative circuits. We can use a similar approach for switching output signals (such as K-LINE and SWCAN onto a single GEP_7 output pin). Doing this, we can have:

The existing K-LINE circuit, using EXT_1 and EXT_2 as async, and output to GEP_7.
A new SDCAN circuit isomer EXT_1 and EXT_2 as SPI CS and INT to a MCP2515, and based on the previous work done here with TH8056 with output to GEP_7.
One or two additional CAN buses, using EXT_1 and EXT_2 as SPI CS and INT (currently seeing if we can fit two on the board).

Using the multiplexed approach, only one of these can be actively communicated with at any one time, but they can be switched in software. For example, for Tesla Roadster we can have K-LINE and another CAN bus (to the VMS diagnostic system), without sacrificing any of the other 3 buses - but we would only be able to use either K-line or fourth CAN at any one time, which shouldn’t be much of an issue. Even something like SWCAN is typically not needed *all* the time (we simply need to enable / switch to it, issue the command we need such as wake-up car, and then disable / switch back). It is not ideal, but given the limitations seems quite an elegant solution.

Knowing now the limitations of the MCP2515, I am also thinking we should take this opportunity to look at other SPI CAN bus drivers. I have identified two options:

MCP2518 (with 31 FIFO messages, and CAN-FD support)
TCAN4550/4551 (with 2KB of FIFO message space, CAN-FD support, and built-in transceiver)

The TCAN4551 seems quite an elegant design to me (with the main drawback being it needs 5.5v so could not run from usb only 12v vehicle power). We would need to write a new driver for whichever we chose.

Thoughts?

Regards, Mark.

> On 26 May 2022, at 8:48 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> Craig,
> 
> Not sure why the US distributors are showing plenty of stock and good pricing, but the ones in China are not good now. Weird chip shortage stuff going on at the moment. Even a simple SPDT DIP switch costing US$1 on mouser is US$5 in China and sourcing them is like trying to find a vein of gold.
> 
> I’ve told the manufacturer either TH8056 or NCV7356 should be ok, and they are trying to source.
> 
> If the component cost is really too high, then we’ll just go back to the two different boards idea (or perhaps one PCB only populated with components for each option like we do with our modem PCBs).
> 
> Regards, Mark.
> 
>> On 26 May 2022, at 2:05 AM, Craig Leres <leres at xse.com> wrote:
>> 
>> On 5/23/22 00:39, Mark Webb-Johnson wrote:
>>> Discussing with the manufacturer, feedback is:
>>> * Given component vs board manufacturing cost, it seems simplest to
>>>   combine this with the existing k-line option board, to produce a new
>>>   ‘combo’ option board containing both K-line and SWCAN (DIP switch
>>>   selectable one or the other, not both).
>> 
>> (Sounds sweet!)
>> 
>>> * The TH8056 component is causing issues. Availability is poor (in
>>>   China) and price is very high.
>>> Does anyone know of any alternative to the TH8056 that can be suggested? Any other comments on this?
>> 
>> On 5/24/22 23:23, Alexander K wrote:
>>> NCV7356 is compliant to GMW3089.
>>> Also TH8056 has two versions with 8 and 14 pins. Both are suitable.
>> 
>> Looks like the difference (for both transceivers) is the presence of an inhibit pin.
>> 
>> I usually use mouser.com when I buy the small quantity of parts I need for my projects. I see $1.12 for quantity 100 for the 8 pin version with ~2K in stock. Looks like the reel quantity is 3000 so they are selling off their last reel. The 8 pin variants are all out of stock with impressive 60+ week lead times (and ~60K parts on order!) The NCV7356 is out of stock for both flavors and look more expensive.
>> 
>> 		Craig
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20220622/e8be3b8c/attachment.htm>


More information about the OvmsDev mailing list