Appello a chi è interessato al ESP8266 [risolto]

[TardoFreak]

Grazie mille, materiale utilissimo.
Proverò far farlo funzionare domani, oggi ho la testa che fuma.
Devo cercare di imparare bene come sono fatti e come si fanno i makefile. Ne avrò per un bel po'.

[TardoFreak]

Scusa se approfitto della rua disponibilità xyz, avrei alcune domande:
- Se si usa RTOS bisogna anche cambiare il makefile?
- RTOS include anche la API non-RTOS, intendo dire quelle normali tipo espconn?

Edit: si, ho letto sulla guida di programmazione che l'unica differenza è nella creazione e gestione dei task. Tutto il resto, per quanto ne ho capito, rimane tutto uguale.

[xyz]

I Makefile sono molto semplici, sono dei file di testo con delle regole per creare altri file, utilizzati per compilare e non solo. Sono nati nel sistema operativo Unix, sono in assoluto il sistema di compilazione più usato, basta dire che Linux usa i Makefile per compilarsi. Hanno la seguente formattazione:

Codice: Seleziona tutto

taget: dipendenze
<tab>comandi per creare il target dalle dipendenze

dove <tab> è il carattere di tabulazione, ASCII 9 in C '\t', è fondamentale se si usa lo spazio come primo carattere è un errore.

I Makefile sono letti e interpretati dal comando "make", il più usato è GNU Make, presente in tutti le distribuzioni Linux con porting in altri sistemi operativi:

https://www.gnu.org/software/make

In rete esistono diversi tutorial, ad esempio:

http://mrbook.org/blog/tutorials/make/
http://www.cs.colby.edu/Maxwell/courses/tutorials/maketutor/

FreeRTOS è distribuito con dei sorgenti generici (tasks.c, queue.c, list.c e heap_[1-5].c) un file col porting specifico per l'architettura (port.c), se si usa in qualche progetto si deve per forza modificare qualcosa per incorporarlo.

FreeRTOS ha solo un API per le funzioni specifiche RTOS, non incorpora altre API.

P.S. Nel URL del tutorial usare Maxwell in minuscolo, viene automaticamente messa in maiuscolo

[TardoFreak]

Grazie per le utili informazioni.
Ok, non mi resta altro da fare che studiarmi bene la mappatura della FLASH del micro e le due configurazioni (con e senza OTA) per modificare opportunamente il makefile.
Direi che sono quasi alla fine.

[TardoFreak]

Aggiornamento
Ho letto tutto quel che c'è per implementare il filesystem ma ho dovuto abbandonare per una serie di motivi:
- Il sistema di sviluppo prevede l'utilizzo del FOTA (firmware update over the air) e quindi non sono riuscito a capire bene se lo spazio del filesystem deve essere allocato nelle due partizioni.
- Bisognerebbe intervenire sullo script del linker per evitare la sovrapposizione della sezione del programma utente con quella del filesystem. Per fare questo dovrei investire troppo tempo, tempo che non ho.
- Le utility per l'upload dei files sono macchinose da utilizzare.

Ma io devo sviluppare un sistema e quindi ho ripreso in mano arduino con il core per ESP8266.

Quello che ci tengo a sottolineare è che è necessario farsi l'esperienza di programmazione usando l'SDK (sia RTOS che non-RTOS) e leggere molto bene il libro perché si possono ottenere risposte che, per mancanza di documentazione, non si potrebbero avere.
Faccio un esempio. Ho avuto grossi problemi di connessione alla LAN utilizzando arduino. Con alcuni moduli si connetteva immediatamente alla lista delle reti WiFi che ho implementato, altri non riuscivano proprio a farlo.
Il problema sta nel fatto che il sistema operativo prevede l'autoconnessione al power-on. Il problema è stato risolto inserendo l'istruzione

Codice: Seleziona tutto

WiFi.disconnect();

prima di ogni tentativo di connessione.
Se non avessi studiato a fondo il micro e se mi fossi (come ho fatto in passato) affidato alla carente documentazione di arduino non ci sarei mai arrivato.
Quindi ho deciso di utilizzare come IDE Code::Blocks che permette di lavorare molto bene, soprattutto sui sorgenti scritti dall'utente.
Per ora vado avanti così con una regola: al sorgere di un qualsiasi dubbio su funzionamenti imprecisi ed errori vari, faccio riferimento sempre al SDK andando a vedere quello che effettivamente farà il micro dietro le quinte.
Purtroppo il livello di astrazione di arduino è troppo elevato e miseramente (per non dire "per niente") documentato.

[xyz]

La memory map è documentata, io mi baso su questa:

https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map

la scrittura dei dati è gestita nel SDK via esptool, di solito sono presente le regole nei Makefile con i vari indirizzi dove scrivere i vari file in memoria.

Per FOTA non mi è mai servita (per ora) esiste il documento ufficiale che spiega come funziona:

http://www.espressif.com/sites/default/ ... n_v1.6.pdf

Per quanto riguardata il linker si tratta del "GNU Linker" il linker usato dal GCC per assembare i binari ELF. Come avviene questa operazione può sembrare compressa ma si basa su di un linguaggio scritto appositamente che si chima "Linker Scripts". Qui si trova un'ottima spiegazione su come funziona, è generico, ogni architettura ha le sue convenzioni ma la sintassi è condivisa:

https://access.redhat.com/documentation ... index.html

Insieme al GCC per Xtensa LX106 si trovano i file Linker Scripts preconfigurarti, hanno estensione "*.ld".

Arduino o meglio API di Arduino è documentata nei sorgenti e viene generata in automatico via Doxygen:

https://github.com/esp8266/Arduino/tree ... ats-inside

[TardoFreak]

Tutto giusto, anche se approfondire gli script dei linker vuol dire investire tempo in studio e prove. Per modificarli opportunamente e fare in modo che funzionino serva altro tempo, altre prove ecc.
Sono meno d'accordo per quanto riguarda la documentazione di arduino. Di molte classi ho scoperto metodi non documentati perché sono andato a guardami direttamente i file .h
Sicuramente sei molto più esperto di quanto non lo sia io (anche i muri se ne accorgono) e, per carità, esaminando tutti gli header si trova tutto, ma ma questo è ben lungi dal definire un qualcosa come "ben documento".
Da come la vedo io la documentazione doxigen serve come riferimento, una buona documentazione spiega i principi, la filosofia di come si ha implementato un qualcosa, delle guide utente.
Pe esempio la keil fornisce (addirittura) anche un documento che illustra le tecniche di programmazione per ottenere i migliori risultati in termini di affidabilità, velocità e compattezza del codice. E lo fa con esempi, facendo vedere come lavora il compilatore dietro le quinte.
Da come la vedo io la documentazione doxigen può essere paragonata all'indice degli argomenti di un libro, quello che manca sono proprio i contenuti.

Comunque ho trovato il modo per lavorare bene e così andrò avanti.

E, aggiungo, quella che sto facendo (anche se di corsa) è una bella esperienza che di sicuro mi tornerà utile.

[xyz]

Si vero i contenuti sono carenti di molta documentazione è per questo che con Doxygen mi genero personalmente la documentazione abilitando i sorgenti online con tutte le dipende calcolate con Graphviz in questo modo se manca la descrizione mi guardo subito i sorgenti per capire cosa il codice combina.

[TardoFreak]

In ogni caso, anche se c'è da tribolare, ne vale la pena. E' un vero e proprio gioiellino.
Più ci lavoro sopra e più mi piace.
Inoltre mi sto facendo un po' di esperienza con la toolchian GNU, cosa che mi è mai capitato di fare.
Servirà quando poi avrò motivo ed occasione di metter mano al raspberry.