Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HM-MOD-RPI-PCB on another SBC than RPi? #157

Open
Jojo-A opened this issue Jan 9, 2018 · 4 comments
Open

HM-MOD-RPI-PCB on another SBC than RPi? #157

Jojo-A opened this issue Jan 9, 2018 · 4 comments

Comments

@Jojo-A
Copy link

Jojo-A commented Jan 9, 2018

Hi,

I like to know, if there is a chance to get the HM-MOD-RPI-PCB running on another SBC platform than RPi. There seems to be some WiP for ASUS Tinkerboard support (https://github.com/jens-maus/RaspberryMatic#fire-limitations). Although I think that especially the Tinkerboard is not really worth the effort atm, because the community is far too small.
I'd love to see HM-MOD-RPI-PCB support on ODROID C-series boards, as they have almost the same GPIO layout as the RPi.
I have ODROID C1 and C2 boards around. Although I can not contribute in programming, I am very willing to do tests!

Cheers

@leonsio
Copy link
Owner

leonsio commented Jan 9, 2018 via email

@Jojo-A
Copy link
Author

Jojo-A commented Jan 9, 2018

Hi and thanks for the reply!

I don't stress anyone to do something, so "waiting" is not a problem at all. I appreciate every little piece of work that people are contributing to open source projects. Take your time, "It's done, when it's done." ;) .

Apart from that, I think my question was not clear enough.
My question was about what are the limitations, why the HM-MOD-RPI-PCB is only supported on RPi platform (and partially on Tinkerboard). Would it be generally possible but nobody has ever tried to port it, or are there "physical" show-stoppers, or software-pieces, that are closed-source and only run on RPi?
Again, I have sadly no clue about Linux driver programming. But it seems to me, as if the HM-MOD-RPI-PCB only needs four data pins: two for UART (RX/TX, pins 8 & 10) plus two GPIOs (pins 11 & 12). So my general idea would be, to make it versatile as possible by giving the user the possibility to define these pins manually, but of course having default configurations for a hand full of SBCs.

Do you know, what I mean?

@alexreinert
Copy link
Contributor

For HmIP support you need special drivers for the UART as the normal linux drivers have a latency which is to high for the dual use of the module for HmRF and HmIP.
As there are different UART chips in use on the SBCs, the raw uart driver needs to be ported to different platforms.

Using just HmRF could be possible this the normal linux drivers, but even than you need to verify the used dev name for the UART and the number of the GPIO of the reset line.

And sometimes there are boards, which are not physical able to support the HM-MOD-RPI-PCB as the Rock64 or the Ordroid XU4.

So it is absolutly possible to support other platforms than RPi (and I already proved that), but it is not possible to create a generic solution, that works on all SBCs.

@Jojo-A
Copy link
Author

Jojo-A commented Jan 9, 2018

@alexreinert Ok, thank you for these clarifications!
I already expected, that it would be a little bit complicated to support a broad range of SBCs.
I just hoped, that it might be possible to create a solution, which is similar to the approach of the "wiringX" project (https://github.com/wiringX/wiringX/tree/rewrite): the user needs to define his platform ("rpi", "odroidc1", "odroidc2", whatever_is_currently_supported) as well as which pins he uses for what ("receiver: 1", "transmitter: 2", ...).
Please don't get me wrong, I do really not demand or request anything. I just want to share an idea (a not that bad one, imho). If this idea is useless in this combination with this project, thats totally ok.

Greetings

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants