Urządzenie do sterowania GPIO, komunikacji UART, ethernet z interfejsem dotykowym. Wybór technologii

Hej,
chce wykonać urządzenie, które będzie służyło do komunikacji UART, pomiarów ADC, pomiaru czasu, sterowania wyjściami przekaznikowymi, odczytu wejsc TTL. Dane z urządzenia będą raportowane do bazy danych lub emaila skad potrzeba podłączenia do sieci ethernet. Jako interfejs będzie służyć ekran dotykowy ekran (7-10cali).

Pytanie w jaką technologie iść?
Wstępnie wymyslilem, że wykonam to na raspberry pi, do którego mogę podpiąć ekran dotykowy. Do raspberry dołożę swoją płytkę z rozszerzeniami tj. Wyjściami przekaznikowymi, ADC itd.
Do całości napisze autouruchamianą aplikację w Python.

Co myślicie?? Czy może rpi/Python to zły wybór i iść w coś innego?

Urządzenie nie będzie komercyjne, kilka sztuk na potrzeby małej firmy.

ESP32 ?

Pozdr

A jak do niego podlaczyc 10 calowy wyswietlacz dotykowy?

RometFan;p wrote:

A jak do niego podlaczyc 10 calowy wyswietlacz dotykowy?

Szukaj z interfejsem SPI.
Malina teraz ma zaporowe ceny i możesz mieć kłopoty np. z wywaleniem się linux'a z powodu karty sd.
Jak bym stawiał to na esp32, sporo pamięci, wifi, dość szybki procek.

W poprzedniej firmie budowaliśmy własne środowisko testowe - do produkcji elektroniki. Całość działa do dziś, oparte na RPI + skrypty Python + autorskie rozwiązanie kart pomiarowych, wejść, wyjść, itp. Komunikacja między kartami po RS485, protokół własny.

Myślę że RPI jest droższe od ESP32, ale masz tu znacznie większe możliwości. Skoro budujesz urządzenia na potrzeby firmy, to te kilka stów da się wygospodarować chyba co ?

Kilka stów na jedną sztukę? On chce kilka sztuk

lopr_pol wrote:

Kilka stów na jedną sztukę? On chce kilka sztuk

Tak, ale...

RometFan;p wrote:

na potrzeby małej firmy.

oznacza (raczej), że to nie jest projekt który będzie się liczyło każdą stówę...
Zwłaszcza, że to nie jest temat na tydzień czy dwa, a raczej miesiące.

Klika stow to na dzis 700 - 1000 zl / szt RPi

Myślę, że na temat finansów powinien wypowiedzieć się autor tematu...
Kalkulacja ceny projektu to nie tylko cena komponentów, ale też czas. Jeśli ktoś spędzi kilka godzin nad np. wyciskaniem siódmych potów z ESP32 po to, żeby obsłużył LCD 10cali, po czym stwierdzi że to działa jak kupa... bo jest zbyt wolne odświeżanie, to właśnie stracił równowartość RPI

Grunt to patrzeć z dalszej perspektywy

Kuniarz wrote:

Jeśli ktoś spędzi kilka godzin nad np. wyciskaniem siódmych potów z ESP32 po to, żeby obsłużył LCD 10cali, po czym stwierdzi że to działa jak kupa... bo jest zbyt wolne odświeżanie

Nie wiem skąd się takie plotki biorą. ESP32 całkiem dobrze sobie radzą z "odświeżaniem" większych wyświetlaczy. To jest kwestia oprogramowania, a jak ktoś ma z tym problem, to powinien użyć wyświetlaczy Nextion

W Pythonie to można tworzyć prototyp softu w embedded (zwany inaczej prowizorką), a nie jego wersje finalne

Kuniarz wrote:

Grunt to patrzeć z dalszej perspektywy

khoam wrote:

ESP32 całkiem dobrze sobie radzą z "odświeżaniem" większych wyświetlaczy.

Czy możesz podać trochę więcej informacji?
Do tej pory nie znalazłem ESP z interfejsem MIPI-DSI (chociaż 2 linie danych), czy choćby standardowe sterowanie LCD (RGB888/VS/HS/PCK/DE) rzędu 1920x1080 czy chociaż 1024x600. Może być gotowy zestaw, nie musi to być goły układ.
Nie mówimy przecież o przepychaniu danych przez port 8-bitowy typu 8080 dla zewnętrznego kontrolera, bo to bez większego sensu.

lopr_pol wrote:

Szukaj z interfejsem SPI.

Użycie SPI dla wyświetlacza wielkości 7-10 cali to chyba jakieś nieporozumienie. Najpierw trzeba by znaleźć taki wyświetlacz, a później płakać nad realizacją.
A kontrolery dotyku pracują na I2C, więc też nie bardzo z tym SPI.

