I would like to read a pin at high speed...

LeafLabs Garden » Support » Maple Hardware Support

I would like to read a pin at high speed...

(30 posts) (4 voices)

Started 5 years ago by Skids
Latest reply from gbulmer

12 Next »

Skids
Member

Hi all,
I am new to the Maple and only have limited experience with an Arduino so I am seeking guidance on how to read a digital pin at high speed.

I asked a question before I ordered my Maple board and Andrew Meyer replied with "While the ADC maxes out at 1MHz on Maple, you should be able to read your comm line on digital pins which max out at 50MHz, although it takes some effort to run it that fast."

I am hoping to write a Manchester Decoder designed to decode a signal that is clocked at 1 Mhz.

Where can I find details of "the effort" mentioned by Andrew and how should I tackle this project?

Thanks
Simon

Posted 5 years ago #
gbulmer
Moderator

Skids - Have you got access to hardware debugging, like JTAG? Have you access to an oscilloscope? They will help a lot to test and debug the system.

Do you have to decode the signal in software, or can you use some of the Maples hardware?

I guess I am asking, is this a course work or project for 'school' with some artificial constraints, which demand that it is a software only solution, or can you use every piece of the Maple?

What do you need to do with the signal? That might be the biggest constraint.

It is pretty straightforward to convert from the Maples Arduino-like library functions to direct hardware access. There are documents at ST.com which explain it, and there are bits of source code in Maplelib which illustrate how to do it. (The Maplelib documentation explains how to get the maplelib source from github). Have a look at digitalRead, and trace it through. It ends up being a memory read.

I have done some simple benchmarks, and 12MHz digital output is just doable in software (can go faster, but their are more constraints), so I'd expect a few MHz input would be feasible in pure software. If it's okay to use the timer hardware, then I think it gets more feasible.

Posted 5 years ago #
poslathian
LeafLabs
heres a short primer on manchester decoding:

http://www.eetimes.com/design/programmable-logic/4007510/Back-to-the-future-Manchester-Encoding--Part-2

There are a few ways to go about this, the first is the easiest, the second we dont quite have library support for yet (DMA on GPIO), and the fourth I think is the best.

1) sample the pin as fast as you can and decode it later.
- with this method you just use a while loop to read from the pin as quickly as you can. My guess would be that this is ~10MHz maybe 18. Since your signal bandwidth is 1MHz, thats cutting things a little tight, especially if you end up sampling at 5 or 6 MHz instead of 15 or 18. Anyway, ignoring when and for how long you should sample the pin for, you could stash your reads in a buffer, and then decode your signal later like this:
```
uint32 buf[NUM];
   int i = 0
   while (i < NUM) {buff[i] &= digitalRead(pin) << (i%32)}

   // now do something with your buffer to decode the data
```
because you arnt doing anything during your buffer fill period, this is probably not very practical, the trick with the bit shifting is just so you can store 32 digitalReads in a single 32 bit memory word, rather than waste bytes on single reads.

2) USE DMA, dma lets you automatically sample a peripheral or location in memory, and copy the result into some buffer while you are off doing other things. This is essentially the same as the above, except solving the practicality problem. Since we dont have the API for DMA+GPIO out yet, I'll leave this one open

3) Use a timer to rapidly sample your GPIO
Setup a timer to interrupt really quickly, and capture the GPIO in its interrupt routine. Since youre sampling really fast, say 10MHz, this method is almost certainly going to result in your program being stuck in the interrupt routine the whole time. Yuck.

4) Finally, the good answer:
Setup the GPIO to externally interrupt on transitions. Setup a timer to just tick off every clock cycle (72MHz). In your external interrupt ISR, record the current timer count value into a buffer.
- this is the best method because A) youre getting ~50MHz resolution instead of 5 or 15 MHz when sampling your signal. B) you only run the interrupt every transition (so every 1MHz) so you might actually be able to get out of the ISR in time before the next one (you wont get stuck in the interrupt). C) you can be constantly decoding your signal, by reading the values out of your timing buffer, in your main program (outside of your interrupt).

