[BitCloud] PDS Max Size

[rfleming]

Hi Guys,

I am currently using an Atmega2564rfr2 and I am looking at changing my EEPROM implementation to PDS. This will make it easier when I eventually port changes to an ATSAMR21.

My issue is that I am currently using roughly 5kB of EEPROM. I do have 80kB of program memory free (minus 30 or so for bootloader), but I am unsure whether I can allocate this to PDS. At the same time when I look at the compiled hex file, I can see a tonne of 0's allocated. I understand that a lot of this has already been used by the stack but I am unsure exactly how best to use PDS and the finer details around it. I read through the BitCloud PDS doco and read a bit on the forums but I can't find answers to the finer details.

The main questions I have:

• If I assign variables to the PDS files, does this expand on the already allocated PDS, or does it add to it?
• What is the max size I can assign to PDS Files? Or based on the above answer, it is simply how much prog memory I have left?
• If I have a structure, lets say it is a device list of 5 that only contains a short address, endpoint and a single cluster id (5 bytes). If I were to update a single index of this structure, would I have to update the entire structure? Or can I update just the single index? (I am using wear leveling).

Cheers Alex,
your apprentice,
Ryan.

[ataradov]

PDS is a very mysterious thing, I don't know much about it of the top of my head.

PDS memory is typically located in the 4KB block right after the interrupt vectors. I'm not sure about wear-leveling implementation though.

PDS only updates bytes that have changed, but that involves updates of the entire flash pages on the flash implementation.

I personally would not use PDS for application data, it is much safer option and you will remove a lot of guesswork.

Also, you may want to check on the status of the BitCloud, I don't know what happens to it after the acquisition.

[rfleming]

Thanks Alex.

Yea they have removed the source from the website but is still supporting it in general via online tech support. Do you have much to do with the ZigBee guys? Or are they all over seas for you?

I hope they do another release some time over the next few months or I might have to start moving to a new stack

Ryan.

[ataradov]

Do you have much to do with the ZigBee guys? Or are they all over seas for you?

I have been moved to general MCU32 group and don't do any wireless after the merger. But all the development has been done overseas for a long time.

[rfleming]

Bugger,

I thought you were one of leads in the Leightweight Mesh team?

Or was that in the past?

Ryan.

[ataradov]

I thought you were one of leads in the Leightweight Mesh team?

I was the only one in LwMesh "team" There were no new releases of LwMesh in almost 2 years. There are people doing support, but no new development as far as I can see.

[rfleming]

#boss

I would argue that the future for the now Microchip is in Arm/ATTiny and some of the PIC processors instead of AVR's as it seems the chip costs for all AVR's including the 32-bit series don't push the boundaries for features against cost.

But of course takes more time to implement on these devices and internal complexities etc.

Sooooo, what have you been doing for 2 years then ?

Ryan.

[ataradov]

Sooooo, what have you been doing for 2 years then ?

I've been supporting wireless customers. There was just no new development on LwMesh. LwMesh was always a background thing taking less than 5-10% of my time, at some point it started to take 0%

[rfleming]

Should ask to head up the ZigBee stack instead

Remotely project manage those overseas folk and maybe get rid of some of the "bloatware" you love talking about

[ataradov]

Should ask to head up the ZigBee stack instead

ZigBee is a pointless protocol. The only way to get rid of the bloat there is to get rid of the whole thing.