2012-09-14 05:29 AM
I'm working on a project on a STM32F4 CPU, generating signals (VGA) with DMA.
I have a generic timer on CPU clock (no prescaler) on a STM32 triggering interrupts on overflow, to generate a periodic signal with GPIO afterwards.
I need to trigger thr GPIO at a very regular time (basically down to a CPU cycle precision). I've managed to reduce this jitter to +-5 cycles by setting priorities & al, but this jitter exists, depending on what the CPU was doing and the interrupted instruction.
I need to compensate this few cycles jitter. Adding a few cycles more latency isn't a problem as long as I toggle GPIOs always at the same counter cycle.
My idea was to read the current value of the counter after the interrupt, and have an active loop of (FIXED_NUMBER-CNT->VAL) time, ensuring I would exit the loop at precise times.
However, doing a simple loop in C - being a FOR loop, or a while(counter->value < TARGET); doesn't work as it ADDS jitter instead of reducing it.
I ensured with empty, non optimized but not hitting memory loop body (asm(''''))See this example on AVR (more predictable timings) See by example
http://lucidscience.com/pro-vga video generator-7.aspx
(search for ''jitter'')I tried a simple loop in assembly such as (r0 has the number of cycles to wait to compensate counter value)
loop : SUBS r0,#1 ; tried with 2 also BGE loop
and, again, jitter is better without it.
To sum it up, I already know how much I should delay. Unfortunately, branches alone don't seem to work (nondeterminisctic pipeline refill ?) and IT conditional expressions don't either because they always take the same number of cycles (sometimes doing nothing).
Would running from RAM instead of flash improve consistency ?
Maybe I'm out of my league here ... any help would appreciated, thanks! (crosspost from stackoverflow as I think I'd have more success here than there, sorry) #interrupts-counter2013-01-29 06:53 PM
2013-05-03 02:41 PM
hello,
can i use this DWT delay for grab the data from dht22 (temp/hum sensor) ?? or any another way to grab the datathxricky2013-05-03 04:11 PM
can i use this DWT delay for grab the data from dht22 (temp/hum sensor) ?? or any another way to grab the data
Probably, it has reasonably fine granularity, and predictability (sans interrupts). Signal placement can also be measured with a TIM in input capture mode, or using the DWT as a timestamp for transitions you watch on GPIO pins.2013-05-27 01:40 AM
thx for replay andsuggestion.
next question, any problem with my code?/* data DHT 22*/
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOE, ENABLE);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
GPIO_Init(GPIOE, &GPIO_InitStructure);
GPIO_SetBits(GPIOE, GPIO_Pin_0);
EnableTiming();
Delay250Ms();
Delay250Ms();
GPIO_ResetBits(GPIOE, GPIO_Pin_0);
EnableTiming();
Delay500Us();
GPIO_SetBits(GPIOE, GPIO_Pin_0);
EnableTiming();
Delay40Us();
//Delay1500Ms(); // <------ this line what i mean
/* data DHT 22*/
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOE, ENABLE);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
focus on ''
<------ this line what i mean''
i dont have any data if i commend the line, but if uncommand the line the output pin do not change to input pin. any next suggestion, or any example if i choice to useTIM in input capture mode...?
thx ricky2013-05-27 05:12 AM
I wouldn't be calling
RCC_AHB1PeriphClockCmd
() and EnableTiming() multiple times. I'd be looking at the signal on a scope, confirm the timing, and compare it to a working implementation of a DHT22 reader, and the available documentation.
2013-05-27 05:52 AM
thx for fast replay,
iam use scope too, its a reason why i know the DHT22 is respons the signal from uC. but if i change the pin from output to input, the data can visual on scope (logic ''0'').suggest ?2013-05-27 06:02 AM
If you switch to an input, with a pull-up, and you are seeing a zero on the line it would be because the DHT22 is driving it there.
2013-05-27 06:35 AM
2013-05-27 06:36 AM
https://www.facebook.com/photo.php?fbid=10200596337445441&l=6c84729d63
it is the photo of scope and part of code like above.... i wish it can solve my problem
2013-05-27 06:49 AM
i wish it can solve my problem
I've never found wishing to be an effective debugging strategy. Are you sure you want to be using GPIO_OType_PP, I'd think OD (Open Drain) mode would be far more effective for a single wire protocol. You should be able to attach PNG images directly here, as well as larger file attachments. The images are a bit fuzzy.The one with modulated signal does not appear to get low enough to read a zero state.