The photon/P1 supports many different pin functions on the same pin. Like the TX,RX pin, how can we change the pin functions to switch between digital GPIO, ADC input or PWM?
Also the P1 has reserved pins. Is there any plan in the firmware to define/use these pins like any of the other pins?
Thanks
@wesner0019, like on the Core, the use of pinMode() will make the pin a digital GPIO, using analogRead() an ADC input and analogWrite()/Tone() an PWM output.
I am not sure what you mean by “reserved” pins. Can you specify? 
Thanks. The P1 has 5 or 6 reserved pins declared on the Pin mapping posted yesterday. I’m guessing these pins are available to be used but not yet defined?
Oh yeah, I mean the spare pins.
Hey guys! Yes currently the pin map for the P1 is loose because there is no reference design at the moment for it like there is with the P0 (on the Photon). The pin map for the P1 was directly copied from the Photon’s pin mapping. Since we already know what functions those pins on the P0 equate to, it’s easy to say you can write code on the P1 like digitalWrite(D0, HIGH) and it’s going to set P1 module pin 36 (MICRO_I2C1_SDA) high.
You can change the mode of the TX pin very easily… just use in code like this:
pinMode(TX, OUTPUT);
digitalWrite(TX, HIGH);
pinMode(TX, INPUT);
digitalRead(TX);
// or
analogRead(TX);
// or
pinMode(TX, OUTPUT);
analogWrite(TX, 127); // 50% PWM
The SPARE1 through SPARE6 pins will definitely get a better name… to be determined. And their functions will be explained more thoroughly like the photon-pinmap:
https://raw.githubusercontent.com/spark/photon/master/pin-mapping/photon-pinmap.png
@BDub Any new progress on the functions of the Spare pins on the P1? I can’t complete my PCB design until I know what these pins function as. Any updates are appreciated.
Thanks
I guess this is analogWrite(TX, 127);
Not yet, these are still Spare1 through Spare6. Here’s a preview of what some of the P1 pin mapping will look like for the P1 datasheet. You can see which pins of the STM32F205RG are hooked to the Spare1 ~ Spare6 pins. From this you can determine what functions are exposed on these pins. Once we determine what’s available, we can add those functions to the pin mapping in firmware, and give the pins an appropriate “software” name like D8 or A10 etc… whatever makes the most sense for these pins.
I went to the data sheet and complied the the functions as shown below.
From my understanding the functions would be (not sure about the interrupts though):
PB0 = PWM, GPIO, ADC
PB1 = PWM, GPIO, ADC
PC0 = GPIO, ADC
PC4 = GPIO, ADC
PC13 = GPIO with limitations to 3mA sink current and 2MHz speed and 30pF load
PC1 = GPIO, ADC
@BDub, Does my above post look to be correct for the Spare pin functions?
Thanks for any help in this area. I would like to finalize my PCB design so that it’s ready when I receive 20 of the P1’s.
Yes that looks good @wesner0019! Thanks for pulling that together. I’d want to look and see what the difference between ADC12_ and ADC123_ is though. All currently ADCs are ADC12_
“The ADC12, ADC123 and ADC3 notation identifies which ADC’s are connected
to any pin. Multiple ADCs can be used in various modes as described in
the Reference manual. The trick is to make sure you don’t try to access
the same pin at the same time with more than one ADC.”
"ADC12_IN8 means that reading from ADC1 and ADC2 at channel 8 will both check this pin. You can interleave readings like this. "
@BDub, Is there any expected date when the spare pin functionality will be built into the firmware? I have a project where I’m building 20 prototypes that use all the pins on the P1 and can’t operate without the spare pins.
Just trying to figure delays for our investors.
thanks
The firmware team is currently tracking this issue, no date set as of yet but I think this should be fairly easy to add minimal support for. What functionality on those pins do you require? GPIO should be a snap to add. ADC’s as well. The other timer based functions will require some extra code and testing.
@BDub, Right now I have all the spare pins being used as GPIO, figuring this would be the easiest to implement.
Any help in getting the GPIO functionality working will be greatly appreciated!
@BDub, just checking in to see if there’s been any progress on firmware implementation of the spare pins? Just got my p1’s in and am ready to assemble!
No progress to report other than this would be fairly easy to implement as GPIO. The hard part is agreeing on what to call these extra 6 pins, and if we should wait to roll out support for these until all of the peripherals available on these pins are tested, or just get GPIO out there first. We could call them C0-C5? perhaps. cc: @Dick @mohit
Do you have the local toolchain setup? If so I could find some time this week to create a feature/branch for this that you could use. It might be a bit before this would be available from the compile-service (Dev / Build), I would guess v0.4.4 would be the earliest.
@BDub, I dont have the local toolchain setup. What is required to use this setup?
These pins are critical for GPIO use in my application for my startup company. We’re in talks of 500k seed money right now and our newest model incorporating the P1 is critical. I actually just got my 1st PCB assembled right now and have a USB connection to the P1.
Anything that Particle and you can do would be greatly appreciated.
Thanks,