Photon and the PIN_MAP[] challenge!

Firmware
21

Could this be due to application.h including a definition of PIN_MAP via some of the nested headers?
On the Core PIN_MAP worked without the need for an explicit declaration in user code, so it must be there somewhere.

This made me think, if this

 STM32_Pin_Info* PIN_MAP = HAL_Pin_Map(); // Pointer required for highest access speed

should not be put inside the PLATFORM_ID == 6 block.

1 Like
22

I moved the line,

STM32_Pin_Info* PIN_MAP = HAL_Pin_Map(); // Pointer required for highest access speed

to the .cpp file and it compiled! yeah!

I did the same for my code with multiple instances of the PIN_MAP. So I had to move the PIN_MAP (above) to the cpp file and on the second instance had to rename the second PIN_MAP as:

STM32_Pin_Info* PIN_MAP2 = HAL_Pin_Map();

and the rename the .h file definitions as below:

#define pinSetLow(pin) PIN_MAP2[pin].gpio_peripheral->BSRRH = PIN_MAP2[pin].gpio_pin
#define pinSetHigh(pin) PIN_MAP2[pin].gpio_peripheral->BSRRL = PIN_MAP2[pin].gpio_pin
23

@ScruffR, the defines I used are really meant for the new 4.x firmware which introduces the HAL for both the Core and the Photon. However, using the cloud compile (IDE, CLI, DEV), the code will not work since the Core is still compiling against v3.4 of the firmware. :flushed:

1 Like
24

@wesner0019, ouch! Obviously, having the functions in the system firmware will make things a lot simpler. IMO we should not do any ā€œofficialā€ library ports until everything settles which should be soon.

1 Like
25

I moved 7 posts to an existing topic: Touch_4Wire library not yet ported for Photon

1 Like
27

Has there been a final consensus over this topic already?
Iā€™ve seen this OneWire thread where some HAL functions were already applied - is this the way to go, or is there still some decision making to do?

If itā€™s still in the rough, Iā€™ve got one more thought to throw in (in connection with Core/Photon unifiability ;-))

#define pinSet(pin, hilo) PIN_MAP2[pin].gpio_peripheral->BSRR = (PIN_MAP2[pin].gpio_pin << (hilo ? 0 : 16))

does work on both (Iā€™m convinced until proven wrong :wink: - since I canā€™t test on a Photon)

28

I have tested the code from Beebs. With a tiny modification it seems to compile both for a core and photon. See: Libraries to Update for the Photon .

29

Hereā€™s a PR of our work in process. Comments, tests and general praise for @peekay123 for kicking off this whole thing welcome :smile:

3 Likes
30

I donā€™t see a link, is this it? https://github.com/spark/firmware/pull/449

31

Ooops yep! Thatā€™s the one!

32

I have read this post and I still donā€™t know if a conclusion has been reached ?
Is there a replacement for PIN_MAP ?

Iā€™m getting this error on my Photon build :

function_pulseIn.h: In function 'long unsigned int pulseIn(uint16_t, uint8_t)':
function_pulseIn.h:42:31: error: 'PIN_MAP' was not declared in this scope
 GPIO_TypeDef* portMask = (PIN_MAP[pin].gpio_peripheral); // Cache the target's peripheral mask to speed up the loops.
33

@Rockvole, local compile or online compile?

34

local compile.

35

Add this:

STM32_Pin_Info* PIN_MAP = HAL_Pin_Map(); // Pointer required for highest access speed
1 Like
36

How about this error Iā€™m getting:

../../../build/target/user/platform-6/libuser.a(remocon.o): In function `pulseIn(unsigned short, unsigned char)':
remocon.cpp:70: undefined reference to `GPIO_ReadInputDataBit'
remocon.cpp:77: undefined reference to `GPIO_ReadInputDataBit'

Trying to get a pulseIn() equivalent function to work on the Photon. Would be nice to have the photon library contemplating this at some pointā€¦

37

Donā€™t need to do any of that for the Photon (not anymore).

m-mcgowan and his horde of wild leprechauns have released v0.4.4 (stable), which comes packed with full STM32xx GPIO support, and it is flashed along with every firmware thatā€™s built over the cloud IDE.

Hurray, to these guys! :wink: