USB to CAN bus to TTL serial

søndag den 6. november 2022 kl. 14.34.38 UTC+1 skrev Ricky:

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.

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.

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

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.

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

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

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.

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.

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.

I have no interest in getting involved in the CAN bus protocol. To me it's something that needs to be invisible, a way to transport characters, in the same way I use a serial port under Windows.

Your description of RS-485 is not important to me. You have either not been part of the previous conversations where I described the use case, and some details of the hardware, or you would realize that the issues you present have no relevance to my design. The speed limitation has nothing to do with the RS-485 or RS-422 buses. The limitation is in the 8 kHz polling rate, which sets the limit on the number of messages which can be handled on the USB interface. The limit is messages, not bits or characters.

Your post presents all the reasons why I have no interest in using CAN. I don't want to even be aware of the messages on the CAN bus. The PC should have software that hides all that and presents a port like a COM port, in fact, it should emulate a COM port. On the slave end, I would want a chip, or better, a module that provides a CAN bus interface with a virtual UART interface on the other side, or a serial port would suffice. The FPGA already has the UART in it. BTW, there are no slow devices on the bus. Every device responds within fractions of a microsecond, depending on the baud rate setting.

Right now, the test fixture talks to the PC through an RS-232 USB cable. I'm looking for something that can take it's place pretty much without software changes. So far, everyone talks about programming though an API, which is of no interest to me.

What was wrong with just diodes on the UUT Tx with a pull-down on the PC Rx, possibly with buffering on the PC Tx?

RS232 idles -ve, and AIUI, only 1 UUT can talk at a time and they don't respond if not addressed.

This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me. I can't think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that's not an advantage.

I had pretty well settled on an RS-422 based approach with the master the only talker on one pair, and the addressed slave replying on the other pair. Because of the back and forth message protocol, there is no worry with collisions unless someone loses their mind and clobbers the bus. The only issue I can see is the USB limitation of of high speed polling being 8 kHz which limits the message rate to a single UUT (with 256 in the system) to 16 commands per second. That will limit the testing rate, but since the audio tests take a few seconds anyway, I think all in all, it will be a foot race as to which will take the longest. So it doesn't look like that is a significant limitation.

So I'm happy with RS-422. If I want to get fancy, I could adjust the protocol so messages can overlap, in the sense that the master can address multiple slaves without waiting for any one to respond. The slaves will need to manage their collisions, but that should not be an issue, since they can reply within a fraction of a microsecond. By the time the second slave has received a command, the first slave will be nearly finished with its reply and the second slave only needs to monitor for the end of message (/n I believe). The only problem is if there are too many overlapped at one time, multiple slaves might be waiting for the end of a response to start its own response and two start at the same time. To sort that, either some delays need to be added to the master, or the slaves need to be aware of who the master is talking to and who has replied. Too much complexity, even if it's not hard to make work. At 1 minute per test on 256 units, this will be around 512 times faster than a human running the tests, so I think we are good.

The real gold in this is the handling of boards are reduced. We have been plugging a board into the test fixture to test, then plug it into the burn in chassis, the the test fixture again. The connectors are pretty much crap for such use and we have a hard time training people to be gentle enough with them. On removal, the narrow board twists in the fingers, bending/braking pins on the test fixture, and breaking connectors on the UUT. Cutting the insertions and removals to one, with 1,000 tests in between, will go a long way to improving our throughput.

I think I got a bit off topic. My point is, the RS-232 approach doesn't seem to have any advantage over RS-422 and multi-point operation with RS-422 is well known and well established. I only was asking about CAN because a couple of people said it was a good way to go for this. Now that I have more info, I'm not so sure.

The advantage is that you could have been up and running for the last couple of weeks with pretty much your existing hardware AIUI. The main disadvantage is the chance of a faulty UUT buggering up the whole deal. Don't let perfect be the enemy of good.

How could I have been up for the last couple of weeks? The new test fixtures aren't even designed yet. I'm not sure what you are talking about with "a faulty UUT buggering up the whole deal"? The UUT is not on the bus. The test fixture is. The purpose of the test fixture is to test the UUTs. I expect the procedure will be to install 8 UUTs onto a test fixture, perform one round of testing to determine if any units fail. Failing units are replaced until all 8 work. Install the test fixture into the chassis. Rinse, lather, repeat, until the test chassis is fully of test fixtures with UUTs that initially pass test. They are then left to burn in over night. The next morning the results will be checked for failures. UUTs without failures will be labeled and shipped with the results of the final test saved as a record.

What are you picturing, exactly? I don't see how a tristated RS-232 interface is any different from an RS-422 interface except that the RS-232 interface won't run as fast and is not specified to actually work well, given the pull down resistor required.

What am I missing?

So you can afford to buy one or two table top PCs and use directly some PCIe RS-422/485 cards which are available at least with 1 to 8 serial lines. You can use these cards directly without messing up with USB.

If you insist on using USB, why don't you go with USB from end to end and skip the RS-232/422/485 all together ? Use two or three USB hubs in series to branch to all slaves.

The RS-232 diode trick will work with a few slaves on the same table, but the noise margins will be deteriorated.

To be pedantic, the standard calls this 4-wire RS-485. The nice thing is that there are good pauses in the Master Tx pair (when a slave transmits on the other pair). Thus you can run even Modbus without being too accurate with timing. With 2-wire RS-485, the slaves must adhere to the timing specification quite accurately.

In 4-wire RS-485 the slave only hears the master, they do not hear the transmission by other slaves. Use 2-wire RS-485 if each slave must listen to master _and_ other slaves.

Yeah, that's an option. I don't know if that is important to do. While the USB limitations create a ceiling for the throughput, I don't know that it is a problem as yet, as long as the USB used is high-speed. So the jury is still out on the need for faster operation.

I've never had much success in cascading hubs. One hub works fine, but serial hubs seem to have issues with various devices. I have zero interest in using a flaky USB distribution. Since I currently have no need and still don't know if that would fix the problem, I'm not going to give this further consideration at this time.

Can you refer me to this standard? I've not seen this in the many sites I've visited regarding the approach. Looking it up, it seems to be discussed, but is not a part of any standard.

Hmmm... I'm not following this, but I doubt Modbus offers any advantages over RS-422/485 that are relevant to me, so I don't think I need to pursue this.

I would never joke with you. I know better.

Ok, thank you.

I read it from the official RS-485 standard document from the 1980's. Of course it was on paper. This standard also talks about "fail-safe" termination, in which the quotes are part of the standard :-).

Did you study the official TIA RS-485 standard document ?

In many papers there are references to full-duplex RS-485 using two pairs

Modbus is a software protocol typically using RS-xxx hardware. The Modbus RTU version is notorious for the timing requirements. It was created before RS-485 standard was finalized and apparently used some RS-232 diode tricks, i.e. had to avoid reflections on a serial bus with impedance missmatches.. Also RS-485 "fail-safe" solved some problems due to a floating tri-state bus.

In Windows user mode timing directives have only 1 ms timing resolution (when multimedis timers enabled). To get 8 kHz scan rate (0.125 ms), you are going to use a kernel mode driver that at least sends out the request and receives the response (possibly handling retransmissions) before returning to user mode.

Actually you would need a WriteReadFile system cal that sends out multiple requests collects multiple read responses into an other buffer and only return to user mode after the response from the last request has been received.

Can you provide a link? I've seen many sites that quote significant portions of the standard an none mention this.

Yup

What does an RTU do?

That's all stuff behind the scenes. My software interface is a simple COM port. I don't care how they do it, just that it happens.