Set timers for CircuitPython Manually

[wallarug]

How do you set the timers for PWM outputs when building custom CircuitPython boards?

I am getting an error at the moment about conflicting timers. However, everything should work fine using alternative timers on the SAMD21G (if it knows which to use).

All timers for this pin are in use.

This is running on a SAMD21G processor, native circuitpython through USB terminal session.

Any assistance would be greatly appreciated.

Thank you.

[wallarug]

SERVO1 and SERVO3 are conflicting.

As a follow up to this... the pins in use at the moment are the following:

Descriptor	CircuitPython	Port	TCC/TC	Alt TCC/TCC
SERVO_1	SERVO1	PA16	TCC2[0]	TCC0[6]
SERVO_2	SERVO2	PA17	TCC2[1]	TCC0[7]
SERVO_3	SERVO3	PA18	TCC0[2]	TC3[0]
SERVO_4	SERVO4	PA19	TCC0[3]	TC3[1]
SERVO_5	SERVO5	PA11	TCC1[1]	TCC0[3]
SERVO_6	SERVO6	PA10	TCC1[0]	TCC0[2]
SERVO_7	SERVO7	PA09	TCC0[1]	TCC1[3]
SERVO_8	SERVO8	PA08	TCC0[0]	TCC1[2]

Note: Bold is what should be used for no conflicts.

I have had issues using TCC1. It seems to have another use that I am yet to discover, hence, it is not being used.

[deshipu]

You might be able to get it working by creating the pwm objects in different order.

[wallarug]

Hey @deshipu ,

I have tried that and I still get the same two outputs conflicting. SERVO1 and SERVO3. None of the others conflict at this point. It's very strange.

[tannewt]

@wallarug How are you creating the PWMOuts? What version of CircuitPython are you using? (I feel like we fixed a bug with PWM recently so try Beta 6 if you haven't.)

[dhalbert]

Ah yes: we fixed a TCC allocation bug: #1184

[wallarug]

I am pretty sure this was latest pull from 2019-04-08 direct from github. So version 4.0.0 of CircuitPython. Not sure of the exact version. I can double check tomorrow.

[wallarug]

@tannewt cycling through all the servos starting at 1 to 8. Creating the PWMOuts based on SeeSaw's libraries (so hidden). I didn't have this issue with the circuitpython built in Feb / March 2019. The SeeSaw firmware that I built is ok - it uses the correct timers that were specified.

from Adafruit_CircuitPython_RoboHat.rm_robohat import RoboMM1
import time

from digitalio import DigitalInOut, Pull, Direction
from adafruit_seesaw.pwmout import PWMOut
from adafruit_seesaw.seesaw import Seesaw
from adafruit_motor import servo
import board
import busio

i2c = busio.I2C(board.SCL, board.SDA)

robohat = RoboMM1(Seesaw(i2c))

def Servo_sweep():
        servo1.angle = 90
        time.sleep(0.2)
        servo1.angle = 60
        time.sleep(0.2)
        servo1.angle = 30
        time.sleep(0.2)
        servo1.angle = 0
        time.sleep(0.2)

servo1 = robohat.servo_1
while True:
        Servo_sweep()

[tannewt]

Now I'm confused. How does Seesaw play into this? Can you link to the robohat library please?

[wallarug]

Hey @tannewt ,

Apologies for causing any confusion.

I was using SeeSaw to test that the custom board was not faulty (rule out hardware issue). I think I have also sent the incorrect sample code, which compounded confusion.

Effectively, when using the PWMOut function it says: "All timers for this pin are in use." after calling SERVO1 then SERVO3. It would look like the TCs are possibly being ignored as an option in CirucitPython.

Code

CircuitPython: https://github.com/robotics-masters/mm1-hat-cpy-native/tree/v4-hat/firmware/boards/mm1_hat_flash_8mb

SeeSaw (which was mentioned): https://github.com/robotics-masters/mm1-hat-seesaw/tree/v4-hat

I am currently away at the moment. So I would need a few days before I can come and look at this again.

[tannewt]

@wallarug Neat! I didn't realize you had compiled it yourself. I'd recommend forking CircuitPython to add the board def directly. We'd love to have it merged into the main repo.

I think your issue may be that the current code doesn't support wave out 0 from TCs. (SERVO_3 above uses TC[0].) We use it internally for the 16bit top value. Without out a fine grained top value we wouldn't be able to get precise frequency of the PWM.

Another tricky bit can be that the number of capture/compare channels in the TCCs can be less than the number of wave outs. That can lead to channels being in use when unexpected as well.

[wallarug]

@tannet Thank you! I will fork soon and do a PR into the main repo when ready.

I think what is happening here is exactly what you outlined above.

TC3[0] is not usable.

In the example Python file we have we go through the servos in order.

Servo	Auto-Configured TCC	Equivalent
SERVO1	TCC0[6]	TCC0[2]
SERVO2	TCC0[7]	TCC0[3]
Attempt: SERVO3	TCC0[2]	TCC0[6]

Since TC3[0] is unavailable, we end up with it unable to use any TCC. Error no available timers on this pin.

In the other example we developed, there is no way to tell exactly what CircuitPython is doing at this stage but it would appear this is what is happening:

Servo	Auto-Configured TCC	Equivalent
SERVO3	TCC0[2]	TCC0[6]
SERVO1	TCC2[0]	NA

No issues.

So I guess it would be good if CircuitPython was able to either have the timers manually configured when compiled (like SeeSaw 🥇 ) or actively adapt to what is happening and currently in use.

It's just a bit annoying that SERVO3 needs to be swtiched on before SERVO1 if you want them all to work.

Any further ideas?

[tannewt]

It is weird that order matters but most people don't have the issue. It'd be a lot of effort to switch them around as needed. So, I don't think it's worth the effort now.

[wallarug]

Hey Scott,

I'll have a play around with it and let you know if I have any success. Like you said - it is just easier to say to people: "initialize SERVO3 before SERVO1" for our board.

I'll PR all the board config stuff a bit later - once I know it is very stable (it's looking that way at the moment).

If your interested in checking out the board, the info is on Crowd Supply. We hope to launch this week.

https://www.crowdsupply.com/robotics-masters/robo-hat-mm1

[tannewt]

Thanks for the link! I'd suggest PRing early for testing. (Then we can add it to circuitpython.org too.) You can always tweak it later.

We usually provide a library that does the init so that in practice most folks don't need to worry about the init order.

[tannewt]

This issue is resolved. The init ordering is just a weird detail.