Closed abecedarian01 closed 10 years ago
I confirm this strange behaviour, I also faced with other MCUs.
I always use the A5
format instead of the number of the pin 2
.
Only digital pins —digitalWrite()
, digitalRead()
— can use the pin number instead of the pin name.
Pin 2
= PB_5
@ LM4F = P6_5
@ FF5529 = P1_0
@ G2553
Analog pins —analogWrite()
, analogRead()
— require the full pin name A2
as they differ from one MCU to another.
That's a little counter-intuitive, is it not?
Pin 2 on the F5529 is P6_5 and A5. Pin 2 on the Tiva / Stellaris is PB_5 and A11. Pin 2 on the G2xxLP is P1_0 and A0.
If one wants to develop a Booster Pack and write board agnostic code, the logical solution is using the Pin number, I would think, as the developer would be looking at what pins share common functionality between the LP's.
Using Pin "names" means that if the code references A0, that will be pin 2 on G2xxxLP, pin 23 on F5529LP and pin 29 on Tiva / Stellaris. That is not conducive to portable code, is it?
I know, it isn't the best solution.
Now, pin numbers do work for digital pins and you can easily use #ifdef
for the analog pins.
In your case,
#if defined(__MSP430G2553__)
#define myAnalogPin A0
#elif defined(__MSP430F5529__)
#define myAnalogPin A5
#elif defined(__LM4F120H5QR__)
#define myAnalogPin A11
#else
#error LaunchPad not supported
#endif
Hope that helps!
I'm sure that will help, but should anyone have to include that for EVERY pin definition when the framework / IDE already makes an attempt to handle that intrinsically?
I'm afraid yes. The #ifdef
isn't a big deal.
The reason behind this is the framework doesn't handle the analog pins internally. The analog pins require more configuration than the digital ones. Again, while all the pins are digital, only some if them are analog and vary from one MCU to another.
Que sera, sera. What(ever) will be, will be.
I would think, however, that choosing the board in Energia would let it know what is what. And then it could decide things and warn the user that certain pins do not support functions....
Yes, I'm a dreamer. ;)
If ADC conversion is done using "analogRead(2)" or "analogRead(P6_5)", the value obtained is not correct- it is as if the pin is not connected to anything. However, using "analogRead(A5)" it works as expected.