Mirki szukam jakiejś podpowiedzi - mam układ gdzie po I2C do procka podłączony układ FPGA - wszystko na tej samej płytce. Na tej samej szynie, wpięte są jeszcze jakiejś czujniki temperatury. Z perspektywy procka powinienem mieć możliwość: - zapisu wartości do rejestrów FPGA (np reset systemu, FPGA steruje całym zasilaniem) - odczyt tych wartości (m.in. wartość temperatury) - update układu FPGA - na FPGA się nie znam ale pewnie do fpga jest podłączony flash i "oprogramowanie" mogłoby brać dane z i2c i zapisywać we flashu.
Będzie potrzebny tutaj jakiś protokół, żeby procek się z tym układem dogadał. Gdybyście mieli pełna dowolność (oprócz zmiany fizycznej, tj FPGA musi się komunikować po i2c) to co byście zaproponowali? Patrzyłem np na jakieś protokoły do obsługi EEPROMU po i2c - nie pamiętam już, który konkretnie model - ale tam za wiele nie ma - ot wysyłam 4 bajty, czyli bajt kontrolny, adres w pamięci eeprom 2 bajty, oraz 1 bajt danych. Żadnych crc itp. Uprzedzam, że nie mam wpływu na wybór interfejsu - wg mnie i2c to chyba nie do końca dobry wybór na wysyłanie takich pakietów danych jak bitstream układu FPGA.
Kolejna sprawa - czy patrząc z perspektywy Linuxa - taki driver powinien być zaimplementowany w user czy kernel space? Czy np czujnik temperatury dostępny poprzez FPGA powinien być podłączony do subsystemu hwmon czy nie? Jeżeli tak to czemu, jeżeli nie to dlaczego? Tak samo reset wyzwalany poprzez zapis do rejestru FPGA, czy powinien być zintegrowany z jakimś subsystemeem czy nie? Z jakim?
Czy napisanie drivera dla tegu układu w kernelu automatycznie wyklucza możliwość napisania driverów w userspace dla innych urządzeń podpiętych pod ten bus?
Ciężko jest o takich rzeczach znaleźć jakieś informacje, dlatego pytam może ktoś z własnego doświadczenia by coś podpowiedział. Ostatnio zmieniłem trochę rzeczy, którymi się zajmuje i potrzebuje z kimś czasem to skonsultować a za bardzo nie ma z kim dlatego pewnie będę coś prostował na tagu :)
z perspektywy Linuxa - taki driver powinien być zaimplementowany w user czy kernel space?
@pepepanpatryk: jeśli nie robisz jakiejś uniwersalnego SBC do sprzedaży, to nie baw się w robienie driverów w kernelu. Co możesz rób w user-space. Tak jak bezpieczniej, jak będziesz miał babola w kodzie, to wywali ci się program a nie kernel (program powtórnie możesz podnieść jakimś nadzorcą typu supervisor/systemd/etc). Debugowanie kodu w user-space też jest łatwiejsze.
@zetisdead: Dzięki za odpowiedź. Niemniej jednak nie do końca jakby odpowiadają mi odpowiedzi, że jeżeli nie robie teog komercyjnie to nie ma sensu robic coś w kernel space itp. Powinienem napisać na początku, że nie dotyczy to zabawy hobbistycznej, a sprzętu komercyjnego. Dlatego np. - co do czujnika temperatury na FPGA - ja bym dla wlasnych potrzeb zrobił to tak żeby mi wystarczyło, ale dlatego, że to jest projekt komercyjny chciałbym
@pepepanpatryk: nie chodzi o to czy robisz komercyjnie, tylko czy to ma być baza do innych projektów robionych przez zupełnie niezwiązane z tobą zespoły/ludzi. Po prostu wystawianie interfejsów jako urządzeń w /dev/* to dodatkowa robota, która może okazać się zbędna jeśli możesz coś wystawić w user-space przez kawałek biblioteki.
@zetisdead: Dzięki, teraz rozumiem. Generalnie jeżeli chodzi o ten układ FPGA oraz te które są tym konkretnym busie, to będą to niezmienne elementy naszej płytki. Inne interfejsy będą używane róznie - w zależności od konkretnego produktu, zbudowanego na naszej bazie.
- zapisu wartości do rejestrów FPGA (np reset systemu, FPGA steruje całym zasilaniem)
- odczyt tych wartości (m.in. wartość temperatury)
- update układu FPGA - na FPGA się nie znam ale pewnie do fpga jest podłączony flash i "oprogramowanie" mogłoby brać dane z i2c i zapisywać we flashu.
Będzie potrzebny tutaj jakiś protokół, żeby procek się z tym układem dogadał. Gdybyście mieli pełna dowolność (oprócz zmiany fizycznej, tj FPGA musi się komunikować po i2c) to co byście zaproponowali? Patrzyłem np na jakieś protokoły do obsługi EEPROMU po i2c - nie pamiętam już, który konkretnie model - ale tam za wiele nie ma - ot wysyłam 4 bajty, czyli bajt kontrolny, adres w pamięci eeprom 2 bajty, oraz 1 bajt danych. Żadnych crc itp. Uprzedzam, że nie mam wpływu na wybór interfejsu - wg mnie i2c to chyba nie do końca dobry wybór na wysyłanie takich pakietów danych jak bitstream układu FPGA.
Kolejna sprawa - czy patrząc z perspektywy Linuxa - taki driver powinien być zaimplementowany w user czy kernel space?
Czy np czujnik temperatury dostępny poprzez FPGA powinien być podłączony do subsystemu hwmon czy nie? Jeżeli tak to czemu, jeżeli nie to dlaczego?
Tak samo reset wyzwalany poprzez zapis do rejestru FPGA, czy powinien być zintegrowany z jakimś subsystemeem czy nie? Z jakim?
Czy napisanie drivera dla tegu układu w kernelu automatycznie wyklucza możliwość napisania driverów w userspace dla innych urządzeń podpiętych pod ten bus?
Ciężko jest o takich rzeczach znaleźć jakieś informacje, dlatego pytam może ktoś z własnego doświadczenia by coś podpowiedział. Ostatnio zmieniłem trochę rzeczy, którymi się zajmuje i potrzebuje z kimś czasem to skonsultować a za bardzo nie ma z kim dlatego pewnie będę coś prostował na tagu :)
#embedded
@pepepanpatryk: jeśli nie robisz jakiejś uniwersalnego SBC do sprzedaży, to nie baw się w robienie driverów w kernelu. Co możesz rób w user-space. Tak jak bezpieczniej, jak będziesz miał babola w kodzie, to wywali ci się program a nie kernel (program powtórnie możesz podnieść jakimś nadzorcą typu supervisor/systemd/etc). Debugowanie kodu w user-space też jest łatwiejsze.