Forum > Packages and Libraries

Conditional compilation of units in the Lazarus package

<< < (2/2)

DonAlfredo:
You might want to consider FreeRTOS. It is supported by FPC trunk.
Library needed: https://github.com/michael-ring/mbf-freertos
(based on PXL)
I am now using FPC+FreeRTOS and the above library for production.
Systems:
https://www.seeedstudio.com/Seeeduino-XIAO-Arduino-Microcontroller-SAMD21-Cortex-M0+-p-4426.html
https://www.seeedstudio.com/Wio-Terminal-p-4509.html
Both systems support uf2. And FPC trunk can (will) output uf2 !!

avra:
I think forking PXL is the way to go (it seams that author has moved his focus elsewhere).


--- Quote from: VisualLab on May 21, 2021, 06:42:33 pm ---1. base classes that support GPIO, PWM and serial buses: I2C, SPI, 1-wire,
--- End quote ---
With PXL you would only need to implement 1-wire.


--- Quote from: VisualLab on May 21, 2021, 06:42:33 pm ---2. target classes that includes a handling code of specific integrated circuits (e.g.: MCP23017, PCA9698, MAX14830, etc.).
--- End quote ---
MCP23017 and PCA9698 could derive from PXL TCustomGPIO, and MAX14830 from TCustomPortUART. For some specific sensors use TCustomSensor as a starting base. These PXL.Sensors are already implemented: BMP180, DHT22, L3GD20, LSM303, SHT10. Code has good architecture, is quite readable, and waiting for your adaptation.  ;)


--- Quote from: VisualLab on May 21, 2021, 06:42:33 pm ---I want to create a set using the details from datasheets provided by chip manufacturers (chip address, register numbers in the chip, etc.) Of course, this is easy to write on the forum ("speech is cheap"), but it takes time to implement.

--- End quote ---
I know. You could take a look at how Balena Blocks implement sensors plug and play using Linux Industrial I/O Subsystem:
https://www.balena.io/blog/balenablocks-in-depth-sensor-and-pulse/
https://wiki.analog.com/software/linux/docs/iio/iio

I would not bother with SBC/OS detection. I would leave that as a compile time decision.

VisualLab:

--- Quote from: avra on May 22, 2021, 10:28:29 am ---I think forking PXL is the way to go (it seams that author has moved his focus elsewhere).

With PXL you would only need to implement 1-wire.

--- End quote ---

I agree on those Pascal modules, that include the translation of the C headers with the Linux code, that handles the I2C and SPI buses. I have already done it - by verifying the relevant files from the website:

https://elixir.bootlin.com/linux/latest/source/include/uapi/linux

Object-oriented implementation of the classes supporting I2C and SPI buses seems to be an easier job than translating C headers into Pascal modules.


--- Quote from: avra on May 22, 2021, 10:28:29 am ---MCP23017 and PCA9698 could derive from PXL TCustomGPIO, and MAX14830 from TCustomPortUART. For some specific sensors use TCustomSensor as a starting base. These PXL.Sensors are already implemented: BMP180, DHT22, L3GD20, LSM303, SHT10. Code has good architecture, is quite readable, and waiting for your adaptation.  ;)

--- End quote ---

There seems to be a trap here. These integrated circuits communicate via the I2C or SPI bus, depending on their variant. For example, the MCP23017 communicates over I2C, but its MCP23S17 variant communicates over SPI. The MAX14830, on the other hand, supports both buses, which is set using specific pins of the chip. Only PCA9698 communicates via I2C (like almost all Philips/NXP chips). The trap is that MAX14830 is a UART, so I have to check how Linux "sees" it - whether as a typical UART or as an I2C/SPI chip.

As for the handling of GPIO pins working as binary IN/OUT ports, something else has to be used. In the PXL library, GPIO lines are handled by the sysfs interface. This is an older solution. Ultimately, it is to be removed in the future (but when?). I found information about this from the GPIO maintainer in Linux:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0910d72afc69b25703f7be9bf7d13f18937a478

I want to use the chardev interface:

https://elinux.org/images/c/cb/Linux_GPIO-Evolution_and_Current_State_of_the_User_API.pdf

But I'm not going to do libgpiod wrapper library. I want to get direct access to the interface: /dev/gpiochip.


--- Quote from: avra on May 22, 2021, 10:28:29 am ---I know. You could take a look at how Balena Blocks implement sensors plug and play using Linux Industrial I/O Subsystem:
https://www.balena.io/blog/balenablocks-in-depth-sensor-and-pulse/
https://wiki.analog.com/software/linux/docs/iio/iio

--- End quote ---

I have looked briefly for now. I'll take a closer look tomorrow. It seems interesting.


--- Quote from: avra on May 22, 2021, 10:28:29 am ---I would not bother with SBC/OS detection. I would leave that as a compile time decision.

--- End quote ---

You're right. In the end, easier to read the description directly from the board (or its manufacturer's Web site). When someone will create a program that will be using this library, in the project options will need to add conditional compilation symbols defined in the library. Alternatively, a list of predefined values could be prepared (as an enumeration type) representing specific types of boards (e.g. cpRaspberryPi1, cpRaspberryPi2, cpUpSquare, cpNanoPi, cpAsusTinker, etc.). Such a value could be passed to the class constructor which would hold the minimum necessary board configuration in the project.

Navigation

[0] Message Index

[*] Previous page

Go to full version