I'm currently working on a project which involves dealing with a HW device tailor-made for this purpose.
The device will serve the purpose of sending certain data via serial port (COM1, for instance). The data it is supposed to send doesn't matter that much.
I already have some knowledge regarding Windows serial port communication. CreateFile, WriteFile, and so on... BUT...
There is one "engine" on the device, which will send me the data when I ask it to, and in order to do so, I need to send there a signal (10101010) the rate of which will indicate the clock rate of that device "engine".
Here comes the explanation of how this device work. It gets a signal to send data through one pin. I'm supposed to send there 0 for start, 1 for end. Then, after this, it will watch some other pin for signal, sample it, and based on the frequency of ones and zeroes I send to it, it will start sending data via the thrid pin.
My questions are:
How to access individual pins of COM port?
How to manage the frequency and any delays I will need by myself?
I think that maybe I will have to do on this in kernel more by use of device drivers which will have to be developed.
There is an easier way. The COM port will send out the signal of alternating 1s and 0s if you just send a 0xAA byte.
Related
I want to create a basic project in Vivado that takes a value that i input to a client, which is sent to a server I made (in C), and then the server writes that value to a peripheral in Vivado, and then that data in the peripheral is sent to an output pin that assigns to LED's, making the LED light up.
Basically I want to go from client-->server-->peripheral-->LED lights up
For example, in the client (a GUI) I want to give it a value such as 0011, which is received by the server. Then the server writes that value to the peripheral which will then make, in this case, LED0 & LED1 not light, but LED2 & LED3 will light.
I know how to make an AXI4 peripheral in Vivado, and the client-server (TCP/IP) has been made. My question is what code/design block I would need to then take the data written to the peripheral and assign it to the LED's?
Should I make the peripheral a Master or Slave? Overall confused how should i proceed from here. I am using a Red Pitaya (Xilinx Zynq 7010 SoC) connected by an Ethernet cable to my computer.
Also, I thought of running the program on the Red Pitaya by loading the bitstream on to it (using WinSCP) by running the command
cat FILE_NAME.bit > /dev/xdevcfg
in PuTTY (connected to the Pitaya by IP address), then running the server on the pitaya, and then sending the signal from the client for the server to receive. Is that the correct way of approaching it?
If my logic is off in anyway please let me know
I am somewhat thrown by your statements.
First you say "I know how to make an AXI4 peripheral in Vivado"
Next I read: "Should I make the peripheral a Master or Slave?"
Maybe I am wrong but to me it says you don't really know what you are doing.
Simplest is to:
Instance a zynq system.
Add the IP with the name "AXI GPIO". (Which, by the way, is an AXI slave.)
Run the auto connection.
Assign the right I/O pins to the GPIO port. (check your development system manual)
Build the system.
By the way you find the address of the peripheral in the address tab and it normally is 0x0080000000.
You wrote that you made a server (TCP/IP). "All" it has to do is write the received value to a register in the GPIO block. (Here I assume Xilinx has a document which describes how the GPIO block works and has example GPIO drivers.)
I'm trying to implement S-MAC protocol on waspmote xbee sensors and i know it has its own CSMA/CA. So first of all I need to understand the basic of xBee collision avoidance.
Two senders set up in api mode in libraries and both periodically sending single bytes to a common receiver. I reduce the delay and many changing in libabries to make collision and to see how algorithm works. But when i monitor data at the receiver all looks as expected at the receiver .. byte1, byte 2 .. byte1, byte2.
Do u have any idea how can i make collision?
Are you sniffing the 802.15.4 traffic? That's the only way you'd see a collision.
The XBee module buffers the data you want to send, using the host communication parameters (baud rate, API mode, etc.) and then sends it out over 802.15.4 at 250kbps. The module has all of the collision avoidance built in, and will retransmit as necessary to deliver your message. If it's unable to deliver after some number of transmission attempts, you'll get a Transmit Status frame indicating failure.
On the receiving end, it buffers the data and delivers it to the local host using local serial settings (baud rate and API mode).
If you're trying to implement S-MAC, you need a different radio processor where you have low-level control over the radio. The XBee module provides an application layer and handles the MAC layer itself.
I am trying to force a 9-bit protocol on a UART in embedded Linux. Currently I am testing this out on the am335x_evm board. I am planning on doing this using stick parity. Ideally I was hoping I would not need to actually modify any of the code for the omap-serial.c driver.
The reason for the 9-bit protocol is to support some legacy hardware that uses it. The parity bit needs to be 1 for the address portion of the message, 0 for the data portion, then 1 again for the termination byte.
I was planning on having a process running in user space that would interface with the UART through standard system calls (open, write, read, ioctl, tcsetattr, etc). I would configure the UART to enable parity and set the stick parity. I would then set the parity to even and call write() to send out my address data. I would then set the parity to 0 and send out the data. My concern is if I change the parity from 1 to 0, when does that take affect? If the UART is not done sending all the address data, will the change in parity apply to any unsent data?
Ended up writing my own 9-bit uart driver. Was the easiest and most efficient solution.
Proper way is to set cs9 on your serial port (and possibly no parity), provided that hardware and driver support this.
I'll search for a link for you...
Is it possible to query serial port tx (send) pin status if it is active or not ?
For example when issuin break command (SetCommBreak) tx pin is set to active (low). I'd like to know when it is active or not. Thanks.
No. (at least not likely)
If you are using the "16550" family of UARTs, then I am confident that you can not query the serial port tx pin status. Of course, if you are using some new version or other UART family, maybe.
You can assume that the TX pin is in the SPACE state ('0', +Volts) whilst performing SetCommBreak(), but I suspect that is not enough for you.
If you are look to debug your code to know if a break occurred, you can short pins 2 & 3 on a 9-pin D-sub, thus loop backing the transmit to the receive. A paper clip will do. Your receive code would detect the incoming BREAK. Shorting to the incorrect pin does not cause a lasting problem with a conforming serial port, but be careful. Try this first with simple data, before testing BREAK condition.
If you have a "16550"-like UART.
You can put the UART into loop-back mode and see if you receiving you own outgoing BREAK signal. Its somewhat complicated in current PCs. Other UART type may support loop-back.
I am using EVK1105 development board with AVR Studio 5 as development IDE for my AVR project.
I am using FreeRTOS in it. I have 3 USART ports on this board. One external module is connected to my AVR32 board via USART-RS232 mode. It sends me continuous serial data to my board on USART0 with 19230 baudrate, 7-databits, odd parity, stopbit-1 and normal-channel mode. I created a new task for this purpose. After each 9 data bytes it sends '\n' and '\r'. So in my task I keep on collecting the 9 databytes in a string buffer and then transmit it on USART1. I am using polling method to collect data from USAR0 which is receiving port. But I am facing problem in receiving data. I don't know if its timing issue or something or the scheduler switches the task while collects the data. But I don't get the required data.
Following are things I have already checked as troubleshooting
1. Connected my external module to my PC hyper-terminal which gives me perfect result.
2. Implemented the same thing of using receiving from USART0 and whatever received is transmitted to USART1 as without FreeRTOS. Its works fine.
Please suggest some idea what may be wrong. I am using a queue to communicate between Tx and Rx task to pass the string buffer from USART0 to USART1. Is it problem in handling queue? How can I troubleshoot the queue?
I am using a delay of 50ms in my infinite task loop in Rx Task. Can it create a problem? If I don't use any delay the OS crashes. Please suggest some good practices to create a new task in FreeRTOS so that I will not get any timing issue.
For such a use case, I would not use a polling method with 50ms delay to retrieve data from UART peripheral. You can easily lose received data depending on the system load and UART reception buffer size.
At least use an interrupt on UART data reception that copies every received byte into a local buffer that will be read by your TX thread.
You can have an even better solution using a DMA channel to receive your data frame and be notified when 9 bytes have been received. I don't know if your AVR device has a DMA peripheral or not.
Are you still working on this? The statement of your problem is vague, but there I have several suggestions/leading questions.
1) You may want some documents to see what the registers are
Get the giant datasheet pdfs at
http://www.atmel.com/dyn/products/product_docs.asp?category_id=163&family_id=607&subfamily_id=2138&part_id=4117
2) In this and an earlier post you state that you have, in some cases, been able to RX data. You will need to find the USART HW initialization code from those example projects and get them into the freeRTOS example project. In particular calls to
gpio_enable_module() with {AVR32_USART0_RXD_0_0_PIN, AVR32_USART0_RXD_0_0_FUNCTION}
To connect to USART to CPU
and i believe
InitRs232()
Just doing this requires poking around a lot of code - there's alot of dependencies.
2) What function are you calling to retrieve data from USART0? 19kbaud is approximately 2000bytes/sec or 1 byte/0.5ms, so 50ms polling is not nearly enough. I'd suggest that your RX task poll continuously (never sleep explicitly) but at a lower priority than the TX task.
3) Concentrate on debugging the RX task at the call to retrieve data. Use the debugger to look at the hardware registers for the usart. In particular
USART0 cr register AVR32_USART_CR_RXEN_MASK should be set to enable RX
USART0 csr register AVR32_USART_CSR_RXRDY_MASK will indicate if there is new data there
You can also check the overlow flag to see if you have missed some data.
When the read of USART0 rhr occurs it should be a byte that you sent.
If you are still working on this I can look into this a bit more.