I'm attempting to read digital signals as short as 0.5 microseconds. I think this may be impossible. Am I right?
No, you can do that with micros() -- in the same fashion that you would millis().
You have given the length of the pulse, but not how far apart they are.
Depending on your actual application, you could probably do this with one of the timers... but as @Paul_KD7HB says, you don't give the repetition rate.
In theory with a RA4M1 processor in a totally minimal code loop one could just about see a pulse that short - maybe - but the code loop would be just doing that, and it would effectively have the processor locked up.
With a 600MHz Teensy 4.x on the other hand you can run interrupts at up to 5MHz, with time to do lots of twiddling. Your USB serial might not work though!
I'm trying to decode various signals between two boards that use a proprietary communication protocol. I may be able to use a different line that uses longer pulses. Is there a hardware counter available? It would be very helpful if I had a simple example of using this counter. I get lost in the source code and the RA4M1 user manual and I don't know where to start.
If a positive pulse is a 1, what will the pulse be for three ones? Or if communicating four zero bits in a row, how will you determine the number of zeros? Does your communications use any start and stop bits?
I guess I should add that any Arduino can read ANY pulse because the rising voltage is what identifies a pulse. So, there is no limit to the shortness of a pulse.
Now if you are looking for the width of a pulse, that is a totally different question and is not what you asked about.
How far apart are these two boards? The capacitance of a cable longer than a meter or so is likely to swallow such a small pulse. You are best using differential signals to transmit and receive short pulses.
Here is an example waveform. These signal groups repeat every 16.8 ms. The group always starts with 7 - 500 ns pulses on D0 and 7 - 16 us pulse width on D1. I've tried a wide variety of decoders for example UART, I2C, SPI. Nothing seems to match. Each group starts with 7 pulses on both D0 and D1, so that's the start of the frame.
I counted the pulses and discovered a correlation between the number of pulses on D0 (the 500 ns pulses) and the data I need, which is why I asked the original question. Then I discovered that the number of pulses on D1 also seems to be unique for each datapoint, so I thought I would start there.
If I can count the number of pulses on D1 and the time in microseconds each occurs after the 7 framing pulses, then I think I'll have the information I need. Part of this exercise is to learn how to program the R4, in particular the timers and counters.
It would be helpful if I could understand the commands and syntax to count pulses using a hardware counter.
Thank you for the picture of the scope trace. BUT!!!! you also need to count the spaces between the pulses. Notice how the space varies across your picture. To do that you need to know the clock timing of the communication. Are there other places where a clock signal is present?
There is no clock! There are only two lines with data. I checked and double-checked several times. If I can determine the delay in microseconds between the end of the framing pulses and the start of each pulse on the lower signal, and the total number of pulses, I think that will be sufficient.
Then you will have to supply the clock and synchronize it with the signal. Half of your data is in the length of the pulses and the other half is in the time of the space between the pulses.
Couldn't I count 7 pulses to mark the start of the frame and then measure the start of each pulse after that? What are the commands to use a hardware counter on the R4? It's different than other UNO models, and although the info is available in the user manual, I'm having a hard time interpreting it. A simple example would be most useful to me, and others who find this thread in the future.
You tell me! How do you know there is a frame? Why not tell us what is sending the signal? Do you have documentation for that device?
My take on this - Your upper trace is your clock, the lower trace is your data. The clock is only changing state during data transmission, is what's confusing the issue.
No, there is no documentation for this device unfortunately. I know the initial 7 pulses are the start of the frame because I've examined thousands of traces.
That's what I thought too initially, but the only consistent pulses are the first 7. The others vary in timing after the 7 framing pulses.
Ok, the mystery device MUST have a clock to time the pulses and you will need a similar clock to decode the signal. Measure the total time for the 7 pulses and the time between the pulses and divide by 7 or divide by 8 if you include the space after the last pulse. That will give you the clock timing for the signal. That will also give you the Baud rate you need.
Great! Now I just need to understand how to use hardware counters on the R4. How to initialize a counter and how to use it to count pulses. Are the hardware counters defined in the FspTimer class, for example "uint32_t get_counter();" ?
This link has lots about counters.
By the way does this mystery device have a name? Or a link to where you bought it from.
At the very least you could post a photograph of it.
Yes I have that code running on an R4 and I'm attempting to modify it to count pulses. Any tips would be much appreciated!
This is the internal communication between the main board and the user panel for my hot tub. The communication appears to be proprietary. The hot tub has no programmability or intelligence. Sometimes it heats during the day when my power costs as much as 84 cents per kw/hr. That's not a typo! If I can make this work then the hot tub will only heat during times of the day when the power is cheapest.