Home
Accesso / Registrazione
 di 

ANTISMARRIMENTO: prove con CPUstick (demoboard)

55 risposte [Ultimo post]
ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM

In base a quanto discusso nel post iniziale:
http://it.emcelettronica.com/forum/antismarrimento

e poi definito nell'articolo pubblicato sul blog:
http://it.emcelettronica.com/antismarrimento-nasce-primo-progetto-collab...

Questo thread vuole essere un diario, un resoconto dei vari test effettuati con la scheda CPUstick.

Queste schede gireranno tra i partecipanti al progetto che potranno collegarle (sono in coppia per ovvi motivi di tx rx) al PC tramite USB e programmarle nel linguaggio StickOS, molto semplice, in Basic. Tutto tramite Hyperterminal o qualsiasi altro terminale, quindi senza necessità di ulteriore hardware!

Lo scopo è rendersi conto delle potenzialità di zigbee relativamente alla nostra applicazione ed anche intervenire a livello software per fare tutte le sperimentazioni del caso.

Prevalentemente a livello software, ma anche misure hardware, come ad esempio gli assorbimenti, potranno essere valutati. Oltre ovviamente a tutte le misure che vi vengono in mente, che dovranno necessariamente essere qui sotto, nei commenti, annotate.

Tutta la documentazione di CPUstick si trova a questo link http://it.emcelettronica.com/cpustick
da cui poi partono i vari articoli e tutorial, con link anche all'autore, Rich Testardi, con cui alcuni anni fa decidemmo la commercializzazione della scheda anche in Europa.

Resta inteso che per questo progetto verrà utilizzata soltanto come demoboard per evidenti motivi di ingombro e sovradimensionamento microcontrollore.

ritratto di lobbyking
Offline
Titolo: User+
Utente+
Ultima visita:
6 settimane 6 giorni fa
Utente dal: 12/12/2008
Messaggi: 13
ci sono

se servisse conferma io ci sono. mi studio la documentazione in attesa della CPUstick

ritratto di AndreaD
Offline
Titolo: User+
Utente+
Ultima visita:
42 settimane 6 ore fa
Utente dal: 24/07/2012
Messaggi: 10
Grazie

Vorrei innanzitutto ringraziare tutto il gruppo per l'entusiasmo, la partecipazione e l'ottimo spirito collaborativo per la realizzazione di qualcosa di utile consentendo contestualmente di offrire diversi spunti di confronto professionale e non solo.

Forza ragazzi, è tempo di passare dalle parole ai fatti... :)

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Mi associo ai ringraziamenti

Mi associo ai ringraziamenti verso l'intera crew, sarà senz'altro una bella esperienza, qualunque sia l'esito finale del progetto!
Intanto vorrei comunicarvi che dopo un pò di ricerche tra vari marchi, ho individuato un possibile "vincitore" tra i microcontrollori.
Si tratta della serie MCP430 della Texas Instruments (tra l'altro è recente sul portale EMC elettronica la presentazione di una demoboard chiamata LaunchPad che ne integra uno e permette la programmazione ed il debug.
La serie di micro in questione sembra sia nata con il preciso scopo del risparmio energetico (ancor più della serie Xtreme Low Power della Microchip, vedendo alcuni benchmark e commenti di utenti), e questo sicuramente è un punto a suo favore.
Inoltre questo tipo di micro si sposa bene con la serie di transceiver CC2530, sempre della T.I., anch'essi orientati al risparmio energetico. In questi ultimi viene caricato direttamente il firmware con le funzionalità di networking e le API di programmazione(lo stack Zigbee denominato Z-Stack, uno stack free di T.I.), lasciando al firmware del micro MCP430 la sola programmazione della logica applicativa.
E' presente il supporto per l'RSSI via software.
Inoltre questi accoppiamenti di chip sono altamente supportati dalla comunità di utenti T.I. e non solo (nella ricerca, a volte mi sono trovato spaesato per la gran mole di datasheet, tutorial, faq etc. presenti..).
Basta che inseriate su Google le due sigle e viene giù una montagna di documenti, quindi evito di postare direttamente i link :-)
Di tutti vendor che ho vagliato (Microchip, Renesas, Freescale, Atmel, Marvel, ST), la soluzione di T.I. mi è sembrata quella più vicina alle nostre esigenze. Ditemi la vostra in merito.
Chiederei però una cortesia a voi della valutazione di CPUStick: nelle vostre valutazioni, potreste annotarvi se possibile i consumi? Nel futuro fattore "miniaturizzazione" sicuramente dimensione e capacità della batteria diventeranno elementi critici, e vorrei capire se basterà o meno una CR2450 (o la sorella minore CR2032) ad alimentare il tutto.
Ci riaggiorniamo

ritratto di signolo
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 3 giorni fa
Utente dal: 07/10/2011
Messaggi: 35
infatti annotare il consumo è

infatti annotare il consumo è fondamentale!!!

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Ragazzi, come procedono le

