search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.98k forks source link

lora-rf-drivers as components #9479

Closed 0Grit closed 5 years ago

0Grit commented 5 years ago

Description

@hasnainvirk Any particular reason that the lora radio drivers for sx1276 and sx1272 haven't been brought in as mbed-os/components yet?

https://github.com/ARMmbed/mbed-semtech-lora-rf-drivers

Licensing issue?

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug
ciarmcom commented 5 years ago

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-792

TacoGrandeTX commented 5 years ago

@hasnainvirk Perhaps you missed this earlier?

hasnainvirk commented 5 years ago

@loverdeg-ep @TacoGrandeTX Have been thinking about it for a while. Didn't find time to do so. Could couple it with SX126X work. Will update asap.

0Grit commented 5 years ago

Current workaround for our custom target is to package the rf driver repository into our BSP via Peru

We do not want to force applications written for our board to bring in the RF drivers.

0Grit commented 5 years ago

@hasnainvirk Any chance of working this in along with the https://github.com/ARMmbed/mbed-semtech-lora-rf-drivers/pull/36

hasnainvirk commented 5 years ago

@AnttiKauppila What is your take on taking the radio drivers as components under the OS tree ?

0Grit commented 5 years ago

Quoting my message above, our context is the following:

Current workaround for our custom target is to package the rf driver repository into our BSP via Peru

We do not want to force applications written for our board to bring in the RF drivers.

AnttiKauppila commented 5 years ago

We have been thinking about it, but it is not in our short term plans.

0Grit commented 5 years ago

Thanks. As mentioned we have what could be considered a permanent workaround. Want to make sure the topic is properly considered.

Final opinion I'd like to get before closure -> @janjongboom

janjongboom commented 5 years ago

Given that we seem to shove everything into mbed-os these days I'd think that the Semtech radio drivers also belong in Mbed OS core. @bulislaw what do you think?

bulislaw commented 5 years ago

I want to get away from "shoving everything into mbed-os", there are tools to manage this kind of dependencies. I don't know enough about this particular case, @AnttiKauppila let's discuss it before bringing it in.

0Grit commented 5 years ago

In this case, a radio driver of some sort is required for the LoRaWAN MAC to work.

It is fine not to include in the OS... But the current setup expects the application developer to pull the radio drivers into their application project.

@bulislaw For various reasons we also would prefer these and other "external IC" drivers be managed as packaged dependencies within a board's support package.

However my team and I have spent more time then I should divulge, evaluating package and or dependency management tools for use with Mbed OS and it's tooling. We have yet to find a solution for C/C++ that meets our minimum requirements.

Examples with semi-jestful notes.

For now we have settled on Peru and possibly gitman.

The above for whatever reason were the only tools I could find that accomodate managing and acquiring the following as dependencies.

• Git & mercurial repos (by branch, tag, hash, ssh, https, etc) • Arbitrary files, blobs, etc, that are hosted on webservers • other useful details like specific subdirectories of a repository

They do not, since my last review, support checksumming the combination of the dependant items and the dependencies that are pulled in.

Validating the right sources and materials have made it into a workspace, unless I am mistaken, will be an absolute requirement for security and general tooling trust.

40Grit commented 5 years ago

@ciarmcom not a fan of your recent auto closures

0xc0170 commented 5 years ago

@40Grit I've noticed dozen of issues closed without a reason as result of closing in our internal tracker.

All will be addressed soon.

40Grit commented 5 years ago

@0xc0170 I've noticed in the past that

"Closed in jira doesn't always mean closed in GitHub."

Internal to ARM what does an issue closing in Jira signify?

0xc0170 commented 5 years ago

I'll talk to the team. They will get back to all recent closed issues.

40Grit commented 5 years ago

@linlingao

linlingao commented 5 years ago

@40Grit Has this question not been answered? Or has this turned into a future request?

40Grit commented 5 years ago

It sounds like it is undecided as to whether the drivers "should" be brought in.

@Bulislaw what were your thoughts regarding dependency management tools? See @loverdeg-ep's comment above.

0xc0170 commented 5 years ago

@loverdeg-ep Good notes above about package managers. One question: have you evaluated yotta? I would like to know how it compares to the list of tools evaluated above. As that one we used previously and has similar attributes to some tools in the list (at least from my quick look at some of the tools there).

40Grit commented 5 years ago

@0xc0170 I was a huge fan of what yotta and Mbed OS 3 represented.

However, yotta is dependant on cmake which is dependant on make.

cmonr commented 5 years ago

We want a modern build system

@40Grit care to elaborate on this a bit?

I hear the phrase used a lot all over the place, but feel that it might mean different things to different people.

0Grit commented 5 years ago

@cmonr You caught me flat footed.

The headings of the following page https://doc.qt.io/qbs/overview.html might be considered an elaboration. There are bits of many other tools that fit the bill.

I'm nearing readiness to create a separate issue for the topics I have been redirecting other issues towards.

Thank you to all for your patience!

AnttiKauppila commented 5 years ago

This will not happen in near future, so this question should be closed.

0Grit commented 5 years ago

Considering new tools team etc. I believe I am okay with the closing.