In terms of code samples for this last one, if you need a boost Ill can show you how to setup the external interrupts and the timer, but everything you need should be in the docs - except for external interrupts which need to be added (to the docs, their already in the library), but should be arduino compatible.
Posted 5 years ago #
mbolivar
LeafLabs

external interrupts are documented here:
http://leaflabs.com/docs/maple-ide/external-interrupts/

Posted 5 years ago #
gbulmer
Moderator

Skids - what does the input look like?
Is it a fixed number of bits, or a small number of bits?
Is there a big gap (silence) between data 'packets', with plenty of time for the data to be used/processed?

My experiments wiggling output pins, showed 12MHz was the fastest practical speed (executing from Flash).
That was:
- 2 cycles to update a pin to 1
- 2 cycles to update a pin to 0
- 2 cycles for the while(true) loop

A for loop would make this slower, and any tests on the data would make it slower still.

I would suggest at 1MHz, sampling in software, and deducing something about the signal is not a good way to go.

But you could try option 1 at low speed to get a feel for the approach.

Option 3
As poslathian said, it will be very hard to make it work using interrupts to trigger sampling, just because it will consume quite a lot of time bouncing in and out of an interrupt.

Any approach using interrupts to directly capture the pin value will consume quite a lot of processor cycles, and runs the risk of losing information if other interrupts are happening. You'd need to switch off the USB and underlying timer interrupt (systick).

I can't seem to find the right document page, but AFAIK, the minimum interrupt response time on the STM32F, is an optional 1 instruction depending on when the input to the GPIO happened, 6 cycles to stack registers and start using the interrupt handler (I assume worse if it uses attach interrupt), and 6 to return from the interrupt.
So worst case, almost 14 cycles, normally 12.
So that would be a maximum sample rate of 6MHz, ignoring the cost of doing anything with the data. Of course, 5 times out of 6, the data will not have changed!

In the interrupt handler, I'm assuming it doesn't have to figure out which pin, as it is the only thing hanging on that port. If that assumption is incorrect, it will get much slower.

An interrupt routine will need to have some state in memory, which gets updated, so 4 cycles per variable, plus time to do an operation on the variable.

So I don't see it being much shorter than 20 cycles/interrupt, and easily much slower, so 3.5MHz would be the maximum sample rate. Clearly it might get damaged if there were another event, like the system clock, or USB, which caused it to miss a signal transition. If it missed two transitions, then it would be harder still.

Option 4
I think the 4 is not as easy as it sounds because a different interrupt could cause a bit to be dropped.

I assume the input capture pin would be used, and so the resolution could be full clock speed, i.e. of 72MHz.

Option 5
IMHO, a better way than 4 is to have the timer channel 'capture' the timer clock when the external signal edge transitions. This gets a reasonably stable value and doesn't depend on the interrupt service routine (ISR) timing to get the clock time.

An ISR needs to be triggered when the signal transition time is captured, so it is only triggered at roughly 1MHz. The ISR copies the value from the channel's capture register to memory, or even decodes it there and then. The ISR resets the clock ready for the next signal transition.

If you are very careful, you may get this to run continuously, i.e. there is no need to have any 'silence' when no signal is being received. I am SWAGing, but maybe it'll consuming about 50% of the processor cycles, or maybe less.

Option 6
A merging of option 5 and option 2
Use DMA to store the times captured by the timer channel, into memory, and process them in the main loop. I'd need to look to see that the DMA can reset the timer, but if it can, then many edges can be captured without spending cycles on a per/transition interrupt. This depends on understanding how to use DMA and the timers properly, which is quite intricate on the STM32F.

Without hardware help, debugging it will be hard, so start off with a slow signal, and measure.

Posted 5 years ago #
Skids
Member

gbulmer
The answers to your questions are as follows:
No I don't have access to Hardware debugging or JTAG, neither do I have an oscilloscope but I do have a cheap logic analyser and I don't mind investing in equipment if there is a chance that it will help me my goals. These are to first decode then possible encode a specific Manchester encoded data stream. I can purchase dedicated hardware devices that do the job but they are very expensive being somewhere in the three to seven thousand pound range. This is not a school project so I am free to use what ever I can afford.

