Arduino for STM32

I looked up ARM's documentation and it says that CM0 isr latency can be as low as 16 ticks (vs. low 20s I got), and CM3 isr latency can be as low as 12 ticks.

OK. here is a quick test on a PY32F002A - the numbers would be similar, if not identical, on other chips. I used TIM1 overflow as a test interrupt tmr1Init(1); tmr1OVFAttachISR(pwm_tks); pwm_tks() is structured as: void pwm_tks(void) { t1 = TIM1->CNT; //read the counter pwm_t2 = TIM1->CCR1; //save t...

for around 5µs

that's too long. your ISR overhead will be 20 ticks. Hard to imagine this thing goes over 100 ticks end-to-end. I will do some testing later on as well.

I would approach the problem this way. 1. Set up an input capture on falling edge. No interrupt. 2. Set up one input capture on rising edge, interrupt enabled. In this isr, you will need to calculate the timer count elapsed between two isr invocations, and the difference between the count captures i...

the solution is fairy simple: 1. find a better way of doing what you are trying to do; 2. if not, write faster ISR - try using integers only; 3. if not, lengthen the ISR invocation frequency - use the input filter; 4. if not, live with the limitation. and yes, reading the reference manual would be q...

Can anyone help me figure out ... you are invoking the two interrupts at 100K times per second, and you are using floating point math in them. each invocation is likely hundreds if not a thousand cycles. so you need something like 2 x 100K * 1K = some out of this world fast processor to handle that...

the 16Mhz should oscillator just fine, with or without caps.

the 32K will likely need something to get it started. you can put your finger on the pins (especially the input pin) to see if it starts.

the clock may run at 128Mhz but the PWM runs at much lower frequency: for 8-bit resolution, the PWM is 128M / 256 = 500Khz. or 128K @ 10-bit resolution...

the way to integrate them together is simple: //I just used some random numbers #define PR_PWM 10000 //pwm period - you can tie it to F_CPU to make the pwm frequency invariant to the chip's speed #define PR_ENC2 2000 //encoder 2 frequency / period #define PR_ENC4 4000 //encoder 4 frequency / period ...

maybe you can simplify it so you can isolate the problem. 1) write a piece of code that generates the pwm on TIM1: //initialize pwm on TIM1, with user-specified period void pwmInit(uint16_t pr) { ... } 2) write code for your encoders: //initialize optical encoder on TIM2 //I actually don't know why ...