- Tue Mar 03, 2015 9:24 am
#11172
The pull request has been merged into the dev branch.
- Wed Mar 04, 2015 3:59 pm
#11310
Woops, didn't want to cause more work than necessary, sorry!
So simply modifying the buffer before sending it worked? Awesome!
It's really a PITA to get the timings correct with the compiler doing weird things with the code.
Lucky this works... Is it possible to get a __delay_cycles(n) macro like in AVR architecture or a interrupt-timer-based implementation which will still work even when the compiler decides to optimize in another way than it does now?
So simply modifying the buffer before sending it worked? Awesome!
It's really a PITA to get the timings correct with the compiler doing weird things with the code.
Lucky this works... Is it possible to get a __delay_cycles(n) macro like in AVR architecture or a interrupt-timer-based implementation which will still work even when the compiler decides to optimize in another way than it does now?
- Wed Mar 04, 2015 4:25 pm
#11315
I think os_delay_us(n); works fine.
flokli wrote:Is it possible to get a __delay_cycles(n) macro like in AVR architecture or a interrupt-timer-based implementation which will still work even when the compiler decides to optimize in another way than it does now?
I think os_delay_us(n); works fine.
