Newsgroup: it.hobby.elettronica.digitale
Titolo: Ethernet x bus di campo

Attualmente utilizzo una semplice RS485 proprietaria per collegare una
manciata di schede a microcontrollore, diciamo una decina.
La chiamo proprietaria, perchè il protocollo a livello di pacchetto è
inventato da me: ci ho messo l'indirizzo, la lunghezza del pacchetto, una
checksum... insomma, una cosa abbastanza tipica.
Devo dire che funziona tutto egregiamente... naturalmente è di tipo
master-slave, solo il master può iniziare a comunicare e interrogare con
gli slave.
Ora volevo passare a qualcosa di più performante, magari più veloce, magari
più standard, magari più affidabile, sempre a basso costo, magari che fosse
P2P (non master-slave).
Naturalmente la scelta ricade quasi immediatamente su CAN e Ethernet.
Mi affascina molto l'idea di Ethernet perché avrei un bus praticamente standard,
quindi facilmente modificabile in un secondo momento.
Con la RS485, già ho trovato problemi ad aumentare la velocità seriale in
quanto i micro avevano quarzi diversi e potevano essere programmati solo fino a
38400bps senza troppi errori.
Con Ethernet avrei almeno 10Mbit/s che sono, per me che vado a 38400bps, più che
sufficiente.
Quello che mi spaventa è il tipo di microcontrollore da usare. Normalmente ho
bisogno di ADC, qualche timer, un paio di UART e un bel po' di pin (un
centinaio). Magari a 16 bit con moltiplicatore hw. Esiste qualcosa del genere a
basso costo con PHY e MAC Ethernet integrato, magari con uno stack TCP/IP molto 
semplice?
Sul TCP/IP non userei protocolli complicati (HTTP, telnet o altri) ma 
semplicemente una trasmissione RAW, un po' come sulla RS485.
Inoltre, essendo un bus interno staccato da Internet, non mi preoccuperei
di attacchi DoS o simili, quindi le risorse per gestire questa rete dovrebbero
essere molto limitate.
Avete qualcosa da consigliarmi?

 ha
scritto:

Per sviluppare Ethernert puoi usare dei moduli già pronti tipo i Tibbo o anche
usare un microprocessore più evoluto tipo ARM a 32 bits.
Ce ne sono di diverse marche e caratteristiche con un sacco di opzioni hw da
Philips a Sharp o Atmel, io per poter implementare protocolli di tipo più
sofisticato (TCP-IP) prenderei in esame questa possibilità.
Oramai il prezzo degli ARM sta scendendo sempre più grazie all'uso sui
telefonini, e oramai la cosa diventa sempre più allettante, io ci farei un
pensierino.
--
ciao
  Stefano

 pensierino.
Sono d'accordo ed ho fatto una piccola ricerca. A questa pagina
 
http://www.keil.com/dd/list_parms.asp?s=arm&bhcp=1
dovrebbe esserci l'elenco di tutti i micro che adottano un'architettura ARM.
Tra queste non ci sono molti dispositivi che supportano Ethernet. In soldoni:
   - 5 della Atmel
   - 6 della NXP (Philips?)
   - 2 ST
Sembra, però, che tutti abbiano integrato solo il livello MAC di Ethernet e 
nessuno abbia anche il livello PHY (quanto difficile/costoso è farselo esterno? 
E come dimensioni?)
Interessanti, invece, sono i microcontrollori della Freescale che hanno sia MAC 
che PHY integrati. In pratica ci devi collegare solo il connettore RJ45 (mi sa 
che anche il trasformatore 1:1 è integrato) e sei a posto.
La famiglia è questa: MCF52235
Certo è che probabilmente si spenderanno più soldi sia per i componenti che per 
gli ambienti di sviluppo.

gli ambienti di sviluppo.
Gli ambienti ormai sono tutti JTAG, e i compilatori si trovano spesso free come
il WinArm del GCC ai quali devi aggiungere i files .h.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/WinARM_20060117_readme.html
E la mia idea è che il futuro passi proprio per la strada ARM.
--
ciao
  Stefano

Abbiamo realizzato un modulo PIC18 con ethernet
a bordo della grandezza di un DIP40.
Stiamo sviluppando varie applicazioni da rendere gratuite sul sito,
il firmware funziona a task, come da application microchip.
Puo gestire 1 seriale (la seconda puo essere via software), ad converter
e le varie periferiche del PIC18
Dai un'occhiata qui se puo interessarti
(il sito è ancora in costruzione, ma il progetto è ultimato)
http://www.ftpmicro.com
Emanuele
-- 
*** YOUR ELECTRONICS OPEN SOURCE ***
http://dev.emcelettronica.com
;---------------------------------------------------------
Progetti Completi e Risorse (Full Projects and resources)

 E la mia idea è che il futuro passi proprio per la strada ARM.
Sì, gli ARM sono destinati sicuramente ad aumentare il loro peso nel mercato dei 
microcontrollori. Ma questi compilatori free (WinARM, per esempio) come si 
comportano?

 esempio) come si comportano?
Benissimo :)
WinARM non è altro che tutta la toolchain GCC compilata per ARM e 
pacchettata in modo che funzioni sotto Windows.
Il GCC, se non lo conosci, è il compilatore GPL per eccellenza, usato 
per moltissime CPU in milioni di progetti in giro per il mondo.
Forse sarà un po' ostico dal punto di vista dell'usabilità (devi 
smanettare tra i makefile senza un IDE standard), ma credo che come 
affidabilità non ci siano paragoni con i compilatori commerciali.
Ciao

comportano?
Come ti ha già detto Francesco WinARM è una versione dello stracollaudato GCC,
lo stesso che si trova su WinAVR ad esempio.
Devi fare un pò di gavetta per usare il make ma si trova diversa roba in rete
già pronta e usabile.
Io non mi sposterei da ARM anche per questo.
--
ciao
  Stefano

 Io non mi sposterei da ARM anche per questo.
gcc lo conosco bene nel mondo Linux su PC. Lì è veramente stracollaudato. Il 
problema è la sua implementazione su ARM che è, immagino, molto diverso da 
un'architettura 8086. E' per questo che mi chiedevo quanto fosse affidabile e 
performante l'implementazione di gcc per ARM, non gcc in sé.

performante l'implementazione di gcc per ARM, non gcc in sé.
WinARM lo usano in moltissimi e da tempo.
Poi sei sicuro che un compilatore non abbia bugs solo perchè è a pagamento?
--
ciao
  Stefano


--
ciao
  Stefano

 per ARM, non gcc in sé.
Ho usato sia il gcc sia lo IAR per ARM e il gcc lo batte quasi su tutti 
i fronti.
Vince sulla stabilità e sulla velocità di esecuzione del codice. Sulla 
dimensione di codice C generico sono pressocchè equivalenti. Perde sulla 
dimensione del codice C quando si usano alcune funzioni della libc standard.
Questo può essere un problema, ma la maggiore occupazione del codice è 
dovuta essenzialmente al fatto che le librerie standard C, sul gcc 
rispettano lo standard ANSI, il C99, sono stracollaudate e stradebuggate.
Sullo IAR esse sono evidentemente state riscritte da zero (quindi con 
più possibilità di bug) e solo per ARM (e quindi più ottimizzate), a 
volte però tagliando funzioni poco usate (caso tipico: la printf non 
supporta tutti i formattatori, oppure non supporta i float, etc...).
Concludo con altri 2 punti, uno a favore dello IAR l'altro del gcc
Lo IAR ha il suo IDE con debugger integrato, che è più facile da usare 
(ma si blocca spesso perchè è pieno di bug :) )
Il gcc è gratis,lo IAR costa alcune migliaia di euro :)
Ciao

 per ARM, non gcc in sé.
Ho trovato un documento che confronta diversi compilatori per ARM, 
neanche a farlo a posta, alla fine arriva alle mie stesse conclusioni:
http://www.raisonance.com/products/STR7/benchmark.php
Ciao

 Poi sei sicuro che un compilatore non abbia bugs solo perchè è a pagamento?
Assolutamente, volevo solo informarmi sullo stato di questo sistema di sviluppo. 
Ci sono numerosi prodotti open-source affidabili e più performanti dei 
corrispettivi a pagamento... in altri casi è, però, il contrario.

 Il gcc è gratis,lo IAR costa alcune migliaia di euro :)
Eccezionale... grazie delle informazioni.