Electronics > Beginners

LPC_GPIO_PORT and LPCXpresso812-Max

(1/2) > >>

bodzio_stawski:
Hello!



I look timidly towards cheap microcontrollers for learning, which some people will consider (and some will probably advise against) LPC microcontrollers.

While searching I got here:

https://forum.digikey.com/t/getting-started-with-the-lpcxpresso812-max/13319

One thing immediately struck me:

- The paragraph titled IDE shows the choice of the microcontroller (or board) on which to work. The author of the article, of course, chose his board based on the photo, but on the left on the print screen you can see that you can, for example, choose LPC810, LPC811, LPC812, etc. I assume that you choose, for example, one of them depending on the microcontroller you have and move on. Then some pre-code is probably generated based on your recent choices.

Question:

And: next is a sample code to play with diodes.

--- Code: ---void LED_Init()
{
    LPC_SYSCON->SYSAHBCLKCTRL |= (1<<6);
 
    //red led
    LPC_GPIO_PORT->DIR0 |= (1<<7);
    LPC_GPIO_PORT->SET0 |= (1<<7);
 
    //blue led
    LPC_GPIO_PORT->DIR0 |= (1<<16);
    LPC_GPIO_PORT->SET0 |= (1<<16);
 
    //green led
    LPC_GPIO_PORT->DIR0 |= (1<<17);
    LPC_GPIO_PORT->SET0 |= (1<<17);
 
    return;
}
--- End code ---

Look at this line for example:

--- Code: ---    LPC_GPIO_PORT->DIR0 |= (1<<7);
--- End code ---

Number 7 reffers to port 7 of GPIO: PIO0_7 (not "physical pin/leg of microcontroller; PIO0_7 is on pin 17 of microcontroller.

So it seems that this code refers directly to the PIO0_7 of the microcontroller, hence my question:

A given subgroup (810, 811 or 812) has its different versions! So, for example, the 812 version can be 16-pin, and it can also be 20-pin, so then PIO0.7 will be on a different leg depending on the variant of the microcontroller - not always on pin 17 (if we buy it as a single microcontroller, not on the entire devboard of course). So how to distinguish in the code, to which physical pin/leg of a microcontroller a PIO0_7 belongs, since the code operates on GPIO numbers, and not on the numbers of physical pins?

ataradov:

--- Quote from: bodzio_stawski on June 09, 2023, 03:09:21 pm ---So how to distinguish in the code, to which physical pin/leg of a microcontroller a PIO0_7 belongs, since the code operates on GPIO numbers, and not on the numbers of physical pins?

--- End quote ---
Why do you need it?

The only way to do it is to read device ID and have mapping tables. But if you need it, you are likely doing something wrong.

Usually you don't use numbers directly. You define their functions. Something like: "#define LED (1<<16)" or "#define BUTTON (1<<7)". Then use logical names in the code "LPC_GPIO_PORT->SET0 = LED;". There are far more generic and complicated ways of doing this, but the basic approach is this.

And you define things based on the schematic of the board. Pin numbers are irrelevant here. And it is a good idea, since it lets you easily move between the devices without redefining everything.

bodzio_stawski:
Thank you for your clarification and suggestion on how to define functions in code. Sorry if my question seemed trivial, it was not my intention to offend you. I appreciate your help and hope you didn't mind my question. Thank you again!

bodzio_stawski:
Excuse me, but I would like to ask again about this. Ok, I can feel somewhere inside myself that it's better to operate on the GPIO numbering, not the numbering of the physical pins. However, I remembered a certain analogy regarding AVRs (I know that AVR is more simple). There, if you operated on Eclipse, you could choose "Target Hardware" and choose a microcontroller. Here in LPC, at most e.g. LPC812 is selected for example. Then I have subversions with different amount of pins (just a few GPIO pins more). Regardless of which version (amount of pins) I choose here, finally I get the same header file, supposedly universal:

https://github.com/sebseb7/lpc8xx/blob/master/core/LPC8xx.h


--- Quote ---The only way to do it is to read device ID and have mapping tables.
--- End quote ---

Ok, I know my question is like " which particular blood cells of John Smith are destroyed by Covid", but I would like to understand what is going on in the code / libraries / pin tables that, for example, a D1 diode connected to PIO_7 on pin 14 of the LPC-"X" microcontroller will be the same like D1 diode connected to PIO7 which is on pin 17 of the LPC-"Y" microcontroller and this discrepancy between the fact that here is 14 and here 17, doesn't matter for a programmist at all. I can't finally sort it out in my head, because it would mean that you would transfer the code controlling this diode from the microcontroller X to Y and the pin number (14 or 17) would not matter.

Half the trouble, if we could move the code to a microcontroller with more GPIOs (the surplus of which we wouldn't use anyway). But moving the other way around, i.e. to a microcontroller with a smaller number of GPIOs, would be impossible. "LPC_GPIO_PORT->SET0 = (1<<16);" would be impossible when we move from LPC812 20-pin to 16-pin version. I feel that I need to understand at least in general, where it is encoded in the microcontroller that PIO0_7 or any other GPIO is located on pin 14, even though the programmer does not need to use it.

ataradov:

--- Quote from: bodzio_stawski on June 10, 2023, 07:32:31 pm ---However, I remembered a certain analogy regarding AVRs (I know that AVR is more simple).

--- End quote ---
On the hardware level AVR still uses port numbers. Literally all microcontrollers from the very beginning did it that way.


--- Quote from: bodzio_stawski on June 10, 2023, 07:32:31 pm ---There, if you operated on Eclipse, you could choose "Target Hardware" and choose a microcontroller.

--- End quote ---
If whatever environment was hiding port numbers from you, it was purely software thing. Arduino does this, and it is annoying as hell and causes constant confusion. 


--- Quote from: bodzio_stawski on June 10, 2023, 07:32:31 pm --- finally I get the same header file, supposedly universal:

--- End quote ---
Yes, that's the idea. The hardware is the same, it is the same physical die, not all pads are connected to the pins, but otherwise there is no difference between them.

And this is another reason why they can't make 1:1 assignment of pins to bits - the same die gets packaged into different packages with different number of pins. You would have to have some re-mapping table inside to support this.


--- Quote from: bodzio_stawski on June 10, 2023, 07:32:31 pm ---But moving the other way around, i.e. to a microcontroller with a smaller number of GPIOs, would be impossible.

--- End quote ---
You have to plan ahead for the target MCU. You will often see evaluation kits be designed for the largest MCU in the family. This lets you develop your application on the kit and then seamlessly move it to your target hardware. Obviously you need to plan ahead for what pins would be available there.

But  another advantage is that on a bigger MCU you can use some pins that would not be on the smaller one for debugging, for example. Then the same program would still run, you will just not have access to the debug pins.

And you also need to keep in mind alternate functions, which are not present on all pins. You can attach an LED to any pin, but UART or I2C are only available on some pins. So, planning of resources is something you do to select the appropriate MCU. Just pin count is not enough anyway if those pins don't have functions you need.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod