ARM: Consigli e libri

[c1b8]

Come da precedente minaccia ...sono nuovamente qui.
Ho letto qualche cosa, confesso non ancora tutto ciò che mi avete indicato, e temo di non aver compreso bene 2 cosette che vorrei condividere con voi per sapere se siano in realtà come le ho interpretate io.

La prima riguarda l'indirizzo di ritorno della chiamate a routine o interrupt.
Sono sempre stato abituato a salvataggio dell'indirizzo di ritorno nello stack in automatico dal processore. Poi con una return (o similare) esso veniva recuperato. In questo modo potevo avere chiamate nidificate senza problemi (salvo dimensione dello stack). Su ARM mi sembra di capire che l'indirizzo di ritorno viene salvato solo nel registro R14 e che sia mio compito salvarlo/ripristinarlo dalla stack se voglio avere chiamate nidificate.
E' così o mi sfugge qualche cosa? Il problema si pone o ci pensano i vari tool di sviluppo a nasconderlo?

Seconda cosa riguarda la valorizzazione del registro PC (Program counter). Mi sembra di capire che in Cortex-M3 si debba valorizzare il PC avendo cura che il bit meno significativo sia sempre 1, altrimenti si verifica una eccezione. Nessun problema in programmi 'normali', ma se devo eseguire salti frutto di calcoli?
Come prima, ho capito bene? Il problema si pone o i tool di sviluppo lo rendono trasparente?

Non esitate a offendermi se non ho capito nulla...
Grazie.

[TardoFreak]

Hai posto delle domande a cui non so rispondere (e me ne scuso) poiché questi micro li programmo esclusivamente in C.
Ovviamente ne conosco anche il set d' istruzioni ma, se posso permettermi un' osservazione, questo è stato progettato apposta per essere utilizzato con un compilatore.
Ora nessuno vieta di utilizzare questi micro mediante programmazione in assembly, tuttavia suggerirei di sfruttare proprio la caratteristica di essere stato pensato per essere programmato con un linguaggio ad alto livello.
Ovviamente ci sono delle eccezioni ...

[c1b8]

Sono assolutamente d'accordo con te, non pensavo di programmare in assembly.
Penso però che per comprendere bene un micro non si possa prescindere dal comprendere, anche se poi non utilizzerai, l'assembly. Anche tu ne conosci il set di instruzioni, non ti sei limitato a imparare il C ma hai dato uno sguardo più a fondo a questi micro. Stavo facendo lo stesso e mi sono sorti questi 2 dubbi.
Mi hai già in parte risposto: non ti preoccupare se ne occupano i tool di sviluppo.

[xyz]

Lo stack è roba da CISC, ARM è un RISC e usa il più possibile i registri. Quando si fa' una call con istruzione "BL label", il registro di ritorno viene semplicemente salvato nel "Link Register" chiamato LR o R14. Il ritorno viene fatto copiando il registro LR nel registro "Program Counter" chiamato PC o R15, con l'istruzione "BX LR". Questo è molto veloce e efficiente quando si ha un programma che esegue semplici chiamate a subroutine senza ulteriori chiamate a subroutine. Nel caso di chiamate annidiate il registro LR viene salvato nello stack (ARM può con una sola istruzione selezionare e salvare più registri nello stack) con l'istruzione "PUSH {LR}", per il ritorno immediato basta indirizzare il PC direttamente "POP {PC}" (piccola ma efficiente vittimizzazione).

Le istruzioni del ARM sono tutte allineate a 4 byte nel caso di set a 32 bit alias ARM, e a 2 byte nel caso di set a 16 bit alias Thumb, quindi il bit meno significativo del PC è sempre a zero, ma non è così. Nel caso di ARM col profilo Cortex-A si hanno tutte e due i set di istruzioni a 32 e a 16 bit, la selezione viene fatta col bit meno significativo del PC. Un codice ARM può chiamare del codice Thumb basta mettere a 1 il bit meno significativo dell'indirizzo di chiamata e viceversa. Gli ARM col profilo Cortex-M hanno solo il set a 16 bit Thumb quindi il bit meno significativo del PC è sempre a 1. I tool di compilazione degli ARM conoscono queste regole e se ben utilizzati (impostare correttamente tutti i flag) generano il codice corretto per ARM in uso.