RometFan;p wrote:

Pytanie w jaką technologie iść?

Jeżeli masz czas i chcesz oszczędności finansowych w projektowaniu, to wybierz platformę którą znasz i załóż sobie sensowny czas, następnie dodaj 2x tyle i to będzie przybliżony termin realizacji pierwszej wersji. Pytanie kto to będzie utrzymywał lub rozwijał kiedy zmienisz pracę?
Jeżeli nie masz czasu, a masz pieniądze, to zleć wykonanie i serwis na zewnątrz.
Jeżeli nie masz czasu i nie masz pieniędzy, to sobie odpuść.

Marek_Skalski wrote:

Do tej pory nie znalazłem ESP z interfejsem MIPI-DSI

ESP nie ma takiego interfejsu.

Marek_Skalski wrote:

czy choćby standardowe sterowanie LCD (RGB888/VS/HS/PCK/DE)

https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/lcd.html#introduction

Marek_Skalski wrote:

Użycie SPI dla wyświetlacza wielkości 7-10 cali to chyba jakieś nieporozumienie.

Nie zgadzam się.

Marek_Skalski wrote:

A kontrolery dotyku pracują na I2C

Są też i takie, co pracują po SPI.

@khoam Sprawdziłem opis pod wskazanym linkiem i mam pewne wątpliwości. Weźmy najnowszy ESP32-S3 - Datasheet

