-
uCAN and miCAN CAN-USB interfaces available on Tindie
Posted by
matkar
on 06 Jun, 2016 21:06
-
-
#1 Reply
Posted by
LHelge
on 13 Jun, 2016 11:02
-
Nice!
One question though, why the RJ45 connector instead of the widely used DB9 with CANH/CANL pn pin 7/2?
If I'd seen this a few months ago I would have bought one or two, but now I've rolled my own low-cost, low-partcount one. For next revision I could really recommend the STM32F042 series which can run USB together with CAN crystal-less. I managed to keep the BoM cost (including PCB) well below $10 even in quantities below 10 pcs. In series of hundreds you would probably get close to $5.
Main effort/cost for a product like this is of course software, and your control software seems to be have a lot of nice features. I use Vector CANoe/CANalyzer, which are great, almost daily at work but I could never afford something like that for personal use. Your tool seems like a good alternative.
-
#2 Reply
Posted by
matkar
on 13 Jun, 2016 13:59
-
There are a lot of CAN standards/products with different connectivity solutions. I went with RJ45 because everyone has a cheap and quick access to LAN cables or they probably already own one. Plus RJ45 offers a reliable and latching connection.
If you need a DB9 connector, cut away one Rj45 plug on a cable and solder a DB9 connector instead.
Vector tools are another range entirely. Price-wise as well.
On the lower end the market has some alternatives but you have to watch what you wish for. Mostly you get what you paid, but if you pay too little it usually means you will have a lot of work to make them usable (prepare to write your own code). In the past I've developed CAN-USB solution around STM32F072. I'm sticking with current solution because it is the most proven.
You're right. The real cost is the time put in development of the firmware and software. The cost of material is not that high. With the above coupon code you basically get the hardware for free.
BTW, I haven't researched this thoroughly, but is a WinCE (ARM or x86 based) driver for STM(CDC) available? In the past I've sold quite a few CAN-USB interfaces to be used on ARM based WinCE devices and had no issues with my current solution.
Regards,
Mat
-
#3 Reply
Posted by
Jeroen3
on 13 Jun, 2016 14:38
-
Looks great, but I kinda feel the market is a bit saturated with these CAN-(USB)RS232 converters.
What makes yours special?
Is the communication protocol proprietary, I have to use your application?
What is the maximum throughput? (2.0B msg/s)
Lets hope this is not true: Sixty percent of the time it works EVERY time.
-
#4 Reply
Posted by
matkar
on 13 Jun, 2016 17:44
-
Looks great, but I kinda feel the market is a bit saturated with these CAN-(USB)RS232 converters.
What makes yours special?
I agree. Actually I have developed my first CAN-USB interface in 2008. During the past years it had a few upgrades but the main core is the same. Until now I was selling them to the industry. Only recently I've decided to sell them to others as well.
I have the idea of developing software support for higher layer protocols. Most likely I will start with J1939 and/or NMEA2000.
Is the communication protocol proprietary, I have to use your application?
What is the maximum throughput? (2.0B msg/s)
No, the protocol is not proprietary. It is still possible to write your own application if a custom solution is required. I'm in the process of making application examples for Basic (Visual Studio), C (NI CVI) and C# (Visual Studio) languages. I'll let you all know when they are released.
Maximum measured hardware throughput (measured on the PC) receiving extended packets with 8 data bytes at 1Mbps is about 2600 packets per second (packets sent evenly every 380us).
The software on the other hand unfortunately can't handle such high packet rate with all the packet processing it has to perform.
On the other hand all CAN bus networks I had seen have much lower packet rate so I never had any throughput related problems.
Lets hope this is not true: Sixty percent of the time it works EVERY time.
Hehe. It's a quote from a movie "Anchorman" which I find funny
-
#5 Reply
Posted by
LHelge
on 14 Jun, 2016 07:36
-
Regarding throughput I think 2600 frames/s should handle most normal cases. The theoretical maximum at 1 Mbit is closer to 8000 frames/s, but that's rarely used. The maximum I've seen "in the wild" is 100% busload on 500 kbit/s, which is not uncommon during communication with bootloaders during software download. that should be close to 4000 frames/s
Another important performance measurement is latency, both from the PC to the bus, but also the roundtrip. We are currently developing a Bluetooth CAN adapter at work, where the minimum Rx/Tx slot time over the wireless connection is a big problem. For software download protocols that relies on a response for each frame before sending the next, the performance is REALLY bad. That should not be a problem over USB, if the protocol is good enough.
-
#6 Reply
Posted by
Jeroen3
on 14 Jun, 2016 10:04
-
Some time ago I searched for CAN-USB interfaces usable for bootloaders.
I can tell you, writing 200kB of image over a 25kBit bus is slow
. For most CAN-(USB)RS232 the limiting factor is the communication method to the host. Not the hardware throughput, not the software throughput. The virtual serial port implementation. Which is especially poor on Windows.
Some of the interfaces actually managed to transmit corrupted frames at high load. Which is never allowed.
Eventually I found Kvaser through a hint from this forum. They don't emulate a serial port. But instead have their own driver. Which you have to install. They also don't price their stuff with only two digits.
I'd suggest you take a look on their vision of abstraction of the CAN interfaces on the host side. For research
.
As a native embedded programmer I really liked not having to fuss around with serial ports. Because it's always a bit dodgy and the unfriendly to end users.
Not that a virtual serial port is bad. But you must be aware of the limits.
-
#7 Reply
Posted by
matkar
on 14 Jun, 2016 10:08
-
Any protocol with a 100% bus load is a badly designed protocol. Normally everything above 50% is considered to be a very busy network and thus not recomended. Of course it can happen to have multiple packets concatenated especially if you have multiple transmitters but that is taken care by the buffer so short bursts don't present a problem. Transmitting devices are usually designed to make a pause between consecutive transmissions.
What throughput can you achieve with Bluetooth and which Bluetooth module/chip are you using?
-
#8 Reply
Posted by
matkar
on 14 Jun, 2016 10:32
-
Some time ago I searched for CAN-USB interfaces usable for bootloaders.
I can tell you, writing 200kB of image over a 25kBit bus is slow . For most CAN-(USB)RS232 the limiting factor is the communication method to the host. Not the hardware throughput, not the software throughput. The virtual serial port implementation. Which is especially poor on Windows.
Some of the interfaces actually managed to transmit corrupted frames at high load. Which is never allowed.
Never tought a virtual serial port driver could present a limitation with 1Mbps at most on CAN side. Perhaps you're right.
Eventually I found Kvaser through a hint from this forum. They don't emulate a serial port. But instead have their own driver. Which you have to install. They also don't price their stuff with only two digits.
I'd suggest you take a look on their vision of abstraction of the CAN interfaces on the host side. For research .
Oh, you're talking about high end tools. I know I can't compare to those. Hats off to them.
As a native embedded programmer I really liked not having to fuss around with serial ports. Because it's always a bit dodgy and the unfriendly to end users.
Not that a virtual serial port is bad. But you must be aware of the limits.
There is the possibility to use DXX drivers instead of VCP. In my app I opted for VCP since it's generally familiar.
Do you think there is a market for a high end CAN analyzer that can handle 100% bus load with as small latency as possible? I think such a device should be PCI-E based...
-
#9 Reply
Posted by
Jeroen3
on 14 Jun, 2016 11:08
-
A 1 Mbps rs232 link is about 90 kB/s. A CAN frame unfolds to minimal 15 bytes. (4 ID, 8 data, 2 timestamp, 1 terminator)
If you want to keep the parsing robust, you'd need need to ascii-encode them, doubling the data, and you're at max 3 kmps.
Full bus load is something for PCI? Could be. But USB should also be capable of that.
Realtime is something for PCI using the IRQ's.
The DXX driver is also a relative simple method of fast USB transfer without custom drivers. You'll be vendor locked to FTDI though.
-
#10 Reply
Posted by
LHelge
on 14 Jun, 2016 11:22
-
I've used several CAN interfaces using native USB that works fine with really high throughput. Vector, I would say, is a class above Kvaser, then there are lower end devices that slightly more expensive than the one mentioned in this thred. PCAN-USB from PEAK-Systems is one of the more popular. CPC-USB from EMS is another one. I would say that these are more aimed at developers, with a good API but not as refined software. However there is an relatively competent open source project Busmaster (
https://rbei-etas.github.io/busmaster/) that supports some of these interfaces. Perhaps you could add support in Busmaster for the uCAN as well?
Regarding busload, anything above 70% for CAN is bad system design. However this is during normal operation. While downloading software over CAN you want to utilize every last bit of throughput to reduce download times. Specially if this is done during production. Hence 100% busload is not unusual. I've heard of people downloading map packs over CAN to a car navigator which took more than 24 h.
I know there is a market for CAN interfaces that can handle 100% load at 500 kbit/s, PCI-E would not be necessary since there are several commercial options doing this over USB, perhaps not with the VCP.
Regarding bluetooth the transfer speed is no problem, latency is the biggest issue.
-
#11 Reply
Posted by
matkar
on 14 Jun, 2016 21:03
-
I did some additional tests today and was able to push the throughput to 4150 CAN packets per second (time between consecutive packets was 240us). I hope this figure is closer to your expectations. This should cover 500kbps network at 100% load.
I also did a separate test to see how fast the data can be transferred from microcontroller's USB transmit buffer to PC application. I tried to send 256k bytes per second and succeeded. I didn't test higher since this is well above the maximum required throughput. So my conclusion is VCP is capable enough.
I have an older version of Busmaster installed but at the time they supported only a few (high end) interfaces. Now I see they added support for a lot of other devices as well. Good to know. I'll take the time to investigate this further.
Thank you LHelge and Jeroen3 for all advices and inspiration!
-
#12 Reply
Posted by
Jeroen3
on 15 Jun, 2016 04:34
-
In a project I was having trouble with bursts. Once every some time a series of 5 consecutive packets came in. The hardware fifo of 3 in an stm32 is not able to handle this and I needed an fast interrupt and ring buffer to cache them. It will happen.
-
#13 Reply
Posted by
DTJ
on 15 Jun, 2016 05:06
-
-
#14 Reply
Posted by
Jeroen3
on 15 Jun, 2016 05:23
-
We use standard Phoenix MSTB connector for CAN bus. Works perfectly.
-
#15 Reply
Posted by
LHelge
on 15 Jun, 2016 06:21
-
I think CAN is robust enough to work on essentially all available connectors. At work we mainly use TE Connectivitys MQS line of connectors. I've seen the MSTB as well inside the heat pump I use to heat my house, I've connected a Raspberry Pi to log some data on the bus.
For commercial CAN interfaces used for development/troubleshooting on the other hand, I haven't seen anything other than DB9 with CAN-H on pin 7 and CAN-L on pin 2.
-
#16 Reply
Posted by
VEGETA
on 07 Sep, 2016 01:23
-
Can I ask how many items do you sell per month? approx number since you started?
Because I would like to start doing the same myself and want to know the outcome. thanks!
-
#17 Reply
Posted by
matkar
on 07 Sep, 2016 07:12
-
I sell a few tens of items to various companies occasionally.
In general don't bother investing your time in development if you don't know for sure who will you sell the product to.
You won't make an income just by setting a store on Tindie.
-
#18 Reply
Posted by
varghese
on 07 Sep, 2016 10:10
-
1. Can this device handle 100% bus load at 1mbps speed ?
2. instead of vcp direct data access via bulk mode is better for applications...
-
#19 Reply
Posted by
matkar
on 07 Sep, 2016 11:19
-
1. Read above. PM me if you need a device that can handle 1Mbps@100% bus load.
2. You can use DXX instead of VCP if you need to develop a custom application.
-
#20 Reply
Posted by
matkar
on 26 Apr, 2017 12:19
-
Hi everybody!
I have made a long expected update to the CAN-USB basic tool application. New features are:
- Possibility to store up to 5 mask/filter presets for easier reconfiguration of hardware filtering.
- Increased number of predefined send messages to 85.
- Recording of CAN traffic and sending recorded data back to CAN.
- Increased timestamp resolution from 1ms to 16us.
I also corrected a few minor mistakes from the previous version.
Software download link:
http://voblox.com/fdown.php?src=http://voblox.com/bin/CAN-USB_basic_tool_1.0.0.14.zipFor those who have installed previous version; in case of trouble installing the new one, uninstall the old one first.
An updated User's manual is also available:
http://voblox.com/fdown.php?src=http://voblox.com/bin/ucan-miCAN_users_manual_1.1.pdfAny feedback is highly appreciated.
I also received a second batch of uCAN boards recently
Anybody interested in having such a tool, send me a PM so I can arrange for a discount.
Regards, Mat
-
#21 Reply
Posted by
eliocor
on 26 Apr, 2017 14:05
-
-
#22 Reply
Posted by
matkar
on 27 Apr, 2017 12:41
-
Hi eliocor,
Communication protocol is very simple. Packets are max. 18 bytes long and consist of a header, CAN ID, packet flags with DLC, data, timestamp and checksum.
CAN-USB basic tool is a simple tool for those who don't need to implement their own packet handling. I'd say it covers most uses but I also have a few regular customers who developed their own custom application with example source code I provided. If you require such a solution, I'm glad to help you.
-
#23 Reply
Posted by
eliocor
on 27 Apr, 2017 15:55
-
I think it will be better if in your documentation you will publish complete details regarding the low level interfacing with your device.
It will render your product more palatable!
-
#24 Reply
Posted by
Jeroen3
on 27 Apr, 2017 17:59
-
Does it allow multiple applications to use the hardware simultaneously?