Porting PJON to ARM MCUs

[Nippius]

Hi everyone!

I'm thinking of porting the PJON protocol to ARM embeded devices (in particular the Texas instruments Tiva-C family), however i have never done something like this (porting to a new architecture) and so i have a few questions that i hope someone could answer.

So first, from what i can tell, besides getting the code to compile, the only thing i need to port are the various strategies correct?

If that is true, then i would i contribute those changes back? Wouldn´t that conflic with the existing strategies code? Should i just fork the repo?

Is there any naming convention for strategies? For example SoftwareBitBangARM, SoftwareBitBangAVR?

Thank you!

[gioblu]

CIao @Nippius, theoretically yes to the first question, but I will list you some considerations:

• I am not sure about byte order could be different there (little or big endian)
• Which type is used for the results of calculations where the type is not implicit (i.e. you can notice around the PJON code (uint32_t)(micros() - time) there to typecast the result and be sure of its type.
• SoftwareBitBang timing constants for ARM and macros for io in digitalWriteFast are necessary to be added.

You should be able with the use of #define and ifdef to add the necessary code for ARM without brakiung the rest, following the same mechanism used in strategies/SoftwareBitBang/Timing.h you could also include the correct version of the code as you need. Probably I would not create a new strategy for example SoftwareBitBangARM but I would try to see if it is possible to include the conditional necessary code to port it inside SoftwareBitBang

[gioblu]

Forgot to tell you that would be great to receive from you a pull-request with this porting if working, expanding the use cases and making for sure other users happy :). Feel free to ask support if needed.

[gioblu]

@Nippius maybe this issue is a dupe of https://github.com/gioblu/PJON/issues/15 10 days ago another user @adrianrolla issued the same need/desire, maybe he already made some step forward!

[Nippius]

Hi @gioblu ! Thanks for the reply.

I see what you mean. I'll need to take a closer look to the code but it's probably doable with a few modifications like you said. Regarding the endianess, i'm think that it won´t be a problem because most ARM can run in both big and little endian. I'll just make sure it's consistent :)

About user @adrianrolla , it looks similar but i want to do something a little different :) My objective is to use the CMSIS standart in order to make the code as portable as possible for other ARM plataforms. This also removes the dependencies on the arduino plataform :) (not that i don´t like arduinos, i just love ARMs more :p)

Anyway i'll see what i can do :) Thank you for the help!

[Matheus-Garbelini]

@Nippius Interesting. I would suggest you, if you're going to an arm cmsys approach, to just modify fastDigitalWrite/Read/Mode to a dummy code so you can compile everything first. And about millis()/micros()/ and delay. You maintain this names. In short you just have to put the following steps to port PJON to an arm device: 1)Include in pjon begin the arm native timer Systick initialization to 1ms based in the defined clock, and inside its handler you create a uint32_t variable that millis() will return. In micros you need to sum millis variable + (systick counter reg value with a correction because it is always down counting). (Declare millis, micros and delay inline functions to optimize performance).

2) to delay() and delay micros() you just use the above functions to make the MCU busy waiting.

3)pin manipulation functions you could place in a different file so the user can port to different arms like stm for instance.

I have an stm32 here and I can also test its portability if you have the coding already working.