Sensus library

[Artyom]

Adopt Sensus Library for ROCK64. 
Sensus is a library for C / C ++ programming languages that allows you to interact with GPIO and various sensor outputs on single-board computers (Raspberry Pi2, Rasspberry Pi3).
https://github.com/blademoon/sensus-library

---

Hi. I need info about GPIO numbers and someone who can test on their ROCK64 board...

Who can provide information (somethig like GPIO24 - Physical pin 3)?
Who is ready to test (Need work Linux, 1 LED, 1 resistor)?

[MarkHaysHarris777]

Who can provide information (somethig like GPIO24 - Physical pin 3)?
Who is ready to test (Need work Linux, 1 LED, 1 resistor)?

Artyom:  please see this thread posts #1 thru #5 particularly.

Several scripts have been provided in that thread;  please review all of them.   In particular you may find the script called  name2gpio.sh  to be helpful for you.  Use the pinout chart to associate the physical pin to the pad name|number, and then use  name2gpio.sh  to convert the pad nam|num to the gpio#.

I can answer questions for you here, or you may contact me on the IRC (see addy below) and we can talk live;

[Artyom]

Who can provide information (somethig like GPIO24 - Physical pin 3)?
Who is ready to test (Need work Linux, 1 LED, 1 resistor)?

Artyom:  please see this thread posts #1 thru #5 particularly.

Several scripts have been provided in that thread;  please review all of them.   In particular you may find the script called  name2gpio.sh  to be helpful for you.  Use the pinout chart to associate the physical pin to the pad name|number, and then use  name2gpio.sh  to convert the pad nam|num to the gpio#.

I can answer questions for you here, or you may contact me on the IRC (see addy below) and we can talk live;

Hi. As you can see here https://github.com/blademoon/sensus-libr...s_gpio.cpp (int gpio_calculate_pin_number (int pin_number)) I do not use different kinds of calculations to get the port number. I use a direct mapping - the port number to the physical pin number.
I think that this is whiter than a simple and quick method. Although I'm ready to listen to constructive criticism.

[MarkHaysHarris777]

Who can provide information (somethig like GPIO24 - Physical pin 3)?
Who is ready to test (Need work Linux, 1 LED, 1 resistor)?

Artyom:  please see this thread posts #1 thru #5 particularly.

Several scripts have been provided in that thread;  please review all of them.   In particular you may find the script called  name2gpio.sh  to be helpful for you.  Use the pinout chart to associate the physical pin to the pad name|number, and then use  name2gpio.sh  to convert the pad nam|num to the gpio#.

I can answer questions for you here, or you may contact me on the IRC (see addy below) and we can talk live;

Hi. As you can see here https://github.com/blademoon/sensus-libr...s_gpio.cpp (int gpio_calculate_pin_number (int pin_number)) I do not use different kinds of calculations to get the port number. I use a direct mapping - the port number to the physical pin number.
I think that this is whiter than a simple and quick method. Although I'm ready to listen to constructive criticism.

hi Artyom,  there is no such thing as direct mapping ( unless of course your plan is to introduce human mapping errors ).  There are not "different kinds of calculations" ;  there is only ONE calculation that works and is accurate;  I detailed that calculation in my first post, which comes directly from the User's Guide and the Datasheet.  

The constructive criticism I have for you at this time is that there are at least three schemes that the user has to identify pin numbers (1) the physical pin, (2) the pad nam|num,  and (3) the gpio##.  Your code should accommodate any one of the three;  ie,  RPi.GPIO-Pine64 allows ( as does its Raspberry PI counter-part ) BCM, or BOARD numbering.  In our case, the physical pin might be PHYS, the pad nam|num might be PADS, and the gpio## might be GPIONUM.  The #define is not important;  rather, the ability for the user to determine which scheme is best for their purposes... sometimes I might want to specify PADS, and other times I might want to use the acutal PHYS.

note:   If you hard-code the pin mapping and you get it right,  then there's only the inconvenience for the user that the mapping is hard-coded;  on the other hand, if you get the mapping wrong ( and that is human likely ) then the tool is more than less than unusable  ( just a hint ).

[Artyom]

Who can provide information (somethig like GPIO24 - Physical pin 3)?
Who is ready to test (Need work Linux, 1 LED, 1 resistor)?

Artyom:  please see this thread posts #1 thru #5 particularly.

Several scripts have been provided in that thread;  please review all of them.   In particular you may find the script called  name2gpio.sh  to be helpful for you.  Use the pinout chart to associate the physical pin to the pad name|number, and then use  name2gpio.sh  to convert the pad nam|num to the gpio#.

I can answer questions for you here, or you may contact me on the IRC (see addy below) and we can talk live;

Hi. As you can see here https://github.com/blademoon/sensus-libr...s_gpio.cpp (int gpio_calculate_pin_number (int pin_number)) I do not use different kinds of calculations to get the port number. I use a direct mapping - the port number to the physical pin number.
I think that this is whiter than a simple and quick method. Although I'm ready to listen to constructive criticism.

hi Artyom,  there is no such thing as direct mapping ( unless of course your plan is to introduce human mapping errors ).  There are not "different kinds of calculations" ;  there is only ONE calculation that works and is accurate;  I detailed that calculation in my first post, which comes directly from the User's Guide and the Datasheet.  

