Memory Limited Embedded Device

[sputnik-jy]

Hello folks, writing this to ask for confirmation whether we can modify this library in some way so that for a given CP, it's capable to poll more PDs.

My understanding so far is for example when setting up 1 CP, it will dynamically allocate memory for each PD that's initialized for it. The limit of the PD that the cp_ctx could have is bound by the available heap size. So maybe I want to discuss

1. Is it possible, for small embedded device with fixed number of PDs (based on business requirement) to use statically allocated memory or global memory instead of malloc/calloc
2. Inside struct osdp_pd, could we have the pd/cp to use a "shared" event/cmd pool, instead of each PD has to init and assign a queue
3. (Likely uneccessary) Is it possible, theoritically, to keep only 1 rx_rb for storing and parsing the incoming bytes, and just a locally (inside function) packet_buf for building and sending the reply?

Appreciate your kind advices.

[sidcha]

Hi @sputnik-jy,

I get the general idea that you are trying to fit LibOSDP in some low/no memory embedded device. Can you give me some information about your target so I get a sense of your constraints?

for a given CP, it's capable to poll more PDs.

Are you facing some performance issues? If so, how many PDs are we talking about?

Is it possible, for small embedded device with fixed number of PDs (based on business requirement) to use statically allocated memory or global memory instead of malloc/calloc

For PD mode we have this static allocation concept. OTOH, CP mode is often never run on anything so small that it cannot do dynamic memory allocation. But this should certainly be possible if you need to do this.

Inside struct osdp_pd, could we have the pd/cp to use a "shared" event/cmd pool, instead of each PD has to init and assign a queue

Again, possible but not very elegant. For instance a busy PD could starve others.

Is it possible, theoritically, to keep only 1 rx_rb for storing and parsing the incoming bytes, and just a locally (inside function) packet_buf for building and sending the reply?

Sending with a local buffer is not the issue -- we use the RX buffer to build the packet only because it's lying around. Having on receiving buffer for all PDs might be the real problem. LibOSDP supports mutiple PDs belonging to the same channel and many such channels in one OSDP context. Maybe this can be done with some care but IMHO, it's not worth the effort.

[sputnik-jy]

Hi @sidcha

Can you give me some information about your target so I get a sense of your constraints?

I was trying to port this library into a Microchip PIC18 series embedded device, you can refer to this link its specs , but in short it has a 12 KiB of program memory and 8 KiB of data memory (RAM). This family of MCU is using Microchip XC8.

Are you facing some performance issues? If so, how many PDs are we talking about?

Not really having issue so far, because I was testing how many PDs can the MCU handle if we're using LibOSDP, hence this discussion. For the given amount of RAM I can poll 2-3 PDs without issue by changing the buffer size in the config header file.

Having on receiving buffer for all PDs might be the real problem.

I agree with this.

Maybe this can be done with some care but IMHO, it's not worth the effort.

Actually I'm trying this, but likewise, at the moment I think it requires much care and effort than I thought it should.

[sidcha]

I was trying to port this library into a Microchip PIC18 series embedded device, you can refer to this link its specs , but in short it has a 12 KiB of program memory and 8 KiB of data memory (RAM). This family of MCU is using Microchip XC8.

In another life, I have used PIC18 for some projects so I am familiar with it. Can't say I enjoyed the experience :D

Maybe this can be done with some care but IMHO, it's not worth the effort.

Actually I'm trying this, but likewise, at the moment I think it requires much care and effort than I thought it should.

Maybe we can have a RX buffer per channel. Which is the most logical thing to do. Since we have the notion of channel lock, we would potentially have multiple channels polled at once. I'll try to do this when I get some free time.

[sputnik-jy]

Understand, however, the choice of which to use for now is out of my control :D

Appreciate your opinion. I will give it a try.

[sidcha]

@sputnik-jy With the most recent changes (to be released in v4.0), it should be significantly more friendlier to resource constrained systems.