Ragazzi,
come procedono le prove copn CPUStick?
Sull'altro thread si sta andando avanti con la valutazione dell'HW per il prodotto finale.
Ho da poco ricevuto il mini kit Zigbee della Texas Instruments che vi dicevo nell'ultimo post (http://www.ti.com/tool/cc2530zdk-znp-mini), ci aiuterà a capire
se il binomio microcontrollore MCP430 e il transceiver CC2530 della Texas Instruments fanno veramente al caso nostro (come credo) o meno.
Nel frattempo chiederei agli utilizzatori di CPUStick una cosa.
Quando produrrete l'implementazione SW dell'algoritmo per ottenere la distanza a partire dall'RSSI, per favore rigiratela anche nel thread sullo schema elettrico,
così vediamo di buttare giù una bozza di firmware specifica per il microcontrollore scelto (o meglio, che stiamo scegliendo...).
Sto scrivendo in fretta dall'ufficio, se non siete convinti o se avete domande/suggerimenti fatemi sapere e ne riparliamo con più calma.

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
SI COMINCIA!!!

Ragazzi mi sono arrivate le CPUStick!
Cercherò nelle prossime due settimane di fare tutte le prove necessarie e di buttare giù un primo algoritmo funzionante.
Vi tengo informati sullo sviluppo del lavoro.
Ciao :)

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
stato di avanzamento con le prove sulla CPUStick

Buongiorno a tutti. Innanzitutto mi scuso se non ho dato notizie prima di adesso,ma impegni lavorativi più urgenti mi hanno impedito di dedicare il tempo che avrei voluto alla CPUStick.
Ho messo in pratica qualche esempio che ho trovato sul manuale e mi sono subito reso conto della semplicità di utilizzo della scheda.
In questo giorni sto approfondendo i comandi messi a disposizione dallo StickOS e in particolare quelli inerenti all' RSSI. Per quanto riguarda l'assorbimento dell'intera scheda, vedo se ci sono dei comandi appositi che mi forniscono questa informazione.
Per qualunque domanda sono a disposizione.

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Buonasera a tutti. Dopo aver

Buonasera a tutti.
Dopo aver sviscerato i vari manuali a disposizione ho messo in piedi un primo algoritmo per estrarre la potenza del segnale dal transceiver. Purtroppo non riesco a testarlo per un problema strano. Il controllore e il transceiver devono comunicare attraverso l'interfaccia QSPI e lo StickOS ne prevede l'utilizzo. Il programma mi da errore perché non riconosce il pin qspi_cs0, utilizzato come "chip select" per abilitare la transazione sull'interfaccia. Dando il comando "pins" ottengo:

heartbeat fec_crs
safemode* fec_col
clone_rst* scl
zigbee_rst* fec_rxer
zigbee_attn* none
zigbee_rxtxen fec_txclk

Manca la riga "qspi_cs* qspi_cs0". Ho provato l'assegnazione digitando "pins qspi_cs* qspi_s0" ma il risultato è:

pins qspi_cs* qspi_cs0
^ - error
Attualmente sto cercando di risolvere il problema. Voglio far notare che questo bit è necessario all'avvio delle transazioni SPI perché è collegato al pin CE* del transceiver come da schema elettrico.
Tutti i consigli sono ben accetti ovviamente.
Grazie.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Sto mettendo le mani sulle

Sto mettendo le mani sulle componenti elettroniche per la scheda che andremo a realizzare, perciò al momento sono abbastanza ignorante in termini di CPUStick. Provo lo stesso a dire qualcosa, sperando di risultare utile.
Partendo dal fatto che nella generica comunicazione SPI il chip select di uno slave viene posto a livello logico basso nel momento in cui il master vuole dialogare proprio con esso, proviamo a scremare insieme eventuali problemi di fondo:
1) quanti slave sono presenti sul bus SPI della CPUStick? Considera che quando c'è solo uno slave, spesso il cs non viene neanche collegato ed anzi viene posto direttamente a massa.
2) Hai già misurato la tensione sul pin cs? quanto vale? varia? e se sì, quando varia?
3) il comando "pins" serve a darti una descrizione di tutti i pin del dispositivo oppure solo di quelli configurati (magari tramite file di configurazione o script etc.)? Inoltre, ti fa vedere solo quelli in un determinato stato logico, es. alto?

Se puoi, rispondi inserendo ogni messaggio di compilazione, log, traccia di debug ti viene in mente. Ogni informazione, anche quella apparentemente più stupida, può tornare utile

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ciao delfino_curioso,

Ciao delfino_curioso, allora:

1)-2)la scheda prevede la possibilità di collegare fino a 3 slave, infatti ci sono 3 pin di chip select (qspi_cs0, qspi_cs2, qspi_cs3). Sono tutti riportati esternamente attraverso il jumper J5 e sono tutti a una tensione di circa 4 V costante. Solo il primo (qspi_cs0) è collegato al chip select del transceiver.
3)il comando pins serve a far vedere le assegnazioni dei pin di default. Come vedi la risposta a questo comando non possiede la riga "qspi_cs* qspi_cs0" che secondo il manuale ci dovrebbe essere.
Provando a fare l'assegnazione con il comando "pins qspi_cs* qspi_cs0" mi da errore come se non riconoscesse valido "qspi_cs*". Il problema non risiede nel tentativo di portare tale bit a livello logica basso, ma nel fatto che non è riconosciuto come nome valido, quindi mi è impossibile utilizzarlo.
Cerco se per caso ci sono eventuali file di configurazione.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Osservazione forse

Osservazione forse superflua:
dalla reference guide di Freescale per CpuStick (http://www.cpustick.com/downloads/freescale.pdf) il nome assegnato di default al pin CS del bus SPI varia in base alla specifica MCU presente su ogni versione della CPUStick.
Hai già verificato che il nome che stai usando è quello valido per l'MCU montata sulla tua scheda?

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Altra considerazione

Altra considerazione:
Nella guida a CPUStick (http://www.cpustick.com/downloads/cpustick.v2.02.pdf), pagina 4, si dice "Note that if ZigFlea is in use, pins irq1* and qspi_cs0 may not be used. Additionally, pins qspi_clk, qspi_dout, and qspi_din may be used only for qspi functionality."
Non so se lo avevi già letto...

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Si lo avevo letto, anche se è

Si lo avevo letto, anche se è poco chiara come frase.
Il mio codice di prova non prevede trasmissione ricezione tra i due dispositivi, ma solo delle semplici operazioni di lettura di un registro sul transceiver "locale".
E poi comunque io utilizzo quei pin solo per funzioni di tipo qspi.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Ok. Hai provato a settare

Ok.
Hai provato a settare manualmente il pin cs dando come parametro non il nome qsp_sc0 ma il numero effettivo del pin che vai a configurare?
Prova a dare un'occhiata a questa discussione:

http://www.cpustick.com/forum1/viewtopic.php?f=3&t=10

sembra sia abbastanza vicina al tuo problema.

Il comando "help pins" dovrebbe darti inoltre un'istantanea dei pin associati ai vari dispositivi sulle porte, prova a vederne il suo output.

Purtroppo, per ovvii motivi, si procede per tentativi a distanza e capisco che spesso i suggerimenti si rivelino buchi nell'acqua.
Se puoi postare un quadro generale della configurazione del tuo sistema ed il tuo codice cercherò/emo di essere più utile/i

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
cliccando sul link mi

cliccando sul link mi risponde che il topic non esiste. Forse hai sbagliato link?

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
posto l'output del comando

posto l'output del comando "help pins". Qui compare il pin qspi_cs0:

pin names:
0 1 2 3 4 5 6 7
-------- -------- -------- --------- ----- ----- ----- ------+
an0 an1 an2 an3 an4 an5 an6 an7 | PORT AN
scl sda | PORT AS
gpt0 gpt1 gpt2 gpt3 | PORT TA
irq1* irq3* irq5* irq7* | PORT NQ
qspi_cs0 qspi_clk qspi_din qspi_dout | PORT QS
dtin0 dtin1 dtin2 dtin3 | PORT TC
utxd0 urxd0 urts0* ucts0* | PORT UA
utxd1 urxd1 urts1* ucts1* | PORT UB
utxd2 urxd2 urts2* ucts2* | PORT UC

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ragazzi ho risolto il

Ragazzi ho risolto il problema. Ho riscritto il programma di test , liberando la memoria da salvataggi precedenti e adesso il programma gira tranquillamente. Vi faccio sapere in futuro se si presentano ulteriori problemi.
Grazie

ritratto di signolo
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 3 giorni fa
Utente dal: 07/10/2011
Messaggi: 35
Vedo che vi state dando da

Vedo che vi state dando da fare :) forza e coraggio tutto si risolverà :)

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Ben fatto zohan, tignoso a

Ben fatto zohan, tignoso a dovere e tutto si aggiusta!
Colgo l'occasione per dirvi che da poco mi sono arrivate le basette adattatrici realizzate da Signolo per il transceiver Zigbee scelto (il CC2530 della T.I.), con le quali sarà possibile fare delle prime prove una volta ottenuti i risultati desiderati con la CPUStick.
Ottimo lavoro, veramente precise !

ritratto di signolo
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 3 giorni fa
Utente dal: 07/10/2011
Messaggi: 35
Ti ringrazio :) per farle

Ti ringrazio :) per farle condurre ti conviene stagnare le piazzole dove alloggerà l'integrato.. ci ho pensato ora senò lo avrei fatto io.. devi usare il flussante senò non ci riesci!!!

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ciao ragazzi volevo chiedervi

Ciao ragazzi volevo chiedervi se qualcuno di voi, leggendo il manuale del transceiver mc13201 è riuscito a capire come si impostano la frequenza di ricezione/trasmissione?
Fatemi sapere, grazie!

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ciao a tutti. Purtroppo vi

Ciao a tutti.
Purtroppo vi informo di un problema che potrebbe portarmi via molto tempo.
Durante i test del codice per l'estrazione dell'RSSI ho pensato di fare un aggiornamento di StickOS per uniformarmi alle funzioni scritte sul manuale e per usufruire delle nuove funzionalità che offre la versione 1.92.
Il problema è che l'aggiornamento non è andato a buon fine e adesso le cpu stick non vengono riconosciute nemmeno da windows (i driver sono sconosciuti).
Ho appena chiesto assistenza sul forum all'amministratore nonché creatore di StickOS sperando di risolvere.
Mi dispiace molto per l'accaduto, ma capite bene che sono cose che possono accadere in questa fase di test. Vi tengo informati sul da farsi e se avete consigli gli accetto volentieri.Grazie.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Ciao zohan, Il S.O. immagino

Ciao zohan,
Il S.O. immagino sia fornito tramite delle immagini apposite, scaricabili da web.
Io proverei a fare così:
1) se è presente una qualche procedura HW per il ripristino delle impostazione di fabbrica (tipo qualche combinazione di pulsanti a bordo), lancia quella -- hai fatto già il backup del SW scritto finora sul PC, vero ?!? :-)
2) disinstalla il driver della scheda e reinstallalo
3) collega la scheda al PC
4) (se il punto 1. è falso) installa l'immagine del S.O. che avevi già (senza l'aggiornamento )

