2009-07-07 3 views
10

Sono un ingegnere SW incorporato, con meno di 3 anni di esperienza. Il mio obiettivo è "affilare la sega" continuamente. Mi stavo chiedendo se ci fosse qualcosa di specifico nella programmazione di basso livello che i programmatori C/C++ dovrebbero essere esperti.Quale set di abilità dovrebbe possedere un programmatore di basso livello?

Quello che mi viene in mente è la familiarità con l'architettura dell'hardware e il set di istruzioni. Anche sapere come giocare con i bit è importante, la gestione delle risorse e le prestazioni hanno fatto parte del mio lavoro, c'è qualcos'altro?

EDIT: lavoro con un RTOS personalizzato interno, non con Linux incorporato.

+1

Pazienza! [15chars] –

risposta

11

concetti specifici come,

  1. Endianness (questo link è quello di un vecchio, ma buon articolo LinuxJournal)
  2. Effective use of multithreading architectures (la site è buono in generale)
  3. Debugging embedded e multithreaded sistemi
  4. Understand, Learn and Follow good programming techniques (il link è molto vecchio e il punto è molto generico e soggettivo, ma pensateci)
  5. Other things (questa pagina IBM su Linux incorporato riassume la maggior parte degli altri punti che voglio rendere)
  6. Un'altra cosa - never underestimate testing! o, pianificando casi di test !!

utilizzare i link di riferimento io do come concetti,
si prega di follow-up di più per la conoscenza più profonda.

+0

Sì TATFT. Se non sai cosa significa, cerca e vivi! – Brian

+0

@Brian, ci puoi scommettere! Mi sono preso a calci per averne perso uno. – nik

+0

Ho appena appreso cosa TATFT significava e ridevo ad alta voce nel mio cubicolo, sono totalmente d'accordo, in realtà siamo sempre TATFT nella mia squadra e disapprovare quei gruppi che non lo fanno. –

9

Vorrei studiare l'elettronica dei chip effettivi. Scopri come lavorano internamente (come l'architettura), l'interfaccia con le periferiche, le caratteristiche elettriche e temporali, ecc.

In pratica, leggi la scheda tecnica che inizia a finire un paio di volte e scopri tutto ciò che non hai visto/usato prima .

A proposito, con che chip lavorate?

+0

concordato. Scopri gli aspetti di ingegneria elettrica/elettronica dei computer! – Noldorin

+0

Lavoro con ARM9 per controller e C55 per DSP, inoltre ho aiutato a scrivere driver per vari tipi di circuiti integrati RF, AD/DA e Power Amp. –

3

Avendo una grande familiarità con i puntatori, i controlli in questi linguaggi non fanno molto (come l'overflow del buffer e cose del genere), l'elettronica digitale. Anche i sistemi operativi interni potrebbero essere d'aiuto.

Scopri come vengono rappresentate le cose internamente, strutture di dati appositamente predisposte (supponendo che tu non costruisca il tuo).

Soprattutto, pratica molto. Farlo ti porta molto di più che limitarti a leggerlo;)

4

Se non lo hai ancora, credo che ogni Software Engineer dovrebbe leggere Pragmatico Programmatore e Codice Completo. So che questi non sono specifici per la programmazione di basso livello, ma hanno una grande ricchezza di conoscenza in essi che si applica a tutte le sotto discipline.

+0

Ho questi libri e li leggo. Penso che siano entrambi fantastici. –

+0

* Le pratiche di uno sviluppatore Agile * sono una sorta di sequel di * The Pragmatic Programmer * ed è anche un ottimo libro. – Imagist

7

Simile a quello che Brian said, imparare a creare unit test e automatizzato build.

Queste competenze sono utili a tutti i livelli di ingegneri del software per essere competenti. Contribuiranno a migliorare la qualità del codice, semplificando inoltre il refactoring e il miglioramento della base di codici.

+0

Buono ma non unico per i sistemi embedded. –

2
  • operazioni bit
  • architetture di processore (cache, ecc)
  • analisi WCET
  • pianificazione

Edit: Quello che ho dimenticato di dire è sviluppo basato modello. Oggi gli algoritmi di controllo sono spesso implementati come una sorta di automa da cui viene generato in seguito il codice C. Gli strumenti disponibili commerciali sono ad esempio MATLAB/Simulink, ASCET o SCADE.

+0

Non sapevo su cosa fosse la wcet, l'ho cercata su google e ho trovato this page. Ho appena imparato qualcosa di nuovo, grazie !. –

1

Prendi una copia del libro MISRA-C. È stato originariamente scritto da membri dell'industria automobilistica e tenta di rendere più robusto il software scritto in C applicando un numero (un numero piuttosto elevato!) Di regole e linee guida.

