USB to CAN bus to TTL serial

If I were to use CAN bus on the test fixture I'm planning, I would need a USB cable that looks like a UART to the PC.  Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface.  

A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes.  I would need something that requires zero programming of the unit itself.  I'm not seeing this.  

-- 

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209 

søndag den 6. november 2022 kl. 14.34.38 UTC+1 skrev Ricky:
> If I were to use CAN bus on the test fixture I'm planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface. 
> 
> A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I'm not seeing this. 
> 

no point in using CAN if what you want it UART (over something like rs485/422)

CAN is similar to rs485 but "ORed" and with a fixed packet sizes, adresses,Acks, NAcks,CRC etc.

On Sunday, November 6, 2022 at 9:48:30 AM UTC-5, lang...@fonz.dk wrote:
> søndag den 6. november 2022 kl. 14.34.38 UTC+1 skrev Ricky: 
> > If I were to use CAN bus on the test fixture I'm planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface. 
> > 
> > A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I'm not seeing this. 
> >
> no point in using CAN if what you want it UART (over something like rs485/422) 
> 
> CAN is similar to rs485 but "ORed" and with a fixed packet sizes, adresses,Acks, NAcks,CRC etc.

I would not care about the protocol on the CAN bus.  I am assuming the interface to the PC would look like a UART.  Or are the interface cards just low level hardware and the PC user code has to manage the low level protocol?   By "look like a UART", I mean I simply pass data to an interface and receiver replies, without knowing, or caring about the details past that.  

If a CAN bus interface can't do that, I definitely would not be interested.  Even if it can do that, I would only be interested if it could provide some benefit.  No one has explained what is better about CAN bus, they've just said I should use it. 

-- 

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Ricky wrote:
> If I were to use CAN bus on the test fixture I'm planning, I would
> need a USB cable that looks like a UART to the PC.  Then I would need
> modules to mount on the test fixture boards that provide a UART like
> TTL interface.
> 

A Total Phase Komodo would provide a UART interface via USB. No need
for anything else. It is both small and has a plastic housing, if that
matters.

There are others. That is just the last one I used. I used it for plant 
sim with a RasPi.

> A quick survey finds lots of modules with wired connectors on both
> ends and units in metal boxes.  I would need something that requires
> zero programming of the unit itself.  I'm not seeing this.
> 

You're probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.

But when you say "test fixture" I think of nodes actively
participating and that requires programming.

-- 
Les Cargill

On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
> Ricky wrote: 
> > If I were to use CAN bus on the test fixture I'm planning, I would 
> > need a USB cable that looks like a UART to the PC. Then I would need 
> > modules to mount on the test fixture boards that provide a UART like 
> > TTL interface. 
> >
> A Total Phase Komodo would provide a UART interface via USB. No need 
> for anything else. It is both small and has a plastic housing, if that 
> matters. 
> 
> There are others. That is just the last one I used. I used it for plant 
> sim with a RasPi.
> > A quick survey finds lots of modules with wired connectors on both 
> > ends and units in metal boxes. I would need something that requires 
> > zero programming of the unit itself. I'm not seeing this. 
> >
> You're probably out of luck. The Komodo does come with software to 
> act as a CAN-alyzer for monitoring, a "Wireshark" for CAN. 
> 
> But when you say "test fixture" I think of nodes actively 
> participating and that requires programming. 

The current test fixture is a single board, testing a single UUT from a single PC.  The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs.  The protocol of communications will be the same.  Each message is a dozen or so characters, including an address of the target, and the command.  The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters.  

So command, response, command, response...   all on a shared bus. 

No one needs to worry with the test fixtures.  That's taken care of, other than needing an interface for CAN.  What is required for that?  

The PC has a control program which will be modified to handle the UUT addressing.  My concern is to not have to muck with programming in regards to anything about the CAN bus.  The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data.  Again, that's all taken care of.  I don't want to have to add anything that involves protocol of the CAN bus.  That's why I say it needs to look like a UART to the PC.  If that's so, I can use my existing software and not do extra work. 

-- 

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

mandag den 21. november 2022 kl. 01.10.43 UTC+1 skrev Ricky:
> On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote: 
> > Ricky wrote: 
> > > If I were to use CAN bus on the test fixture I'm planning, I would 
> > > need a USB cable that looks like a UART to the PC. Then I would need 
> > > modules to mount on the test fixture boards that provide a UART like 
> > > TTL interface. 
> > > 
> > A Total Phase Komodo would provide a UART interface via USB. No need 
> > for anything else. It is both small and has a plastic housing, if that 
> > matters. 
> > 
> > There are others. That is just the last one I used. I used it for plant 
> > sim with a RasPi. 
> > > A quick survey finds lots of modules with wired connectors on both 
> > > ends and units in metal boxes. I would need something that requires 
> > > zero programming of the unit itself. I'm not seeing this. 
> > > 
> > You're probably out of luck. The Komodo does come with software to 
> > act as a CAN-alyzer for monitoring, a "Wireshark" for CAN. 
> > 
> > But when you say "test fixture" I think of nodes actively 
> > participating and that requires programming.
> The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters. 
> 
> So command, response, command, response... all on a shared bus. 
> 
> No one needs to worry with the test fixtures. That's taken care of, other than needing an interface for CAN. What is required for that? 
> 
> The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that's all taken care of. I don't want to have to add anything that involves protocol of the CAN bus. That's why I say it needs to look like a UART to the PC. If that's so, I can use my existing software and not do extra work. 
> 

if it needs to look like a uart don't use CAN, use a uart 

Ricky wrote:
> On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
>> Ricky wrote:
>>> If I were to use CAN bus on the test fixture I'm planning, I
>>> would need a USB cable that looks like a UART to the PC. Then I
>>> would need modules to mount on the test fixture boards that
>>> provide a UART like TTL interface.
>>> 
>> A Total Phase Komodo would provide a UART interface via USB. No
>> need for anything else. It is both small and has a plastic housing,
>> if that matters.
>> 
>> There are others. That is just the last one I used. I used it for
>> plant sim with a RasPi.
>>> A quick survey finds lots of modules with wired connectors on
>>> both ends and units in metal boxes. I would need something that
>>> requires zero programming of the unit itself. I'm not seeing
>>> this.
>>> 
>> You're probably out of luck. The Komodo does come with software to 
>> act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.
>> 
>> But when you say "test fixture" I think of nodes actively 
>> participating and that requires programming.
> 
> The current test fixture is a single board, testing a single UUT from
> a single PC.  The new test fixture will have one PC talking at a rack
> of test fixtures, with each one having eight UUTs.  The protocol of
> communications will be the same.  Each message is a dozen or so
> characters, including an address of the target, and the command.  The
> addressed target then responds with the information requested, or
> simply acknowledgement of the command, again, some doze or so
> characters.
> 
> So command, response, command, response...   all on a shared bus.
> 
> No one needs to worry with the test fixtures.  That's taken care of,
> other than needing an interface for CAN.  What is required for that?
> 

So at least J1939 is 29 bits of address and 16 bytes of payload. It is 
not equivalent to a serial port. There will be a proprietary API to send 
one PDU and to receive PDUs.

> The PC has a control program which will be modified to handle the UUT
> addressing.  My concern is to not have to muck with programming in
> regards to anything about the CAN bus.  The current interface is a
> simple UART, which is handled by system software and becomes two
> interfaces, one for sending data and one for receiving data.  Again,
> that's all taken care of.  I don't want to have to add anything that
> involves protocol of the CAN bus.

I suspect you will have to. It's not like 485 or 422.

> That's why I say it needs to look
> like a UART to the PC.  If that's so, I can use my existing software
> and not do extra work.
>

You will need to adapt your existing commands to and onto the 
proprietary API.

-- 
Les Cargill

On Sunday, November 20, 2022 at 7:16:48 PM UTC-5, lang...@fonz.dk wrote:
> mandag den 21. november 2022 kl. 01.10.43 UTC+1 skrev Ricky: 
> > On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote: 
> > > Ricky wrote: 
> > > > If I were to use CAN bus on the test fixture I'm planning, I would 
> > > > need a USB cable that looks like a UART to the PC. Then I would need 
> > > > modules to mount on the test fixture boards that provide a UART like 
> > > > TTL interface. 
> > > > 
> > > A Total Phase Komodo would provide a UART interface via USB. No need 
> > > for anything else. It is both small and has a plastic housing, if that 
> > > matters. 
> > > 
> > > There are others. That is just the last one I used. I used it for plant 
> > > sim with a RasPi. 
> > > > A quick survey finds lots of modules with wired connectors on both 
> > > > ends and units in metal boxes. I would need something that requires 
> > > > zero programming of the unit itself. I'm not seeing this. 
> > > > 
> > > You're probably out of luck. The Komodo does come with software to 
> > > act as a CAN-alyzer for monitoring, a "Wireshark" for CAN. 
> > > 
> > > But when you say "test fixture" I think of nodes actively 
> > > participating and that requires programming. 
> > The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters. 
> > 
> > So command, response, command, response... all on a shared bus. 
> > 
> > No one needs to worry with the test fixtures. That's taken care of, other than needing an interface for CAN. What is required for that? 
> > 
> > The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that's all taken care of. I don't want to have to add anything that involves protocol of the CAN bus. That's why I say it needs to look like a UART to the PC. If that's so, I can use my existing software and not do extra work. 
> >
> if it needs to look like a uart don't use CAN, use a uart

What interface to the software does CAN use?  I thought you were one of the people, who in another thread were suggesting I use CAN?  

I just don't want to have to program a bunch of CAN protocol in my application.  I would expect drivers to handle that.  On the test fixture I would expect a chip to provide a UART on one side and CAN on the other.  

This is not important.  I see no reason why RS-422 or RS-485 would not be a good choice.  It's actually the USB that presents the bottleneck from the polling rate. 

-- 

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

On Sunday, November 20, 2022 at 7:32:37 PM UTC-5, Les Cargill wrote:
> Ricky wrote: 
> > On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote: 
> >> Ricky wrote: 
> >>> If I were to use CAN bus on the test fixture I'm planning, I 
> >>> would need a USB cable that looks like a UART to the PC. Then I 
> >>> would need modules to mount on the test fixture boards that 
> >>> provide a UART like TTL interface. 
> >>> 
> >> A Total Phase Komodo would provide a UART interface via USB. No 
> >> need for anything else. It is both small and has a plastic housing, 
> >> if that matters. 
> >> 
> >> There are others. That is just the last one I used. I used it for 
> >> plant sim with a RasPi. 
> >>> A quick survey finds lots of modules with wired connectors on 
> >>> both ends and units in metal boxes. I would need something that 
> >>> requires zero programming of the unit itself. I'm not seeing 
> >>> this. 
> >>> 
> >> You're probably out of luck. The Komodo does come with software to 
> >> act as a CAN-alyzer for monitoring, a "Wireshark" for CAN. 
> >> 
> >> But when you say "test fixture" I think of nodes actively 
> >> participating and that requires programming. 
> > 
> > The current test fixture is a single board, testing a single UUT from 
> > a single PC. The new test fixture will have one PC talking at a rack 
> > of test fixtures, with each one having eight UUTs. The protocol of 
> > communications will be the same. Each message is a dozen or so 
> > characters, including an address of the target, and the command. The 
> > addressed target then responds with the information requested, or 
> > simply acknowledgement of the command, again, some doze or so 
> > characters. 
> > 
> > So command, response, command, response... all on a shared bus. 
> > 
> > No one needs to worry with the test fixtures. That's taken care of, 
> > other than needing an interface for CAN. What is required for that? 
> >
> So at least J1939 is 29 bits of address and 16 bytes of payload. It is 
> not equivalent to a serial port. There will be a proprietary API to send 
> one PDU and to receive PDUs.
> > The PC has a control program which will be modified to handle the UUT 
> > addressing. My concern is to not have to muck with programming in 
> > regards to anything about the CAN bus. The current interface is a 
> > simple UART, which is handled by system software and becomes two 
> > interfaces, one for sending data and one for receiving data. Again, 
> > that's all taken care of. I don't want to have to add anything that 
> > involves protocol of the CAN bus.
> I suspect you will have to. It's not like 485 or 422.
> > That's why I say it needs to look 
> > like a UART to the PC. If that's so, I can use my existing software 
> > and not do extra work. 
> >
> You will need to adapt your existing commands to and onto the 
> proprietary API. 

Ok, then CAN just went into the waste bucket for this project.  I see no reason to explore complexity for something that is fundamentally simple. 

-- 

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209 

On Sun, 20 Nov 2022 16:34:02 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>What interface to the software does CAN use?

The CAN frame consists of two main  fields:
* CAN identifier (11 or 29 bits)
* Payload (0-64 bits, 0-8 bytes)

Especially with 29 bit CAN-ID you could allocate a few bits for slave
address and a few bits for function code. In the simplest case the
interface would contain a 32 bit CAN-ID ad an 8 bit payload for both
reading and writing.

The nice thing about CAN is that the hardware does the arbitration
between frames based on the CAN-ID.  Thus, you can send out broadcast
reads and collect all responses. You could also send out requests to
multiple slow devices at once and collect the responses room diff rent
devices when ready, without having to worry about collision handling.

he problem with half-duplex RS-485 is the line turnaround delays and
waiting for slave responses, which quickly degrades throughput at high
line speeds. On CAN the line mutilation can be quite high and at 1
MBit/s the throughput can be better than on RS-485 at higher speeds.