Does anyone ever develop some application to control the spi device on OMAP3? I can load the spi driver "mcspi", but I don't know how to use it.
As of at least PSP 3.00.00.04, the mcspi driver is integrated with the Linux spi stack.
Turn on
CONFIG_SPI and CONFIG_SPI_OMAP24XX
in your kernel.
Here's how to use spi devices, in general.
There is also the spidev driver, which presents a char device to userspace, but it's experimental.
Ok So first I need to apologize for my previous shoot from the hip answer.
I too have now started looking into trying to get the McSPI's working and it has been some what painful. TI does not have lot of documentation, and I still haven;t been successful in getting any of the McSPI's to actually work, yet. But I thought I would post a link to the beagle board google discussion on the subject, as it appears they have been successful at getting at least McSPI3 working on the OMAP3530.
http://groups.google.com/group/beagleboard/browse_thread/thread/15d9488c1ec314ef/5ca06c67ff438106?q=mcspi3#5ca06c67ff438106
Related
I have an obsolete hardware level/pressure transmitter that communicate with mcu using custom protocol (it appear to be similar to modbus RTU), that hardware comes along with an old commissioning software that works perfectly fine under latest windows, that software contain all communication protocol components that I try to extract and use in something like Arduino to pull data out of transmitter, anyone can help out?
Update - Didn't mentioned above that form of communication here is half-duplex serial communication where master hardware/software query slave transmitter.
Now mentioned to program Arduino mcu to pool data out of transmitter.
What best way of getting readable data out of it?
Again many thanks for all your comments and help!
What you need is called a sniffer. Use that as a keyword and you should be able to find plenty of info here at SO and around the web.
To set the record straight it is actually possible to use Wireshark to sniff on Modbus RTU over serial, see my answer here. If your protocol is similar to Modbus I would start with SerialPCAP.
If you prefer more Windows-friendly solutions you can check these out: 1, 2.
Since Modbus is pretty simple I would say reverse engineering a similar protocol should be, maybe not a piece of cake but just manageable, even if you are not very experienced.
These days when almost everyone is a maker or at least a wannabe, you might want to first take a good look around, maybe somebody else already reverse-engineered that protocol and published it somewhere.
The best tool to analyze a protocol is Wireshark. Run it on the communication link between the Windows machine and the radar. First possibility: the protocol is actually something that Wireshark knows (some trials and errors with the "Decode as" menu may be necessary.) Second possibility, less funny: the protocol is indeed completely proprietary and unknown to Wireshark. At least, Wireshark will make it easier to examine the binary data.
I am trying to learn Linux by following instructions in "Mastering Embedded Linux Programming" by Chris Simmonds. By following the book and with some help from Stack_Overflow_1, i was able to build the MLO and u-boot.img.
However, when i connect USB cable to my PC and execute the ls /dev/tty* command, i cannot find any device with /dev/ttyUSB. All i can see are devices with /dev/tty0-63, /dev/ttyS0-31 and one /dev/ttyprintk.
Also, when i press down the S2 button and connect the USB cable, i can only see the power led glowing and nothing else.
I have properly built the u-boot (three attempts to get it right).
Also, as per the instructions in the book, i am only testing the u-boot stuff and yet to reach the kernal part.
If i remove the sd card and connect the USB, im an able to talk to my BBB over ssh (192.168.7.2).
How to i get the u-boot to work? Thank you!
If you don't have one yet, I'd recommend to get a USB-to-serial device (3.3V Vref). You connect it to the debug UART (J1) which is located next to the P9 side. Nowadays those are very cheap and can cost below 1$. Ones that feature a genuine FTDI part will be 5-10$ at least.
The serial port you are referencing is only available once the device has passed through U-Boot, booted the kernel and finally userspace has set up the communications.
Especially when working with U-Boot and the Kernel, low level UART access is crucial.
As a further note, could it be that the Book refers to the (white) original Beaglebone? That has a FTDI USB-to-UART chip on board and will allow you even U-Boot access. You can do the same things if you have the above mentioned USB device.
https://groups.google.com/g/beagleboard/c/eNDjK05spY8/m/GPvhcP52BAAJ shows that one needs to hold the space key to enter u-boot.
Also, the info. here might be more up to date compared to the book.
https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black
There is no way to copy and paste everything from the eewiki. I just left you the link. Enjoy!
I have got Arduino MEGA 2560. What I would like to do is to send a signal to Arduino via serial port to light specified LED up. However, I cannot find any documentation about this. What steps should I follow?
I think first, I need to compile the driver of Arduino and add it to Linux kernel. Second, I have to find some header files to use them in module. Then, I have to find functions to start serial communication and to light LEDs up. However, these are just my thoughts.
Any advice will be appreciated.
The arduino-mega (the one with ATmega2560) documentation is here:
https://www.arduino.cc/en/Main/ArduinoBoardMega2560#documentation
The serial communication via UART:
https://www.arduino.cc/en/Reference/SoftwareSerial
Since there are other ways for serial communication with the ATmega please read the documentation [above] and compare that to your exercise sheet.
I think such a kernel module is already available - and used by the arduino-ide.
I'm trying to get 9bit serial working for communication with a device that requires the 9th bit set high in order to receive (yea, I know...).
I'm using a pretty standard USB-RS232 dongle with an FTDI chip in it and it appears to be using the FTDI drivers on the system.
I've been using this guide for MARK/SPACE parity which my research suggests is the only way to go (?) and basing my code off of this which I've been lead to believe is terrible but, hey, that's never stopped me before.
I'm pretty sure at this point that the Linux FTDI drivers completely ignore CMSPAR but if anyone knows otherwise, your input would be greatly appreciated. I do know for a fact that the FTDI dongle I have can, in a limited capacity, support 9bit serial as I have the dongle working fine on a windows machine.
Assuming nobody has a magical answer to all of this, the main question I'm asking becomes, how difficult it would be to "fix" the FTDI driver, if necessary, to work? Additionally, where would be a good place to start for someone with limited experience with linux device drivers? Assuming all goes well, it seems I'm not the only person with this problem so it would be great to contribute something, however small, to the community.
If the ninth bit should always be high, just use 8 data bits and one more stop bit than you would normally be using.
To gain more control, use the D2XX Direct Drivers that provide a relatively simple C API.
I wish to read the EUI64 address from an AT24MAC602 memory chip interfaced to an Atmega128rfa1 MCU over the Two wire interface. I tried to modify the I2C master drivers which are available for other platforms to suit my need. However, I wasn't able to carry out these modifications successfully as the program stopped responding as soon as the slave address was written to the twi bus with Write flag set. I failed to uncover the underlying reasons for the same.
As Contiki OS is quite popular, i thought someone might have already come up with contiki specific libraries for reading writing over TWI interface for Atmega128rfa1 MCU. If so, please provide pointers to the twi drivers or documentation for the same, or suggest factors that should be considered for developing such drivers. Thank you.
If you don't have any luck finding/creating a driver for the TWI peripheral, you might consider emulating it by configuring the SDA/SCL pins as general I/O and then implementing the TWI protocol yourself. If you're just doing a one-time read of a chip ID then speed probably isn't a big concern, so this could work if you get desperate. Google should throw up a few examples of emulated TWI.