ADAPT: LR Radio and CSMA port, demo, and app note

[Nathan-Stohs]

Task is to port Samraksh.NET (radio, csma, rf231 driver, etc) to ADAPT platform (debug board). Interface is via .NOW shim-board.

[AnanthAtSamraksh]

This has been completed. I just have to test it.

[MichaelAtSamraksh]

Looks like LR Radio does not reply to MSM's SPI commands. Recommend testing "Live Emote"->breakout-<------>breakout->"LR radio on dumb eMote" to ensure LR Radio works when sitting on "empty" eMote.

[AnanthAtSamraksh]

The above mentioned did not work. Initialization on "Live DotNow" failed due to the absence of the LR radio. This was my setup: "Live Emote"->breakout-<------>breakout->"LR radio on dumb eMote". I had another DotNow with a LR radio to send and receive.

[Nathan-Stohs]

Are you sure your radio works at all?

[Nathan-Stohs]

Not to say you don't have a problem, but I would be surprised if the problem was the "dumb eMote". If it actually is erased (and I mean a mass_erase from openocd/gdb) all of the ports are in high impedance analog mode.

I think its more likely you are missing a GPIO (or I forgot to tell you about one)

[AnanthAtSamraksh]

The radios work.

[Nathan-Stohs]

After debugging a minute with Ananth, there was a problem where he read the note "Signal Active low/high" as being an instruction to add a pull up/down to that pin. That has been sorted out and we also made some other pin assignment and pull changes. Ananth is doing some re-wiring and will test.

[AnanthAtSamraksh]

The issue was with the GPIO configuration. I think this did the trick and I am able to see output on MOSI and MISO as well. Thank you very much Mike for your help.

Before change: val |= enable << 9;

After change: val |= (enable & dir) << 9;

But the problem is that, the first message is being sent out from Adapt, but none of the others. I am working on it now.

[MichaelAtSamraksh]

@AnanthAtSamraksh @NathanAtSamraksh @ChrisAtSamraksh @MukundanAtSamraksh The other day somebody called me a nice guy. I am not a nice guy.

The real issue is that we need to use existing HAL APIs when possible. TO BE CLEAR, I HAD ALREADY FIXED THIS SEMANTIC BUG IN THE OFFICIAL TINYCLR KRAIT_GPIO DRIVER. EVERYONE SHOULD USE THE EXISTING NETMF HAL API INSTEAD OF CONTINUALLY COPYING BROKEN CODE FROM THE LITTLE KERNEL INTO OTHER DRIVERS. IMPLEMENTING THE SAME FUNCTION IN MULTIPLE DRIVERS RESULTS IN CODESPACE BLOAT AND UNKNOWN/UNMAINTAINABLE HARDWARE STATE. WE CANNOT AFFORD TO CHANGE HARDWARE STATE WILLY-NILLY OUTSIDE OF THE DRIVER THAT OWNS THE HARDWARE. GPIO FUNCTIONS ARE ALREADY IMPLEMENTED IN THE GPIO DRIVER AND SHOULD NOT BE REIMPLEMENTED IN THE LONG RANGE RADIO DRIVER.

That said, the NetMF HAL APIs have non-existent documentation. And management has explicitly said that "Doxygen and its ilk are a seriously bad idea." I understand. Code should be self-documenting. It's a bad idea to try and maintain code and maintain documentation that matches the code. Doxygen is still a useful tool for navigating a large, unknown codebase, and summarizing code. So the find button in Eclipse, grep on the command line, or a fresh Doxygen build loaded into a web browser all can help answer the pressing question: "Hey, I want to configure the GPIO. Is there already a function that configures GPIO?"

In this case, it should have been apparent that the Little Kernel's function tlmm_config accepted a "direction" parameter but didn't actually do anything with that parameter. Yet at least two separate developers copied the tlmm_config function into the TinyCLR kernel. The first time around, the developer also copied LK code that called the tlmm_config function without using the "direction" parameter, so the code worked and it was a non-issue. A month ago, I fixed the "direction" parameter in NetMF's version of function tlmm_config, in case a future developer decided to dip behind the GPIO API and call the tlmm_config function directly. This time, instead of using the NetMF HAL GPIO API (best choice), and instead of calling the fixed tlmm_config function inside of the Krait_GPIO driver (not a good choice but would have worked), a developer again copied the broken tlmm_config function out of the Little Kernel. WE CANNOT AFFORD TO DO THIS. WE NEED TO "SEPARATE CONCERNS".

The blame for the tlmm_config issue with the long range radio is shared by everyone. Somebody pointed a new developer to the Little Kernel's GPIO tlmm_config function instead of the NetMF API. I didn't push hard enough upfront for the LR radio code to use the official NetMF GPIO API when I first glanced at long range radio code. We don't have a published NetMF HAL API. Some functions in the HAL API go empty, without a warning that they are still stubs, so why would anybody trust the HAL API? This message is about working smarter in the future, not working harder at fixing solved problems.

[Nathan-Stohs]

Mike is the correct, and the fault is largely mine. His diagnosis is correct, old (bad) code is not dying properly due to my abuse of statics. What generally happens is that I do development on LK and then the port back to MF isn't as clean as it should be.

EDIT: I singled out the static functions in the above, but this doesn't just apply to them. I believe there are other places in the code where we re-invent the wheel (and sometimes not even my fault!)