search

leonsio / YAHM

Yet Another Homematic Management - Skripte zur Einrichtung der Homematic CCU Oberfläche in einem LXC Container unter Debian Jessie auf ARM CPU (z.B.: Raspberry Pi & Co)
Creative Commons Zero v1.0 Universal
114 stars 21 forks source link

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

Open Jojo-A opened 6 years ago

Jojo-A commented 6 years ago

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 commented 6 years ago

Hi

I‘m working on full armbian support including Tinker Board. Will take some days my tinker board will arrive today. If you dont want to wait. You can use deb based Solution from pivccu

Von meinem iPhone gesendet

Am 09.01.2018 um 10:47 schrieb Jojo-A notifications@github.com:

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Jojo-A commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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