Immagino che uno o più di questi step tu l'abbia già provato, se non è così provali e facci sapere. Strano a dirsi, ma in questa sequenza a me a volte le cose sono andate bene (con altre schede simili).
A mio avviso, purtroppo un problema dei moderni sistemi embedded è che il controllo sulle singole componenti, come ad esempio l'MCU, è sempre più limitato. Non so di preciso come stiano le cose con CPUStick, ma con altre schede del genere se vuoi cancellare la memoria programma del micro a bordo e riprogrammarlo per conto tuo è un mezzo dramma, senza un programmatore Hw devi passare per forza per il loading tramite PC del firmware e se per qualche motivo la comunicazione tra PC e scheda non va, si rimane un po' con le mani in mano.
Aggiornaci, ciao

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ciao delfino, grazie del tuo

Ciao delfino,
grazie del tuo aiuto, ma fortunatamente ho già risolto.
Smanettando un po e sopratutto con l'aiuto di rtestardi (che è diventato il mio eroe ormai) sono riuscito a portare a termine con successo l'aggiornamento del firmware. Quindi è stato solo uno spavento (che c**o!!!):)
Adesso ho perso tutti i miei programmi salvati in memoria, ma per fortuna mi sono fatto degli appunti. Quindi continuo nel mio lavoro, ma adesso il nuovo StickOS mi agevola!
Grazie.
Ci aggiorniamo.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Meglio così ;-). Posso

Meglio così ;-).
Posso chiederti di preciso cos'era andato storto nell'upgrade del firmware e come avete risolto?
E' solo per curiosità, sto raccogliendo in un piccolo database di conoscenza tutte le esperienze e/o gli errori che mi capita di incontrare nell'ambito dei sistemi embedded e sono sempre felice di poterlo aggiornare anche con le esperienze altrui

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Certo! L'aggiornamento era

Certo!
L'aggiornamento era andato a buon fine solo che windows non riconosceva i nuovi driver. Ho dovuto scaricarli da cpustick.com e installarli.
In seguito a questo la scheda veniva riconosciuta da windows e ho dovuto rifare l'assegnazione dei pins come da default, altrimenti StickOS "non sa cosa ha attorno il controller". Insomma direi una disattenzione mia, per fortuna!!!!:)

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ciao a tutti, vi aggiorno sui

Ciao a tutti, vi aggiorno sui fatti.
allora riesco a leggere/ scrivere su ogni registro del transceiver (quindi anche al potenza del segnale ricevuto). Il problema è che non si riesce a fare mentre le due cpustick comunicano tra loro, è cioè proprio quando servirebbe a noi (altrimenti non avrebbe senso il progetto). Informandomi, ho scoperto che il motivo consiste nel fatto che le due cose non possono essere contemporanee perché sia StickOS che il mio programma in BASIC cercano di accedere al transceiver nello stesso momento, quindi l'una esclude l'altra. Per risolvere il problema,mi è stato suggerito (dal buon rtestardi!) di aggiungere queste funzionalità allo StickOS, modificando parte del progetto skeleton. Non vi nascondo che la cosa non mi incuriosisca e non mi entusiasti, anzi! Capite bene, però, che la cosa richiede tempo perché il progetto è veramente vasto e le modifiche sono delicate e mirate.
Pensavo che se fossimo in due o più a studiare il progetto, magari si può fare più in fretta.
Fatemi sapere.Ciao.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Come mai vuoi accedere al

Come mai vuoi accedere al registro contenente l'informazione sull'RSSI durante la comunicazione tra le due schede?
Non puoi estrarre tale valore a seguito della ricezione del singolo pacchetto dati da parte di una delle due schede?
In linea con le specifiche che ci siamo dati, in teoria la scheda che funge da slave (o le schede) dovrebbe inviare ogni x secondi un pacchetto dati minimale, al fine di permettere alla scheda master di rilevarne la potenza del segnale ricevuto (RSSI) ed approssimarne la distanza.

Riguardo alla collaborazione sul progetto, sono sicuro che lo stiamo studiando piu o meno tutti, sulla base dei compiti che abbiamo concordato di assegnarci (anche se ogni tanto sarebbe bello risentire sul blog interventi dei vari partecipanti... ;-) ). Senz'altro, un ostacolo nella collaborazione in questa fase è dato dal fatto che al momento la CPUStick disponibile è una sola; non potendo smanettarci sopra in almeno due persone, la conoscenza che possiamo avere noi altri della scheda è praticamente limitata alle info disponibili sul sito della casa produttrice e questo significa, come già accaduto, che quando si presenta un problema i suggerimenti della "crew" risultano poco efficaci.

Ad ogni modo, come sapete, nell'altro thread "schema elettrico" si sta comunque andando avanti con l'HW che è stato ideato per il prodotto finale (transceiver Zigbee e microcontrollore) e di certo si presentano problemi che possono risultare comuni anche con la parte di prove con CPUStick (vedi ad esempio il recupero dell'informazione sull'RSSI ), per cui ti invito a consultare entrambi i thread: per quanto mi riguarda C'è sempre disponibilità ad affrontare insieme i problemi. E credo valga lo stesso per tutti gli altri.
Ciao

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Nell'ultimo post sono stato

