supermileage / dynamometer-pcb

Dynamometer pcb kicad project
0 stars 0 forks source link

Consecutive pins for rotary encoder #16

Closed cosparks closed 8 months ago

cosparks commented 1 year ago

Unfortunately, only neighbouring (consecutive pins) can be used for the pico's rotary encoder input.

JamesZhZhang commented 11 months ago

Note to self that the pin assignments in the firmware will have to change too

cosparks commented 11 months ago

the current display driver that this project uses already makes use of the second pio module (I switched to that new driver this summer), so pio is no longer an option for rotary encoder. Fortunately, it runs very smoothly from the main control loop so shouldn't need it.

That's not to say that the pins shouldn't be made consecutive, just to leave the option open in case rotary encoder performance deteriorates as the firmware grows in complexity and you decide to reclaim that pio module at some point in the future.

JamesZhZhang commented 10 months ago

Thanks for the reply @cosparks! I'm just having trouble interpreting what you mean, as I'm still trying to wrap my head around the codebase as a whole. What's the difference between the second pio module, and the main control loop here?

cosparks commented 10 months ago

The rp2040 (mcu for rpi pico) has 2 programmable input/output modules which run independently of the main processor cores (although they run on the same clock). Here's a simple tldr. More info in chapter 3 of the rp2040 datasheet.

Essentially, they allow you to write small programs (4 states each, and up to 32 assembly instructions per state) which can read and write to IO pins, and which can read and write data from the main cores using pico SDK functions. You could write a PIO program which implements SPI, UART, CAN or some other communication protocol, for instance.

A really simple example would be the encoder program I wrote to count optical sensor pulses here, (which compiles to this). You can see how we request data from that module in SensorOptical::handle here.

The original plan was to use one module to read the optical sensor, and the other to handle the rotary encoder. It was a mistake that the pins on the rotary encoder weren't placed consecutively, but this summer I switched from our old tft display driver to a new one which uses the second PIO module, so both have been claimed! At least for now

JamesZhZhang commented 10 months ago

Thanks for the explanation! I understand the implentation of the PIO now 😄

Just wanted to clarify what's currently implemented in the code. So the rotary encoder uses pins on the pico that correspond to the main control loop (i.e. no changes need to be made to the code, unless I change the pin assignments of the rotary encoder on the PCB?)

cosparks commented 10 months ago

Just wanted to clarify what's currently implemented in the code. So the rotary encoder uses pins on the pico that correspond to the main control loop

yep! the rotary encoder pins are being handled by the input manager in the main control loop.

The decision on whether or not to change those pins is up to you, but I'd recommend it. It would be a very small change in the code and would make the design a bit more flexible in case things change in the future

cosparks commented 10 months ago

oops didn't mean to press close with comment haha

JamesZhZhang commented 10 months ago

Gotcha, thanks so much for taking the time to explain all this to me! I'll go forward with making the pins consecutive for now, and probably add a comment in the code for the rotary encoder pin assignment for future reference. Best of luck with your capstone!