My task at work is to use a Raspberry Pi 3 to controll a turntable.
The turntable has an internal RS485 serial port which can be accessed through a build in FTDI USB converter (USB-RS485-WE-1800-BT).
I am using Raspbian Jessie Lite on the Pi and have not jet decided, what programming language to use.
First of all it seems to me, the FTDI converter is properly installed. Please correct me if I am wrong:
pi#turntable_ctl1:~ $ dmesg | grep FTDI
[ 2.236219] usb 1-1.3: Manufacturer: FTDI
[ 5.085380] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 5.086330] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[ 5.087760] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
Also if I run minicom -D /dev/ttyUSB0 (there turn hardware flow control off and software flow controll on and set the baudrate to 19200 8N1) the red LED inside the USB plug of the converter is blinking with every of my keystrokes.
Unfortunately there is no complete documentaion for the turntable, because it is custom made for us by a company in france. The guys there have provided me with this graphic (half in english/half in french) along with the following information:
"When you send us a PC frame the board respond with a MT frame."
As far as I understand this, to get the table turning I now have to open an RS485 connection on the /dev/ttyUSB0 and then do something like:
sendChar(P)
sendChar(C)
sendChar(1)
sendChar(100) // for example
sendChar(1) // for example
But I have no idea how to do that in any programming language. And even worse, I was not able to find any sample of code that does this, allthough I expected this to be a rather standard task.
So if anyone could point me in the right direction or tell me where my train of thought went off the rail, I would be very grateful!
Thanks for your time!
Mark
If this may concern anyone other than me, here is my solution:
After some more searching and a lot of hints from friends I found this library that offers (among other helpfull tools for Raspberry Pi) a great simple toolset for serial communication on the Raspberry Pi.
WiringPi - Serial Library
Gordon has all the documentation and Tutorials on his website you will need.
Thanks to Gordon!
Mark
Related
I have a project based on a Nucleo H743ZI2 board that communicates with a PC through the USB OTG port on the Nucleo.
Everything is working fine as long as, weirdly enough, I have the STlink USB cabled plugged in (which I have been using to work on the firmware, flash, debug, etc).
However, today I was getting ready to do actual tests with this project and used an external power source to power the H7. I initially tried a 3.3V external source which is available from one of the shields, and then tested a lab PSU at both 3.3V. Thinking it could be PSU related I also tried external 5V with the same results.
Basically, the device is not recognized by the computer operating system, unless the STlink USB is plugged in.
I can't really put my finger on this one; I initially thought it was a PSU related issue (that nucleo board has some restrictions when it comes to using external power sources) but at this point I am fairly confident I am failing to initialize something in my code. Not sure what though.
I'd be happy to share with my code, but wouldn't know where the start. I haven't done much as far as the USB OTG is concerned other than modifying the receive callback to process the data.
Any idea what I might be missing here?
Cheers
I made a STM32F042k6, battery powered device, that I would to flash vi DFU protocol.
In order to do so I disconnect the battery, I pull BOOT0 to VCC, and then plug the device in USB3 port of PC (no USB2 available). The device is not recognized and showed
VID:0000 PID:0002 (case I)
However, when I first connect battery, and then connect the device to PC it is recognized without a fuss (case II).
The problem I face is that I would like to initiate jump to bootloader program by command in software - but then I reach exactly the same condition as in case I.
Could you help me to identify what conditions for proper boot I am violating?
EDIT:
The way I have discovered the problem was when I implemented software jump to bootloader. It seemed not to work at all (VCP device dissapeared, and erroreous <> device appeard in system PID:0002 VID:0000).
I wanted to enter bootloader by pulling up BOOT0 pin, but I could see that I sucseed only when battery-power cycled. USB power cyccle resulted in the same "failed descriptor" device.
I suspect that when powered on via USB, the booloader has som ecommunication problems and cannot establish proper PID and VID. When powered via battery - this problem is not existing.
Do you have a discovery board?
I read in the STM32F042x4/x6 Reference Manual (DocID025832 Rev 5):
The STM32F042x4/x6 embeds a full-speed USB device peripheral compliant
with the USB specification version 2.0.
(part 3.19, p.27).
In the AN2606 (Rev 33), a table shows the USB configuration which is used by the DFU Bottolader in USB FS (Full-speed):
I assume that the USB in the bootloader is the 2.0, but USB 3.0 must be USB 2.0 compliant. So it is possible to use an USB 3.0 port.
I suggest you use the DfUSe Demo from ST. Its interface consists of a tab where the DFU devices available are displayed when detected. I try it on another STM32x by following these steps:
Open DfuSe Demo software.
Plug BOOT0 to Vdd to put the micro on DFU mode.
Plug the USER USB to your computer port.
The name of your device should appear in “Available DFU Devices” field.
You could try to use directly PA11 and PA12 as well (according to Table 12) instead of the USB port of your board.
EDIT:
Another solution to upgrade your firmware without driving boot0 is to jump directly into the DFU bootloader of ST inside your firmware. Else you could design your own IAP bootloader (In-Application Programming).
I hope that helps.
I faced this same issue with the STM32 Mini F401 and dug into it for several days. Unlike the OP I was unable to find any electrical conditions which reliably got the bootloader to do the right thing. I was able to program my board maybe once every 20 tries, which was really slowing down my process.
In the end I discovered that I can go to the Windows device manager, show hidden devices, and there will be an entry in Universal Serial Bus Devices called STM32 BOOTLOADER. When the issue is happening the board is connected in dfu mode but that device is not marked active in the device manager.
To resolve the issue consistently, you can manually delete the hidden STM32 BOOTLOADER entry, uninstalling the device (no need to delete the driver, just uninstall the device). Then reboot your board in DFU mode and it should connect as expected every time. Unfortunately I need to do this process every time I want to program, but that's far better than the inconsistent/intermittent failures before.
Hopefully I will have more luck today. I have no prior USB integration and about 8 months of learning embedded systems on Atmel devices. I am trying to use an Atmel SAM L series to connect over USB to a computer. The use case is for data transfer. Specifically, the MCU will be gathering data from it's sensors and packaging it for USB transfer.
I have searched through and read up on all of Atmel's included USB examples. I have also started reading through usb.org's class specifications for CDC.
I have running now something that lets me send data along one com port, into the target usb and then out the debugger usb to another com port. However, I don't think this is real USB.
My problem is two fold.
1.) I do not fully understand what differentiates USB from serial communication on a com port.
2.) Even if I were doing it correctly, I'm not sure how to test and verify that I have indeed created a legitimate USB device that can be accepted by a host computer.
Links to documentation(Atmel or generic) or example code would be appreciated.
1) USB is defined in the USB specifications from http://www.usb.org. Serial ports were an older and simpler interface that involved sending data back and forth asynchonously on pins with names like TX and RX. The USB CDC class and its ACM subclass allow you to make a USB device that emulates a serial port. If you make your device be a USB CDC ACM device, then you don't need to supply any drivers for Windows 10, Linux, or Mac OS X.
2) You can read the USB specification and the CDC ACM specification. You can run the USB command verifier. You can test your device with a variety of different USB hosts to make sure it works.
I need to communicate with some custom hardware that will use either a FTDI or Silicon Labs usb to serial driver.
I found a couple examples but they are older and was hoping for a more up to date example. Plus, I have been confused by the new AppleUSBFTDI kernel driver in how that works with the IOKit and other chips like the Silicon Labs part. It would be nice to have one program that doesn’t care which driver is used.
I have already looked at this example:
FTDI Communication with USB device - Objective C
The nature of these drivers and devices is that they are supposed to function as a standard serial port virtually over USB. So in terms of access it should be no different than accessing a standard RS232 COM port.
I would suggest reading the Serial Programming Guide for POSIX Operating Systems. I'm not sure what older examples you're seeing but serial access itself is many years old, but the idea behind communicating to the serial device is the same in the case of these USB to serial bridge devices.
For information on some Objective-C frameworks, take a look at this Stack Overflow post.
Finally, here is an article directly from the Apple documentation, Working With a Serial Device, and you'll see it also references the POSIX style API.
You should simply need to install the driver associated with your device and plug it in for this to work. In terms of the Silicon Labs CP210x device just download and install the OSX driver. Then plug in your device. This is where the one difference may show up, the name of the tty device on the system (it will show up in the /dev directory). In the case of the CP210x it will show up and be accessible as tty.SLAB_USBtoUART or cu.SLAB_USBtoUART. This will be the name of the device you should open, then use and API from above to start your communication.
Just as the question states, the goal is to reverse engineer the protocol used by a device.
Let's say you have a webcam, an Arduino and an Arduino USB Host shield. You want to talk to that webcam, from which you don't know the protocol. Can it be done by monitoring USB data packets and by analyzing the driver installed for that device?
It would be a really interesting project.
Thanks in advance.
I often use a serial spy program to look at the conversation between two devices. In windows you can pay for it...
http://www.sinnovations.com/htdocs/serial-port-monitor.htm
In Linux it's free...
http://www.cyberciti.biz/faq/howto-monitor-data-on-a-serial-port-in-linux/