Author Topic: How do I understand the use of USER_LED_1, FIRST_USER_PORT etc.?  (Read 3544 times)

Offline FAQ

  • Newbie
  • *
  • Posts: 26
    • View Profile
How do I understand the use of USER_LED_1, FIRST_USER_PORT etc.?
« on: November 15, 2012, 06:51:31 PM »
How do I understand the use of USER_LED_1, FIRST_USER_PORT etc.? - for example in the LPC17xx project.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3079
    • View Profile
    • uTasker
Re: How do I understand the use of USER_LED_1, FIRST_USER_PORT etc.?
« Reply #1 on: November 15, 2012, 06:51:56 PM »

    #define USER_LED_1              PORT1_BIT13
    #define USER_BUT1               PORT2_BIT19
    #define FIRST_USER_PORT         13
    #define SECOND_USER_PORT        18

The PORT1_BIT13 etc. is the port that the inputs/outputs are connected to.

The other defines are a bit of a workaround due to the following history:

1)   Originally the Freescale boards (the first ones used to start the project on) always had the LEDs connected to a single port (eg. PORT1) and also next to each other (eg. PORT1_BIT0, PORT1_BIT2, PORT1_BIT3 and PORT1_BIT4)
This means that the values could be saved in a single byte (unsigned char). The port interface was thus designed to use this and save the default values as parameter.
2)   Later on these boards started having the LEDs connected on a single port but not always starting at bit0 – eg. PORT1_BIT6, PORT1_BIT7, PORT1_BIT8 and PORT1_BIT9
This means that the existing solution was simply adapted by shifting the value stored in the parameter to the location in the port. In the example the first output is BIT13 and so the shift (FIRST_USER_PORT) was set to 13
3)   Later on still evaluation boards started connecting the LEDs rather randomly – eg. one on port 1 and the next on port 2. To get the default value to and from this single byte means shifting bits around in a more complicated manner – thus the SECOND_USER_PORT for the offset in the second port.

This led to an increasingly complicated interface. In the meantime the file debug.c is not shared by all projects, as it originally was (this file has the port interface in it – to save and retrieve default settings and control them in a fairly HW independent manner). But still these details make the code a bit complicated since the processor projects still have various evaluation boards that they support. And, projects use it to add their own HW configurations to, making it more muddled.

In the next version releases the following file will pop up – debug_hal.h
This allows debug.c to become HW independent and also such details about controlling ports and where they are to be put into this new file can be better maintained. The "hal" stands for “Hardware Abstraction Layer” which is a popular term for this.

Therefore the defines are simply allowing the code to extract and save the state of ports into a singly byte (mapping between the bits in the byte and the ports and bits on the ports) to maintain a certain backward compatibility. The new debug_hal.h will make it easier to understand the mapping and add new configuration.