Rowley supporta gli stellaris e si puo' usare l' emulatore della Olimex che cosat meno del loro e costa un bel po' meno dello IAR :-) A.
Rowley supporta gli stellaris e si puo' usare l' emulatore della Olimex che cosat meno del loro e costa un bel po' meno dello IAR :-) A.
Il 08/02/2012 17:19, aa ha scritto:
Ma quanto costa ora lo IAR? Perché già il Rowley è a quasi 1200 euro :(
Marco
Un bel giorno Marco Trapanese digitò:
Mi pare che il bundle con l'emulatore J-LINK e la versione dello IAR Embedded Workbench per ARM nodelocked e limitata a 256 KB (sufficienti direi per quasi tutti gli Stellaris) costi attorno ai 2000 euro. Certo non è poco, ma inizia a dividere i 2000 euro per il costo orario di una persona, o addirittura per il prezzo a cui vendi un'ora di sviluppo (che non è così insensato: il tempo che una persona perde per configurare dei tool malfunzionanti sono ore improduttive) e vedrai che salta fuori un tempo inferiore a quello che sicuramente dedicheresti a capire perché gdb non vuole saperne di andare, Eclipse non si interfaccia bene con gdb, il driver USB non funziona, la libreria manca...
Poi ci sono anche Keil e Code Red. Quest'ultimo in particolare dovrebbe costare parecchio meno, ma non so dirti molto di più, a parte che si basa su Eclipse (il che ai miei occhi è un demerito :-)).
-- Fletto i muscoli e sono nel vuoto.
Il 08/02/2012 19:33, dalai lamah ha scritto:
Sulla carta è tutto vero. Nella pratica purtroppo è raro "vendere" al giusto prezzo l'ora di sviluppo. Anche perché le ore improduttive sono sì perse ma non sono costi vivi. Per recuperare 2000 euro (nel senso di andare alla pari, senza averci ancora guadagnato nulla) dovrei sviluppare continuativamente e per parecchio tempo su quell'architettura.
Eclipse in sé non è malvagio. Sono i plugin che danno un sacco di problemi. A parte che - ripeto - avevo provato le demo se ben ricordo proprio Code Red e Atollic. Eppure davano grossi problemi al punto che ho rinunciato all'acquisto, dopo ammissione da parte del supporto tecnico.
Viceversa dal lato free, la difficoltà maggiore era dovuta al plugin zylin. Essendo freeware non offre supporto diretto e anzi lo sviluppatore è stato pure abbastanza scortese in proposito.
Provo magari a vedere cosa offre la TI oggi.
Ciao! Marco
Il 06/02/2012 16:44, aa ha scritto:
mumble, c'è forse una via migliore. Visto che alla fine dovendo isolare tutto avrei 1 solo slave per ogni segmento CAN anziché utilizzare 4 ARM
Metto un solo ATxmega*A1 che ha 8 UART. Su ogni UART ci metto gli 8 transceiver isolati, ciascuno che va verso uno slave.
Quando è complesso implementare 8 master CAN su un micro che non ha il CAN controller in hardware?
Teniamo conto che la comunicazione sarà molto elementare: ciclicamente il master invia un pacchetto (8 byte) verso ciascuno slave, il quale risponde con un altro unico pacchetto. A meno di guasti non ci saranno mai collisioni.
Marco
Il 09/02/2012 14:40, Marco Trapanese ha scritto:
Voglio dire, comporre il frame (esteso nel mio caso) del CAN mi sembra piuttosto banale. Occorre gestire li bitstuffing e il CRC.
Cosa fanno in più i controller CAN hardware, considerando le specifiche del messaggio precedente?
Marco
Il 09/02/2012 14:40, Marco Trapanese ha scritto:
Mi rispondo da solo. La fregatura sta che dovrei utilizzare una tecnica bit-banging, le UART non possono essere utilizzare in questo caso visto che hanno i bit di start e stop e i messaggi di lunghezza predefinita.
Torno agli Stellaris. Sembrava troppo semplice infatti :)
Marco
Un bel giorno Marco Trapanese digitò:
A questo punto piuttosto che un altro micro (che comunque come hai detto non ti risolverebbe il problema) fallo con una FPGA: in quel modo di rami ne puoi mettere anche 50, e con 10 euro fai tutto.
-- Fletto i muscoli e sono nel vuoto.
Il 09/02/2012 20:43, dalai lamah ha scritto:
Giusto, peccato che non riuscirei a farlo in un paio di settimane o poco più non avendo mai toccato una FPGA ;)
Vado di 4 LM3S8970, di cui uno lo sfrutto anche come master.
Marco
Mai dire mai :-)
BTW, Con una CPLD o una piccola FPGA isolare gli otto canali 'parallelizzandoli' si risolve tutto con una manciata di porte OR e AND ... una cosa da fare in mezza giornata :-) Rimarrebbe da gestire 'lenable dei singoli canali a software... A.
Il 10/02/2012 08:02, aa ha scritto:
Eventualmente lo propongo come step successivo, dati i tempi stretti non farei a tempo ad acquistare ambiente di sviluppo / programmatore, imparare a utilizzare le FPGA e realizzare il progetto.
Però posso farlo per i fatti miei e proporlo a tempo debito come upgrade.
Giusto per capire, non mi è chiaro cosa andrebbe "parallelizzato". Il lato digitale dei transceiver? Da abilitare poi con l'enable?
Marco
Il 10/02/2012 08:02, aa ha scritto:
Che dev kit per FPGA consigliereste per iniziare a farci qualcosa?
Marco
da quello che ho capito, hai un unico master che colloquia con otto slave, ognuno dei quali deve essere isaolabile dagli altri in modo da non bloccare il resto degli slave, giusto?
Allora, usi otto transceiver per ogni segmento di bus, ma poiche' e' sostanzialmente un unica linea quello che devi fare e' ricircolare i segnali del lato digitale : tutti i TX su tutti gli RX (Sostanzialmente fai l' AND di tutti i TX e il risultato finisce nei vari RX).
Questo è un po' come mettere in back to back i transceiver: a questo punto devi condizionare i singoli TX che arrivano dagli slave con un enable (sostanzialmente e' un OR: se enable=1, il TX e' disabilitato). (Complicando un p' la logica, puoi disabilitare anche l' RX del canale disattivo, cosi fa non propagare i messaggi degli altri)
La CPU master tramite 8 linee di IO, oppure implementi un registro di controllo nella CPLD/FPGA, puo' a questo punto abilitare la ricezione di uno o piu' slave alla volta. Quindi puo' o inviare e ricevere messaggi a tutti i nodi o selezionare uno o piu' nodi del gruppo. Se ci sono dei problemi, abilitando un nodo alla volta e' possibibile discriminare se un nodo sta' bloccando il bus e quindi isolarlo. A.
Il 10/02/2012 17:44, aa ha scritto:
Giusto. Isolamento prima di tutto galvanico, poi anche a livello logico per evitare che il bus rimanga inchiodato in caso di slave pazzo.
Intendi un transceiver per ogni segmento immagino, otto in totale.
Aspetta, mettiamoci d'accordo sui nomi. Per i transceiver i pin TX sono ingressi (dato da trasmettere) mentre gli RX sono uscite. Mentre dalla tua descrizione sembrerebbe il contrario.
Sono abituato a "parallelizzare" con gli OR e ad abilitare con gli AND. Qui invece è dovuto al fatto che il bit dominante è lo 0, giusto? E' questo che mi confondeva mi sa.
Chiaro.
Perfetto. Quello che mi fregava è che io ragionavo con gli OR e mi ritrovavo nella condizione di bus inchiodato.
In effetti è molto semplice, vedo se trovo un dev kit della Altera per cominciare a fare qualche esperimento con le FPGA.
Grazie ancora per il tempo che hai dedicato a rispondermi. Marco
Si...
Ho indicato come TX le uscite e con RX gli ingressi...
;-) BTW, di solito si usa una logichetta simile (AND/OR ed enable) sui nodi CAN il cui controller non supporta la modalita di solo ascolto... serve per fare l' autobaud :-)
Bye! A.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.