I work with Zedboard and vivado v2017.3.
I have a custom IP in the PL part of zynq generating 32 bit values and stores them in one of the registers, say slv_reg0 (address : 0x43c00000).
In the PS part I read this register and I can print it in the gtkterm (simple one).
I now want to transmit these values over ethernet to to the PC.
Any suggestion on how to carry out this?
Thanks,
Upasana.
Xilinx supplies sample programs, one of these is an echo server. It should be quite simple to change it so that it serves the data you generate instead of just echo-ing the received message, and you can learn out of it how to use the lwip library in case you want a more suitable solution.
Related
Maybe I am asking the wrong question actually but I am just making my first steps in the embedded world. So I am sorry if the question is somehow stupid.
I am trying to program a software for 9DOF IMU in c++ and linux environment.
As far as I understood the SPI, the SS pin has to be low active in order for a transmission to occur. I have seen multiple reading or writing bytes function examples and all using the struct spi_ioc_transfer but they were all single slave examples and there is no mention about setting or configuring the SS in the code. Also When I check the structre of spi_ioc_transfer there is the cs_change however, how does it know which cs we are dealing with from the beginning ?
The chip select (CS or SS) to use is determined by which device node you open.
To talk to a SPI chip with the Linux spidev driver, you open a device such as /dev/spidev0.1. The numbers in the device node file name refer to the bus and chip select, respectively — in this example it would be the first bus (0) and the second CS (1). If you want to talk to devices on different chip-selects, you have to open different device nodes and do ioctls on the appropriate one.
I'm building a linux-based cashless device and trying to achieve communication with VMC in vending machines over UART directly without needing additional hardware adapter to convert between 8-bit and 9-bit frame data.
I'm only using the cashless device, no intention to connect any other peripheral to the VMC.
I read questions asked about this before, some of them stressed on the need to an adapter, others suggested possible hacks to achieve the 9-bit to 8-bit conversion, but still can't find a confirmed working and stable solution.
My question is, Is it possible (and reliable) to achieve this using a pure software solution? and how?
Thanks
Yes.
The 9th bit is a control bit. It will show if the data is to be interpreted as an address or as data. If you are communicating with one device and sending only data you want to strip the 9th bit out and only look at data frames. Check and see if it's always zero:
If controlBit = 0:
ProcessData(byte)
Else:
print("This is an address: " + byte)
EDIT:
Many people have reported that your connection will not be stable without special hardware due to timing problems.
Instead of reinventing the wheel you can use opensource code as a starting point.
https://github.com/mhaqs/vendiverse/wiki/Programming-the-VMC
This way you don't have to make the same mistakes over and over again.
I am trying to write a verilog code for FPGA which will output sound from the embedded "line out" pin. I use Quartus II and Altera DE1.
I am new to hardware programming, therefore it just takes too much time for me to catch up with basics. Apparently I need to initialize the wolfson chip and need to write something to communicate with it, as discussed here:
http://www.alteraforum.com/forum/showthread.php?t=6005
It uses wolfson WM8731 codec, manual is in here:
http://www.rockbox.org/wiki/pub/Main/DataSheets/WM8731_8731L.pdf
and an example I found but couldnt figured out how to use it is in here:
https://code.google.com/p/vector06cc/wiki/SoundCodec
I have found bunch of examples about how to generate sounds using GPIO pins, but barely anything about the usage of WM8731. I would really appreciate any guidance or experience you might share.
Assuming you're using Nios II and either SOPC Builder or Qsys, the Altera University Program offers an IP core to control the Audio CODEC on the DE-Series boards.
If you don't already have it, you can download it here (at the bottom of the page, listed as University Program Installer): https://www.altera.com/support/training/university/materials-ip-cores.html
Once you install it, check the <altera-directory>/University_Program\NiosII_Computer_Systems\DE1\DE1_Media_Computer directory. app_software and app_software_HAL both give example methods to write to the audio output (using C code running on the Nios II), and the verilog or vhdl folder show example systems on connecting the core to a NIOS II using your preferred HDL.
The core itself can be found in <altera-directory>\ip\University_Program\Audio_Video. See also ftp://ftp.altera.com/up/pub/Altera_Material/14.1/University_Program_IP_Cores/Audio_Video/Audio.pdf for some (potentially) helpful reading/reference.
Addendum:
All of the FPGA inputs and outputs use the "Digital Audio Interface" of the WM8731 chip. The pins available on the FPGA are as follows:
PIN_A6 : AUD_ADCLRCK
PIN_B6 : AUD_ADCDAT
PIN_A5 : AUD_DACLRCK
PIN_B5 : AUD_DACDAT
PIN_A4 : AUD_BCLK
PIN_B4 : AUD_XCK (MCLK on WM8731)
Output is sent to the CODEC on the AUD_DACDAT pin.
The chip is configured using the I2C_SDAT and I2C_SCLK pins on I2C address 0x34 for read, and 0x35 for write.
No other pins are available to the FPGA - some are used for external connections (like the mike or line-in), or are not connected at all.
For a full list of pin assignments for the DE1 (which can be directly imported to Quartus) see: ftp://ftp.altera.com/up/pub/Altera_Material/12.1/Boards/DE1/DE1.qsf
Does anyone know of a good way to get a bi-directional dump of MIDI SysEx data on Linux? (between a Yamaha PSR-E413 MIDI keyboard and a copy of the Yamaha MusicSoft Downloader running in Wine)
I'd like to reverse-engineer the protocol used to copy MIDI files to and from my keyboard's internal memory and, to do that, I need to do some recording of valid exchanges between the two.
The utility does work in Wine (with a little nudging) but I don't want to have to rely on a cheap, un-scriptable app in Wine when I could be using a FUSE filesystem.
Here's the current state of things:
My keyboard connects to my PC via a built-in USB-MIDI bridge. USB dumpers/snoopers are a possibility, but I'd prefer to avoid them if possible. I don't want to have to decode yet another layer of protocol encoding before I even get started.
I run only Linux. However, if there really is no other option than a Windows-based dumper/snooper, I can try getting the USB 1.1 pass-through working on my WinXP VirtualBox VM.
I run bare ALSA for my audio system with dmix for waveform audio mixing.
If a sound server is necessary, I'm willing to experiment with JACK.
No PulseAudio please. It took long enough to excise it from my system.
If the process involves ALSA MIDI routing:
a virtual pass-through device I can select from inside the Downloader is preferred because it often only appears in an ALSA patch bay GUI like patchage an instant before it starts communicating with the keyboard.
Neither KMIDIMon nor GMIDIMonitor support snooping bi-directionally as far as I can tell.
virmidi isn't relevant and I haven't managed to get snd-seq-dummy working.
I I suppose I could patch ALSA to get dumps if I really must, but it's really an option of last resort.
The vast majority of my programming experience is in Python, PHP, Javascript, and shell script.
I have almost no experience programming in C.
I've never even seen a glimpse of kernel-mode code.
I'd prefer to keep my system stable and my uptime high.
This question has been unanswered for some time and while I do not have an exact answer to your problem I maybe have something that can push you in the right direction (or maybe others with similar problems).
I had a similar albeit less complex problem when I wanted to sniff the data used to set and read presets on an Akai LPK25 MIDI keyboard. Similar to your setup the software to setup the keyboard can run in Wine but I also had no luck in finding a sniffer setup for Linux.
For the lack of an existing solution I rolled my own using ALSA MIDI routing over virmidi ports. I understand why you see them as useless because without additional software they cannot help at sniffing MIDI traffic.
My solution was programming a MIDI relay/bridge in Java where I read input from a virmidi port, display the data and send it further to the keyboard. The answer from the keyboard (if any) is also read, displayed and finally transmitted back to the virmidi port. The application in Wine can be setup to use the virmidi port for communication and in theory this process is completely transparent (except for potential latency issues). The application is written in a generic way and not hardcoded to my problem.
I was only dealing with SysEx messages of about 20 bytes length so I am not sure how well the software works for sniffing the transfer of large amounts of data. But maybe you can modify it / write your own program following the example.
Sources available here: https://github.com/hiben/MIDISpy
(Java 1.6, ant build file included, source is under BSD license)
I like using aseqdump for that.
http://www.linuxcommand.org/man_pages/aseqdump1.html
You could use virtual midi devices for this purpose. So you have to load snd_seq_dummy so that it creates at least two ports:
$ sudo modprobe -r snd_seq_dummy
$ sudo modprobe snd_seq_dummy ports=1 duplex=1
Then you should have a device named Midi through:
$ aconnect -i -o -l
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0:A'
1 'Midi Through Port-0:B'
client 131: 'VMPK Input' [type=user,pid=50369]
0 'in '
client 132: 'VMPK Output' [type=user,pid=50369]
0 'out '
I will take the port and device numbers form this example. You have to inspect them yourself according to your setup.
Now you plug your favourate MIDI Device to the Midi Through ports:
$ aconnect 132:0 14:0
$ aconnect 14:0 131:0
At this time you have a connection where you can spy on both devices at the same time. You could use aseqdump to spy the MIDI conversation. There are different possibilities. I suggest to spy the connection between the loopback devices and the real device. This allows you for rawmidi connections to the loopback devices.
$ aseqdump -p 14:0,132:0 | tee dump.log
Now everything is set up for use. You just have to be careful about port names in your MIDI application. It should read MIDI data from Midi Through Port-0:B and write data to Midi Through Port-0:B.
Some additional hint: You could use the graphical frontend patchage for connecting and inspecting the MIDI connections via drag and drop. If you do this you will see that every Midi Through port occurs twice once as input and once as output. Both have to be connected in order to make this setup work.
If you want to use GMidiMonitor or some other application you spy on both streams intermixed (without showing the direction) using aconnect suppose 129:0 is the Midi Monitor port :
$ aconnect 14:0 129:0
$ aconnect 132:0 129:0
If you want to have exact direction information you could add another GMidiMonitor instance that you connect only to one of the ports. The missing messages come from the other port.
What about using gmidimonitor? See http://home.gna.org/gmidimonitor/
How do I send a string output from a DAQ Board (NI- USB 6259) using LabVIEW? I want to send commands such as "CELL 0" or "READ" to a potentiostat device using LabVIEW.
Thanks
The 6259 doesn't do string output. It's a data acquisition board that's intended for reading/sourcing analog voltages or sending/receiving individual digital signals. It's not a communications device.
If you're really trying to send strings to this device, you probably need something more like an RS-232 or GPIB connection.
As eaolson said a DAQ is not intended to control devices. However it is an interesting project to enter the guts of the communication protocol. Doing it with a DAQ would require to:
Identify the protocol (GPIB or RS-232)
Make your cable from the DAQ output connector
For each command, generate the waveform in LabVIEW, by using the letters' ASCII code, stop bits, etc. This is the funniest part (INMHO, but I understand it's not everybody!)
Send it (using DAQ analog write VIs, you should find many examples for this)
The oscilloscope will be your best friend