Re: Is there any alternative to OS_delay_us()?
Posted:
Thu Aug 27, 2015 11:11 amby eriksl
pvvx wrote:eriksl wrote:What I mean is that you can't really expect NANOsecond operation in software. If only because of several things you cannot predict:
- cache behaviour
- interrupts
- compiler optimisation
Every interrupt can mess up the cache completely, for instance. If that means your code runs from flash instead of sram (cache), that will make a whole lot of difference.
NMI strobe ~38 ns (~6 CLK CPU 160 MHz)
Code IRAM section.
Synchronise fifo bus...
Output i/o pin = 10 ns jitter.
Min step ~100..200 ns. Steps only synchronise I/O bus
PWM and WLAN operation also use NMI...
Re: Is there any alternative to OS_delay_us()?
Posted:
Fri Aug 28, 2015 5:26 pmby pvvx
eriksl wrote:PWM and WLAN operation also use NMI...
PWM = Hard GPIO_SIGMA_DELTA
WLAN no delays and not uses _NMIExceptionVector
Re: Is there any alternative to OS_delay_us()?
Posted:
Fri Aug 28, 2015 5:30 pmby pvvx
pvvx wrote:eriksl wrote:PWM and WLAN operation also use NMI...
PWM = Hard GPIO_SIGMA_DELTA
WLAN no delays and not uses _NMIExceptionVector
Who is able to use - everything works, those who are looking for excuses - nothing works.
NMI, TIMER0 - 5us Call timer0_tst_is(). WiFi AP+ST On. WEB TCP GET/send file:
Code: Select all3:08:05.870> srv[80] 192.168.1.2:48733 [3] listen
3:08:05.870> srv[80] 192.168.1.2:48733 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:05.870> srv[80] 192.168.1.2:48731 [3] disconnect
3:08:06.008> srv[80] 192.168.1.2:48734 [3] listen
3:08:06.008> srv[80] 192.168.1.2:48734 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:06.008> srv[80] 192.168.1.2:48732 [3] disconnect
3:08:06.076> srv[80] 192.168.1.2:48735 [3] listen
3:08:06.134> srv[80] 192.168.1.2:48735 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:06.134> srv[80] 192.168.1.2:48733 [3] disconnect
3:08:06.258> srv[80] 192.168.1.2:48736 [3] listen
3:08:06.258> srv[80] 192.168.1.2:48736 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:06.258> srv[80] 192.168.1.2:48734 [3] disconnect
3:08:06.350> srv[80] 192.168.1.2:48737 [3] listen
3:08:06.350> srv[80] 192.168.1.2:48737 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:06.350> srv[80] 192.168.1.2:48735 [3] disconnect
3:08:06.520> srv[80] 192.168.1.2:48738 [3] listen
3:08:06.520> srv[80] 192.168.1.2:48738 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:06.520> srv[80] 192.168.1.2:48736 [3] disconnect
3:08:06.605> srv[80] 192.168.1.2:48739 [3] listen
3:08:06.605> srv[80] 192.168.1.2:48739 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:06.605> srv[80] 192.168.1.2:48737 [3] disconnect
3:08:06.697> srv[80] 192.168.1.2:48740 [3] listen
3:08:06.697> srv[80] 192.168.1.2:48740 [3] read: 348 of1[heap.xml] GET f[/heap.xml] head[200]:200 send: cf1 63 dis
3:08:06.697> srv[80] 192.168.1.2:48738 [3] disconnect Code: Select allvoid timer0_tst_isr(void *arg)
{
GPIO_OUT = GPIO_OUT^1;
GPIO_OUT = GPIO_OUT^1;
}
Re: Is there any alternative to OS_delay_us()?
Posted:
Sat Aug 29, 2015 9:30 amby eriksl
No sigma-delta is something else. Is similar but not the same. I cannot give the same resolution as the software (!) PWM implementation, which, uses NMI, as claimed by Espressif themselves.
Wlan using NMI is also something Espressif claimed themselves. Don't shoot the messenger...