xpcc
xpcc copied to clipboard
roboterclubaachen
[feature] DW1000 Driver, 802.15.4 Frame & Ranging
Added driver for DW1000 with generic and STM32F4_disco examples Added MAC Frame for IEEE 802.15.4 with unitttests Added Ranging algorithms for UWB modules with unittests
It is one year since I started this project of including a DW1000 Ultra-Wide-Band Radio and I finally want you to merge it into the dev branch, so everyone can profit from it. Everything is on discussion names, paths etc...
The code is tested and used at my workplace and the bugs are mostly fixed. I see forward to an useful discussion and I know this merge request will take some time. Please be aware that I do the public changes in my free-time of which I do not have much.
The atmega-unittests test in CircleCI fails because there is not ostream-operator for long long types for AVRs.
https://github.com/roboterclubaachen/xpcc/blob/2c898aeb8e10b6a345619606fb23d5f2a8989d62/src/xpcc/io/iostream.hpp#L512-L515
What is the reason for that? @salkinium
What is the reason for that?
Perfomance concerns on AVRs. The issue was that this will make ALL printf calls use 64-bit integer math, regardless of whether you need it or not. https://github.com/roboterclubaachen/xpcc/pull/315
We can selectably enable this with a macro for AVR targets that want to use this. By default it would be limited to 32-bit integers, but if you really need this, you can add a such a define flag to the build and enable this. In modm this would then be enabled with a module option.
I will disable unittests with 64bit uint for AVRs for now. If they work fine on STM32 and/or Linux it should be enough...
When this is done you can finally critique my additions.
I've split @Maju-Ketchup commits to get a better overview.
And replaced execfile() by +exec(compile(open(xpccpath + '/scons/SConstruct', "rb").read(), xpccpath + '/scons/SConstruct', 'exec')) in some SConstruct files.
FYI: I've just put up our deprecation notice for xpcc, as we are currently moving on to modm as its successor. I will be porting all new code to modm for the next 6 months, but in Jan 2019 I will be archiving this repository and then no more contribution can make it into xpcc.
So… no pressure, but just keep it in mind for your time planning.
I already asked you this before in https://github.com/roboterclubaachen/xpcc/pull/318#issuecomment-352307826, but are you/your employer still ok with dual licensing this contribution as BSD for xpcc and MPLv2 for modm?
@Maju-Ketchup any update on this? We still want this in xpcc, tell us how we can help you with this.
Hi there,
sorry for my long absence but i had no time due to exams and a high workload. My idea for this is that I split my work into 3 pieces as @rleh commented.
-The Decawave DW1000 driver -The MAC-Frame of IEEE 802.15.4 -The trilateration and ranging algorithms/framework
The last part is highly work in progress and throws some issues. So i would leave it out for now.
my workprocess would be the following for the next step:
-Close this merge request. -Add the 802.15.4 Frame to xpcc -Add the Decawave driver to xpcc -Add the Ranging Framework to xpcc/modm -Add the examples
I will add feature branches for everything during the next week. Or is there something else on your mind?
@salkinium We are totally okay at my workplace to change the license to MPLv2 and include it into modm.
Or is there something else on your mind?
No, that sounds perfectly fine for me. This doesn't need to be perfect, just good enought that it'll pass the examples/tests, so I can port it to modm with reasonable assurance that I didn't break anything. Although the API changes will only be cosmetic, and not functional.
As announced, I'm going to archive the xpcc repository soon. You fork will not be influenced, you can still use it as long as you need to. Looking at your code, I'm fairly positive that it can be ported to modm with only a few changes (and a healthy dose of s/xpcc/modm), if you still want to do that.