Hardware trigger

[linas2]

Posted on March 31, 2013 at 20:24

Hello, i have CLK which is generated by ADC, and i need to generate SI signal as shown in this picture. I used software version, but it is very unstable, and if i recompile that, it can completely mess up timing.

GPIOA_Pin15 connected to CLK

while(GPIOA->IDR < 
32765
); // wait if CLK is low, 

while(GPIOA->IDR > 32765); // wait if CLK is high, when i go out from this loop CLK should be low
Delay(6); // wait a bit, it is 6x ''nop''
GPIOA->BSRRL= GPIO_Pin_10; // Set Si high
Delay(6); // wait a bit
GPIOA->BSRRH= GPIO_Pin_10; //Set SI low

Can i do it by using STM32F4 hardware ? (now stm32f4 core is clocked to 255MHz)

[sdim2]

Posted on April 01, 2013 at 00:29

If you want precise timing, you should use ''output compare''.

Another option, a bit easier to implement but less accurate, is to setup the output pin as serial (for slower signals) or spi and transmit the appropriate bitstream .needed to create the signal. For example, if you have set your SPI transmit speed  to 10Mhz, each bit should have length of 100ns. If you transmit 1000000b, then you will get an output pulse with 100ns duration and no other pulse for the next 700ns. If you transmit 11000100 you will get a pulse with 200ns duration, no pulse for 300ns, one pulse for 100ns and no pulse for 200ns. As you can see, it is very easy in theory but it may be hard to set the clock values needed for your specific requirements.

So, try output compare.

By the way, you should never overclock an MCU when you work on a project that will go to production. There is no way to know if the MCU will work overclocked after 2 years of use, and in many countries the minimum warranty allowed by the law is two years. You don't want to have product returns under warranty because of the overclocked MCU.

[linas2]

Posted on April 01, 2013 at 11:23

well, i know that STM32F4 already is clocked at 200MHz, but is still not in the production. i don't see any excess heat or any other artefact of overclocking (i only stress ARM cortex M4 core, nothing else, i don't toggle gpio at 130MHz and do stuff like that, all i need is more processing power, is more than 50% performance increase)

if this project will go to production  it will be based on FPGA or BlackFin dsp or something like that.

(i just wish that some day ST will produce simple processor running 500MHz or more in LQFP package)

This project is for

bachelor work

in university

[emalund]

Posted on April 01, 2013 at 17:44

while(GPIOA->IDR <

 

32765); 

while(GPIOA->IDR > 32765);   trying to make it more difficult to understand?. I would like to know which bits you test, but have no intention of figuring it out from decimal constants.

<I>well, i know that STM32F4 already is clocked at 200MHz,..... i don't see any excess heat or any other artifact of overclocking </I>

Someone crashed his car into another and said ''I did not see you''. That you do not ''see any artifact of overclocking '' does not mean ther isn't any.

Erik

[Tesla DeLorean]

Posted on April 01, 2013 at 18:59

i just wish that some day ST will produce simple processor running 500MHz or more in LQFP package

The market for these faster parts tends to favour ones with external SDRAM buses, and LCD attachment (figure phone and pad markets), which drives the pin count up, and the package size down. Parts which have the volume to drive the costs down will be using fine pitches, and 6-8 layer PCB's.

I can get 400 MHz LQFP parts today, the packages are monstrous, and cost about 5x what I pay for STM32 parts.

[linas2]

Posted on April 01, 2013 at 19:33

so for this speed STM32F4 clocked to 255MHz is to slow to do my job, it is just too much of jitter in all signals generated by mcu.

so i made all on Altera cyclone 3 in no time, and signals are perfect, within ns range but still, what is the fastest way to check gpio bit ?. I have fifo which is controlled by fpga, and i need to read out data as fast as i can. it is clocked at the same time by adc form another side (async FIFO), and i need to unload data with loop like this:

while(i<
128
)
{
while((GPIOD->IDR & GPIO_Pin_13)!=GPIO_Pin_13);
CLK_LOW;
CLK_HIGH;
array[i]=GPIOB->IDR;
i++;
}

pin13 is empty flag, i need to wait until i have data inside fifo (aka flag is 1), then clock it out. can i do better than this ? for now idea is to use

GPIO_Pin_15 so condition is shorter to check:

while(i<
128
)
{
while(GPIOC->IDR < 
32765
);
CLK_LOW;
CLK_HIGH;
array[i]=GPIOB->IDR;
i++;
}

[Tesla DeLorean]

Posted on April 01, 2013 at 19:46

The micro is not the appropriate tools for fine clock/signal control. A general purpose micro hardly ever addresses specialist needs.

The GPIO bus is not where to do efficient signalling, if you want to pull data from the FPGA use the FSMC bus, or perhaps the DCMI.

[linas2]

Posted on April 01, 2013 at 20:00

i have fast DAC on FSMC, that why i made adc board with async fifo, so no mater what, i will not miss any word from ADC (last time i just couldn't keep up with 8MHz 16b data stream directly from ADC )

this code works, i just need to get as much speed as i can, if i save 10ns on read, that means total 1.28us shorter program cycle .

[Tesla DeLorean]

Posted on April 01, 2013 at 20:13

Consider coding the loop in assembler, and perhaps unwinding it a little.

The FSMC can support multiple devices at different addresses.

You could reduce the STM32F4 clock if you suitably architected the solution, and moved some of the donkey work to devices better suited to such.

[linas2]

Posted on April 01, 2013 at 20:22

i already have loop unrolling as optimization, and it does work, save some time.

i don't need just unload data, i need to do two floating MAC operations with it, to be more precise single frequency DFT for real and image part, that's hy i used gpiob as my data port, if i need just copy data to memory i can do it much faster than 8MHz with fsmc and DMA, use CS as clk for clock for fifo.

this works well for DAC, can generate any signal in memory, and just copy that in DMA circular cycle while doing other stuff with processor core.

[sdim2]

Posted on April 02, 2013 at 01:40

Polling is not a good option when you use microcontrollers.

The best option is to use specific timer features. STM32F4 supports input capture, output compare, PWM generation and one-pulse mode output.

The STM32F4 timers have up to 11.8ns resolution (AHB/APB1 prescaler distinct from 1, fTIMxCLK=84MHz). Unfortunatetly the datasheet (v3) does not have the timing specifications for the I/O ports.

Such timer features allow even slow frameworks (arduino, .netmf) to create or read fast signals.

About my other notice, overclocking, the problem is not heat itself but electromigration. Even if the chips' temperature is not above its' specs temparature limit, overclocking rises it's temperature and it reduces the MCU lifetime in long term.

http://en.wikipedia.org/wiki/Electromigration