You ask what I what to do with the signal, well initially I wish to just decode the data and my thoughts are to have the Maple decode the data and pass the data elements up to a host computer where the data is written to file and decoded into man readable form. Later I would like to transmit data as well (which is what the expensive interface cards do). Ideally I would like to have one Maple do everything but a second Maple could be used. I should say that the data of interest is running on a 1553b data bus which is configured to have one Bus Controller and a single Remote Terminal. My ultimate aim is to write some test software that is capable of controlling the remote terminal via the 1553b data bus.

My big problem is that I do not have much idea what I'm doing (you can tell can't you!), I have not touched any electronics since the 1970s when the OC71 or BC109 (from memory) were as complex as it got. Earlier this year I played with an Arduino and built a working device to display speed up/down commands to a rally driver friend of mine based on distance gone sourced from a hall sensor. I enjoyed playing with the micro controller and wondered if they could be used to decode my data. I have looked at using FPGA but I don't have any clue where to start with assembling gates to solve a computational problem, then I found Maple and though that it might have the horse power to do the decoding. I have two Rev 3 boards and I hope to use one to provide a 1Mhz test signal and the second to do the decoding.

Last night I tried switching a Maple pin on and off and monitoring it with my Logic Analyser. The best speed was in the region of 800khz to 1.2 Mhz which is why I posted my question.

Thanks poslathian for the 4 methods and the pointer to the primer, I would like to accept your offer of a boost - any help is gratefully received and thanks also to mbolivar for the link to the documentation about external interrupts. I am keen to learn but I need these pointers to where I should be placing my attention.

At least none of you have said don't be so silly and you have given me some sound starting points plus possibly the excuse to buy an oscilloscope.

best wishes and thanks
Simon

Posted 5 years ago #
Skids
Member

gbulmer, Our last posts crossed. The description of the data taken from the designers handbook is "1553 requires each word to consist of 16 bit of data plus, a sync pattern (3 bit times long), and a one bit parity providing a 20 bit word format"

These are the data words which are fixed at 20 bits but the number of words sent at any one time is variable with a minimum of 18 data words every 20 milliseconds. The device I am dealing with requires 4 milliseconds in every 20 for house keeping. This period of silence extends if the amount of data flowing reduces.

"Without hardware help, debugging it will be hard, so start off with a slow signal, and measure." By hardware help do you mean a dedicated chip or something else?

I'm getting a strong feeling that this is just a bit to much to ask of the card and me especially as it is my first project.

best wishes

Simon

Posted 5 years ago #
gbulmer
Moderator
skids - I think it is completly feasible.

As you remember what a BC109 was, and have used a Hall sensor with an Arduino timer then you likely know enough electronics to get this working. Further, you know how to use a logic analyser to measure frequency, so you may be over qualified :-)

Some observations and answers

The device I am dealing with requires 4 milliseconds in every 20 for house keeping. This period of silence extends if the amount of data flowing reduces.

Maple can do a lot of processing in 4 milliseconds. So even if all that can be done while the signal is arriving is to "catch the edges", I think there is time to decode.
Further, even if the signal was continuous data for 16milliseconds, and you use the option 5 I suggest, it is only 16,000 bits, so if there is a small amount of processing on each transition (to reduce data volume), I think it is feasible to buffer it all in RAM.

These are the data words which are fixed at 20 bits but the number of words sent at any one time is variable with a minimum of 18 data words every 20 milliseconds.

18 data words is a lower bound, but 18words x 20bits, at 1MHz, is only 0.36 milliseconds (360uS) in 20 milliseconds (20,000uS). So even if the signal was 10x more data, it would still be less than 20% of the time available.

It would be very helpful to characterise the worst case, largest volume, of data, as that will give a clue how hard the final solution might look.

