hsanjuan / dccpi

A simple, easy to use, NMRA Digital Command Control (DCC) Python implementation for Raspberry Pi
GNU General Public License v3.0
54 stars 13 forks source link

Do not initialize wiringPi in the module #4

Closed sengels closed 7 years ago

sengels commented 7 years ago

"""wiringPi doesn't need to be enabled by default, as a custom RPiEncoder could be written or even wiringPi might have been set up before."""

Hi, I'd like to use dccpi but also get decoder programming to work (at least loco address and speed steps). I plan to write a custom rpi encoder which also includes feedback from the SGND channel.

If I should split my patch into two (constants for pins and external setup routine) or you have other suggestions, please let me know!

Thanks a lot for your work, I was quite pleased today when I got my loco running with your software (& hardware setup) without having a commercial command station!

regards, Patrick

hsanjuan commented 7 years ago

Thanks, looks very good!

It is a coincidence that you reach out now. I have been working on a Go implementation of dccpi: https://github.com/hsanjuan/go-dcc . It includes a command line application.

Because Go is compiled, it works way better. Python hangs noticeably because the threads are very slow. The packet-sending thread needs heavy sleeps to give time to the control thread to do anything (I test with the single-core Raspberry Pi Model B+, I hope the latest models are better). Then there is the wiringPi dependency and C-bindings just to be able to pause some microseconds.

So I'm going to focus any future work in Go. If you'd like to contribute to that project rather than this one you'd be more than welcome. Otherwise it is perfectly fine to keep working on this one, but remember that Python is not very good for the job in the end.

Thanks for the patch!!

sengels commented 7 years ago

Hm, I want to use some python framework on top, and my Go skills are non-existing. I'd rather try to work on the C side a bit, and if you also think that wiringPi could be removed, then I can produce a patch for that. In general, moving all time-critical things to a C module (or even a library?) isn't such a bad idea; I just found another (proof-of-concept) implementation where some code could be taken from: https://github.com/brianwiddas/gpiodcc .