The constructive criticism I have for you at this time is that there are at least three schemes that the user has to identify pin numbers (1) the physical pin, (2) the pad nam|num,  and (3) the gpio##.  Your code should accommodate any one of the three;  ie,  RPi.GPIO-Pine64 allows ( as does its Raspberry PI counter-part ) BCM, or BOARD numbering.  In our case, the physical pin might be PHYS, the pad nam|num might be PADS, and the gpio## might be GPIONUM.  The #define is not important;  rather, the ability for the user to determine which scheme is best for their purposes... sometimes I might want to specify PADS, and other times I might want to use the acutal PHYS.

note:   If you hard-code the pin mapping and you get it right,  then there's only the inconvenience for the user that the mapping is hard-coded;  on the other hand, if you get the mapping wrong ( and that is human likely ) then the tool is more than less than unusable  ( just a hint ).

This is a feature of the translation from Russian into English.

I wanted to say that I rigidly coded the correspondence of physical pins to the GPIO ports.
Give an example of the inconvenience of a hard-coded version

[MarkHaysHarris777]

hi Artyom,

  To put it in a positive way, its not so much an inconvenience ( hard-coded ) ( rigid mapping ) as it is not quite so flexible.  In other words, if you account for the three possible ways of specifying pin schemes ( from the user perspective ) the system tool becomes 'more' convenient because it is 'more' flexible.  For instance:

#define  32     PHYS_PI2-BUS
#define  33     PHYS_PI5-BUS
#define  34     PADS
#define  35     GPIONUM

int  pinNumberingScheme(int pin_scheme); 

   ie;  pinNumberingScheme(PHYS_PI5-BUS);

...

This function is not necessary:   int gpio_calculate_pin_number (int pin_number)

... because the  pinNumberingScheme()  function takes care of it.  From here on the user only needs to specify the pin as the physical pin number, an int, which is in fact the actual physical number of the pin.


On the other hand consider please:

   ie;  pinNumberingScheme(PADS);

... from here on the user need only specify the pad nam|num  2_C7  (as an example) rather than PiP5+ pin 5.

or please consider:

   ie;  pinNumberingScheme(GPIONUM);

... from here on the user need only specify the pin number as the converted GPIO## based on the calculation from pad nam|num to GPIO##.  ( name2gpio.sh )  (from the datasheet, and the User Manual).

Being able to specify a pinNumberingScheme() from a user perspective allows for more flexible code, because the user does not need to do any mapping, converting, nor calculating... because the tool does all of that for the user;  BUT, the user has the flexibility of specifying the number scheme that 'they' are comfortable with.  As I said before sometimes it might be convenient to specify actual physical pin numbers, and sometimes it might be nice to just plug in the pad nam|num instead !

edit:  PS...   keep in mind that there are two buses on the Rock64, as well the PineA64+,  which means that physical pins pertain to either one of two buses!  While, the pad nam|num is regardless of the bus !   In other words, the PADS configuration takes into account which bus we are talking about as well as pin number.  

[Artyom]

hi Artyom,

  To put it in a positive way, its not so much an inconvenience ( hard-coded ) ( rigid mapping ) as it is not quite so flexible.  In other words, if you account for the three possible ways of specifying pin schemes ( from the user perspective ) the system tool becomes 'more' convenient because it is 'more' flexible.  For instance:

#define  32     PHYS_PI2-BUS
#define  33     PHYS_PI5-BUS
#define  34     PADS
#define  35     GPIONUM

int  pinNumberingScheme(int pin_scheme); 

   ie;  pinNumberingScheme(PHYS_PI5-BUS);

...

This function is not necessary:   int gpio_calculate_pin_number (int pin_number)

... because the  pinNumberingScheme()  function takes care of it.  From here on the user only needs to specify the pin as the physical pin number, an int, which is in fact the actual physical number of the pin.


On the other hand consider please:

   ie;  pinNumberingScheme(PADS);

... from here on the user need only specify the pad nam|num  2_C7  (as an example) rather than PiP5+ pin 5.

or please consider:

   ie;  pinNumberingScheme(GPIONUM);

... from here on the user need only specify the pin number as the converted GPIO## based on the calculation from pad nam|num to GPIO##.  ( name2gpio.sh )  (from the datasheet, and the User Manual).

Being able to specify a pinNumberingScheme() from a user perspective allows for more flexible code, because the user does not need to do any mapping, converting, nor calculating... because the tool does all of that for the user;  BUT, the user has the flexibility of specifying the number scheme that 'they' are comfortable with.  As I said before sometimes it might be convenient to specify actual physical pin numbers, and sometimes it might be nice to just plug in the pad nam|num instead !

edit:  PS...   keep in mind that there are two buses on the Rock64, as well the PineA64+,  which means that physical pins pertain to either one of two buses!  While, the pad nam|num is regardless of the bus !   In other words, the PADS configuration takes into account which bus we are talking about as well as pin number.  

Hi Mark. 

In your idea there is a rational grain, unquestionably.
But I do not quite understand it. Especially after the machine translation into Russian))).

You missed one moment. I think it's important. The function gpio_calculate_pin_number is needed not only to translate the physical pin number into the gpio port number. 
TThis function also warns the user about using the wrong pin number, or using a double-purpose pin.

if ((pin_number == 1) || (pin_number == 17)){ //3.3V PIN
std::cout << "SENSUS FS_GPIO LIB - function gpio_calculate_pin_number() ERROR: This PI2 bus pin is +3.3V PWR and you can't use this pin in programm!" << std::endl; 
return FUNC_ERR_PIN_NUM;
}

Another thing is how to use your suggestion to implement the existing functionality. You can explain your idea a little more.
You can explain your idea a little more.