I am a high school student, who is not very familiar with FPGAs and the Xilinx line.
I am running a ring oscillator module on a Zybo Z7 board. I am also running a counter module, which I want to sample at a high rate. I am currently sending the data through AXI to the ZYNQ processing system, and then using the inbuilt UART to USB buffer to send the data through a USB cable to my computer. On the computer side, I treat this input as a virtual serial line, and use a python script to take and log the data from an IOstream. This method takes very long, however, and I am trying to increase the sample speed. Thus, I was wondering if I could bypass the onboard PS, and connect the FPGA fabric directly to the UART buffer.
I have tried optimizing my PS code, which I have written in C. I have reached the point where it takes 30 oscillations of the onboard ZYNQ clock between samples. Now, however, I have created a newer and more reliable sampling framework in the FPGA logic, which requires a 'handshake' mechanism to start and stop the counter between samples. It takes a very long time for the PS to sample the counter, send the sample, and then restart the counter. Thus, the uptime of my sampling framework is a fraction of what I want it to be. Removing the PS would be ideal, as I know I can automate this handshake signal within the PL if I am able to connect it to a UART interface.
You can implement logic in the PL that can handle the UART communication thus bypassing the PS.
Here's an implementation you can try using:https://github.com/jakubcabal/uart-for-fpga
You would connect the UART pins to one of the Zybo Z7 Pmod ports and use an external USB to UART adapter such as this one, anyone would work as long it supports 3.3V: https://www.adafruit.com/product/5335
The adapter built into the board is connected to directly to the PS MIO pins and cannot be used by the PL.
Related
We are looking at using the Telit BlueMod+SR chip in a hardware idea we are working on. Towards that I've been trying to build a Bluetooth Low Energy (BLE) server simulation using the Telit BlueEva+SR evaluation board driven over USB by a Python script.
The two relevant manuals appear to be:
BlueMod+SR AT Command Reference
Terminal I/O Profile Client Implementation Guide (though I'm implementing the server)
(N.B. these are available here but are behind a register/login.)
I'm stuck on something basic: how to send or receive data. I understand that this is done by setting the value of a Generic Attribute Profile (GATT) service's characteristic. The BlueMod+SR already has the GATT service characteristics that I need (a UART data TX characteristic and a UART data RX characteristic) on its Terminal I/O Service. The UUID's of the characteristics I need are given in the Terminal I/O Profile Client Implementation Guide but I cannot see how to read from nor write to them. The AT Command Reference has a section on GATT Server commands but the only one listed, +LEATTRIB, is for defining the attributes for a service (and the ones I need are already defined).
What are the commands I need to read and write the values for the characteristics UART Data TX, UART Data RX, UART Credits TX, and UART Credits RX?
It turns out that I did not need to use the credit mechanism, that's handled for me. So to write to the TX characteristic I can either connect to BLE and just write the data, or use the multiplexing and write the data to channel 0x01 (Terminal I/O). Reading the RX characteristic si similarly just reading the serial connection.
I have a project in which I need to have the lowest latency possible (in the 1-100 microseconds range at best) for a communication between a computer (Windows + Linux + MacOSX) and a microcontroller (arduino or stm32 or anything).
I stress that not only it has to be fast, but with low latency (for example a fast communication to the moon will have a low latency).
For the moment the methods I have tried are serial over USB or HID packets over USB. I get results around a little less than a millisecond. My measurement method is a round trip communication, then divide by two. This is OK, but I would be much more happy to have something faster.
EDIT:
The question seems to be quite hard to answer. The best workaround I found is to synchronize clocks of the computer and microcontroler. Synchronization requires communication indeed. With the process below, dt is half a round trip, and sync is the difference between the clocks.
t = time()
write(ACK);
read(remotet)
dt = (time() - t) / 2
sync = time() - remotet - dt
Note that the imprecision of this synchronization is at most dt. The importance of the fastest communication channel stands, but I have an estimation of the precision.
Also note technicalities related to the difference of timestamp on different systems (us/ms based on epoch on Linux, ms/us since the MCU booted on Arduino).
Pay attention to the clock shift on Arduino. It is safer to synchronize often (every measure in my case).
USB Raw HID with hacked 8KHz poll rate (125us poll interval) combined with Teensy 3.2 (or above). Mouse overclockers have achieved 8KHz poll rate with low USB jitter, and Teensy 3.2 (Arduino clone) is able to do 8KHz poll rate with a slightly modified USB FTDI driver on the PC side.
Barring this, and you need even better, you're now looking at PCI-Express parallel ports, to do lower-latency signalling via digital pins directly to pins on the parallel port. They must be true parallel ports, and not through a USB layer. DOS apps on gigahertz-level PCs were tested to get sub-1us ability (1.4Ghz Pentium IV) with parallel port pin signalling, but if you write a virtual device driver, you can probably get sub-100us within Windows.
Use raised priority & critical sections out of the wazoo, preferably a non-garbage-collected language, minimum background apps, and essentially consume 100% of a CPU core on your critical loop, and you can definitely reliably achieve <100us. Not 100% of the time, but certainly in the territory of five-nines (and probably even far better than that). If you can tolerate such aberrations.
To answer the question, there are two low latency methods:
Serial or parallel port. It is possible to get latency down to the millisecond scale, although your performance may vary depending on manufacturer. One good brand is Brainboxes, although their cards can cost over $100!
Write your own driver. It should be possible to achieve latencies on the order of a few hundred micro seconds, although obviously the kernel can interrupt your process mid-way if it needs to serve something with a higher priority. This how a lot of scientific equipment actually works. (and a lot of the people telling you that a PC can't be made to work on short deadlines are wrong).
For info, I just ran some tests on a Windows 10 PC fitted with two dedicated PCIe parallel port cards.
Sending TTL (square wave) pulses out using Python code (actually using Psychopy Builder and Psychopy coder) the 2 channel osciloscope showed very consistant offsets between the two pulses of 4us to 8us.
This was when the python code was run at 'above normal' priority.
When run at normal priority it was mostly the same apart from a very occassional 30us gap, presumably when task switching took place)
In short, PCs aren't set up to handle that short of deadline. Even using a bare metal RTOS on an Intel Core series processor you end up with interrupt latency (how fast the processor can respond to interrupts) in the 2-3 µS range. (see http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/industrial-solutions-real-time-performance-white-paper.pdf)
That's ignoring any sort of communication link like USB or ethernet (or other) that requires packetizing data, handshaking, buffering to avoid data loss, etc.
USB stacks are going to have latency, regardless of how fast the link is, because of buffering to avoid data loss. Same with ethernet. Really, any modern stack driver on a full blown OS isn't going to be capable of low latency because of what else is going on in the system and the need for robustness in the protocols.
If you have deadlines that are in the single digit of microseconds (or even in the millisecond range), you really need to do your real time processing on a microcontroller and have the slower control loop/visualization be handled by the host.
You have no guarantees about latency to userland without real time operating system. You're at the mercy of the kernel and it's slice time and preemption rules. Which could be higher than your maximum 100us.
In order for a workstation to respond to a hardware event you have to use interrupts and a device driver.
Your options are limited to interfaces that offer an IRQ:
Hardware serial/parallel port.
PCI
Some interface bridge on PCI.
Or. If you're into abusing IO, the soundcard.
USB is not one of them, it has a 1kHz polling rate.
Maybe Thunderbolt does, but I'm not sure about that.
Ethernet
Look for a board that has a gigabit ethernet port directly connected to the microcontroller, and connect it to the PC directly with a crossover cable.
I am posting this question after not getting any sort of help across the web and reading many articles and tutorials. I ended up asking questions with hope of getting guided.
DESPERATE FOR HELP.
What i want:
1) I want to build a R/C tank.
2) Basically its not controlled by a remote control but i want control by a laptop.(i could write a c++ or c# program).
What i know:
1) I know how to develop a development board. (i want to develop my own, not use arduino)
2) I know c++ and assembly very well.
3) I know about AVR's ALU, Memories(all 3), Stack, Interrupts, IO Operations well.
4) I know theory about how SPI, RS232, UART works.
PROBLEMS: (I have many questions, but most important are)
1) B/c i have made my own board. How can i transfer my program(hex file) to my board(i seek practical and physical implementation, not theory please)(i know about a 6-pin ISP but not clear about practical implementation)
2) After it, how can i make wireless communication b/w my AVR and laptop.(hardware device?)(SPI, RS232, UART?)
MAIN CONFUSION:
1) I cannot help myself differentiating or relating SPI, RS232 and UART.
I know these are used for serial communication between devices but how?(which is used when and why and how)(appropriate hardware for transmitting device and receiving device)
THING TO KNOW:
1) I haven't started making my board and programming it because i think i should learn everything first and then do it in a one go. OR should i start practical work and things get easier automatically??
2) I learnt a tutorial series on Serial Communication from http://maxembedded.com/2013/09/serial-communication-introduction/ the starting 5 topics leaving the last one(I2C). Am i missing something there?
I hope everything is clear, and waiting for a good-men's words.
Note: I am already very misguided and lost, so i want experienced and expert's guidance. Many Many Many Many Thanks in Advance.
MY BOARD LOOKS LIKE:
http://www.robotplatform.com/howto/dev_board/schematic_l/38.jpg
1) To upload your code into AVR chip, you can use ISP interface. That requires you to connect at least 5 pins: SCK, MISO, MOSI, RESET, GND, and optionally VCC (it used to control or supply voltage, but not mandatory, if your board has it's own power supply). All you need is just to wire 6- or 10-pin ISP connector to that pins of your CPU.
To begin programming process you need to obtain some programmer device (USBasp, AVRISPmk2, STK500/600 etc.), Also, you can use Arduino board itself as ISP-programmer for external AVR chip, like this: http://www.instructables.com/id/Programming-an-ATTiny13A-using-Arduino-servo-int/
Each of programmer model requires it's compatible software (such as PonyProg), for example STK500 and AVRISP programmes could be used directly from Atmel Studio.
Also, you can connect ISP to parallel (LPT) port of the PC, and upload firmware using specialized software, such as uniprof
Another way to upload software - it is to make your own bootloader - a tiny program that will update firmware, using any available interface.
2) USART, SPI, I2C - it is different interfaces to communicate with peripherals. Note that RS232 - it is electrical interface built over USART. I.e. you need external IC which will convert USART logical level signals to RS232 electrical levels.
each of that interfaces have it's own profs and cons. And usually selection of which interface to use depends on which interface is supported by peripherals.
SPI - it is interface for high-speed communication. One master many slaves. It requires a lot of wires: MISO (data from master to slave), MOSI (data from slave to master), SCK (clock) - those three could be common for all slaves. Also it requires a SS (slave select) - one SS wire for each slave to determine which slave is in communication at the moment, also it sets the edges of the data packet.
USART - it is common interface, to communicate two chips. Each byte transmitted with foregoing start bit, optional parity and following stop bit. I.e. transfer has a quarter overhead, but byte can be transmitted in any moment.
Works in synchronous and asynchronous modes. Asynchronous mode requires only 2 wires (RX and TX, not counting GND that also required). This mode requires that receiver and transmitter to be sychronized, in most cases that required to crystal oscillator to be installed.
Synchronous mode works in the same format as asynchronous, but have additional XCK (clock) wire, that determines in which moments bits are possible to be transmitted. This allows to increase transmission speed and not requires time precision from receiver. Synchronous mode is rare used.
I2C - it's a bus with only two wires, allows many masters and many slaves. Utilizes pull-up resistors to achieve wired AND, have it's own algorithm to detect collisions, more complicated to be programmed, transmission speed is limited.
Often used by peripherals, such as accelerometers, RTCs etc.
AVR chips have no it's own support for wireless communication, therefore, to do that you need to use some external wireless chip, for example bluetooth, or WiFi, there are a lot of such modules (for example ESP8266). AVR chip communicate with them using USART, sending and receiving simple commands.
I am working on a project with the UART controls. I am attempting to simulate the sending and receiving of messages through the UART. The UART will be connected to a RS-485 transceiver in the real world but I will be providing the input/output through a test.c file.
Currently, I have to pause the execution of the program in the simulator, manually flip the bit and return the program back to execution again for the UART to send about byte.
My question to the group is can I auto-magically set the TXC bit to simulate a successful transfer of bytes? I am currently reading through Atmel's documentation and deciphering how to setup a stimuli file.
This would help out since I would like to make the communications testing more complicated the deeper I get with development.
Thanks,
Ryan
For me it is quite hard to understand your english...
set the TXC bit to simulate a successful transfer
On the real hardware you can't set TXC manually.
If you are talking about simulation environment, I only use http://www.nongnu.org/simulavr to do this kind of jobs. In this simulator you simply can add a c/c++-testprogram which runs on the host in the native host fashion and connect a simulated uart to the simulator which runs your avr program.
I currently have an embedded device connected to a PC through a serial port. I am having trouble with receiving data on the PC. When I use my PCI serial port card I am able to receive data right away (no delays). When I use my USB-To-Serial plug or the motherboards built in serial port I have to delay reading data (40ms for 32byte packets).
The only difference I can find between the hardware is the UART. The PCI card uses a 16650 and the plug/motherboard uses a standard 16550A. The PCI card is set to interrupt at 28 bytes and the plug is set to interrupt at 14 bytes.
I am connected at 56700 Baud (if this helps).
The delay becomes the majority of the duty cycle and really increases transfer time. (10min transfer vs 1 hour transfer).
Does anyone have an explanation for why I have to use a delay with the plug/motherboard? Can anyone suggest a possible solution to minimizing or removing this delay?
Linux has an ASYNC_LOW_LATENCY flag for the serial driver that may help. Whatever driver you're using may have something similar.
However, latency shouldn't make a difference on a bulk transfer. It should add 40 ms at the very start of the transfer and that's it, which is why drivers don't worry about it in the first place. I would recommend refactoring your transfer protocol to use a sliding window protocol, with a window size of around 100 packets, if you are doing 32-byte packets at that baud rate and latency. In other words, you only want to stop transmitting if you haven't received an ACK for the packet you sent 100 packets ago.
You'll probably find that different USB-Serial converters produce different results. We've found that the FTDI ones work well for talking with embedded devices. Some converters seem to buffer the data for a long time and/or fragment it.
I've never seen a problem with a motherboard connection - not sure what is going on there! Can you change the interrupt point for the motherboard serial port?
I have a serial to usb converter. When I hook it up to my breakout box and create a loopback I am able to send / receive at close to 1Mbps without problems. The serial port sends binary data that may be translated into ascii data.
Using .Net I set my software to fire an event on every byte (ReceivedBytesThreshold=1), though that doesn't mean it will.