Nell'ultimo post sono stato sicuramente poco chiaro.
Cerco di spiegare nel modo più chiaro possibile la situazione in cui sono arrivato. Ho due cpustick,una con id=1(slave) e una con id=2(master). Sul pin dtin0 del master ho un led che voglio fare accendere a intermittenza dallo slave. Quindi, codice master:
10 dim led as pin dtin0 for digital output
> 30 while 1 do
> 50 endwhile
> end

... e codice slave:
10 dim led as remote on nodeid 2
20 while 1 do
30 let led = !led
31 sleep 1000 ms
40 endwhile
end
e fin tutto chiaro. Funziona!
Adesso voglio che il master sia in grado di "capire" con che potenza arriva il segnale dallo slave, quindi modifico il suo codice di prima con il seguente:
1 // defining variables
> 10 dim led as pin dtin0 for digital output
> 15 dim rxtxen as pin fec_txclk for digital output
> 20 dim cs as pin qspi_cs0 for digital output
> 30 dim irq as pin irq1* for digital input
> 50 dim cmd as byte
> 60 dim control_a as short, rx_status as short, cca_thresh as short
> 70 dim irq_status as short, value as short
> 80 // start
> 90 let rxtxen = 0
> 100 // setting cca_threshold
> 110 let cmd = 0x4 // writing on 0x4 register (CCA_Thresh)
> 120 let value = 0xa49d //cca_vt=0xa4, power_comp=0x9d
> 130 let cs = 0
> 140 qspi cmd, value
> 150 let cs = 1
> 160 //setting control_a
> 170 let cmd = 0x6 // writing on 0x6 register (Control_A)
> 180 let value = 0x411 // cca_mask=1, cca_type=01, xcvr_seq=01
> 190 let cs = 0
> 200 qspi cmd, value
> 210 let cs = 1
> 220 let rxtxen = 1
> 221 on !irq do gosub read_registers
> 230 while 1 do
> 240 assert rxtxen
> 260 endwhile
> 270 end
> 280 sub read_registers
> 290 let rxtxen = 0
> 310 let cmd = 0x86 // reading 0x6 register (Control_A)
> 320 let cs = 0
> 330 qspi cmd, control_a
> 340 let cs = 1
> 350 print "CONTROL A REGISTER ", hex control_a
> 360 let cmd = 0x84 // reading 0x4 register (CCA_Thresh)
> 361 let cs = 0
> 362 qspi cmd, cca_thresh
> 363 let cs = 1
> 370 print "CCA THRESH REGISTER ", hex cca_thresh
> 380 let cmd = 0xad // reading 0x2d register (RX_STATUS)
> 390 let cs = 0
> 400 qspi cmd, rx_status
> 410 let cs = 1
> 420 print "RX_STATUS ", hex rx_status
> 430 let cmd = 0xa4 // reading register 24 (IRQ_STATUS)
> 440 let cs = 0
> 450 qspi cmd, irq_status
> 460 let cs = 1
> 470 print "IRQ_STATUS ", hex irq_status
> 480 let rxtxen = 1
> 490 return
> 500 endsub

La modifica consiste nel fatto che adesso il master "aspetta" un interrupt (di avvenuta ricezione del pacchetto) per chiamare una funzione che non fa altro che leggere determinati registri nel transceiver (quindi anche l'RSSI).
Il codice slave rimane uguale a prima. Non funziona! Sembra che le due cpustick perdano la comunicazione e al comando "connect" StickOS va in crash.Allora ho provato in un modo differente: ho messo in modalità trasmissione (TX_mode) lo slave e in modalità ricezione (RX_mode) il master. Ho sincronizzato le cpustick sulla stessa frequenza e ho fatto in modo che lo slave inviasse un solo pacchetto ogni secondo. Il master alla ricezione del pacchetto avrebbe "sentito" un interrupt che avrebbe chiamato la funzione di lettura di prima. Non funziona! Stessi sintomi di prima.
A questo punto ho chiesto aiuto sul forum a rtestardi, spiegandogli la situazione il più dettagliatamente possibile. La sua risposta è stata la seguente:
I think you're going to hit some fundamental issues here because you have a BASIC program talking to the modem at the same time that StickOS (i.e., a C program) is trying to do so, and there's no coordination between the two so the modem will get confused.

So your two choices are:

1. prevent StickOS from talking to the modem at all, and do everything (even receiving packets) in BASIC -- that's a lot of work, or
2. modify sources/zigflea.c in the skeleton project and recompile StickOS to add your new functionality directly in C.

Neither of these is trivial.

I can tell you that when I first brought the modem up, I did full communication between CPUSticks in BASIC, so it can be done, but basically you have to implement everything in zigflea.c in BASIC -- it's a lot of code.

So I think it will probably be easier to recompile the skeleton project to add the new functionality you need in C, in the receive packet path.

Sorry I don't have something simpler for you.

-- Rich
Capito? StickOS è il mio programma non possono accedere contemporaneamente al transceiver. Di conseguenza la strada da prendere è una di quelle consigliate e a mio avviso preferisco la seconda.
Siccome il progetto skeleton è vasto volevo una mano per lo meno a comprenderlo in prima battuta per poi apportare le giuste modifiche senza fare danni!

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Chiarito il primo punto

Chiarito il primo punto volevo dire che è normale che io abbia più concezione dei problemi in questo caso perchè "ci smanetto"!!! Sono disposto, infatti a spedire le cpustick a chi voglia cominciare a lavorarci (come da precedenti accordi). Mi sembra giusto dare la possibiltà di lavorarci (non solo teoricamente) alle prove sulla cpustick. Basta dirlo.
Detto questo volevo dire a delfino_curioso che ha ragione riguardo la mia totale assenza sull'altro thread. Quindi da ora in poi sarò più partecipe anche di là, come è giusto che sia.
Ciao.

ritratto di lobbyking
Offline
Titolo: User+
Utente+
Ultima visita:
6 settimane 6 giorni fa
Utente dal: 12/12/2008
Messaggi: 13
Ho seguito le varie

Ho seguito le varie discussioni che torneranno sicuramente utili quando potrò metter mani alle CPUStick. io dovrei essere il terzo a riceverle. aspetto il turno.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Ciao zohan, per carità, non

Ciao zohan,
per carità, non punto il dito verso nessuno per l'assenza dal forum :-)
L'invito a guardare di tanto in tanto anche l'altro thread è solo per tenere a mente che stiamo tutti lavorando per lo stesso scopo, anche se lo affrontiamo da punti di vista differenti (HW,SW,FW). E l'interazione , secondo me, fa sempre bene!
Vale quanto già detto sulla disponibilità a collaborare, e spero che non ci siano stati ripensamenti da parte di nessuno date le inevitabili difficoltà iniziali, ma che supereremo.
Tignosi fino in fondo!

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
A tutta la CREW!

Leggendo il codice di zohan, avrei un paio di domande.

1) Conosco pochissimo il BASIC, ma le variabili dichiarate con i nomi di "led", "rxtxen", "irq" etc. immagino siano definite in uno o più header file da qualche parte, mentre "control_a", rx_status", "cca_thresh" etc sono variabili di tipo primitivo short definite nello spazio utente del tuo programma BASIC: non essendo queste ultime puntatori a registri liberamente accessibili da altre procedure esterne, chi è che ci carica dentro i valori che poi vai a leggere tramite SPI?

