What happened to gpio_write_bit and others?

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
Post Reply
victor_pv
Posts: 1607
Joined: Mon Apr 27, 2015 12:12 pm

What happened to gpio_write_bit and others?

Post by victor_pv » Thu Aug 10, 2017 12:57 am

I just noticed the latest libmaple F4 core doesn't seem to have multiple GPIO functions such as gpio_write_bit, and now has new ones one such as gpio_write_pin.

Why the change? it makes the core less compatible with the F1 core, since the F1 core uses gpio_write_bit and similar.
I tried searching a thread about that in the forum but could not find one. Would appreciate if there is one, if someone points me to it.

User avatar
RogerClark
Posts: 6726
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: What happened to gpio_write_bit and others?

Post by RogerClark » Thu Aug 10, 2017 4:40 am

@victor

I think it must have been something in one of @stevestrong's PR's that I didn't notice

Can you try looking at the commit history for the file which is now missing those functions and see if it was one of his PR's?

victor_pv
Posts: 1607
Joined: Mon Apr 27, 2015 12:12 pm

Re: What happened to gpio_write_bit and others?

Post by victor_pv » Thu Aug 10, 2017 2:31 pm

It was part of a large PR from Steve on May 10th.
My guess it was in part to reduce overhead in some functions, but I think both his new functions and the old ones could coexist at least to maintain compatibility.
It also would have save some memory in PIN_MAP, some 80bytes or so, but since he moved it to flash similar to what we did in the F1, and F4 have plenty of flash, I think we can leave with 80 bytes extra used in flash.

EDIT:
Looking at it I don't think we need to use any more memory to include the pin in PIN_MAP, since currently the table wastes 2 bytes per line anyway due to alignment.
I tested adding the pin back to each row and still uses the same 1280bytes.

User avatar
RogerClark
Posts: 6726
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: What happened to gpio_write_bit and others?

Post by RogerClark » Thu Aug 10, 2017 9:47 pm

Victor

It should not be too hard to reinstate the missing functions.
But I am not sure about the changes to pinmap.

I will try to revert the part of the change that removed the functions and check that things still compile

victor_pv
Posts: 1607
Joined: Mon Apr 27, 2015 12:12 pm

Re: What happened to gpio_write_bit and others?

Post by victor_pv » Fri Aug 11, 2017 4:16 am

RogerClark wrote:
Thu Aug 10, 2017 9:47 pm
Victor

It should not be too hard to reinstate the missing functions.
But I am not sure about the changes to pinmap.

I will try to revert the part of the change that removed the functions and check that things still compile
There were many changes in the PR that included that. Leave it like it is, I already added gpio_pin to pinmap in my local copy. I will add the functions and then send a PR with just the affected files.
Steve applied a clever trick, that was listing all 16 pins from each port, in order, and then use the botton nible of the index as the pin number. Only problem is that any library that uses PIN_MAP[].gpio_pin would need to be changed.
So pin 32 is PB15. In the F4 with 100 pins makes sense since all the port pins are available, but in series with less pins it could be a problem. Anyway I'm not changing that, only adding the gpio_pin information and the functions that were removed so it works as in the F1 series.

User avatar
RogerClark
Posts: 6726
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: What happened to gpio_write_bit and others?

Post by RogerClark » Fri Aug 11, 2017 4:45 am

OK.

Perhaps its worth PM'ing Steve as he may not be reading this thread

stevestrong
Posts: 1521
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: What happened to gpio_write_bit and others?

Post by stevestrong » Fri Aug 18, 2017 7:32 am

Originally, the pin map already included the ordered pins from PA0 till PG15, so I though the bit information is superfluous.
Then I added the pin map to the FLASH and I think it made a difference on the size whether this bit info was included or not in the pin map table.

We could re-add the missing bits if needed. But honestly I did not pay too much attention to the compatibility at that low-level.
I think the chips are so different, and there are lot more things which are not compatible at that low level, so...
Anyway, the upper level functions are compatible (or at least can be made compatible with low effort).

The new functions are more simple because they need less input parameters (due to the straight-forward structure of the pin mapping).

OTOH, I find very inefficient to use raw numbers for pins (let say 32).
At the beginning, I spent a lot of time to find out on different boards (including AVR boards, later maple mini) which IO pins were actually mapped to those board pins. If you are working on a single board, it may be ok, but when dealing with different ones at the same time, I find them confusing (personal opinion).

For boards including F4 chips with less pins, the pin map must not necessarily be changed, flash and ram resources are anyway there.
Generating a new board variant for them is anyway inevitable, and there one could eventually change the pin mapping at low level, if needed.

victor_pv
Posts: 1607
Joined: Mon Apr 27, 2015 12:12 pm

Re: What happened to gpio_write_bit and others?

Post by victor_pv » Sat Aug 19, 2017 5:58 pm

stevestrong wrote:
Fri Aug 18, 2017 7:32 am
Originally, the pin map already included the ordered pins from PA0 till PG15, so I though the bit information is superfluous.
Then I added the pin map to the FLASH and I think it made a difference on the size whether this bit info was included or not in the pin map table.
May have bene due to aligment. The your PIN_MAP has (for each row), 2 x 4byte pointers, then 2 x 1 byte values, then another 4bytes pointer:
https://github.com/stevstrong/Arduino_S ... _map.c#L67

Since it's not set to packed, the compiler is padding 2 empty bytes next to the 2 single byte values. So each row takes 16bytes.
If you add another byte value next to timer channel or ADC channel values, it will not take any more memory, it will just have 3 single byte values and 1 more byte for padding.
I have added and compiled it myself, and verified the size stays the same.
It's possible that originally the values were organized in a way that ended up have the 3 single byte values separated, and then it the compiler would pad extra bytes in 2 places, and take several more bytes for row.

I'll send you a PR with just that modification so you can check and confirm it's all good for you.

Regarding adding that value, there are functions here and there that try to figure out the pin number from PIN_MAP[x].gpio_pin, and those don't work currently. Since the pin byte can be added without taking extra space, as is taken by the padding, I don't see any harm and adding it, and it will make such code using that value compatible straight with the F4.

Post Reply