I am trying to learn how to debug an MCU non-intrusively using SWD & openOCD.
while (1)
{
my_count++;
HAL_GPIO_TogglePin(LD2_GPIO_Port,LD2_Pin);
HAL_Delay(750);
}
The code running on my MCU has a free running counter "my_count" . I want to sample/trace the data stored in the address holding "my_count" in real time :
I was doing it this way:
while(1){// generic algorithm no specific language
mdw 0x00000000200000ac; //openOCD command to read from an address
}
0x200000ac is the address of the variable my_count from the .map file.
But, this method is very slow and experiences data drops at high frequencies.
Is there any other way to trace the data at high frequencies without experiencing data drops?
I made some napkin math, and I have an idea that may work.
As per Reference Manual, page 948, the max baud rate for UART of STM32F334 is 9Mbit/s.
If we want to send memory at the specific address, it will be 32 bits. 1 bit takes 1/9Mbps or 1.111*10^(-7)s, multiply that by 32 bits, that makes it 3.555 microseconds. Obviously, as I said, it's purely napkin math. There are start and stop bits involved. But we have a lot of wiggle room. You can easily fit 64 bits into transmission too.
Now, I've checked with the internet, it seems the ST-Link based on STM32F103 can have max baud rate of 4.5Mbps. A bummer, but we simply need to double our timings. 3.55*2 = 7.1us for 32-bit and 14.2us for 64-bit transmission. Even given there is some start and stop bit overhead, we still seem to fit into our 25us time budget.
So the suggestion is the following:
You have a timer set to 25us period that fires an interrupt, that activates DMA UART transmission. That way your MCU actually has very little overhead since DMA will autonomously handle the transmission, while your MCU can do whatever it wants in the meantime. Entering and exiting the timer ISR will be in fact the greatest part of the overhead caused by this, since in the ISR you will literally flip a pair of bits to tell DMA to send stuff over UART # 4.5Mbps.
I'm using a Mediatek MT3333 GPS receiver (baudrate: 115200 bpS), but all I'm getting is this:
b'$GNGGA,132002.448,,,,,0,0,,,M,,M,,*5C\r\n'
b'$GPGSA,A,1,,,,,,,,,,,,,,,*1E\r\n'
b'$GLGSA,A,1,,,,,,,,,,,,,,,*02\r\n'
b'$GPGSV,1,1,00*79\r\n'
b'$GLGSV,1,1,00*65\r\n'
b'$GNRMC,132002.448,V,,,,,0.00,0.00,100417,,,N*5A\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N*2C\r\n'
After some research I found that my receiver doesn't have a fix, any idea how to solve this?
It looks that the received signal strength is low so that your GPS receiver mode doesn't get a GPS FIX. It would be better to place the device outdoor to verify if there is a stable reception.
From the GPS sentences showed above, your Mediatek MT3333 GPS receiver output modified NMEA 0183 Sentence. All the standard sentence should started with $GP as the suffix and with format of $GPaaa, where aaa is alphabetic.
For instance,
b'$GNRMC,132002.448,V,,,,,0.00,0.00,100417,,,N*5A\r\n' should be read as
$GPRMC,132002.448,V,,,,,0.00,0.00,100417,,,N*5A if conforms to NMEA. This sentence tells that at 2017-04-10 12:30:02 (GMT) got no GPS fix with speed at 0 knot and course at 0 degree.
If the output of your GPS receiver conforms NMEA, you can use some free software, such as VisualGPS, to evaluation the GPS signal quality.
If possible, suggest to change the GPS antenna to external one, an active GPS antenna with 2-stage amplifier at around 28dBm gain, to improve the GPS signal reception in order to get a stable fix.
From the datasheet of Mediatek MT3333, it did mention below for improving GPS signal reception:
An external antenna and high gain external LNA connected to the
internal LNA in low-gain mode, which offers high linearity. In this
configuration, external LNA gain ranging from 15 to 20 dB is
recommended. The maximum total external RF front end gain including
active antenna and external LNA can be 43dB.
Hope this help.
I really want to make use of the SPI module on my NodeMCU. SPI keeps my code clean and frees up some of my GPIO pins. I feel it is sending data too fast for my 74HC595 to keep up with. It was working for a bit, then stopped.
It seemed like there was a lot of noise on the line so I hooked up the logic analyzer and saw that when I was sending data, bits were flying across the line at almost 6 ns (which is awesome). I am driving a 595 and ultimately a stepper, that need data at a way slower rate. I have tried using the clock parameter in the setup call, I feel it never slows the SPI clock.
Is there any way to set the clock speed to something that would be more 595+stepper friendly?
Just looking at the docs in the most recent dev branch of NodeMCU (get it from the NodeMCU Build website) you can setup SPI with a divider to lower the data rate of the SPI transmissions (higher div, lower bit rate):
spi.setup(id, mode, cpol, cpha, databits, clock_div[, duplex_mode])
Parameters include:
clock_div - SPI clock divider, f(SPI) = f(CPU) / clock_div
Im currently creating a satellite ground station which will be used to control our cubesat in coming months. The modulation scheme used is GFSK and the baud rate is 9600. I have tried to run some tests by using a USRP board before I could try to communicate with the satellite by directly connecting the tx and rx blocks in the flowgraph.I was able to send and receive a png file using this flowgraph.
However, when I connect the tx and rx output to my USRP B210 TX/RX(transmission sink) and RX2(reception source) as shown below, I receive no data even though the two the source and sinks have been connected to each other carefully by RF cables with attenuators.
Below are the assumptions I took into account when I was making the second flowgraph. Please tell me if im on the right path.
Transmitter side : The packet decoder and GFSK mod blocks use 20 samples per symbol. Baud rate is 9600 and sample rate is 20*baud rate = 192K. Since the expected symbol rate by the satellite is baud_rate = 9600, I included a rational resampler and set UHD symbol rate to baud_rate. Is my logic correct?
GFSK mod and demod : For both of these blocks, I calculated sensitivity as S = Pi * Modulation_index/Samples_Per_Symbol. The default BT value of 0.5 is used. Are my calculations sound? Is there a link for to find documentation for GFSK blocks? My derivations are based on the GFSK python source code which is a poor substitute for documentation.
Packet Encoder/Decoder : The output of packet decoder is null even though the GFSK demod block give some kind of output which is rather meaningless. Is this normal? What is the meaning of the threshold variable and why its value is -1?
I'm a newbie in GNU Radio as well as GFSK in general. So please drop me any further references.
Thanks in advance.
Moses.
I was finally able to solve the problem. All I did was re-implementing the GFSK demod in GRC. If you go into source of gfsk.py, you will find out that the blocks used are Quadrature Demod --> M&M Clock recovery --> Binary slicer which can easily be connected in GRC directly. As Marcus suggested in my other thread, GFSK demodulation with Xlating filter in GNU Radio , I replaced the M&M Clock recovery block with PFB block. My flowgraph is shown below.
Even if I can not answer all of your questions, I provide below some thoughts:
When using hardware devices the Throttle MUST be removed from the flow-graph. The hardware device is now responsible for the rate limiting. Mixing hardware device and the Throttle block may break the real-time boundary of your flow-graph required by the device. Underflows or Overflows messages should be produced by the UHD driver in such a case.
Are you sure that the USRP can support the requested sampling rate? You may need also to change the master_clock_rate of the device, if the requested sampling rate is not an integer decimation of the clock. If this is not possible consider some kind of re-sampling.
EDIT: The B200 can not provide 192e3 sampling rate with the default clock. You can set the master_clock_rate at 19.2e6. The hardware will apply then the proper decimation. The master_clock_rate can be changed either by the device specific arguments or the Clock Rate field of the UHD Sink/Source blocks that presents in the latests GNU Radio versions.
Hi Im using the following RF module
http://www.apogeekits.com/rf_receiver_module_rx433.htm
on an embedded board with the PIC16F628A. Sadly, I realized that the signal strength was in analog form and couldn't get any ideas to get the RSSI reading off the pin because well my PIC is digital DUH!.
My basic idea was
To get the RSSI value from my Receiver
Send it to the PIC
Link the PIC to a PC via RS232
Plot a graph of time vs RSSI of the receiver (so I can make out how close my TX is to my RX)
I thought it was bloody brilliant at first but ive hit a dead end here. Any ideas on getting the RSSI data to my PC from this receiver would be nice.
Thanks in Advance
You can get a PIC that has an integrated ADC for sampling the analog signal. Or, you can use an external ADC chip to do the conversion. You would connect that to your PIC using SPI or I2C.
The simplest thing to do is obviously to use a more appropriate microcontroller - one with an ADC! There are many (most), including PICs (though that wouldn't be my first choice).
Attaching an external SPI or I2C ADC might be a bit tedious since having no SPI or I2C on your part, you'd have to bit-bash it. If you do that, use an SPI part - its simpler. Your sample rate will suffer and may end-up being a bit jittery if you are not careful.
Another solution is to use a voltage controlled PWM, then use the timer input capture to time the pulse width. That will give you good regularity and potentially good resolution. You can get a chip (example) to do that, or grow your own. That last option requires a triangle wave input as well as the measured (control) voltage, but on the same site...
In a similar vein, you could use a low frequency VCO (example) and use the output to clock one of the timers, then using a second timer periodically sampling the first and reset it. The count will relate to the voltage, though not necessarily a linear relationship, linearisation could be none on the PIC or at the receiving PC - I'd go for the latter - your micro will suck at arithmetic (performance wise) - even integer arithmetic, especially if it involves division.