(I am a big fan of Pareto's 80:20 principle, so when (what appears to be) the biggest part seems to shrink to under 20% of the available resources I tend to believe the solution is feasible (of course, I might be wrong 20% of the time :-)

"Without hardware help, debugging it will be hard, so start off with a slow signal, and measure." By hardware help do you mean a dedicated chip or something else?

A normal, low-end, analogue oscilloscope would be fine (20MHz bandwidth is about as low as they go). Dual trace would let you see what is happening quite well.

What country do you live in? My experience is you can pick up a second hand CRT-based analogue oscilloscope quite cheaply (under 40 GBP on eBay) if you have the time to wait.

Last night I tried switching a Maple pin on and off and monitoring it with my Logic Analyser. The best speed was in the region of 800khz to 1.2 Mhz which is why I posted my question.

Yes, that's about right.
The program probably looked like:
```
void loop() {
  digitalWrite(13, HIGH);
  digitalWrite(13, LOW);

}
```
or
```
void loop() {
  while (1) {
    digitalWrite(13, HIGH);
    digitalWrite(13, LOW);
  }
}
```
There is a lot of code in the digitalWrite(...); to make sure everything works properly.
You can write directly to the pin, and get 12MHz and more.

The pin has an address in memory; write to it, and it flips. That transition will happen at about 36MHz, hence 2 transitions 18MHz, plus the overhead for a loop.

If you use some variation of the technique I suggest in option 5, then the hardware detects the change of state, and times it. An interrupt is triggered for your code to retrieve the value.

IMHO, none of poslathians four options will be as solid as using a timer (or two) to do the work. I think those approaches are better for asynchronous signals, or ones where the clock is unknown or drifting a lot, but I don't think this is a "sampling a signal problem", which is the flavour of those four options. IMHO, it is decoding edge times, and the edges happen at quite precise times (that's a feature of Manchester encoding). So let the encoding work for you.

EDIT: D'oh! I'm an iDiot.
I think it may be even simpler, because there are leading synch pulses.
Is there are proper spec. on the Internet, where I can look at the definition of the signal-level protocol?
Posted 5 years ago #
gbulmer
Moderator

I read the wikipedia page http://en.wikipedia.org/wiki/MIL-STD-1553

It says "The combined accuracy and long-term stability of the bit rate is only specified to be within ±0.1%" (± = +/-)
So, doing this with timers should be fine; there should be no need to oversample the signal. The tutorial at EE times is intended for a more complex situation than I have understood you need to solve.

It was less clear to me whether the signal is exactly 'true', or exactly 'false' in the halves of the clock cycle. It isn't a big deal, as all the bits in the data word can be inverted with a single instruction.

Strategy
Sample the signal pin at a specific point in the cycle, every 1uS, and put the value into memory. That's it.

The value of every bit is stable both before and after the 'mid cycle' transition of the Manchester encoded signal, and the level represents the bit value (true or inverted).

The complication is to sample at the right point in the signals' cycle.

The 'trick' is to use the synch transitions to set a timer to trigger at the right place in the signal. The signal needs to be sampled at a consistent point, every 1uS. It should be well away from the transitions so that there are no errors. Sample at 1/4 or 3/4's of the way through the cycle to keep as far away from transitions as possible.

Detect the synch pulses, and use them to set a timer to 'trigger' 1/4 or 3/4 of the way through the 1MHz clock cycle, every 1uS. So the first bit will be shuffling to get into synch with the signal (like the shuffle to get onto an airport moving walkway :-), then after that, it is a regular 1uS sample.

On each timer trigger, read the pin. I'd maybe accumulate the bits of the 17 bit word in that routine (it'll only be a few cycles), and store back into memory. I think this is well under 50% of the processor cycles while data is being received.

A niftier solution
Instead of using the processor to sample the signal pin in an interupt handler every 1uS, set up the timer to trigger DMA to sample and store the signal pin value. Have the DMA read the (bitband) address of the pin, and store 17 values into a 17 byte buffer (data + parity)
At the end of the capture of the whole data word, the DMA will be set up to trigger an interrupt for the processor to come and deal with the data. So the processor will only get interrupted for the synch pulses (to get everything ready), and to convert the 17 samples into a data value.
I guess a few uS of work in 20uS.

