Search found 11 matches

It's not a backdoor...

Hmm... with that suggestion I'd potentially try a harder pull-up, but if you're satisfied with the hardware/bus parameters then I'd look at doing a minimal roll-your-own MSSP/I2C setup + data transmis ...

You might need to dig into the assembly listing and investigate what the compiler is potentially doing wrong with the setup/usage of the MSSP on that particular chip.

It's interesting that CCS didn ...

After looking at the datasheet for the 16F18124 I'm not sure what the issue is?

It doesn't have distinct registers for each module - you select what CLC you want to configure via the CLCSELECT regi ...

I'm not familiar with how CAN works on that PIC, but there's possibly ramifications to doing debug prints inside the interrupt with the current setup?

I see that you have 'TXISR' set in the #use st ...

Have you tried removing DISABLE_INTS from your #USE RS232 definition?

Less program space is used.

Some PICs allow to you to perform a scan/calculation in the background, throwing an interrupt when complete.

That's one of the benefits when using chips that feature the vectored interrupt controller - there's no need to scan for the interrupt source, so the only block of (hopefully fixed) latency is saving ...

It looks like your device has a vectored interrupt controller, so you might be able to squeeze a little bit more control over latency by adding this line -

#device vector_ints

@jaka : Can't thank you enough for sharing that codebase. Cheers!

There's also an interface to configure APF + pulse steering provided via the setup_ccp() function/s i.e

setup_ccp1(CCP_PWM | CCP_P1A_A5); // route pwm output to A5 (pin 2)
...