Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
USB / Re: Data transfer problem
« Last post by SAE on June 30, 2021, 05:47:20 am »
Hello
I have been working with serial port transmission in embedded environments for many years and have the following suggestions for you.
1. Connect a cable directly between the tx and rx systems to determine if the loss is due to the RF units.
2. I have used USB/RS232 dongles a lot and found these units to be trustworthy.
3. I have also used different chips from FTDI with good result. They connect at embedded CPU rx and tx pins and to USB on the other side of the chip.
4. In older days I found out that serial communication on winxx platforms were not 100% trustworthy. When doing the same on embedded systems I have successfully had links up on 1 Mbaud with good result. Check the cable trick above with higher or lower baudrate to find out.
Brgds

SAE
22
USB / USB stick wait time?
« Last post by SAE on June 30, 2021, 05:19:48 am »
Hello all
I have developed a data logging unit to save data on a USB pen drive. I store data on binary type files with fixed length of several Mb. SW for FAT32 is working quite well. Only issue is that my drive stops recording for up to a few seconds now & then. Can be recording continuously at 25-50Kb/second for many hours without problems but at random times it stops recording for times from a few hundred milliseconds up to several seconds. I have implemented a ring buffer for incoming data that can store up to 30 Kb before it need to access the drive. If drive stops longer than the buffer can hold data there will be a buffer overrun error and current file will be closed and a new one will open and continue the process. I have tested several different drives and it seems problem exists among all of them. Any suggestions would be welcome.
Brgds
SAE
23
Yes, Ellisys USB Explorer 200 Basic Edition (900) would be sufficient.

A hardware analyzer shows the traffic down to the transaction level, for example, for an IN transaction, did the endpoint return data or NAK?

Good advice from the others here.

24
If you see an analyzer on eBay that you think will do the job, don't be afraid to ask if they'll take a lower price.

Sometimes they are there because they are cleaning out a lab or something and they have no idea what they are selling.

I offered $700 for a Elise after seeing that it was not having any interest at $1900 and they accepted the $700.

Using an hardware analyzer gets away from such things as having things work with an Intel hub and not an NEC Hub
and other hairpulling strangeness of the world of USB, when you have a known working standard to use as a reference.
25
USB 3.0 has made USB 2.0 hardware analyzers a bit cheaper.
Sometimes you can find them used on ebay at reasonable prices.
Other times on ebay they are listed for more than the new price from the manufacturers who are still selling them.

I find that "GPIO" connectivity is helpful sometimes for providing sync to a scope or logging external events for timing considerations.
26
Hi Jan,

thanks - really appreciate your hint!

If I got it right, the benefit of a HW analyzer over a SW one is merely that it doesn't influence USB communication in any way, or are there more benefits?

Would you think Ellisys USB Explorer 200 Basic Edition (900) would be sufficient?

Kind regards,

Markus
27
Serial Ports / Re: want to repurpose a ECU flash cable
« Last post by Jan Axelson on June 26, 2021, 11:15:01 pm »
I think this will be difficult without documentation of the protocols or the ability to communicate at a higher level and monitor the communications.
28
Serial Ports / want to repurpose a ECU flash cable
« Last post by gyroplane on June 26, 2021, 10:36:18 am »
Hello all.

So, I have been involved in the performance tuning scene for a while now and have accumulated quite a few FTDI tools of varying protocols and use. My most recent target is a stand alone proprietary flash tool provided by Integrated Engineering. Its a long story why its no longer functional through IE servers but It is and I paid 150 for this thing and would like to see if there is a way to open it up and make it a universal. I believe it operates off of UDS Through a server client system but all the ICs are ground so  one cannot Identify the IC, processor or eeprom. If someone could point me in the right direction or has seen something like this design.Its a really nice interface that I know first hand can flash any vw. I just have to figure out how to make it work for me now. Thanks guys.                                                                                                                                                                             
29
Again, a hardware-based analyzer would show any errors or problems at the transaction level and thus would help isolate the problem. The older Ellisys models would be sufficient and less expensive than many others.

http://janaxelson.com/development_tools.htm#analyzers
30
Hello and thanks everybody for the suggestions/hints so far!

The reason why we've headed for 2x USB CHID is the following:
- Our devices already have 1 USB CHID interface which is already used by our customers to control our device from their code.
- We want to add a second USB communication without HW change which allows a second program on the customer's host (which is created by us) to get some data out of the device and putting it into the cloud, possibly without the customer having to change his code.
- So, for Multiple Top-Level collections, as far as I understood it, the two (separate) programs would need to somehow share the same interface, distinguishing communication only via report ID. In my sight this would require some significant change in the SW of our customers. That's why we headed for the two interface solution.
- Using a 2nd CHID interface was a) convenient to implement (since the first already worked) and b) has the benefit that we don't need to make the customers install a special .inf file when using Windows (which we want to avoid).
Do you see a different solution (e.g. using Multiple TLCs) here?

Concerning the hidapi driver: I'm aware that it is no longer maintained, however since our solution works for another device (with different libraries), I think that the problem probably lies somewhere in the FW itself. However, thanks for pointing out that it hidapi contains several bugs!

Thanks also concerning the hint with the possibly interleaved control transfers - will check up on this as well!

Additionally, I've also seen crashes when using an USB 1.1 hub...

Kind regards,

Markus
Pages: 1 2 [3] 4 5 ... 10