A more robust solution
1. Put some filtering on the signal to reduce electrical noise
2. Sample the signal before and after the 'mid point' transition putting all the 'before' samples into one set, and all the 'after' samples into the other set.
Decode both into the two datawords, invert one, and compare. Parity is very likely enough, but this would detect some other types of errors. It would also be a handy check that the code is working ;-)
If this was 'for real, use two DMA channels and two timer channels to make this easier, and use very little CPU.

I'd do it in software using the timer and an interrupt first :-)
To make it easier, I'd start with a much lower frequency signal from the 2nd Maple.
That way you'll be able to see what is happening and print out data.

Posted 5 years ago #
Skids
Member

gbulmer,

Thanks for your two very detailed posts and your encouragement.
I have to say that my head is spinning following a single read through - but I do get the strong impression that you think it is possible.

I will go and locate some recorded data and try and calculate what a typical bus load is, (very roughly its 80-100 Mbytes per hour).

I live in the UK and I have been looking at oscilloscopes on ebay, I've just placed a watch on a couple to see what they go for.

Yes your code snip is spot on - I just modified the LED blink program. I tried the Arduino as well and it made about 125khz.

The following link http://www.ddc-web.com/Products/MIL-STD-1553/DesignersGuide.aspx is an often quoted guide to 1553.

As I understand it the databus line switchs polarity between plus 15 volts to minus 15 volts (unipolar?) to ensure that the DC component is zero - this also allows equipment to be isolated from the bus by the use of coupling transformers.

I have tried drawing out my clock, NRTZ data and the manchester encoded version and it seems that the sample has to be taken just after clock rise and just after clock fall. The two values are then compared to determine the change direction and thus the data bit. The part I can't see at the moment is how to fire the clock from the sync pulses as these are 1.5 clock cycles in length plus the type also determines how the data should be decoded (as data or as command)....tea break!

I've just moved the clock drawing trace to start running at the transition of the long sync bits - this seems to place the rise and fall of the clock signal at the 1/4 and 3/4 point of the manchester code which seems rather to simple (i.e. I must of made a mistake)

I'm off to read up on clocks, timers and DMA.

best wishes
Simon

Posted 5 years ago #
gbulmer
Moderator
<>very roughly its 80-100 Mbytes per hour</>
100Mbytes/hour is pretty good!
100MBytes/hour is about 278Kbits/second (including *time* for the synch, and the parity bit), so almost 28% utilisation

I think this is feasible.
I think doing receive and the retransmit is feasible too, but IMHO, you'll have to be sneaky to do the two concurrently (but I do think it is feasible).

As I understand it the databus line switchs polarity between plus 15 volts to minus 15 volts (unipolar?) to ensure that the DC component is zero - this also allows equipment to be isolated from the bus by the use of coupling transformers.

Okay, but is the point in the system you are conecting is stable logic level signals?

I have tried drawing out my clock, NRTZ data and the manchester encoded version and it seems that the sample has to be taken just after clock rise and just after clock fall. The two values are then compared to determine the change direction and thus the data bit.

Try looking at it a different way.

Manchester encoding is designed so that a single line can be used to send data and self clock the signal. So there is always one transtion (in the 'middle' of the bit). Let's call this the 'Manchester transition'.
There may be another transition at the start of the bit, so that the logic level in the first 1/2 is adjust to be correctly orientated for the mid-bit transition. Let's call this the 'optional transition' because it isn't there if there is a '0' followed by '1', or '1' followed by '0'.

If you don't know the clock speed, this is brilliant.

You do know the clock speed within +/-0.1%, so I think you can 'cheat'.

The signal changes in the middle of the bit duration, at the Manchester transition.
I am suggesting that 1/4 of the time (0.25uS) before or after the mid-bit (data carrying) transition, the signal is at a stable level. The processor can just sample the signal. It doesn't care about the transition.

So look at the stable logic levels before or after the mid transition, and I think they are the logic value (or its inverse).

I've just moved the clock drawing trace to start running at the transition of the long sync bits - this seems to place the rise and fall of the clock signal at the 1/4 and 3/4 point of the manchester code which seems rather to simple (i.e. I must of made a mistake)