[c1b8]

Ottimo, non mi rimane che scegliere un micro e provare ad accendere il solito led...
Adesso faccio qualche ricerca, mi piacerebbe cominciare con una schedina semplice (diciamo micro e poco più... tipo il Pierin per capirci). Devo capire come programmare il micro, sia come realizzare il primo programmino sia come trasferirlo nella flash, e non mi piace che molto lavoro sia già fatto dalle schede di test... quindi una schedina ridotta la minimo sarebbe l'ideale.
Faccio qualche ricerca, se come al solito avete suggerimenti sono qui...
Grazie.

[TardoFreak]

La ST fa una schedina per STM32F100 value line.

E' un Cortex-M3 depotenziato perché viaggia a 24MHz invece che a 72MHz ma è comunque un gran micro (io uso questi per i trabiccoli che costruisco).

Poi c'è quella per STM32F4 con il "bestio" Cortex-M4 a 168 MHz. e coprocessore matematico.

Tutte e due le schede hanno già a bordo il ST-LINK che permette di fare il debug che, se ti servirà più avanti, potrai separare dalla scheda e farlo funzionare da solo, magari collegato ad un tuo prototipo.
In ogni caso ST-LINK costa veramente poco (e funziona molto bene).
Il sistema di sviluppo gratuito lo prendi dal sito della Keil. Ha una limitazione a 32KB e non supporta RTOS e middleware ma è un bellissimo tool.
Se vuoi usare micro di altre case suggerisco, come emulatore, il J-LINK versione EDU. Costa una cinquantina di euro ed è venduto solo per applicazioni didattiche. In teoria non potresti usarlo per lavoro.

[c1b8]

Molto belle ed economiche quelle 2 schedine.
Il solo ST-Link costa quanto le 2 schede... credo convenga utilizzare quello a bordo scheda anche in futuro.

Sono assolutamente ignorante quindi ti chiedo: secondo te quel st-link a bordo delle schede funzionerà solo su chip della ST?

[TardoFreak]

Si, funzionano solo con ST come pure ST-LINK.

Per la cronaca,
Di ST-LINK ne ho diversi visto che uso questi micro. Ho anche comprato diversi schedini con STM32F100 per due motivi: avere eventuali altri ST-LINK a poco prezzo e/o usare tali schedini per fare attrezzature di produzione/collaudo.
Poi mi sono comprato un paio di J-LINK edu per poter emulare tutti.

Tutto questo perché, per quello che faccio io, ho visto che i Cortex-M sono più che sufficienti (anche solo i piccolini), per il futuro prossimo saranno ultra sufficienti per fare quello che dovrò fare, ed i micro costano veramente poco.

[c1b8]

Ma quindi non esiste un programmatore (inteso come trasferimento alla flash) unico per tutti gli ARM?
Lo so è una domanda stupida...

[xyz]

Oltre alla già citata ST esistono board della TI, Atmel, NXP, ecc..., di solito i costi sono molto contenuti, molti hanno a bordo il programmatore JTAG e l'interfaccia USB per un uso quasi immediato. Esistono ARM anche in PDIP a 8 pin (il package del NE555) come LPC810M021FN8 e il più piccolo ARM finora realizzato il Kinetis KL02 in 1.9 mm x 2 mm.

http://www.ti.com/ww/en/launchpad/tiva_ ... aunchpad-b
http://store.atmel.com/PartDetail.aspx? ... escription
http://www.nxp.com/products/microcontro ... 21FN8.html
http://www.freescale.com/webapp/sps/sit ... is/KL02CSP

Come tool di sviluppo io utilizzando Linux mi compilo tutto quello che mi serve, dalle binutils per assembler e il linker, il GCC per il compilatore C/C++ (e non solo), per interfaccia JTAG OpenOCD.

http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
http://openocd.sourceforge.net/