Qualcuno sperimenta con Arduino?

[gawain]

Originalmente inviato da faustog_2

credo di aver capito.... ....dammi un feedback

quindi il controllo
if (TIFR1 & (1<<ICF1))
serve per capire se il timer è arrivato a fondo scala ?

PPM.h lascia scorrere il timer 1 .. e si regola facendo differenze matetmatiche.. lo zero diventa il punto di partenza.. X, poi da esso si sviluppa il treno di PPM..

quindi non lo azzera.. anche perchè appena arriva in fondo a 65.000 scala e ricomincia da zero..

..ho realizzato tempo fa un sistema su Pic che fa lo stesso lavoro, un gruppo di registri li utilizzo , uno per ogni canale, gestito con FSR, il tmr0 quando scadeva in modo naturale, 16 mS , ricominciava.. finchè non scadevano i 16 mS leggevo la seriale & il sensore infrarosso.. appena scaduti i 16 mS allora eseguiva il treno di impulsi secondo quello che trovava nel buffer.. precedentemente riempito durante l'attesa.. quindi non c'erano tempi morti..

In pratica la libreria Servo è una cosa relativamente affidabile! però è strano perchè nei sorgenti di ARDUPILOT si fa uso della libreria Servo.. magari loro raggirano il problema ..chi sa in che modo.. devo studiare tanto.. ancora sono un principiante!

no, l bit ICF1 va a 1 quando l'input cambia stato, l'ICR1 memorizza il valore di TCNT1
al cambio di stato.
il test if (TIFR1 & (1<<ICF1))
serve quindi a vedere se c'è un nuovo valore memorizzato su ICR1

[faustog_2]

ho avuto 5 minuti son andato a spulciare sul datasheet, ecco il risultato :
il Counter sarebbe il registro TCNT1H and TCNT1L – Timer/Counter1, registro a 16 bit , infatti arriva oltre i 65.000 ovvero 2 elevato a 15.

a pagina 139 presenta il registro TIFR1:
TIFR1 – Timer/Counter1 Interrupt Flag Register

http://www.atmel.com/Images/doc8161.pdf

Quindi è il registro degli interrupt del timer.. se leggiamo il bit 5 dice:
the ICF1 Flag is set when the counter reaches the TOP value.

quindi ICF1 è il bit 5 del registro TIFR1 ... e quando cambia di stato? quando il timer raggiunge fondo scala.. in pratica volendo fare un paragone con i Pic

BTFSS INTCON,T0IF
GOTO $-1 ;attende overflow timer
BCF INTCON,T0IF ;resetta bit overflow.

in questo caso INTCON è il registro degli interrupt del TMR0, quindi il bit T0IF di posto non ricordo! sarà 1 se arriva a fondo.. ovviamente tutto dipende da quale punto parte TMR0 e il prescaler impostato.

Mikia ma dico, non c'è un modo più semplice per intervistare un bit? che occorre fare una operazione così complessa?

if (TIFR1 & (1<<ICF1))

RIMPIANGO L'ASSEMBLER DEI PIC ! SEMPLICE E POTENTE!

a dopo
fausto

Originalmente inviato da gawain

no, l bit ICF1 va a 1 quando l'input cambia stato, l'ICR1 memorizza il valore di TCNT1
al cambio di stato.
il test if (TIFR1 & (1<<ICF1))
serve quindi a vedere se c'è un nuovo valore memorizzato su ICR1

[faustog_2]

quindi in sostanza:
ho un piedino definito come ingresso il modulo Compare1 , il quale mi fa scattare un'interrupt appena cambia di stato , contemporaneamente al cambio di stato il contenuto di un timer viene copiato in un registro a 16bit per cui leggendo questo registro si può sapere quanto tempo è passato dalla lettura precedente.

Se è necessario avere più precisione occorre lasciare correre liberamente il timer e poi sottrarre dalla memorizzazione precedente, quindi a via di sottrazioni non abbiamo bisogno di azzerare il timer1


correggimi se sbaglio.. ..aggiungo mi fa piacere comunicare con te, per la pazienza e per la competenza quando per il piacere di confrontarsi... ..e soprattutto per giudizi inutili sulla incompetenza altrui!

Originalmente inviato da faustog_2

ho avuto 5 minuti son andato a spulciare sul datasheet, ecco il risultato :
il Counter sarebbe il registro TCNT1H and TCNT1L – Timer/Counter1, registro a 16 bit , infatti arriva oltre i 65.000 ovvero 2 elevato a 15.

a pagina 139 presenta il registro TIFR1:
TIFR1 – Timer/Counter1 Interrupt Flag Register

http://www.atmel.com/Images/doc8161.pdf

Quindi è il registro degli interrupt del timer.. se leggiamo il bit 5 dice:
the ICF1 Flag is set when the counter reaches the TOP value.

quindi ICF1 è il bit 5 del registro TIFR1 ... e quando cambia di stato? quando il timer raggiunge fondo scala.. in pratica volendo fare un paragone con i Pic

BTFSS INTCON,T0IF
GOTO $-1 ;attende overflow timer
BCF INTCON,T0IF ;resetta bit overflow.

in questo caso INTCON è il registro degli interrupt del TMR0, quindi il bit T0IF di posto non ricordo! sarà 1 se arriva a fondo.. ovviamente tutto dipende da quale punto parte TMR0 e il prescaler impostato.

Mikia ma dico, non c'è un modo più semplice per intervistare un bit? che occorre fare una operazione così complessa?

if (TIFR1 & (1<<ICF1))

RIMPIANGO L'ASSEMBLER DEI PIC ! SEMPLICE E POTENTE!

a dopo
fausto

[gawain]

Originalmente inviato da faustog_2

quindi in sostanza:
ho un piedino definito come ingresso il modulo Compare1 , il quale mi fa scattare un'interrupt appena cambia di stato , contemporaneamente al cambio di stato il contenuto di un timer viene copiato in un registro a 16bit per cui leggendo questo registro si può sapere quanto tempo è passato dalla lettura precedente.

Se è necessario avere più precisione occorre lasciare correre liberamente il timer e poi sottrarre dalla memorizzazione precedente, quindi a via di sottrazioni non abbiamo bisogno di azzerare il timer1


correggimi se sbaglio.. ..aggiungo mi fa piacere comunicare con te, per la pazienza e per la competenza quando per il piacere di confrontarsi... ..e soprattutto per giudizi inutili sulla incompetenza altrui!

perfetto...
e il piacere è reciproco piu siamo piu si sviluppa.....W open source

[romoloman]

Originalmente inviato da faustog_2

RIMPIANGO L'ASSEMBLER DEI PIC ! SEMPLICE E POTENTE!

Fai un programma complesso, ma molto complesso in assembler e l'equivalente in C e poi mi dici quanto rimpiangi l'assembler.
Quello in C è mantenibile e se fatto in modo furbo portabile,
quello in assembler te lo dimentichi di portarlo fra CPU diverse...

Giusto per farti un'esempio che conosco da vicino.
Tempo di porting di open9x da AVR a ARM: 3gg

Se fosse stato fatto in assembler probabilmente mesi...

[faustog_2]

...si concordo.. ..sicuramente la lettura ai datasheet rimane cosa fondamentale, irrinunciabile, ho appena letto sul datasheet dell' ATmega-328 i moduli Capture e Compare.. ...giusto per realizzare degli appunti personali:

Fino a questo momento con i Pic ho creato segnali digitali per svariate destinazioni, per esempio un segnale digitale PWM tipico per il controllo dei motori elettrici, caratterizzato dal Duty Cycle, ho creato via software un segnale digitale per la comunicazione seriale, segnali digitali per per pilotare dei servo, anche il viceversa leggere il segnale di una Ricevente in modo software ecc.
Sono riuscito a mettere in ascolto via software un pin che se legge un valore alto, inizia a contare finchè lo stesso non raggiunge nuovamente il valore basso. In questa maniera abbiamo grossomodo un idea dell’onda quadra che è entrata in INPUT nel nostro Pic. Realizzando un ascoltatore via software, creiamo continuamente delle inevitabili latenze dovute al ritado software delle istruzioni .
Il nostro Pic ha un potenziale da offrirci, ovvero i moduli Capture e Compare. Questi moduli esistono quasi per tutti i Micro della famiglia Microchip, ma in questa sessione studierò quelli dell’ ATmega328 di Arduino. Rispettivamente il modulo Capture, legge un segnale digitale in ingresso mentre il Compare scrive un segnale digitale in uscita. Il modulo Capture per funzionare ha bisogno degli Interrupt, ovvero sono dei sistemi di interruzione programma che il Processore riesce a mettere in atto e gestire, per risolvere problemi di lettura e scrittura di periferiche. Questo ci fa capire che non dobbiamo più occuparci via software di leggere da un pin, ma deleghiamo al modulo hardware del compito, riducendo al minimo le latenze, ottenendo una lettura precisa del segnale. Il registro a 16 bit incaricato per il modulo Capture è ICR1, esso è composto da due registri esattamente: ICR1H : ICR1L , ma il linguaggio C di Arduino lo tratta come se fosse un unico registro, daltronte, passando ad ATmega328 è come se fossimo passati a un Pic della famiglia 18FXXX per cui non è più consigliabile programmare in Assembler, troppo dispendioso. Quindi quando il bit ICF1 del registro TIFR1 assume valore logico 1 (alto) allora il valore di timer1 TCNT1H : TCNT1L viene copiato in ICR1H:ICR1L in pratica viene catturato, infatti il modulo si chiama Capture.

Quindi dobbiamo impostare il nostro pin 14 come Input, inoltre dobbiamo impostare correttamente il bit ICES1 del registro TCCR1B registro di controllo del Timer/Counter1 per stabilire quando deve occorrere l’evento per far scattare l’interrupt, ovvero quando vi è un fronte di salita o un fronte di discesa. Per quello che ricordo nei Pic anche altre alternative, per esempio ogni 4 fronte di salita oppure ogni 16 fronte di salita, tutte opzioni che possono essere gestite attraverso bit dei registri preposti. Basta leggere il datasheet, il discorso si ripete, cambiano i nomi dei registri ma il concetto è lo stesso, altrettanto dicasi per i linguaggi di programmazione, non importa se ASSEMBLER o linguaggio C.

Allora riprendendo il tema Capture se il bit ICF1 viene settato attraverso il registro WGW allora esso verrà settato a 1 quando TCNT1 raggiunge 65.535 quindi il TOP.
Il bit ICF1 bit viene azzerato quando l’Interrupt Vector è in esecuzione. In generale dopo che avviene un interrupt il processore mette nello stack il PC (process counter), come dire metto da parte il lavoro che sto facendo, per occuparmi temporaneamente di qualcosa’altro, automaticamente il processore va ad eseguire I’interrupt Vector che si occupa di bloccare temporaneamente gli altri interrupt, cerca di capire quale Interrupt ha bloccato il normale flusso e cosi esegue le operazioni definite nel modulo hardware in causa, nel nostro caso il modulo Capture.


Passiamo adesso al modulo Compare ovvero ad un modulo che permette di generare su due linee di output un segnale digitale. Questo modulo esegue la comparazione tra il registro OCR1A con TCNT1 , per il pin OC1A mentre la comparazione tra OCR1B con TCNT1 gestisce l'uscita del pin OC1B.
Ovviamente quelli appena visti sono solo la sintesi dei due, in realtà la comparazione riguarda OCR1AH : OCR1AL con TCNT1H : TCNT1L quindi registri a 16 bit, e lo stesso vale fra OCR1BH : OCR1BL e TCNT1H : TCNT1L.

Quando occorre l’uguaglianza tra i due registri visti prima il bit OCF1B del registro TIFR1 viene posto a 1 (alto). Questo vale solo se il bit di posto 7 corrispondente all' I-flag del registro SREG è posto a 1 (alto).

Originalmente inviato da romoloman

Fai un programma complesso, ma molto complesso in assembler e l'equivalente in C e poi mi dici quanto rimpiangi l'assembler.
Quello in C è mantenibile e se fatto in modo furbo portabile,
quello in assembler te lo dimentichi di portarlo fra CPU diverse...

Giusto per farti un'esempio che conosco da vicino.
Tempo di porting di open9x da AVR a ARM: 3gg

Se fosse stato fatto in assembler probabilmente mesi...

[faustog_2]

giusto per appunto.. visto che è piuttosto difficile trovarle, ecco le librerie Java per la connssione su Seriale.

Software


In questo modo potete scrivere vostre applicazioni in Java dotate di interfacce grafiche e poter comunicare con Arduino.
buon divertimento!

[Davide B.]

giusto per appunto.. visto che è piuttosto difficile trovarle, ecco le librerie Java per la connssione su Seriale.
Software
In questo modo potete scrivere vostre applicazioni in Java dotate di interfacce grafiche e poter comunicare con Arduino.

Visto che è difficile trovarle, usare VB.NET o C# che le hanno già integrate no?
Se poi scarichi la versione Express dell' IDE, è pure gratis.

[faustog_2]

..ma chi sei? il figlio di bill gates? VB.NET C# , tutti prodotti MIcrosoft? Java è multipiattaforma!!! ti consente di sviluppare su tutte le piattaforme, ..non ti sembra un buon motivo per pensare che è meglio usare Java??

Originalmente inviato da Davide B.

Visto che è difficile trovarle, usare VB.NET o C# che le hanno già integrate no?
Se poi scarichi la versione Express dell' IDE, è pure gratis.

[Davide B.]

No. Non sono il figlio di bill gates e preferisco sviluppare per ogni piattaforma con il top degli strumenti disponibili. Per quanto riguarda il multipiattaforma dovendo sviluppare userei il firemonkey e non il Java. Avendo a disposizione un ide decente, tra l`altro. E poi con il java non so bene se tu possa pubblicare l`app sull` appstore.... per cui per me sarebbe inutile.