Tornando in topic, qualcun'altro a fatto qualche altro test con l'Ardutester versione 7d? A me funziona!
Michele, tu hai un prototipo?
07e
- SetDeafult function
- Some fix
- selFreq optimized
- TestKey improvements
- Iniziato il supporto al software Client
- Prima di fare la compilazione controlla che i parametri siano settati in maniera corretta.
Funziona anche ad altra gente
Messaggio di servizio: Paolo nel pomeriggio ti invio email.
at07e.ino (188 KB)
Questo si può semplificare
//Push button
#ifdef LCD_PRINT
#define TEST_BUTTON A3 //Test/start push button (low active) - LCD
#else
#define TEST_BUTTON A3 //Test/start push button (low active) - Serial
#endif
Non hai inserito nel log delle versioni l'introduzione della disabilitazione delle periferiche non necessarie (TWI, SPI, TIMER2) dy PaoloP.
Nel primo post, nella data in rosso manca il 7.
Devo verificare, ma forse il comando
analogReference(EXTERNAL); //Set Analog Reference to External
è superfluo.
Non è cattiveria, mi sono dimenticato
Adesso lo faccio.
Nelle prossime pulizie primaverili togo tutto quel codice. Il pulsante sarà e rimarrà solo su A3.
- A4 servirà per gestire la retroilluminazione dell'lcd
- A5 per lo standalone
Full
pighixxx:
Nelle prossime pulizie primaverili togo tutto quel codice. Il pulsante sarà e rimarrà solo su A3.
Ho dato una sbirciatina al codice, un consiglio, dividilo in più file (tab sull'ide) in modo da migliorare la leggibilità e avere le varie sezioni divise tra loro, ti semplifica la vita anche nella manutenzione e sviluppo del codice.
Per rendere più veloce il ciclo nella ReadU si potrebbe modificare
if ((Counter == 4) &&
((unsigned int)Value < 1024) &&
!(Probe & (1 << REFS1)) &&
(Config.AutoScale == 1))
{
Probe |= (1 << REFS1); //Select internal bandgap reference
cycle = true; //Re-run sampling
break;
}
con
if (Counter == 4)
{
if (((unsigned int)Value < 1024) && !(Probe & (1 << REFS1)) && (Config.AutoScale == 1)))
{
Probe |= (1 << REFS1); //Select internal bandgap reference
cycle = true; //Re-run sampling
break;
}
}
in questo modo il primo if controlla solo il valore del ciclo e non tutti gli altri and ogni volta.
Si risparmia qualche ciclo macchina, così Markus è contento.
Io non lo provo nemmeno... so già cosa succede
Cesare non dire così, non scoraggiarti. L'estate è lunga.
Appena saranno pronte le shield credo che alberto ne manderà una anche a te e a quel punto avremo una base comune per fare i test.
Paolo, come ho detto altre volte il mio tempo non mi permette di lanciarmi in avventure i progress, però visto che dovrò realizzare il progetto stand-alone sarei contento se Pighi mi mandasse uno shield, poiché sono ben attrezzato sia di componentistica che di strumentazione di misura professionale; in tal modo potrei verificare la bontà del progetto, prima di imbarcarmi nella mia avventura "a solo", e fornire feedback qualificati.
Il consiglio che dò è questo: se in qualche modo il firmware fa uso dei timer o in generale di segnali in frequenza non provate lo shield con Arduino UNO, bensì con Arduino 2009; infatti tra il risonatore ceramico dell'UNO e il quarzo della 2009 non c'è paragone in termini di stabilità e di risposta. E' una cosa che ho riscontrato quando facevo i primi test della libreria FreqCounter. Lo stand-alone risolverà ogni problema in merito, ovviamente.
Ma Arduino 2009 ha il problema a l pin 13 mi pare, serve qualche coraggioso che lo estirpa
Si esatto, la 2009 ha il problema della resistenza e del led in parallelo sul pin 13 che modifica il comportamento della resistenza di precisione
schema 2009 --> http://arduino.cc/en/uploads/Main/arduino-duemilanove-schematic.pdf
Quindi non è possibile utilizzarla.
Nello stand-alone il discorso sicuramente cambierà.
Allora perché il pin 13 non si destina ad altro e lo si sostituisce? voglio dire ala fine si farà uno shield che funziona solo con Arduino UNO? non è un po' limitativa la cosa??
PaoloP:
Si esatto, la 2009 ha il problema della resistenza e del led in parallelo sul pin 13 che modifica il comportamento della resistenza di precisione
Nello stand-alone il discorso sicuramente cambierà.
Assegnate il pin 13 al pulsante e il problema non esiste più
Ma da quel che ho capito è difgicile gestire questi cambi, perché il fw ragiona sulle porte. Cioè tutto si può fare ma non è cime siamo abituati su arduino.
Anche il fatto di dividere in tab, è stato già detto w forse anche fatto se ricordo, poi si sono tolte, forse sempre perché di difficile gestione ?
Io ho aperto il codice ed effettivamente, ricorderete mia vecchia critica sul concetto fi sempligicazione, il progetto è tosto e a basso livello.
anch'io ho fatto ricorso ai PORT per la gestione dei pin, certo impostare un byte di volta in volta è comodo e rapido, ma se ciò deve significare moncare la validità di un progetto, vuol dire ch si gestiscono 7 pin col PORT unico e l'8o con un PORT separato, no?
Test: questo è uno di quei progetti che da hobbysti si può decidere di adottare o meno, se lo si fa ci si limita a seguire le istruioni di montaggio e flashare il micro, col lavoraccio che stanno facendo c'è poco da implementare o modificare.
Separare i pin delle porte complicherebbe il codice già notevolmente complesso.
Non è pensabile.
Come volete, a me pare una cosa insensata....
Yes, sono daccordo.
È anche una spinta per chi vuole spingersi oltre il reference arduiniano, capire a fondo tutti gli elementi di questo progetto fa crescere tantissimo, chi non ha voglia o capacità, vedi sottoscritto almeno per ora, si limiterà come hai detto al massimo a fare il betatester.
Testato:
[quote author=Michele Menniti link=topic=163227.msg1327695#msg1327695 date=1374670458]
Test: questo è uno di quei progetti che da hobbysti si può decidere di adottare o meno, se lo si fa ci si limita a seguire le istruioni di montaggio e flashare il micro, col lavoraccio che stanno facendo c'è poco da implementare o modificare.
Yes, sono daccordo.
È anche una spinta per chi vuole spingersi oltre il reference arduiniano, capire a fondo tutti gli elementi di questo progetto fa crescere tantissimo, chi non ha voglia o capacità, vedi sottoscritto almeno per ora, si limiterà come hai detto al massimo a fare il betatester.
[/quote]
siamo sull'identica lunghezza d'onda XD
Usando una sola porta è possibile al posto di questo
digitalWrite(R1L, LOW);
digitalWrite(R1H, LOW);
digitalWrite(R2L, LOW);
digitalWrite(R2H, LOW);
digitalWrite(R3L, LOW);
digitalWrite(R3H, LOW);
scrivere
R_PORT = 0;
Si perde l'immediatezza nella lettura del codice, ma è moooolto più veloce nell'esecuzione e più efficiente nell'occupazione della memoria.