Linux SPI from the terminal - terminal

I am very new to embedded linux development but need to interface with a microcontroller via SPI.
I am using a VAR-SOM-MX8M-MINI and yocto Dunfell (kernel 5.4.142). I can access the spi from /dev/spidev0.2 and can output data by just echoing to this device
echo "test" > /dev/spidev0.2
This works fine, I can see the waveform on a logic analyser and I can see the microcontroller respond. However I do not know how to access the received data from the Linux side. For uart devices I could cat the /dev/ file but that doesn't work for SPI I get the response "cat: -: Message too long"
does anyone have any ideas?

Related

Can the NXP PN532 work on UART at a 38400 baud rate?

I am trying to integrate an RFID1356MIFARE, which uses NXP PN532, with an ESP32-EVB using their UART capabilities.
The NXP docs states that the PN532 is able to communicate on High Speed UART.
I am trying to use 38400 because that's the baud rate fixed by the reader that I'm using.
I've found a modified Adafruit PN532 library that added HSU support. This library states that HSU uses 115200 baud rate.
Now, I've modified PN532_HSU.cpp, where we can find:
void PN532_HSU::begin()
{
_serial->begin(115200);
}
into
void PN532_HSU::begin()
{
_serial->begin(38400, SERIAL_8N1, 36, 4);
}
Unfortunately, I haven't been able to establish communication between the reader and the ESP using this method.
I am able to get a readable output using normal Serial.read(), so UART communication works, but that's not how you read MIFARE cards.
I don't know what the problem is.
What do you think ?
[EDIT]
I went through the documentation and here is what i suggest: If you have a USB to serial device use it to directly connect reader module to computer else connect it directly using mini USB port in module. the follow following steps:
Put device in UART/ USB CDC mode depending on how you connected device to computer. Exact method to do this is provided in operation section of documentation
Use picoterm / screen or other serial terminal (if you are using Linux) or just use Arduino serial monitor with correct baud rate to connect device.(115200 for USB and 38400 for UART)
Type in commands listed in COMMAND SET FOR CDC AND UART MODE section in documentation to check if module is working or not.
Place some cards over reader to check what response does module sends when card is detected.
Use this information to develop your own library for reader.
It will not work with regular PN532 libraries. Instead you'll need to use regular Serial read and write to communicate.
[Original]
PN532 datasheet says host interface is selected by pulling up/down I0, I1 pins of device. For HSU both pins must be pulled down. This is implemented in hardware so you need to verify if the mode you want to use is set.
Looking into the link you posted for module, it says that it uses another micro-controller on board to extend communication capabilities, so maybe you need to use driver for that specific controller firmware? The link seems to have document explaining how to setup different communication system in Document section, please have a look there and check if it works.
Link: https://www.olimex.com/wiki/MOD-RFID1356MIFARE

Access data from a guest's device

I've been trying to get into QEMU development in order to virtualize a not supported hardware.
I want to develop a new QEMU i2c device (qemu x86), that would get/send data to an application running on the guest. Thing is : I need these data onto the host, as a daemon will send/get the same kind of data to the guest.
My questions are : is it easy to get the data from this device ?
Are there any examples already in QEMU that can fit my needs ?
PS : my i2c device is only a "bridge" between the host and the guest. I need the application to use i2c (can't change that).
Typically, the qemu device will use the "chardev" abstraction to get data from a socket on the host. For example, something like -chardev socket,path=/tmp/foo.sock,server,nowait,id=foo -device myi2c,chardev=foo will connect your i2c device to a socket on the host.
There are many examples of devices that use chardevs in QEMU's hw/char directory. A simple example is digic-uart.c.

Identifying what /dev/ is a USB device connected to

I'd like to write a Ruby program for OSX that communicates via USB with my Arduino.
I am going to use the serialport gem for that purpose.
I found a sample code that says:
port_str = "/dev/ttyUSB0" #may be different for you
How can I scan and find the Arduino, and know to what port I should connect to automatically?
(I have OSX)
Thanks!
This can be tricky to do in a general way, because Arduino devices appear as USB serial ports, making it hard to distinguish between Arduino and non-Arduino ports.
The brute-force approach is: enumerate the USB serial devices, open() each in turn, and see if your firmware boot header is sent on the other end. On OSX, the USB serial devices are at /dev/tty.*, but that may change with future OS updates. This method works, but can be slow and timing sensitive. I've found that a startup delay on the Arduino before sending a header helps, as well as a simple "hello, are you there?" command the host can use to bang for signs of life.
Also, you can save the last port found so that subsequent app launches try that port first.
A variant: if your app asks the user to plug in the Arduino at startup, you can list the USB ports in /dev, wait for user to confirm it's plugged in, and list the ports again. Any newly appearing device is likely your Arduino.
At the next level, you could look at the USB Vendor and Product IDs (VID & PID). However, these IDs are all over the map in Arduino-land. They differ by model, version, revision, Chinese clones, and the various Arduino-compatible devices. See this writeup at Adafruit.
If you're just trying to make things work with a very narrow hardware set (e.g. the one Arduino on your bench), you can use this OSX command to see the USB device details:
system_profiler SPUSBDataType
With my system, I get:
...
USB Bus:
Host Controller Location: Built-in USB
Host Controller Driver: AppleUSBUHCI
PCI Device ID: 0x7fff000027c9
PCI Revision ID: 0x7fff00000002
PCI Vendor ID: 0x7fff00008086
Bus Number: 0x3d
Communication Device:
Product ID: 0x0043
Vendor ID: 0x2341
Version: 0.01
Serial Number: 75331313133351800000
Speed: Up to 12 Mb/sec
Manufacturer: Arduino (www.arduino.cc)
Location ID: 0x3d100000 / 2
Current Available (mA): 500
Current Required (mA): 100
The location ID (0x3d100000 / 2) seems to match up with the device name: /dev/cu.usbmodem3d11
See this question for running command line commands from within a Ruby script.

Redirection of kernel messages to another device than /dev/tty01

I have a BeagleBone-like device and have enabled CDC ACM so I can login using USB. That part works just fine, but I can't figure out how to redirect the kernel messages, so I can see the messages during the login. Normally I have the kernel output at /dev/tty01 and logging in using this serial port works fine, also with kernel output. The CDC ACM device is called /dev/ttyGS0.
It would be fine just to be able to redirect kernel messages after login.
I have tried stuff like:
dmesg | tail -f
You could add another console=ttyGS0,<mode> to your kernel command line to log to the serial port.

Create serial communication in NetBSD

I'm trying to create serial communication in NetBSD. This
communication will connect the computer with a controller via RS-485.
The problem is that I don't know if it necessary some configuration or driver to do it.
Specifically, the communication will be through the RS-485 port. I've tried to use /dev/tty01, but there are no pulses in serial output.
Are there some configurations , drivers or codes necessary to open, send and receive serial data in NetBSD?
I didn't have sucess until now.
Thanks
Nothing special needed.
If your serial is a real serial, then you could connect via:
# cu -l /dev/tty00
if your serial is a serial over USB then:
# cu -l /dev/ttyU0
However in both cases you have to be root, or change permissions on the device.
If the output is not visible, then adjust the speed with -s switch.

Resources