I am using an STM32-Discovery board for my first time. I want to use two of the USART ports on the board at the same time to read in serial information. Can the STM32 read in serial information from both of these USART ports at the same time? Do I need to set an interrupt instead, to switch between them?
I realize this is connected to threading on the board, but I do not understand the threading of the board.
You can read and write as many peripherals as you wish. But of course you need to do it a proper way. For example if you poll for the data from UART1 the data can be overrun on the another ones. So you need to implement other methods like using the interrupts. The topic is too broad for the simple answer.
Related
I am working on a project using a Raspberry Pi where I need to create a GUI that can interface with the various peripherals. Specifically the program needs to:
-read the position data from a touchscreen, mouse, or other HID
-perform some math on on the position data
-store the data in a FIFO buffer
-output that data over the SPI port at a fixed frame rate
I have an electronics background, with some experience writing firmware for microcontrollers, but I'm a relative novice when it comes to this kind of stuff. I have done some research, and it looks like the mouse/touchcreen data is available by reading a file in the /dev/input directory, and I assume you can access the SPI port by reading or writing to some file in the /dev directory. (I am currently running Raspbian)
My initial thoughts were to write a simple C program that a) reads the touchscreen data file and stores it into a preallocated buffer in memory and b) writes the data that next in line to the SPI data file in order to write it out to the SPI port. Part (a) would fire off either on a timer interrupt and poll the touchcreen data to see if it's new, or fire off from a "new data" interrupt. Part (b), the SPI part of the program, would fire off at a fixed rate, probably from a timer interrupt.
So my questions are:
-Is it even possible (or easy) to access interrupts or system timers from the user space? I assume you would need to get hooks into the kernel somehow?
-If so, how would I make it so that my function runs whenever a interrupt or timer fires off?
-How easy is it to use the SPI DMA in user space? Does anyone have any experience doing that? I did a little research and it looks like you need to load a custom kernel driver, but I didn't know how tricky that would be.
-Is it possible to write out a parallel word on the GPIOs the way you would do it on a microcontroller (ie all at once by writing the word to the port's output register)?
I know there are plenty of higher level programming languages and wrappers that allow you to talk to the perepherals, but I'm a little hesitant doing it that way since the timing seems pretty tight. I need to output (3) 16-bit words per frame at ~1k frames per second. At 500kHz SPI bitrate, each frame is 96 us long, and at 1k frames per second, each period is 1ms. This is why SPI DMA, or even writing the data out as a parallel word would be a lot easier in terms of timing.
Thanks for the help!
Im trying to learn about serial communication and I saw that command in below link
http://www.tldp.org/HOWTO/Serial-HOWTO-19.html#pinout_
Only 3 of the 9 pins have a fixed assignment: transmit, receive and signal ground. This is fixed by the hardware and you can't change it.
But the other signal lines are controlled by software and may do (and mean) almost anything at all.
So, these 6 pins, are they reliable to control state of them?
I have many devices, is there any way to make hardware handshaking in a common way?
what I have to do, If some drivers does not handle this pins accurately?
Is there any way to make them fixed assigned by program?
I'm new with SPI; the Linux kernel provides an API for declaring SPI busses and devices, and managing them according to the standard Linux driver model.
You can find the description of the struct spi_master here: https://www.kernel.org/doc/htmldocs/device-drivers/API-struct-spi-master.html
The description at the link above says that "Each device may be configured to use a different clock rate, since those shared signals are ignored unless the chip is selected". To put the sentence in a contest, I have to say that with "device" they mean SPI slave device, and with "those shared signals" they mean MOSI, MISO and SCK signals.
In fact, in the struct spi_device (https://www.kernel.org/doc/htmldocs/device-drivers/API-struct-spi-device.html) there is an attribute named max_speed_hz that is not present in the struct spi_master. So I can understand on the first part of the statement above: "Each device may be configured to use a different clock rate".
But, what does mean the second part? Does "since those shared signals are ignored unless the chip is selected" mean that I'm allowed to used different clock rates but only one at time by enabling/disabling the slaves with different rates?
Thank you for your help! Regards,
--
Matteo
#Matteo M.: I think you actually are not allowed to simultaeously setting SS1, SS2 and SS3 to zero and in this way enabling all three SPI slaves at the same moment in time. The reason is, that the SPI slaves, while receiving data on the MOSI line, simultaneosly send back data on the MISO line. If actually all three slaves would put data on the (shared) MOSI line, really bad things could happen, both regarding the data and the electrical flow.
SPI is a very loose "standard", there are not many rules to follow, which is good (and bad I guess). It is good because it is flexible. It is bad because it can be implemented differently depending on the specific hardware you are dealing with. Some devices support only half-duplex communication, which as you know requires coordination of when the bus can be driven. Select lines (chip enable, slave select, whatever you want to call them) provide a handy way to do this without using bits to identify which slave should get a message off the bus.
In the full-duplex mode, where data is dropped onto the bus from the master and from the slave on each clock pulse, the select line could be very much required to prevent bad things, as Wolfgang stated. I want to stress could be required; it is completely reasonable to have perhaps a master processor communicating with other processors that only drive the bus when responding to some specific bit pattern (like for instance, an "address")... More software/firmware? Yeah, but it is not stopping you.
So, if your 8-bit slaves are say, for instance 8-bit DACs you could indeed write the values chunks of the master data register. Independant select lines will enable you to do this without all those slaves driving the bus at once. Yeah, you have to shift the values from each slave into the master register one at a time, but that too is a completely reasonable design.
Unlike some more complex serial protocols SPI is actually really flexible; because it doesn't lock you into max word size or require any of the data you write to the bus to be comprised of things like addresses and offsets and stuff.
I want to use rs485 placed on my card. I'm working on arm-linux and with pxa255 processor. I have already checked "serial.h" located in arm-linux tool chain but unfortunately i couldn't find the appropriate rs485 settings struct although it is supported in some other environments like cris. So now, do i have to write a low-level driver to enable rs485 or is there any other easier way to do this?
I'd recommend reviewing this page about Linux RS-485 support.
There seems to be quite a lot of confusion about serial ports with regards to RS485 mode support on Linux drivers. I think I might be able to shed some light answering this question.
First off, you should ask yourself: why do I want to activate RS485 support on my serial port? I don't know what development board or hardware you're using but be aware that most UARTs work with single-ended TTL levels only (5V or 3.3V levels). That means you won't be able to talk to RS485 devices directly because they only handle differential signals. If you want more details you can see this link: https://www2.htw-dresden.de/~huhle/ArtScienceRS485.pdf for a good introduction.
So you can write as many lines of code and drivers as you want but that won't help your TTL UART talk to RS485. Even if you have a device that supports RS485 on its driver, the hardware itself needs to have a level translator IC (like a MAX485) for you to be able to use it. Fortunately, our beloved Linux Kernel developers know a lot about hardware and you don't have to worry about this (for most devices anyway). Then, answering your question: if you are not able to find the RS485 settings on your driver it will most likely mean your hardware does not offer support directly.
Luckily for you, the solution is quite easy: just get a cheap USB to RS485 dongle. You can find them from 5-10$ and they should work fine out of the box for most scenarios. In my experience, FTDI chips work well.
If you really have to go with one particular UART for any reason whatsoever, for instance, imagine you want to use the UART on your Raspberry Pi or any other where you only have TX and RX signals accessible. Then you have a slightly more difficult challenge ahead of you and you need to study a bit more about how RS485 devices work. The key aspect here is to understand that RS485 on a half-duplex two-wire link (see note below for more details on this). To be able to share a two-wire bus where one or multiple devices are listening and only one is talking at any time, you need an additional control signal (Drive Enable/~Read Enable) on top of your TX and RX (note that when you go on single-ended TTL you have two signals referred to GND using three wires compared to one differential bus with two wires for the RS485 side). Your RS485 transceiver (say MAX485) will need this RE/~DE signal to arrange who is talking and who is listening on the bus, namely: all devices listening on the bus will have this signal low (read enable set) while the talker will be high (drive enable).
Here we get to the essence of your question: where can you get this additional signal? Well, the answer is: it depends on your UART chip. Some chips don't offer anything to work with, then you're left with the option of manually driving in your software application a GPIO line or flow controls signals (RTS or DTR) for UARTS where you have them available. You can read more details on this topic for the particular case of the FTDI chips here: RS485: Inappropriate ioctl for device. There is also a reference to a nice hardware solution to this problem using the mythical 555 timer IC.
Note: more confusing areas: one, RS485 is half-duplex and sometimes mixed up with RS422, which is full duplex and needs four wires; and two: where I say two-wire and four wires I should better say three-wire and five wires because the differential voltage signals need a GND to serve as a return path; sadly, most practical implementations of RS485 are two-wire and they seem to work reliably for most people, but that's a huge topic itself and we can talk about it somewhere else.
For a project I'm working on I have to talk to a multi-function chip via I2C. I can do this from linux user-space via the I2C /dev/i2c-1 interface.
However, It seems that a driver is talking to the same chip at the same time. This results in my I2C_SLAVE accesses to fail with An errno-value of EBUSY. Well - I can override this via the ioctl I2C_SLAVE_FORCE. I tried it, and it works. My commands reach the chip.
Question: Is it safe to do this? I know for sure that the address-ranges that I write are never accessed by any kernel-driver. However, I am not sure if forcing I2C communication that way may confuse some internal state-machine or so.(I'm not that into I2C, I just use it...)
For reference, the hardware facts:
OS: Linux
Architecture: TI OMAP3 3530
I2C-Chip: TWL4030 (does power, audio, usb and lots of other things..)
I don't know that particular chip, but often you have commands that require a sequence of writes, first to one address to set a certain mode, then you read or write another address -- where the function of the second address changes based on what you wrote to the first one. So if the driver is in the middle of one of those operations, and you interrupt it (or vice versa), you have a race condition that will be difficult to debug. For a reliable solution, you better communicate through the chip's driver...
I mostly agree with #Wim. But I would like to add that this can definitely cause irreversible problems, or destruction, depending on the device.
I know of a Gyroscope (L3GD20) that requires that you don't write to certain locations. The way that the chip is setup, these locations contain manufacturer's settings which determine how the device functions and performs.
This may seem like an easy problem to avoid, but if you think about how I2C works, all of the bytes are passed one bit at a time. If you interrupt in the middle of the transmission of another byte, results can not only be truly unpredictable, but they can also increase the risk of permanent damage exponentially. This is, of course, entirely up to the chip on how to handle the problem.
Since microcontrollers tend to operate at speeds much faster than the bus speeds allowed on I2C, and since the bus speeds themselves are dynamic based on the speeds at which devices process the information, the best bet is to insert pauses or loops between transmissions that wait for things to finish. If you have to, you can even insert a timeout. If these pauses aren't working, then something is wrong with the implementation.