search

chipKIT32 / chipKIT-core

Downloadable chipKIT core for use with Arduino 1.6 - 1.8+ IDE, PlatformIO, and UECIDE
http://chipkit.net/
Apache License 2.0
59 stars 53 forks source link

DEIPcK / MRF24G default object creation is completely broken #217

Open majenkotech opened 8 years ago

majenkotech commented 8 years ago

The whole way the network library is constructed is wrong IMHO. The main problem I am facing right now is that for some bizarre reason the default deIPcK (and many other) objects and buffers etc are created inside a header which means it is impossible to include any networking libraries in multiple places within a program - or within any helper libraries, etc. Simply because you get multiple definitions of those objects:

These all seem to be defined in headers with #ifdef DEIPINCLUDECODEHERE around them. Then, for some strange reason, the main adapter headers all turn that option on - so every single file that gets those headers included then defines new copies of all those variables.

That is not the way to do it. You define variables once and once only in C files, not header files. You never ever ever have definitions like that in header files. Even if you think you are only using them in specific places - it is completely prone (as this shows) to failures and problems. All these definitions need moving into a single C or C++ file (or files) instead of having them in headers!

majenkotech commented 8 years ago

Please assign this to @KeithV and mark it urgent.

EmbeddedMan commented 8 years ago

Matt, it is unlikely that Keith will be working through this issue. I suggest that, if you would like to, you could take it upon yourself to try and change the code that you feel needs changing, such that it will work in the scenario you describe. Of course, it's critical to test to make sure that it still works in the places it worked before (so make sure to test on all relevant boards, with the example sketches Digilent has provided) so that we don't break anything moving forward (if possible). Of course it will be up to you to decide just how far you take these changes - just enough to get things to work right, or all the way, or somewhere inbetween. But as a general rule, from this point forward we'll need to work on fixing problems in the chipKIT-core codebase as we see fit, without relying on Digilent.

majenkotech commented 8 years ago

Ok. It's going to take me some time to unpick Keith's code. I have ethernet and wifi shields heading my way to test with as well as the WF32 and Wi-Fire.

EmbeddedMan commented 8 years ago

Also, please feel free to send me or Guy a list of any chipKIT hardware you are missing so that you can have a complete set to test changes on. Your work on this project is invaluable (especially answering virtually every question on the forums) and we want to support you in any way we can.

On Mon, May 16, 2016 at 6:11 PM, Majenko Technologies < notifications@github.com> wrote:

Ok. It's going to take me some time to unpick Keith's code. I have ethernet and wifi shields heading my way to test with as well as the WF32 and Wi-Fire.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chipKIT32/chipKIT-core/issues/217#issuecomment-219575672

majenkotech commented 8 years ago

That link is already in place :)