Quindi, acquistare PC-Lint (o un altro strumento di analisi statico) per verificare il codice per MISRA e altre regole.

Questi sono particolarmente rilevanti per C di basso livello e embedded, poiché tra loro si occupano delle cause di molti bug in questo software, come problemi relativi a puntatori, perdite di memoria, promozione di interi (c'è un intero capitolo su quello nel libro MISRA), endianness e comportamento indefinito.

13

Qui vedo un sacco di risposte del sistema operativo di alto livello, ma in particolare hai detto basso livello.

Alcuni pensieri sparsi:

  • design per il test. Mentre lavori su un problema, modifica solo una cosa alla volta per test.
  • È necessario capire i bus e le interfacce, spi, i2c, usb, ethernet, ecc. Interfaccia numero uno, oggi, ieri e domani, l'utente, seriale.
  • I passaggi coinvolti nella programmazione di un flash.
  • Trucchi per evitare di rendere il prodotto facilmente murabile.
  • Bootloader in generale.
  • Bit-banging sopra dette interfacce su varie famiglie di parti (diversi chip i venditori hanno idee diverse su io pin, pull up, direzione comandi , ecc.).
  • Board e chip di far apparire, certamente non desidera avvio a molte decine di migliaia di linee di programma in codice al primo accensione (si pensi led acceso, led spento).
  • Come eseguire il debug di un prodotto senza utilizzare troppe apparecchiature di test (analizzatori logici e ambiti), allo stesso tempo devi imparare a utilizzare un ambito per il debug, sei molto più prezioso se non hai un tecnico o un ingegnere in laboratorio con te.
  • Come si riprogrammare l'unità sul campo? Cosa farebbe lo per minimizzare l'errore umano quando si consente all'utente di mettere in campo l'aggiornamento ? Ricorda anche i downgrade del campo.
  • Cosa faresti per scoraggiare l'hacking (file binari, ecc.).
  • Uso efficiente del flash/rom (non consumare un banco o una sezione, diffondere l'usura in giro o vedere se il flash lo sta facendo per voi).
  • Come e quando utilizzare un timer watchdog.
  • Macchine di stato, molto utili con i byte (seriali ed ethernet), strutture di pacchetti di progettazione che si adattano bene e sono adattate a una macchina a stati e che hanno un'intestazione e un checksum o un'altra struttura che garantisce che non interpretate i pacchetti parziali o dati casuali come un buon pacchetto.
+1

+1, ho bisogno di più upvotes! –

+0

Buon post. Vorrei aggiungere che quando costruisci app incorporate, le tue capacità di debug sono meno numerose, e la previdenza del design diventa assolutamente necessaria molto più di quanto non avvenga in ambienti amici quando sei in modalità sandbox e non stai andando a rovinare il codice altrove. Inoltre, girando verso il bit sbagliato o dereferenziando un puntatore che penzola ha conseguenze reali qui, a differenza della programmazione desktop in cui il peggiore che si ottiene è un arresto anomalo del programma. Programma in modo difensivo, anche quando non si vede un forte bisogno di. –

+0

sì, programma in modo difensivo, mi piace quel termine. anche sapere quando andare contro la norma come più variabili globali e meno locali. Non assumere sempre che. Bss e.i dati sono stati impostati (perché non lo hai fatto) e hai scelto un'alternativa. Gestione dell'alimentazione, sempre più cose vengono scaricate dalle batterie. Ci vuole meno energia per immagazzinare un 1 in una rom piuttosto che uno 0. Salva su ram di NV dopo l'interruzione di corrente. Riattivare, gestire l'evento, tornare alla modalità di risparmio energetico. –

1

Buona domanda. Alcuni che non sono stati citati ...

Scopri le varie opzioni per ottenere il multitasking a basso livello. Dagli scheduler di base round-robin (non preventivi), con i tempi di temporizzazione da un timer hardware, fino a un RTOS preemptive. Scopri perché potresti aver bisogno di un RTOS e perché potresti non farlo. Se usi un RTOS, impara che i principianti con un background su PC probabilmente tendono a voler creare troppe attività.

Ottenere visibilità all'interno dei componenti interni per il debug può essere una sfida. Normalmente non c'è schermo, quindi non devi chiamare "printf" dove vuoi. Un emulatore o un'interfaccia JTAG è l'ideale: puoi impostare punti di interruzione e passare attraverso il tuo programma (finché l'interruzione del micro non fa impazzire l'hardware, come far oscillare il braccio di un robot a tutta velocità!). Se l'emulatore/JTAG non è disponibile, impara come usare una porta seriale libera (o forse anche un bit-bash di un pin per creare una porta seriale) per un canale di debug, con alcuni semplici comandi di memoria peek/poke.