Second there might be the idea of supporting different chips in the future
(I already thought about).
Linux style is never to write code for the future.
Ok. I didn't know.
To be honest, I already started writing code, also supporting the rf12
some time ago, thus programming a rfxx.c, but never finished, due to
lack of time.
For getting stuff started, I need to focus on rf69 and pi433.
A few monthes ago, Hope RF (the producer of those chips) proposed me a
new chip (can't remember the number - maybe 95), that also supports
loraWan. Seems like there will be even more interesting chips coming up,
that could be controlled with a similar interface implementation.
Then it might be, that DATAMODUL_MODE_PACKET might need an other value.
That's future code so we can delete that sentence for now.
With the rule above, you are absolutely right. But we now spend time, to
remove an currently non necessary feature ("double layer"), which will
take time to re-introduce as soon, as someone wants to support a second
chip.
Isn't that double-work and a thus a pitty?
Cheers,
Marcus
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