I think the time from the synch transition to the first time data is sampled is a one-off value, then the data is sampled at 1uS intervals.

I think the Manchester data encoding (ignoring the extra transition) always leaves the signal in a consistent state. Depending on the encoding, the signal after the Manchester transition is either logic true (high is true, and low is false), or inverted (high is false, low is true).

Try this code to see how to flip a pin directly (this code can flip a whole 16-bit port at a time, or any perm of pins, which you probably don't need).
```
/* QuickererPin :-)
 *
 * Turns a GPIO pin on and off fast using direct updates.
 * Copyright 2010 G Bulmer
 */

// #include <gpio.h>
// #include <boards.h>

int pinNumb =  13;

GPIO_Port *const port = PIN_MAP[pinNumb].port;
const int32 pinOffset = PIN_MAP[pinNumb].pin;

void setup()   {
  // initialize the digital pin as an output:
  pinMode(pinNumb, OUTPUT);   // don't bother doing this at a low-level, use the library

}

void loop()
{
  while(true) {  // An infinite loop, going fast (can be faster, but yeuk)
    port->BSRR = 0xFFFF0000 | (1<<pinOffset);
    port->BSRR = 1<<(pinOffset+16);
  }
}
```
Try running it from Flash, and RAM. I get two different speeds.

I hope this will give you some confidence that things can go quite a bit faster than the library calls.
Posted 5 years ago #
gbulmer
Moderator

I should have added, I think there is another way to do this.

Even if the clock is not so tightly regulated, and hence has to be decoded using the clocking data, I think that can be done efficiently (i.e. a couple of interrupts / data word).

I think it will be quick enough, but it is more intricate, and takes a bit more effort to decode, so I'll forget about it unless we figure out that idea B is doomed :-)

Posted 5 years ago #
Skids
Member

Hi,
Sorry to have been deep and silent for four days; I've just had a load of electrical work completed on the house and my power has been on and off, then it was the weekend....

I have purchased an oscilloscope and should have it by the end of this week. Unfortunately I am rather busy with work at present but I hope to try your code out later today (when I get board with work!).

I read the tutorial on timers which seemed quite straight forward, then I read a chapter on Arduino timers which seemed more complicated (well more options). How similar are the commands between the two cards?

As yet I have not found any tutorials on DMA.

best wishes

Simon

Posted 5 years ago #
gbulmer
Moderator

Skids - Would you post a link to the Arduini timers?

I just read the Atmel documentation:
http://atmel.com/dyn/products/product_card.asp?part_id=4720
specifically
http://atmel.com/dyn/resources/prod_documents/doc8271.pdf

I am happy reading proper datasheets (some wold say, never happier :-)

Similarly,
http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=REFERENCE_MANUAL&SubClassID=1169
(Sadly ST have really £#@ked up their web site, and made finding products and documentation much harder than any of their competition, and NXP were horrible!)

The timers on the STM32F/Maple are much more flexible, and powerful than the timers on the Arduino's ATmega168/328

There are three flavours on the ATmega168/328, with one of each, Some are good for input capture, some for being driven off an external clock. Two have only 8 bit counters, one has a counter configurable for 8, 10 or 16 bits. There are two different types of pre-scaler. It is sort of flexible, by choosing the appropriate timer, but quite complex.

The STM32F also has several types of timer. All timers are 16 bit counters, all timers have input capture channels, all can output waveform or PWM, all have full 16 bit clock prescalers. I think all can be driven from an external clock source. One type of timer is optimised for driving motors, and so can generate "dead-band" signals. One type can be used to decode quadrature signals. One type is designed to drive the higher-density devices DACs. They are very flexible, but quite complex.

Don't worry about DMA initially. IMHO, with a 1MHz signal, you can do everything with timers and software on an STM32F/Maple. You can develop and debug using your second Maple to generate a lower frequency signal. DMA will be 'icing on the cake' :-)

Posted 5 years ago #
mbolivar
LeafLabs

skids -- there aren't any DMA tutorials up yet; library support for it is still too premature to put on github, even on a branch. but from what gbulmer has said, it seems like that won't be necessary for your application. good luck!

Posted 5 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.