2) Come dice rtestardi, visto che stai lavorando mediante interruzioni, è possibile che nel tuo programma BASIC l'intercettazione dell'arrivo di un pacchetto avvenga (quasi) contemporaneamente alla stessa operazione fatta dal sistema operativo. Se è solo una questione di tempi di accesso ai registri tra il S.O. ed il programma, potresti fare una prova immettendo un ritardo al lancio della subroutine "read_registers": ad esempio la prima istruzione potrebbe essere un delay di un secondo prima di "let rxtxen = 0".....

SE QUANTO APPENA SCRITTO DOVESSE RISULTARE ININFLUENTE RIGUARDO AL PROBLEMA DI ZOHAN, vorrei proporre una riflessione a tutto il gruppo.

E' veramente necessario imbarcarsi nelle imprese (non banali) suggerite da rtestardi?
Si tratterebbe di spendere tempo ed energie nel "customizzare" per il nostro scopo un hardware che alla fine non sarà neanche quello del prodotto finale. A meno di ripensamenti, per le prove si era deciso di usare CPUStick per:
1) disponibilità del prodotto;
2) ambiente di programmazione semplice;
3) presenza delle funzionalità legate a ZIGBEE.

Ora, se il punto 2) (decisamente importante) viene meno ci troveremmo a fare un bel mazzo per il solo ambiente di test funzionante.
Non sarebbe allora meglio fare il mazzo direttamente su tutte le problematiche connesse all'HW finale e magari semplificarci un pò la vita per le fasi di test (riconsiderando ad esempio il binomio Arduino+Zigbee che avevate proposto, o altre soluzioni disponibili e/o acquistabili senza svenarsi)?

Sia chiaro, non voglio nè essere distruttivo verso il tempo finora dedicato da zohan alla CPUStick nè tirarmi indietro alla prima difficoltà.
Se il gruppo la pensa diversamente, si torna a lavorare su CPUStick senza problemi, come già si stava facendo.
Prendetela come un'occasione per risentire il parere di tutta la crew sul nostro blog ;-)

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ciao delfino_curioso, ti

Ciao delfino_curioso, ti rispondo subito.
1)alle righe 330, 362 e 400 del programma che ho postato faccio uso del comando "qspi" che StickOS mette a disposizione per utilizzare proprio questo tipo di interfaccia (SPI). In particolare, in queste righe vado a leggere i registri che mi interessano e metto il risultato nelle variabili che ho definito short(lo faccio sia per leggere dei registri di stato, sia per avere la conferma che le operazioni di scrittura fatte prima siano andate a buon fine).
2) Il problema consiste sicuramente nella giusta coordinazione tra StickOS e il mio programma in BASIC. Il punto è come fare a capire la giusta tempistica? Le ho fatte le prove che dici tu, utilizzando il comando "sleep" che StickOS mette a disposizione proprio per "aspettare". Ho provato diversi tempi e in diversi punti del programma. Il risultato non cambia.
Spero di essere stato esaustivo.
Riguardo alla tua considerazione sono pienamente d'accordo con te e penso lo siano tutti.Mi sembra ovvio che conviene spendere le nostre energie per creare un firmware personalizzato alle nostre esigenze sul prodotto finale e non su una scheda di prova che poi non utilizzeremo.
Io ho fatto presente il problema e la soluzione. Le prove sulla CPUStick in fondo servivano anche a questo, ad individuare eventuali ostacoli che si potrebbero avere sul prodotto finale.Il fatto che per i nostri scopi progettuali non convenga percorrere la soluzione è un altro discorso.Ne condivido il fatto di non andare a studiarci il progetto skeleton anche se sarebbe un bell'esercizio che appunto rimarrebbe tale.

ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM
Antismarrimento collaborativo

