I want to write LED blinking code in Forth. I have knowledge of the I/O peripherals address mapping of ICEstick or the Verilog code written for Mecrisp-Ice 0.8. When I open nucleus.fs - the heart of the J1 CPU, I find ": main" and below are the words "2emit" which are used to send characters Mecrisp-Ice 0.8 serially.
Should I write the LED blinking program in this section?
Related
I have a ZTurn board that mounts a Zynq 7020. In the PL part I have a programmed code in AXI4-Lite slave that contains the programming code of the part of interest that I need (VHDL).
In this block, when I send "start" in the PS I write '1' to slv_reg0(0) and I tell it to start capturing data; it would be capturing 32-bit data (1 every 2 MHz) that I want it to store in DDR memory from the PL part.
At the end of the capture process, when I send "stop" in the PS (writting '0' in slv_reg0(0)), what I want is to stop saving data in DDR memory and then begin the process of reading the data from the entire written memory in the main.c file
I know that to do this I need to implement some kind of DMA connection but I would like to know how to do it. My level of knowledge in this field is very limited and I can't find any tutorial that fits my exact needs.
What I want to know is what I have to change from my AXI4-Lite slave and where to put the VHDL code and how to write the data to the DMA block in different addess positions.
Thank you.
I'm using an ESP8266 NodeMCU 12-E development board to capture audio from a pre-amplified electret microphone, then I upload it to the web where it will be converted to a wav file. My first thought was to cast the integer values of analogRead(A0) on the ESP8266 as String type, then concatenate them into a longer string payload which I can publish to an MQTT broker.
My MQTT client subscribers didn't seem to be getting proper sound files, because all I heard were series of rhythmic pops.
I decided to investigate if my code on the ESP8266 board was even capturing things properly. I stripped the code down to these few lines which seem to cause problems:
#include <ESP8266WiFi.h>
const char *ssid = "____"; // Change it
const char *pass = "____"; // Change it
void setup()
{
Serial.begin(115200);
Serial.println(0); //start
WiFi.mode(WIFI_STA);
WiFi.begin(ssid, pass);
}
void loop()
{
int analog = analogRead(A0);
if (analog > 255) {
analog = 255;
}
else if (analog < 0){
analog = 0;
}
Serial.print(String(analog));
Serial.print(" ");
}
Here's how I use the code above to produce a wav file to check if the sound is what I expect:
- I start up the ESP8266 development board
- I turn on the Serial Monitor and clear all previous output
- I power up my electret microphone and speak into it
- I power down my electret microphone
- I copy the contents of the Serial Monitor (which is a series of integers) into a text file called `audio.raw`
- I copy `audio.raw` to a linux machine that has ffmpeg installed
- I issue the command `ffmpeg -f u8 -ar 11111 -ac 1 -i audio.raw -y audio.wav` on the linux machine
When I listen to the audio.raw file, I hear my voice, but the speed is maybe 5-10 times faster than normal. (I also get a lot of noise and distortion, but that might be a separate issue with the input signal quality.)
I then tried changing this one line of code Serial.print(String(analog)) to Serial.print(analog). Then I repeated the steps above. But this time, my voice sounds like it is about 2 times faster than normal.
Why does changing this one line from Serial.print(String(analog)) to Serial.print(analog) make such a big difference?
Is it because the String() function is a very expensive operation that takes up a lot of time? And when the script needs more time to process each line of code, the script then has less time to capture enough analogRead(A0) data points? And if I run the same ffmpeg command using all the same flags, then ffmpeg will try to meet the -ar 11111 requirement by speeding up the audio play? Which would imply that my sampling rate is dependent on execution speed of my script? Which means I have to consider variable execution speeds across other boards of the same model due to variability in manufacturing precision, environmental temperature, etc...?
Your sampling rate is coupled to your loop implementation (as you have discovered). This will also cause jitter in your sampling rate as different code paths will take different amounts of time and interrupt service routines will also steal CPU cycles.
This jitter will be one of the causes of distortion in your output.
When I listen to the audio.raw file, I hear my voice, but the speed is maybe 5-10 times faster than normal.
The ESP8266 has a hardware UART so the code can potentially load the UART's FIFO buffer faster than it can output. This would be a source of the perceived faster sampling rate but also cause jitter or data loss when the buffer fills up. Depending on the implementation, when the buffer fills it will drop data or alternatively block (causing jitter).
Why does changing this one line from Serial.print(String(analog)) to Serial.print(analog) make such a big difference?
Is it because the String() function is a very expensive operation that takes up a lot of time? And when the script needs more time to process each line of code, the script then has less time to capture enough analogRead(A0) data points?
Yes, yes and yes.
One of the reasons for the performance difference is that String() involves allocating and managing memory on the heap to store the characters.
Serial.print(analog) uses a fixed size buffer on the stack as the code knows the maximum number of characters required to display an int.
And if I run the same ffmpeg command using all the same flags, then ffmpeg will try to meet the -ar 11111 requirement by speeding up the audio play?
Yes. ffmpeg assumes that the samples have a fixed sampling rate but this does not match the samples that are being printed out.
Which would imply that my sampling rate is dependent on execution speed of my script?
Yes!
Which means I have to consider variable execution speeds across other boards of the same model due to variability in manufacturing precision, environmental temperature, etc...?
Yes. There will be a multitude of variables that affect execution speeds.
What can you do?
Decouple the sampling of data from the code execution.
This can be done by implementing an Interrupt Service Routine. Tie the ISR to a hardware timer so it executes at a fixed sampling rate and avoiding jitter.
The ISR can write to a buffer which the code in loop() transmits over the serial connection. The ISR and serial transmission code need to manage the buffer to ensure that neither overrun the other. One means of doing this is to use alternate buffers that the ISR and transmission code use.
Since you use Serial.begin(115200) ESP8266 Microcontroller will transfer 115200 bits per second through serial port. Which is 115200 / 8 = 14400 bytes per second and that means since you use u8 (unsigned 8 bit) format for audio, each sample consists of a single byte. Just change the ffmpeg -ar parameter to 14400.
I don't any have microphones which i can connect to MCU for testing but it should work properly this way. The other -ac parameter is correct since it is mono channel audio.
Edit : Also don't use String() constructor while printing out to Serial.
While using Serial() constructor sound speeds up about 5 times because String converts your 1 byte value to 3 bytes, example ; byte : 255 -> String : "2", "5", "5" , you don't have to consider execution speed of Microcontroller, it will output 115200 bits per second as if you defined. You just need to consider it's output.
Finally delete the line
Serial.print(" ");
Also change
int analog = analogRead(A0);
to
byte analog = (byte)analogRead(A0);
since int consists of 4 bytes, you would not want to send extra 3 bytes to serial.
And after changing int to byte you can get rid this code block
if (analog > 255) {
analog = 255;
}
else if (analog < 0){
analog = 0;
}
If you connect ESP8266 to linux device through usb which has ffmpeg on it you can use
ttylog -b 115200 -d /dev/ttyUSB0 | ffmpeg -f u8 -ar 14400 -ac 1 -i - -y audio.wav
to capture audio data in realtime from ESP8266.
From the topic of Memory Read Machine Cycle, I got an example of timing diagram for MVI instruction.
Again in another topic Memory Interfacing, the book shows timing diagram of Memory Read Cycle. Here 8085 provides two signals – IO/M(bar) and RD(bar) to indicate that it is a memory read operation. The IO/M(bar) and RD(bar) can be combined to generate the MEMR(bar) (Memory Read) control signal that can be used to enable the output buffer by connecting to the memory signal RD(bar). And the memory places the data byte from the addressed register during T2, & that is read by the microprocessor before the end of T2.
Why in this diagram there is arrow from IO/M to RD and from RD to MEMR?
Both the figure says Memory Read Cycle but there are some differences in the two timing diagrams in M2. Please can anyone explain when to use the first one and when to use the second timing diagram.
The arrow specifies that this line is the one that can be affected due to change in another line.
There are two types broadly:
1. Single line single effect (as in the opcode fetch cycle)
2. Multiple line single effect (as in the memory addressing)
As you can see in the opcode fetch cycle, whenever the Rd\ line changes, there is a change in the AD7 -AD0 lines. So this is a single line with single effect
And, in case of memory addressing, a change in Rd\ brings a change in MEMR\ which brings a change in AD7 - AD0 so it is a multiple line with single effect. I'm not sure why the arrow goes from Io/M\ line.
You might wanna look at the timing diagram of 8085 as a whole on the internet.
I'm trying to demodulate a signal using GNU Radio Companion. The signal is FSK (Frequency-shift keying), with mark and space frequencies at 1200 and 2200 Hz, respectively.
The data in the signal text data generated by a device called GeoStamp Audio. The device generates audio of GPS data fed into it in real time, and it can also decode that audio. I have the decoded text version of the audio for reference.
I have set up a flow graph in GNU Radio (see below), and it runs without error, but with all the variations I've tried, I still can't get the data.
The output of the flow graph should be binary (1s and 0s) that I can later convert to normal text, right?
Is it correct to feed in a wav audio file the way I am?
How can I recover the data from the demodulated signal -- am I missing something in my flow graph?
This is a FFT plot of the wav audio file before demodulation:
This is the result of the scope sink after demodulation (maybe looks promising?):
UPDATE (August 2, 2016): I'm still working on this problem (occasionally), and unfortunately still cannot retrieve the data. The result is a promising-looking string of 1's and 0's, but nothing intelligible.
If anyone has suggestions for figuring out the settings on the Polyphase Clock Sync or Clock Recovery MM blocks, or the gain on the Quad Demod block, I would greatly appreciate it.
Here is one version of an updated flow graph based on Marcus's answer (also trying other versions with polyphase clock recovery):
However, I'm still unable to recover data that makes any sense. The result is a long string of 1's and 0's, but not the right ones. I've tried tweaking nearly all the settings in all the blocks. I thought maybe the clock recovery was off, but I've tried a wide range of values with no improvement.
So, at first sight, my approach here would look something like:
What happens here is that we take the input, shift it in frequency domain so that mark and space are at +-500 Hz, and then use quadrature demod.
"Logically", we can then just make a "sign decision". I'll share the configuration of the Xlating FIR here:
Notice that the signal is first shifted so that the center frequency (middle between 2200 and 1200 Hz) ends up at 0Hz, and then filtered by a low pass (gain = 1.0, Stopband starts at 1 kHz, Passband ends at 1 kHz - 400 Hz = 600 Hz). At this point, the actual bandwidth that's still present in the signal is much lower than the sample rate, so you might also just downsample without losses (set decimation to something higher, e.g. 16), but for the sake of analysis, we won't do that.
The time sink should now show better values. Have a look at the edges; they are probably not extremely steep. For clock sync I'd hence recommend to just go and try the polyphase clock recovery instead of Müller & Mueller; chosing about any "somewhat round" pulse shape could work.
For fun and giggles, I clicked together a quick demo demod (GRC here):
which shows:
I have an Adafruit (Gemma) / Arduino and a Neopixel LED ring that I would like to control from World of Warcraft in-game events. This part is soldered and working.
Question:
Is there any way to send communications between World of Warcraft and some sort of listener on the PC that can then in turn send messages over USB to the Arduino/Gemma device?
My aim is to create an on-desk LED indicator e.g. if I'm a healer, then I want green/yellow/red light to represent the health of each raid/party member - so refreshes would be required at a high rate (0.5 / sec).
Thanks for your feedback in advance and welcome any future possibilities with the soon to be released Warlords of Draenor.
Is there any way to send communications between World of Warcraft and some sort of listener on the PC
Not directly via the WoW API. I came up with a way which I've never shared, because my usage broke Blizzard rules. But I haven't played in years, so here ya go. :)
I used an addon to create a one pixel frame in the top-left of the WoW window. I manipulated the color of this pixel to send data to the outside world.
The "listener" app can read this pixel with three Win32 calls:
HWND hwnd = FindWindow(NULL, "World of Warcraft"); // find WoW window
HDC hdc = GetDC(hwnd); // get the device context (graphics drawing abstraction)
COLORREF color = GetPixel(hdc, 0,0); // read the pixel at x 0, y 0
I then interpreted the bits of the color like this:
4: sequence number
7: checksum: (sequence + key code + ctrl + alt + shift + win)/6
8: key code or ASCII character
1: 1: virtual key code, 0: ASCII
1: CTRL key pressed
1: ALT key pressed
1: SHIFT key pressed
2: WINDOWS key pressed
The "sequence number" was just means of detecting that a new message had been posted to the pixel. The checksum was to prevent bogus reads when my special pixel was not active, like during loading screens. The rest was keystroke information. This allowed me to generate keystrokes from an addon. The entire watcher app is about 100 lines of C. Very simple.
I wrote an in-game script editor and used this with "pixelbot" to automate things in game. Towards the end of my WoW life I had more fun coding for Wow than playing it, which is saying a lot, because it's a fun game. :) One upon a time I knew everything there was to know about WoW addon programming, but I'm several years out of date now. I'll see if I can dig up some pixelbot Lua code for, though.
Anyway, you can adapt this scheme to send any messages you like. For instance:
4: sequence number
7: checksum (sequence + player number + LED color)/3
5: player number
2: LED color (0: green, 1: yellow, 2: red)
6: *reserved*
As for speed, I never actually measured it, but it blows away your 0.5 second requirement. At most a few milliseconds of latency between writes and reads.
that can then in turn send messages over USB to the Arduino/Gemma device?
That's just writing to the serial port in the "watcher" app and using Arduino libraries for read from the serial port inside your device.
I have source code for the "listener" app (pixel watcher) and for the WoW side stuff that writes message to the pixel. Let me know if you're interested and I'll help you out of band or dramatically increase the side of this post.
After some research, I did not found any built-in functionnality to signal/pipe/communicate with an external software. I believe it is due to the anti-bot blizzard policy. Actually you could do this with a memory watcher ( just like CheatEngine ), but there is chances you'll be banned for using this.
The only thing you could do if you can't find anything, is to ask on official forum, and hope a technic-friendly blue poster will answer =)
If you find anything, update your post, your idea is pretty interesting =)
There are only two ways to communicate with the game client without breaking the ToU:
Saving variables between sessions. Meaning that you can have an addon read and write to its storage file but this requires you to either relog or to /reload the UI for this file to be written to and read from. In short this wouldn't be so viable.
Have an addon use a tiny space on screen to write colors and use said colors to communicate with your external software by reading the pixels on screen.
There are many ways to achieve the second suggestion. You only need to be able to write this addon for the game. Then write an external program to read pixels. Sending commands back to the game would require hotkeys or sending it in the chat window.
Note that you are still limited to the API in-game that require hardware events. So for those you'd have to push a button or use the mouse to buypass.