DOMANDA Come realizzare un'applicazione per un dispositivo che deve eseguire solo quest'ultima.

Auron93

Utente Attivo
157
11
Salve,
ho un problema un po' particolare che spero di riuscire a spiegare nel modo più chiaro possibile...
Ho la possibilità di farmi assemblare un piccolo hardware composto da tutto ciò che serve per eseguire un qualcosa su uno schermo touch da zero.
Immaginiamo banalmente un'app (magari uso impropriamente il termine) che mostri l'ora, il giorno della settimana e del mese, com possibilità di scegliere se visualizzarla in negativo o in colorazione normale.
Chi mi potrebbe assemblare quest'hardware ha necessità di sapere da me, però, cosa deve "metterci su", se un Sistema Operativo specifico, se soltanto un Bios particolare, un firmware fornito da me, o cose simili.

Quello che vorrei chiedervi è... Immaginando che l'hardware nasca proprio dall'assemblaggio delle materie prime (per capirci, a partire proprio dalla fabbricazione dei pezzi metallo che lo compongono), quindi pulito di tutto, di cosa si ha bisogno (lato dispositivo e lato applicazione) per scrivere un'applicazione con cui si deve poter interagire tramite un touch che possa andare su questo dispositivo, nato e dedicato unicamente all'esecuzione di questa applicazione senza possibilità di fare altro (ad esempio uscire dalla stessa)?

Immagino di essere stato abbastanza confuso nella spiegazione, sono disponibile ad ogni chiarimento...
Grazie infinite a chi cercherà di rispondere al problema.
 
U

Utente cancellato 371741

Ospite
Si parte dalla scelta dell'hardware ma servono piu dettagli dell'applicazione.
E anche sapere che touch screen vuoi usare, perche' ad esempio un touch semplice grafico tipo ssd1289 320x240 gira bene con un micro stm32 connesso sul bus parallelo.

Se ti serve la rete, che immagino dovrai allinearti a qualche server ntp, si puo andare su qualche stm32 con ethernet.

Oppure puoi andre su qualcosa linux based, che puo essere anche una raspberry.
Per mostrare l'ora si puo fare anche con un semplice micro 8 bit core AVR (atmega e compagnia) e un display + touch i2c o spi.

Le possibilita' sono tante, su due binari:
1) spesa minima, sviluppo piu complesso, bare-metal + librerie, o con OS a scelta
2) spesa piu alta, scheda linux, sviluppo applicativo comodo e banale

Qualsiasi scelta ha librerie di supporto, o librerie dinamiche e tool gia pronti come linux, dove per esempio per un display spi basta scrivere la tua applicazione e usare il driver "spidev" da userspace o il driver del display.
 
Ultima modifica da un moderatore:

Auron93

Utente Attivo
157
11
Ok, qualcosa ho capito, provo a specificare meglio la mia domanda...

Immaginiamo di avere un'applicazione già pronta e che si voglia visualizzare ed interagire con questa applicazione attraverso un touchscreen (come formato posso pensare a NWjs, HTML5, apk o simili). Esempio stupidissimo: questa applicazione ha tre pulsanti digitali di tre colori diversi che si accendono quando vengono cliccati (mediante pressione sul touchscreen, appunto).

Qual è il modo più semplice ed economico (o con il miglior rapporto tra le due cose) per far sì che quando si accende un dispositivo "primitivo" (dotabile di ciò che vogliamo) questo esegua immediatamente quell'applicazione e che impedisca di uscirne?

In pratica io vorrei, scusa la ripetizione, avere un dispositivo che lato utente quando si accende è già dentro la mia applicazione e che non permette in nessun modo di fare altro...
 
U

Utente cancellato 371741

Ospite
che si accenda e presenti subito l'ora si puo fare in tanti modi.

ma mancano ancora informazioni fondamentali

1) serve connessione alla rete ?
2) batteria o con power supply ? Se deve essere a basso consumo il progetto cambia di molto.
 
  • Like
Reactions: Moffetta88

Auron93

Utente Attivo
157
11
No, non serve rete, è tutto in locale... Deve memorizzare delle informazioni, ma su una memoria locale, appunto...
Non focalizziamoci sull'ora, era un esempio, io faccio riferimento ad una vera e propria applicazione "completa", diciamo così...
Per quanto riguarda l'alimentazione dovrebbe essere a muro.
 
U

Utente cancellato 371741

Ospite
mm ora parli di dati da memorizzare, dunque, ti serve memoria non volatile per i dati ? quanta roba devi salvare ?

Per un boot quasi immediato, potresti usare un stm32, atmega 8bit lascerei stare, ovviamente in stm32 lavori tutto in C. Per provare puoi comprare una dev board tipo "nucleo" per stm32, display "spi".

Puoi anche partire con una raspberry, modello anche vecchio, o similari, tipo biglebone black e molte altre, scrivi la tua app nel linguaggio che ti piace. Ovviamente cariamento linux sta qualche secondo, anche se otimizzando e piazzando tua app come pid 1 puoi arrivare a un paio di secondi o meno. Dati se serve salvarli non volatili li salvi su SD, in linux tutto molto semplice.
 

Auron93

