Design Pythonic per il controllo di più dispositivi tramite un bus I2C

Question

Design Pythonic per il controllo di più dispositivi tramite un bus I2C

#1 da (2 voti)

0

Sto scrivendo un pezzo di software in python che comunicherà con un gruppo di dispositivi tramite un bus I2C. Ognuno di questi dispositivi avrà bisogno di una sorta di modulo o classe per gestire la comunicazione e la conversione dei dati in modo ragionevole. Le operazioni eseguite da ciascuno dei moduli del dispositivo sono drasticamente diverse.

La mia preoccupazione principale è il controllo del bus I2C. Temo che condividendo il bus, ad esempio avendo ciascuno dei moduli dispositivo istanziare un nuovo oggetto di controllo bus I2C si ottenga un codice che è difficile da seguire e non sono sicuro di come questi oggetti potrebbero comunicare se c'è un interrupt nel bus . Tuttavia, non condividendolo, temo che finirò con una enorme classe di controllo che è difficile da mantenere ed estendere.

Se mi avvicino alla classe di controllo, ognuno dei moduli del dispositivo dovrebbe contenere una mappa di operazioni, come OrderedDict o un elenco di tuple di funzioni con valori o intervalli di risultati previsti. L'oggetto di controllo I2C potrebbe quindi iterare quel dizionario, scrivere e leggere i risultati dal bus e passare alla funzione successiva se il risultato è nell'intervallo previsto. Sembra un progetto di macchina statale, ma non sono sicuro di poter davvero generalizzare tutte le operazioni.

Suppongo che la mia domanda si riduce a qualcuno ha un buon suggerimento per un modello di progettazione ?

design design-patterns python hardware

posta msvalkon 18.02.2014 - 10:59

fonte

1 risposta

Leggi altre domande sui tag design design-patterns python hardware

Quali sono i termini corretti per il test desk / utente? Come leggere il modello di Entity Framework e convalidarlo con una determinata connessione?

score 2 · Accepted Answer

Non come pitone come tu vuoi, ma penso che tu voglia solo che l'oggetto di controllo i2c sia solo un arbitro di bus, non un controller di dispositivo; ogni diverso oggetto dispositivo può istanziare la propria copia dell'oggetto bus i2c e comunicare al bus come se avesse accesso esclusivo al bus. Ciò semplifica notevolmente la programmazione degli oggetti del dispositivo. Non vedo come questo si traduca in codice che è difficile da seguire. Pensa a questo come alla logica del driver del dispositivo. Lo strato di livello superiore sarà il livello logico di sistema, che istanzia dispositivi e comunica con i dispositivi tramite le loro interfacce oggetto.

Il tuo oggetto bus i2c può avere metodi di classe e attributi di classe (come mutex, code di lettura, code di scrittura, ecc.) che gli utenti della classe non devono sapere. Gli utenti della classe, che sono istanze degli oggetti del dispositivo, chiamano semplicemente i metodi di lettura e scrittura della classe i2c.

Gli oggetti del dispositivo presenteranno quindi un'interfaccia di attributo e metodo che ha senso per il dispositivo fisico sottostante sul bus. Ad esempio, solo il tuo oggetto dispositivo per il braccio sinistro del tuo robot sa che il metodo della sua classe "setPowerLevel (x)" risulta in una particolare operazione del bus i2c. La conversione dei dati da o verso un valore BCD, come richiesto dal dispositivo sul bus i2c, verrebbe eseguita dall'oggetto del dispositivo, forse con l'aiuto delle funzioni di supporto sull'oggetto bus i2c.

Non ero sicuro di dove fossi diretto con OrderedDict . Sembra che tu abbia voluto in qualche modo dare a tutte le possibili operazioni e valori di dati / dati attesi di tutti i dispositivi in qualche oggetto iterable , e avere qualche controller iterato di uber-controller e inviare / ricevere dati in quel modo. Ad essere onesti, penso che questo renda il codice più difficile da leggere, in realtà. Penso che i dispositivi siano dispositivi, puoi creare un modello a oggetti per i dispositivi ma non dovresti provare a oggettivarli così tanto da spremerli in un'interfaccia unica per tutte le dimensioni. Puoi ancora avere classi (in modo concettuale) di diversi oggetti raggruppati in diverse classi base, dove ogni classe base rappresenta tipi simili di dispositivi (ad esempio memoria, controllo motore, display, ecc.) ...