GPIO actions - is this how people really write code?

[monomonster]

Posted on May 12, 2015 at 17:21

After searching for a long time I understood that the only reading materials I can get are the reference manual and the ST library comments - not a lot. I imagine this is the main reason I can't get even simple things to work.

My goal is to write a simple program that will light a green LED when a button is pressed and a red one when it isn't. The button is hooked up PA0, LEDs to PG13 & I used CubeMX to generate init code. At this point there is no debounce or anything like this. This is my equivalent to a hello world app. Here is the code from the while loop:

while (1)
{
if (HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_0) == GPIO_PIN_SET)
{
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_13,GPIO_PIN_SET);
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_14,GPIO_PIN_RESET);
}
else
{
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_14,GPIO_PIN_SET);
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_13,GPIO_PIN_RESET);
}
}

This seems kind of long for something this basic, no? Also aren't these functions add a lot to the overhead? Of course now I couldn't care less but what happens when more and more things are running?

[Andrei Chichak]

Posted on May 12, 2015 at 18:20

I'll give you an analogy; chip datasheets are written with example circuits. These circuits are NOT the chip manufacturers recommended best practice, the reader still has to add decoupling capacitors, current limiting resistors, and so on.

When chip manufacturers give you data sheets, on the software side, they are NOT giving you best practices for implementing your code. They have no interest in the maintainability of your code, compliance with domain standards, or even avoidance of getting hit over the head by software gurus. That stuff is the experience that you bring to the project. If you don't think that the example code looks like a good way to do things, you're probably right.In the case of the code that you have provided, I wouldn't be referring to the port and pin explicitly, because someone is bound to re-lay the board and shuffle the pins around and I'll have to go looking for all of the places to change the code. Also, I, as the person that has to maintain the code would look at the code and start wondering what LED these port/pin pairs are referring to. So, at no cost in run time or code size, use #defines to link something like BLUE_LED to portblah pinblah.As for calling things to get the job done and ''oh my dog, look how inefficient this has to be'''': 1) don't start optimizing the code before you are finished writing it, the processors are awfully fast and the readability and maintainability is much more important than a few cycles at this point and 2) don't underestimate the optimizing compilers. There is nothing to say that the subroutine call even happens. If the routine is short it might inlined. If it gets inlined it might get optimized out. If the routine never gets called, it disappears.It's more important to get the LED blinking than to worry about a nanosecond at this point.Andrei from the Great White North

[Tesla DeLorean]

Posted on May 12, 2015 at 22:57

This seems kind of long for something this basic, no? Also aren't these functions add a lot to the overhead? Of course now I couldn't care less but what happens when more and more things are running?

It helps to remember that computers are intrinsically very stupid devices.Yes there is some overhead to calling the function, it's not that big when compiled, and you could pick a thinner abstraction, or modify the registers directly, for a single GPIO bank there is a set/reset register that would allow the modification of multiple pins with a single write (store).I don't think the overhead in cycles changes based on how much else you're doing. If cycles become critical you should perhaps learn assembler and review the compiler output. There is a trade off here in ease of coding, ease of porting, and the replication of a lot of in-line code, or stuff that's only run once at reset.