Concordo con le ultime osservazioni di Delfino e credo inoltre sia il caso di mettere un punto, chiudendo questa fase e per poi passare alla successiva.

Chiedo quindi a Zohan di scrivere una relazione conclusiva finalizzata a:

1) studio fattibilità
2) assorbimenti
3) identificazione della distanza in base alla quantità di segnale ricevuto.
4) considerazioni varie

Se riesci (in privato) ad inviarmi alcune foto posto il resoconto in prima pagina sul blog, come STEP 2
per tenere traccia del lavoro ed allo stesso tempo dare visibilità all'iniziativa.
(Se vuoi che sia pubblicato a tuo nome fammelo sapere che ti attivo i permessi da Contributor, come preferisci).

A questo punto attenderei anche le prove di Delfino sul sistema Texas e poi decidere come proseguire.

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Ciao Emanuele, come avrai

Ciao Emanuele,
come avrai letto ho riscontrato un problema la cui soluzione richiederebbe troppe energie e tempo assolutamente non giustificate ai nostri scopi.
A mio parere non risolvendolo è difficile dare delle considerazioni relative al nostro progetto. Ammetto che per quello che riguarda gli assorbimenti non ho ancora fatto nulla perché ho dato priorità all'estrazione della potenza del segnale. Vedo di provvedere.
Siccome si era deciso fin dall'inizio che le prove sulla CPUStick dovevano essere fatte da più persone, io proporrei di permettere ad altri membri della crew di fare le loro considerazioni prima di scrivere una relazione.
Dico questo non solo perché mi sembra corretto per gli altri, ma anche perché voglio confrontarmi sul problema da me riscontrato. Spero che ci sia qualcuno che riesca a estrarre l'RSSI utilizzando solo quello che StickOS mette a disposizione, insomma spero di avere torto:)
Che ne pensi?

ritratto di lobbyking
Offline
Titolo: User+
Utente+
Ultima visita:
6 settimane 6 giorni fa
Utente dal: 12/12/2008
Messaggi: 13
se quello sulla CPUStick deve

se quello sulla CPUStick deve essere un mero esercizio, non finalizzato all'utilizzo dello stesso per i nostri scopi portando via tempo inutilmente, allora concordo con il cambiare pagina e prendere di petto altre soluzioni

ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM
Sin dall'inizio l'utilizzo

Sin dall'inizio l'utilizzo della CPUstick era finalizzato a quanto sopra scritto.

Come dicevo, e poi dimostrato da Zohan, usare la cpustick è estremamente facile e quindi, l'intento era esclusivamente quello di utilizzarle come demoboard (anche perchè le abbiamo in casa)

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Assorbimento CPUStick

Ciao a tutti.
Ho fatto una prima misura di assorbimento. La misura si è svolta così:
ho preso un multimetro, l'ho impostato come amperometro con un fondoscala di 250mA e ho connesso i puntali ai piedini del jumper j2.
Ho connesso la CPUStick alla porta USB e la misura è disponibile.
Sia in standby che in run il consumo istantaneo è di circa 206.2 mA.
Non è tantino?

ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM
Anche a me il consumo sembra

Anche a me il consumo sembra un po' eccessivo, anche perche il transceiver dovrebbe assorbire 30/40 mA ma in tx/rx mentre in standby siamo nell'ordine dei uA.

Prova a vedere se riesci a gestire le modalità di run, sia del micro che del ricetrasmettitore.

Comunque il mio parere è sempre che tu concluda le prove con una relazione, quanto meno per dare un senso a quanto fatto ed agevolare il lavoro degli altri, nell'ottica del progetto ovviamente.

MA sentiamo anche gli altri che ne pensano.....

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
In termini di consumo ed ai

In termini di consumo ed ai fini del progetto, darei più peso alla differerenza di valori tra le operazioni "spinte" e quelle "a risparmio" di CPUStick piuttosto che al valore assoluto di corrente assorbita dall'intero sistema.
L'HW finale del progetto, minimale e con firmware ottimizzato, avrà senz'altro dei valori di consumo globale più bassi, ma soffrirà nelle operazioni più onerose (es., la trasmissione radio) e grazie alle esperienze su CpUStick si capirà meglio come dimensionare e scegliere una opportuna batteria.

Quanto alla relazione, penso che qualche riga su quanto sperimentato da ognuno di noi faccia comunque bene a chi deve prendere "le nostre consegne".

Una proposta per ottimizzare i tempi: gli informatici della crew, se non già impegnati su altre parti del progetto, potrebbero provare nel frattempo ad implementare una bozza di algoritmo di calcolo della distanza a partire dalla potenza del segnale? Una base di partenza potrebbe essere l'equazione di Friis ( http://en.wikipedia.org/wiki/Friis_transmission_equation ). Coordinator Emanuele, che ne pensi?

ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM
Ottima idea

Inoltre TI ci guida anche in questo
http://www.ti.com/lit/an/swra169a/swra169a.pdf

Punto a favore per utilizzare un sistema TI

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
ottima proposta