Mamy tu do wyboru bufor obrazu w wewnętrznej pamięci SRAM, albo w zewnętrznej pamięci PSRAM.
- Wewnętrzny SRAM to 512 KiB. Dla małego LCD 7" 800x480 potrzebujemy 750 KiB na pojedynczy bufor, nie mówiąc o podwójnym. A gdzie reszta pamięci dla OS i aplikacji użytkownika? To nie zadziała.
- To może zrobimy bufor cząstkowy i będziemy generować obraz w locie? Potrzebujemy przesłać 800 pxl * 480 pxl * 2 bajty/pxl * 60 Hz = 45000 KiB/s. Rdzeń ma 240 MHz więc licząc bardzo pobieżnie co 5 instrukcja to dane obrazu, a musi jeszcze wygenerować ten obraz pobierając dane źródłowe (fonty, wartości, tablice kolorów... Transfer danych zrealizujemy za pomocą DMA, ponieważ musi być stabilny timing. Chyba nie damy rady ze względu na ciągłą walkę o dostęp do pamięci między CPU i DMA (jedna magistrala danych to wąskie gardło tego systemu).
- To może spróbujemy skorzystać z PSRAM na SPI0 lub SPI1. Maksymalna częstotliwość pracy to 120 MHz w DDR. Nieźle, około 20% przepustowości idzie na odczyt bufora obrazu dla LCD, a drugie 20% na zapis do bufora obrazu przez CPU. Można zrobić podwójny bufor, o ile pamięć nam na to pozwoli. Ale pojawia się inny problem - ten układ ma bardzo mało portów I/O (45 max), więc po uwzględnieniu stałych funkcji dla SPI, JTAG, USB (0,3,10,11,12,13,19,20,39,40,41,42,45,46) i podłączeniu LCD (21 linii), praktycznie nic już nie zostaje. A jak tu zrealizować inne funkcje?

Proponowany układ pewnie sprawdzi się w połączeniu z małym LCD rzędu 320x240, ale do wyświetlaczy 7" czy 10", to ja bym tego nie wziął. Ogólnie, mikrokontrolery mogą obsłużyć do 1024x600 ze względu na wymagany transfer danych, wielkość bufora obrazu oraz przede wszystkim interfejs. LCD o większej rozdzielczości czy wielkości wymagają MIPI-DSI z 4 liniami danych, a to spotyka się tylko w mikroprocesorach dedykowanych do takich zastosowań, np. iMX8. Korzystanie ze specjalizowanych konwerterów nadal stawia bardzo wysokie wymagania dla ilości pamięci i transferu danych, co wymusza użycie szybszych procesorów.
Nie krytykuję samego produktu (ESP32-S3), ale propozycje osób polecających ten układ lub moduł do aplikacji Autora tematu. To nie ma prawa dobrze działać. Szkoda czasu na tworzenie takiej aplikacji. W tej sytuacji Rpi jest znacznie lepszym rozwiązaniem.

Marek_Skalski wrote:

Proponowany układ pewnie sprawdzi się w połączeniu z małym LCD rzędu 320x240, ale do wyświetlaczy 7" czy 10", to ja bym tego nie wziął. Ogólnie, mikrokontrolery mogą obsłużyć do 1024x600 ze względu na wymagany transfer danych, wielkość bufora obrazu oraz przede wszystkim interfejs.

Jeżeli chcesz oglądać "Szybkich i wściekłych" na 10", to oczywiście ESP też bym nie wziął. Natomiast w przypadkach kiedy zależy nam na prezentacji danych z odczytu portów, czujników etc. (to jest tematem wątku) to ESP do takich celów w zupełności wystarczy. Ponadto ESP32 czy ESP32-S3 dysponuje dwoma rdzeniami.

Marek_Skalski wrote:

więc po uwzględnieniu stałych funkcji dla SPI, JTAG, USB

JTAG korzysta z USB. Link

Atrakcyjność RPI w tym wypadku wynika z możliwości programowania w Python i korzystania z (zwykle) gotowych sterowników wyświetlacza, jakich dostarcza Linux. Jak na "niezbyt" szybkim pececie.

Marek_Skalski wrote:

Nie krytykuję samego produktu (ESP32-S3), ale propozycje osób polecających ten układ lub moduł do aplikacji Autora tematu.

Nie naciskam, a krytyki się nie boję

khoam wrote:

i korzystania z (zwykle) gotowych sterowników wyświetlacza

W to bym się nawet nie bawił, tylko web-serwer i można dane przeglądać przez www - przetestowane wielokrotnie, działa wyśmienicie

Porównywanie MCU z jednoukładowym PCetem z Linuxem może być trochę niesprawiedliwe. Niemniej możliwości graficzne Rpi są powalające w stosunku do ESP bo posiada on akcelerator grafiki (OpenGL) i pewnie też sprzętowy dekoder MPEG, więc można do tego podłączyć poprzez HDMI wyświetlacz i robić taki wizualny show jaki ESP się nie śniło.

Zapotrzebowania na prąd oczywiście ma większe, a odnośnie zużywania się karty SD to można się poratować stworzeniem RAMDISKu i tam umieścić pliki bazy danych, które co jakiś czas można zrzucać do czegoś bardziej trwałego.

Paraca zdalna na Rpi poprzez ssh, robienie updatów wydaje się dużo wygodniejsze niż w przypadku MCU bo tam to trzeba się bawić z bootloaderami albo być na miejscu i wpinać się z programatorem (JTAG, USB, etc.).

Jak się wystawi webserver na Rpi to po co mu wyświetlacz? Każdy posiada smartphona więc tam może poprzez przeglądarkę lub aplikację natywną kontrolować cokolwiek jest tam podłączone. Tutaj więc można zaoszczędzić na wyświetlaczach.

Kuniarz wrote:

W to bym się nawet nie bawił, tylko web-serwer i można dane przeglądać przez www - przetestowane wielokrotnie, działa wyśmienicie

Też jestem zdania, że najlepszym wyświetlaczem jest smartfon czy tablet

jvoytech wrote:

Praca zdalna na Rpi poprzez ssh, robienie updatów wydaje się dużo wygodniejsze niż w przypadku MCU bo tam to trzeba się bawić z bootloaderami albo być na miejscu i wpinać się z programatorem (JTAG, USB, etc.).

W ESP32 aktualizację oprogramowania można przeprowadzać zdalnie przez OTA - nie wymaga to żadnych dodatkowy komponentów sprzętowych. Jest również dostępny klient oraz serwer SSH dla ESP32.

@jvoytech Porównanie wynika z pytania jakiej platformy sprzętowej użyć do realizacji postawionego zadania, więc to nie jest kwestia niesprawiedliwego porównania, ale oceny realnych możliwości. Korzystanie z przeglądarki lub aplikacji natywnej na telefonie to kwestia oprogramowania. Napisanie front-endu aplikacji webowej lub na telefon to jednak inny świat w porównaniu do embedded MCU z lokalnym interfejsem. Oszczędność na wyświetlaczu przekłada się na zaangażowanie developera dla Androida lub iOS, a to jest koszt, którego pominąć nie można. Z tego powodu proponowałem Autorowi użycie środowiska i języka jaki zna lub zlecenie całości na zewnątrz. Inaczej będzie to albo bardzo długi czas realizacji, albo porażka. Mówię na podstawie własnych doświadczeń z podobnymi urządzeniami, ale może się mylę i da się szybko poskładać coś z tanich elementów i będzie dobre jakościowo. Tylko na rynku jakoś nie widać takich rozwiązań.

Tak, dla uzupełnienia. Dla ESP32 dostępny jest również interpreter Pythona, w dwóch wersjach: MicroPython oraz CircuitPython.