Home Forum NUOVE IDEE O PROGETTI DA SVILUPPARE ANTISMARRIMENTO: prove con CPUstick (demoboard)

Questo argomento contiene 55 risposte, ha 6 partecipanti, ed è stato aggiornato da  Emanuele 1 anno, 11 mesi fa.

Stai vedendo 15 articoli - dal 1 a 15 (di 56 totali)
  • Autore
    Articoli
  • #59138

    Emanuele
    Keymaster

    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.

    #71775

    lobbyking
    Membro

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

    #71782

    AndreaD
    Membro

    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… :)

    #71783
    delfino_curioso
    delfino_curioso
    Partecipante

    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

    #71788

    signolo
    Membro

    infatti annotare il consumo è fondamentale!!!

    #71812
    delfino_curioso
    delfino_curioso
    Partecipante

    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.

    #71834

    zohan85
    Membro

    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 :)

    #71867

    zohan85
    Membro

    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.

    #71887

    zohan85
    Membro

    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.

    #71890
    delfino_curioso
    delfino_curioso
    Partecipante

    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

    #71888

    zohan85
    Membro

    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.

    #71889
    delfino_curioso
    delfino_curioso
    Partecipante

    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?

    #71891
    delfino_curioso
    delfino_curioso
    Partecipante

    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…

    #71892

    zohan85
    Membro

    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.

    #71893
    delfino_curioso
    delfino_curioso
    Partecipante

    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

Stai vedendo 15 articoli - dal 1 a 15 (di 56 totali)

Devi aver eseguito l’accesso per poter rispondere a questa discussione.