Trovo ottima la proposta di delfino. Procedo con le prove sull'assorbimentoe poi comincio ad abbozzare la relazione. Volevo informarvi che nelle modalita off e nella modalita "idle" del transceiver, il consumo scende intorno a 180 mA, come era prevedibile. Continuo nei prossimi giorni agendo sulle modalita low power offerte dal microcontrollore.

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
assorbimento: prime considerazioni

Ho fatto alcune prove e ho notato che all'accensione della cpustick, il transceiver si porta in modalità RX_mode e il controllore lavora a una frequenza del PLL pari a 80MHz. Sui datasheet ho trovato che in queste modalità il transceiver consuma dai 35-40 mA e il micro può arrivare a consumare fino a 180mA. Questo spiegherebbe il consumo che vi ho detto prima.
In condizioni di "idle" il transceiver non consuma praticamente nulla. Giocando sulla frequenza del PLL e abbassandola fino a 8MHz ho notato che il consumo della scheda scende fino a 70mA circa (con transceiver attivo). A frequenze cosi basse ho notato che perdo il controllo tramite hyper terminal, ma StickOS e il programma in BASIC continua a girare. Di questo sono sicuro perchè ho riprovato il solito programma che fa accendere un led a intermittenza di 1 sec sulla scheda slave e funziona. L'unica differenza è che con una frequenza di PLL a 8MHz, 1 secondo per il programma diventano 10 secondi. StickOS sembra programmato per funzionare bene con PLL a 80 MHz.
Attualmente sto studiando le modalità low power del microcontrollore.
Qualsisasi tipo di osservazione è ovviamente ben accetta.
Ciao a tutti.

ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM
PLL assassino

Evidentemente la colpa è del PLL se lo disattivi completamente lasciando il micro alla frequenza del quarzo penso che l'assorbimento scenda a pochi mA.

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
jumper j4?

Emanuele se hai un'altra cpustick a portata di mano potresti verificare la presenza del jumper j4? Te lo chiedo perchè nello schema elettrico è presente , ma sulla scheda non lo trovo.
Questo jumper permette di selezionare diverse modalità di funzionamento per quel che riguarda il pll, e quindi permette anche di disabilitarlo.
Grazie.

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Mi correggo. Il jumper j4

Mi correggo. Il jumper j4 serve per cambiare le modalità di uso del pll, anche per disabilitarlo. Disabilitarlo non credo significhi "spegnerlo",per avere questa sicurezza si dovrebbe mettere a massa il pin VDDPLL, ma non si può fare perchè la scheda non lo prevede.

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
Articolo pubblicato

Ho pubblicato l'articolo che sintetizza le prove sulla CPUStick. Ho dei problemi di "formattazione" e poi le immagini non si vedono. :) help!
Cmq spero sia utile. Qualunque commento/chiarimento è ben accetto.

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Zohan, in che sezione hai

Zohan, in che sezione hai pubblicato il tuo articolo?
Colgo inoltre l'occasione per dirvi che per questo fine settimana avrete anche lo schema elettrico della prima release delle schede master e slave del progetto, con allegati BOM, documento esplicativo e (se faccio in tempo) layout del PCB.
Ciao

ritratto di signolo
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 3 giorni fa
Utente dal: 07/10/2011
Messaggi: 35
Se mi fai avere lo schema

Se mi fai avere lo schema elettrico posso conttribuire facendo il master

ciao

ritratto di delfino_curioso
Offline
Titolo: User++
Utente++
Ultima visita:
2 giorni 14 ore fa
Utente dal: 01/09/2012
Messaggi: 96
Utente PREMIUM
Ok Signolo! Considera che lo

Ok Signolo!
Considera che lo schema si riferisce ad una prima versione di prova delle schede. Troverai dei componenti che conto di eliminare una volta che le board potranno essere considerate stabili (es. Il connettore di debug), ma inizialmente ci fanno comodo.
Suggerimento: per semplicitá, utilizzerei per il master di questa prima release componentistica tradizionale THT piuttosto che SMD, magari inserendo qualche test-point tra le piste, e lascerei ad una fase successiva la progettazione miniaturizzata...
Richiesta: l'unico componente che va montato superficialmente è il transceiver e purtroppo non sono attrezzato per saldature di precisione. Se ti spedisco per posta il transceiver, hai modo di montarlo direttamente una volta realizzato il pcb?

ritratto di signolo
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 3 giorni fa
Utente dal: 07/10/2011
Messaggi: 35
si inviamelo lo salderò :)

si inviamelo lo salderò :)

ritratto di zohan85
Offline
Titolo: User+
Utente+
Ultima visita:
19 settimane 5 ore fa
Utente dal: 18/09/2012
Messaggi: 33
L'articolo è scritto ed

L'articolo è scritto ed Emanuele lo sta "sistemando". Il tempo di aggiungere una foto e sarà pubblicato.

ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM
Articolo pubblicato
ritratto di Emanuele
Offline
Titolo: Moderator
Moderatore
Ultima visita:
2 ore 10 min fa
Utente dal: 28/07/2007
Messaggi: 1022
Utente PREMIUM
MESSAGGIO PER LA CREW

MESSAGGIO PER LA CREW

Mercoledì 19 DIC videoconferenza sul progetto. Contattatemi in privato per i dettagli

 

 

Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ci sono attualmente 19 utenti e 58 visitatori collegati.

Ultimi Commenti