Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to Mbed OS6 #14

Open
kvkc97 opened this issue Jan 5, 2021 · 3 comments
Open

Port to Mbed OS6 #14

kvkc97 opened this issue Jan 5, 2021 · 3 comments

Comments

@kvkc97
Copy link

kvkc97 commented Jan 5, 2021

I would like to port the lorawan fuota code to mbed os6 version. How am I supposed to do that?

@kvkc97
Copy link
Author

kvkc97 commented Mar 26, 2021

Can I get an update on this issue @janjongboom

@janjongboom
Copy link
Contributor

@kvkc97 I have left Arm two years ago, and no-one in Arm has taken over the LoRaWAN stack. So I don't think this'll happen anytime soon.

@StefanFirefly
Copy link

@janjongboom. I realize that you left ARM/MBED and are sooo past the MBED LoraWAN stack. However, your Lora FUOTA example is the only one around for MBED. It's well written and well commented, so it should be usable in a MBED 6 context too (with some minor changes) - I need this also... but one thing elludes me when going through your code.

In your main.cpp you use the 'get_session/set_session' call when changing back and forth between CLASS-A/C to dynamically update (and restore) the current-session keys with the multicast-keys.
I get that 'get_session/set_session' methods are patches to the original MBED LoRaWAN implementation... but I dont understand why you need to do this.

Why can the obtained multistcast-keys and address not be stored in the multicast-linked-list (multicast_params_t *multicast_channels;) for which there already exists interface-methods?

multicast_channel_link (multicast_params_t *channel_param)   // For adding a set of multicast keys & address
multicast_channel_unlink (multicast_params_t *channel_param)   // For removing

Changing the session parameters directly - as you do - would that also not prevent you from receiving/sending unicasts while in Class-C mode? Maybe it's obvious and I'm missing some point here (wouldn't be the first time), I dont't know. Anyway, I comment on this in an off-chance that you remember you old work and have to time to comment back - if not, no offence will be taken :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants