Hello,
I am an FRC mentor and relatively new to Pololu. FRC is about to support the Romi base and we are excited because this setup serves a need for our team.
We are in a unique position of having many Vex edr devices (motors, servos, motor controllers, and sensors). We have purchased the Romi and the control board and are wondering a few things about IO. We will be using the base, control board, and a Raspberry Pi.
Assuming we use the Romi motors and encoders as the drive base, but extend the functionality by adding vex motors (with thier own controllers). how many external pwm pins does the control board have?
If we were to use the control board without the base (using vex motors and controllers), how many own channels would we have access to?
We realize the power constraints may not match and have a plan for a safe remedy for that.
How many PWM capable pins are available will depend on what other functionality you need from your Romi 32U4 Control Board since many of the pins that support PWM are also used for other purposes. There are a total of eight pins that support PWM:
Two connect to the built-in motor drivers to control speed.
One shares a pin that is used for I2C communication, such as with the built-in IMU or a connected Raspberry Pi.
One connects to the buzzer.
One connects to the yellow LED.
If you add an LCD screen, two of its data lines will connect to pins that also support PWM, but one of these is the same pin the yellow LED I mentioned before is on.
Two connect to free I/O pins and are not used for any functions on the board.
I am still confused. I think the reason is all the data sheets say they support pwm.
However, can support does not necessarily mean that it can support it simultaneously. For instance in the data it says pin 12 and pin 6 can conflict. So, if we are not using the buzzer, can we use both pin 6 and pin 12 for motor control? In addition, it seems that each motor output is using two pwm channels.
So if all we want to use is the pi interface (i^2c correct)?
How many pwm channels are available with or without the Romi motors?
Forgive my ignorance. We work primarily with devices that are a bit clearer as far as io and pin assignments go.
Sorry, I thought I included this in my post last night. But as a follow-up, based on your response last night, can I assume that we will be able to access…
5 PWM pins with the motors (and encoders as well as the pi interface).
and
7 PWM pins without them (assuming we do not need the buzzer, LCD, or yellow LED)?
Thank you again.
The assessment in your latest post is correct, though it might not be practical to use one of the pins (pin 12) as a PWM pin since it is not supported by analogWrite(). Excluding that pin would leave you with four available hardware PWM pins if you do not need the buzzer, LCD, or yellow LED, and six available PWM pins if you also do not need use the motors included with the Romi chassis.
It seems like in your previous post you were maybe just over thinking this and have it mostly figured out now, but just in case there is still any confusion, here are a few quick clarifications:
I am not sure what you mean when you say “all the datasheets say they support PWM”, but as I explained before, there are eight pins with hardware PWM outputs. If there is something in our documentation that is leading you to think that there are more, can you link to it?
As mentioned in our documentation, pin 12 and pin 6 (which controls the buzzer by default) are complementary outputs of Timer4 channel D, so they can conflict with each other. However, as I mentioned before, pin 12 is not supported by analogWrite(), so it might not be easy or practical to use anyway.
The motor drivers use two PWM outputs total (each driver uses one) to control speed. They also each connect to another I/O pin (which are not hardware PWM pins) to control direction, so the motor drivers use a combined total of four pins.
When I said “all the datasheets say they support PWM,” perhaps I was unclear. Sorry about that. I meant that the datasheets say which pins support PWM. However, how they do is a bit confusing to me. This is how I interpreted the table.
11-> Timer0 PWM output A (OC0A)
Timer1 PWM output C (OC1C)
---------------------------------
13 -> Timer4 PWM output A (OC4A)
---------------------------------
6 -> Timer4 PWM output D (OC4D)
---------------------------------
10 -> Timer1 PWM output B (OC1B) (left motor)
Timer4 PWM output B (OC4B)
---------------------------------
9 -> Timer1 PWM output A (OC1A) (right motor)
Timer4 PWM output B (OC4B)
---------------------------------
3 -> Timer0 PWM output B (OC0B) I^2C clck Pi
---------------------------------
5 -> Timer3 PWM output A (OC3A)
Timer4 PWM output A (OC4A)
---------------------------------
12 -> Timer4 PWM output D (OC4D)
So, the first thing I did not know was if each timer could control multiple PWM signals at the same time (as opposed to just be locked to a specific frequency). If not, there really may only be 4 PWM channels that are usable for motors at any given time. The second confusion was that many pins are linked to multiple timers. Some timers are linked to multiple pins. Would using one influence the other? Then, though I do know how H bridges work, I was confused by the PWM assignments on the motor pins (I thought it was possible the motors took both assignments). But, I think I understand it now.
For pin 12, would it not be digitalWrite() rather than analogWrite() we would need for PWM? Regardless, I agree, it may be best to avoid if there could be crosstalk.
I do have a follow-up question. If we use the Romi motors, but no LCD (or red LED), it seems that we would be able to use 4 pins for external encoders. Is this correct?
Thank you so much. We are excited about this project thanks to WPILib and Pololu.
A timer can be used to generate a PWM output on multiple pins at the same time. Those PWM signals will have the same frequency, but they can have different duty cycles, which is the main parameter you would be interested in varying to control separate motors.
Even though a single pin on a microcontroller can have multiple possible functions, only one is actually enabled at a time. In the case of using timers to generate PWM signals, that means even though a pin potentially can generate a PWM using two timers, it will only ever actually use one at a time. When you use Arduino’s functions for setting up and commanding pins, those functions take care of making sure pins do not overlap timers in ways that could cause interference, so you probably do not have to worry about them influencing each other.
Arduino’s analogWrite() is the relevant function in the Arduino IDE for generating PWM signals. (Yes, the name could be a little misleading depending on how think about it.) This Arduino language reference page has more information.
As for external encoders (i.e. encoders other than the ones for the included motors), like with your PWM questions the answer is not that simple. There are several pins you might be able to use to read encoder signals, but most of them would probably not work well for that unless you either use slow (low-frequency) encoders or are not doing much else in your program. The best candidate pins for reading encoders are ones that connect to interrupts on the microcontroller, but as with the hardware PWM pins, many of those are also used for other purposes. For example, I/O pins 0 and 1 might be good candidates for reading an encoder, but those pins are also used for the board’s hardware UART Serial, so it would conflict if you also wanted to connect a TTL serial device to the control board.
In general, we expect that these electronics are going to be more complicated for teams to use than some of the other FIRST electronics because they are much less abstracted from the microcontrollers that they use, but I hope that helps provide teams with a deeper learning experience. This “Abstractions” blog post might offer some helpful guidance for how to deal with confusion that often arises from abstractions.
Hello,
Sorry I have been absent for so long. I had known about abstraction, but had difficulty wrapping my head around how it worked in this case.
The matter is simultaneously simplified and confounded by the level of abstraction in the WPILib software. So, they actually solve the problem quite deftly.
However, if anyone wants to go farther and utilize more io (or an lcd as well (though you would probably need a tall header, taller standoffs, and a ribbon cable to use that with a raspberry pi), you would need to delve into this particular implementation of the WPILib HALSim WebSocket API.
Thanks again. These devices are incredible. We are learning so much with them and having a wonderful time (even though we are currently fully remote).