Utente Attivo
157
11
Diciamo che la via del "linguaggio che ti piace" è sicuramente la più appetibile... Ma in che formato devo esportare l'applicazione per permettere al Raspberry di lanciarla? Più che la velocità di lancio dall'accensione, mi interessa l'automatizzazione di questo, cioè il fatto che venga lanciata soltanto quell'applicazione e che, lato utente, non sia possibile impedire questo lancio.
I dati da memorizzare non sono molti, sarebbe una lista di descrizioni e quantità, ma assolutamente molto piccola...
 
U

Utente cancellato 371741

Ospite
Sei su linux, per raspberry con mmu il formato del binario e' elf, lavori sul PC e cross-compili. Starei su una scheda arm 32bit (rpi vecchie, biglebone), non 64. Poi carichi il file sul root file system che sta sulla scheda sd, o non so se rpi abbia eMMC, mai comprato una, a me piace progettare le schede e farmele in casa. Ad esempio lo metti in /sbin/tuaapp.

Poi basta lanciare l'applicaizone come pid 1. Si fa tramite kernel command line

/ # cat /proc/cmdline
console=ttymxc3,115200 init=/bin/tuaapp

Si configura dal bootloader, quale che sia. Kernel config diet, che venga minimale, solo con driver che servono, che stia sotto i 2M, cosi hai un boot decentemente veloce. Anche il kernel si cross-compila dal tuo PC, e si opia zimage o uImage su sd, dove il bootloader lo leggera'.

Come file system userei un read-only, romfs, squashfs o ext2 in ro indistruttibile, rapido, con link simbolici a partizione scrivibile, solo per dati da salvare. O anche initramfs + link simbolici per salvare i dati. Cosi sai che il sistema di base non viene corroto/modificato.

Rootfs solo busybox con shell ash per eventuale manutenzione/sviluppo.

(Questa domanda ora cadrebbe bene su una sezione "linux.embedded" o forse minipc/raspberry). Ma magari ci stara' un po di programmazione :)
 
Ultima modifica da un moderatore:

pabloski

Utente Èlite
2,707
782
Io ci vedo un grosso problema, ovvero che l'applicazione esiste già. Almeno così mi è parso di capire dai commenti precedenti.

Se l'applicazione già è fatta, non è che hai molte possibilità di scelta. Devi usare l'ambiente runtime per cui è stata fatta.

In caso contrario, le scelte sono essenzialmente due ( visto che parliamo di Raspberry PI ). La prima è installare un normale sistema operativo ( Linux, FreeBSD, ecc... ) e settarlo in modo che avvii l'applicazione al boot. A ciò va aggiunto un meccanismo che non consenta la chiusura della stessa. In generale bisognerebbe escludere qualsiasi tipo di window manager tradizionale. E si può fare o usando Xorg/Wayland con un window manager molto semplice ( pure i3 va bene, basta settare l'applicazione per l'avvio in modalità fullscreen ) o sfruttando egl e quindi scrivendo direttamente sul framebuffer senza intermediari. Ma dovresti gestire pure l'input!!! Senza contare che questa seconda opzione necessita di modificare l'applicazione.

Una seconda possibilità è di usare qualcosa come Ultibo per realizzare un'applicazione bare-metal. Anche in questo caso un'applicazione già scritta non va bene.
 
U

Utente cancellato 371741

Ospite
Mah, se non ho capito male, lui deve fare (implementare) un semplice orologio a muro, su un piccolo display touch, che giri solo esclusivamente quell'app. Non servirebbe affatto linux, ma giusto per facilitare lo sviluppo se non si ha pratica di microcontrollori.

Cosi lo farei io, pero' ovviamente la pratica richiede un po' d'esperienza.

- raspberry veccchia o beaglebon. evitare roba 64bit arm, che complica estremamente la vita, ed e' estremamente inutile per un orologio a muro.
- assolutamente niente "OS". busybox e basta.
- kernel mainline rigorosamente minimale, niente roba pronta.
- file system read only, a garanzia che il sistema riparte rapido e integro. O initramfs di 2/300KB max
- link simbolici per salvare i dati
- app semplice, con i font e grafica hardcoded in C, nessuna libreria, punto, anche perche un display spi non supporta grandi effetti speciali. Altrimenti, per grafica/display piu accattivanti creerei piccola immagine con yocto e librerie necessarie.
- app lanciata come pid1, o lanciata da console per developement
Post automatically merged:

-----
Altra possiblita'. stm32
anni fa ho implementato questop piccolo firmware

1621071419425.png

ovviamente qui siamo nella sezione programmazione e non minipc pronti, quindi considero si voglia progettare l'hw e implementare il firmware.

---

ultima possibilita' prendere una scheda linux tipo rpi con OS quello che e' scegliere un display che sia supportato, e magari modificare un app opensource che si trova gia pronta.
 
Ultima modifica da un moderatore:
  • Like
Reactions: Andretti60

Entra

oppure Accedi utilizzando

Hot: E3 2021, chi ti è piaciuto di più?

  • Ubisoft

    Voti: 8 21.6%
  • Gearbox

    Voti: 1 2.7%
  • Xbox & Bethesda

    Voti: 28 75.7%
  • Square Enix

    Voti: 0 0.0%
  • Capcom

    Voti: 1 2.7%
  • Nintendo

    Voti: 4 10.8%
  • Altro (Specificare)

    Voti: 1 2.7%

Discussioni Simili