View Full Version : [Elettronica] Alimentazione sul segnale
Cosa fa l'ingegnere elettronico in vacanza? Idea circuiti per il tempo libero :D
Ecco, c'è una cosa a cui sto pensando da un po' di tempo ma su cui non ho avuto modo di fare prove, e dato che tutta la mia attrezzatura non mi ha potuto seguire per le ferie e io sono fondamentalmente uno sperimentatore, mi trovo un po' spaesato. Ergo, chiedo consiglio.
Per motivi di fili, dovrei alimentare dei dispositivi che comunicano tra loro sfruttando i cavi addetti alla comunicazione.
Ossia, io ho TX, RX, GND, e su uno dei due di trasmissione ho bisogno di farci arrivare anche l'alimentazione. Che si possa fare, ne sono certo: lo fanno. Come si faccia, nutro qualche dubbio in proposito...
Ossia: nel "trasmettitore" (quello da cui parte l'alimentazione, insomma) ho pensato che sia sufficiente, sulla linea TX per esempio, mettere un condensatore in serie e a valle del condensatore collegare l'alimentazione in continua, così lui non se ne accorge. Sul ricevitore stessa cosa, condensatore in serie e a monte prende l'alimentazione e a valle il segnale.
Dubbi: il segnale passerà pure attraverso il condensatore, come faccio a fare in modo che non venga assorbito troppo? Dovrei mettere un condensatore che, per la frequenza del segnale, abbia una impedenza abbastanza alta? O magari fare un filtro LC con la L verso l'alimentazione in modo che il segnale passi più difficilmente?
Insomma, che ne dite?
Ciao, allego uno schizzo.
Il condensatore piccolo va dimensionato in base alla frequenza del segnale, più è alta e piu puoi permetterti di metterlo piccolo, la capacità polarizzata serve per mantenere la carica e il diodo serve a raddrizzarla (in quanto il condensatore in serie disaccoppia la componente continua).
Ovviamente questa è un'accrocchiata :D
In genere per questo tipo di applicazione si utilizzano dei loop di corrente o un bus tenuto alto dal master su cui la comunicazione è di tipo open collector (i2c like).
Che grado di libertà hai su questi dispositivi? I firmware, il protocollo e l'hardware sono stati sviluppati da te o sono schede gia pronte all'uso che devi adattare? Che consumi hai ?
Ciao
Ciao, allego uno schizzo.
Il condensatore piccolo va dimensionato in base alla frequenza del segnale, più è alta e piu puoi permetterti di metterlo piccolo, la capacità polarizzata serve per mantenere la carica e il diodo serve a raddrizzarla (in quanto il condensatore in serie disaccoppia la componente continua).
Ovviamente questa è un'accrocchiata :D
In genere per questo tipo di applicazione si utilizzano dei loop di corrente o un bus tenuto alto dal master su cui la comunicazione è di tipo open collector (i2c like).
Che grado di libertà hai su questi dispositivi? I firmware, il protocollo e l'hardware sono stati sviluppati da te o sono schede gia pronte all'uso che devi adattare? Che consumi hai ?
Ciao
Orca, addirittura lo schizzo :D (per la cronaca, io sono Gpc, non Jpc :D ma fa niente :p )
Non mi torna molto però, così, devo dire... con lo schema che hai messo tu, sul 3 del ricevitore arriva pure la continua, mentre invece non dovrebbe essere così... Praticamente, dovrei avere C1 in serie tra il connettore e il ricevitore, e prima di C1 metterci il diodo per prendere la continua, e dopo C1 attaccarci il ricevitore, che così non si beccherebbe la continua in ingresso. No?
Comunque il grado di libertà è massimo, per ora tutto esiste solo nella mia mente (malata :D ).
Praticamente questo accrocchio mi serve per poter iniziare a progettare un sistema di irrigazione estremamente fico e intelligente, dotando ogni vaso di un sistema di sensori di temperatura-umidità-luce-timer da interfacciarsi con una unità centrale che li imposta, li controlla, registra gli eventi e comanda le elettrovalvole e la pompa del serbatoio.
Ops ho fatto la gaff :stordita:
Comunque ora ho capito cosa volevi fare, sommare una componente continua ad una alternata e separarle tramite condensatori ;)
In questo caso l'unico problema penso che sia il fatto che i condensatori distorceranno un po' il segnale che non sarà più una bella quadra. Credo che servira un operazionale per ridargli una forma più "digitale".
Pero se il grado di libertà è massima tanto vale fare un sistema di comunicazione half-duplex usando un solo filo per la comunicazione lasciando un filo libero per l'alimentazione :D
Dulcis in fundo se la tua passione è complicarti la vita potresti usare solo due fili ingegnandoti un po', massa per uno e alimentazione+tx+rx per l'altro :D
Ciao
PS.
Con lo schizzo che ho postato prima si ricava una continua (a dire il vero a metà tensione :p ) da un'alternata e funziona solo se il dispositivo continua a comunicare continuamente. Funziona tranquillamente con la seriale ai livelli della 232 e con logica a 5 o 3,3V (ormai la più comune).
Praticamente questo accrocchio mi serve per poter iniziare a progettare un sistema di irrigazione estremamente fico e intelligente, dotando ogni vaso di un sistema di sensori di temperatura-umidità-luce-timer da interfacciarsi con una unità centrale che li imposta, li controlla, registra gli eventi e comanda le elettrovalvole e la pompa del serbatoio.Wow John (J).
Perche' non usi una 1394B? :sofico:
Ops ho fatto la gaff :stordita:
Comunque ora ho capito cosa volevi fare, sommare una componente continua ad una alternata e separarle tramite condensatori ;)
In questo caso l'unico problema penso che sia il fatto che i condensatori distorceranno un po' il segnale che non sarà più una bella quadra. Credo che servira un operazionale per ridargli una forma più "digitale".
Sì, esatto, per la forma della quadra non credo che ci siano problemi, tanto la RS-232 non dovrebbe essere schizzinosa :p
Devo solo stare attento al caso in cui trasmetta una sfilza di "1", perchè in quel caso lì avrei dei problemi.
Potrei dimensionare il condensatore in modo che si carichi con un tempo superiore ad una quantità ragionevole di "1" di seguito e metterci un pull-down perchè si scarichi più in fretta. Potrebbe essere?
Pero se il grado di libertà è massima tanto vale fare un sistema di comunicazione half-duplex usando un solo filo per la comunicazione lasciando un filo libero per l'alimentazione :D
Dulcis in fundo se la tua passione è complicarti la vita potresti usare solo due fili ingegnandoti un po', massa per uno e alimentazione+tx+rx per l'altro :D
Eh c'avevo pensato...
Solo che avrei dei problemi con i conflitti tra le comunicazioni... diciamo che una delle postazioni dei sensori rilevi che c'è bisogno di acqua, inviando così un pacchetto al "cervello". Ma nello stesso tempo il "cervello" stava inviando qualcosa ad un'altra delle postazioni, oppure alla pompa. In quel caso lì c'è un bel conflittone... se usassi solo un filo per tutto, tx-rx-alim, sarei nella cacca. Se usassi tx e rx, non sarei comunque in una situazione fantastica perchè un conflitto sulla stessa linea può comunque avvenire, ma diciamo che si dimezza la probabilità che avvenga. Se poi aggiungo, come temo di dover fare, una linea che segnali la trasmissione in corso, ho risolto il problema. A meno che... se usassi il tx per l'alimentazione e l'rx per un altro segnale... naaa... troppa pippa, una piattina da 4 fili non ha mai dato fastidio a nessuno :D
Ciao
PS.
Con lo schizzo che ho postato prima si ricava una continua (a dire il vero a metà tensione :p ) da un'alternata e funziona solo se il dispositivo continua a comunicare continuamente. Funziona tranquillamente con la seriale ai livelli della 232 e con logica a 5 o 3,3V (ormai la più comune).
Eh sì avevo notato... :p
Wow John (J).
E perchè non Juan? :D
Perche' non usi una 1394B? :sofico:
Uuuuhhhh... 1394B sarebbe?
Piuttosto, devo trovare queste stramaledette elettrovalvole, sono una cosa impossibile da scovare, maledizione... più che altro perchè è un prodotto che non conosco minimamente e quando penso di aver trovato quel che fa per me, mi rendo conto che in realtà è una valvola, che so, da gas per alte pressioni e ambienti ostili da 300€ a pezzo :fagiano:
Edit: ah la 1394B sarebbe la firewire, mi suonava come numero in effetti :asd:
Eh no, se non lo faccio io non c'è gusto (sono entrato ormai nella spirale dell'università italiana, ti devo scrivere per raccontarti quello che succede qui, roba dell'altro mondo...) :stordita: Poi non credo che qualche sensore di umidità generi un traffico tale da rendere necessaria una firewire :D
Edit: ah la 1394B sarebbe la firewire, mi suonava come numero in effetti :asd:Specificamente, la B e' quella che viaggia a 800 MHZ, sai, per non avere problemi di banda con le valvole dei fiori.
Che peraltro non e' che assorbano pochissimo, per cui non penso te la caverai trasferendo una continua sulla RS-232. Piuttosto pensa a batterie ricaricabili o piccole celle solari (piu' batterie, perche' vuoi bagnare di notte, in genere, per questioni di evaporazione) e eventualmente comanda wireless.
Fai un giro sul solito sito di Home Depot e dovresti trovare tutto cio' che ti serve. Poi chiaro che non lo compri li', ma almeno trovi tutte le parole chiave necessarie per le ricerche successive.
Se non vuoi partire da home depot, parti cercando "garden watering", "watering system", "automatic watering" e via dicendo.
Buona fortuna.......
Sì, esatto, per la forma della quadra non credo che ci siano problemi, tanto la RS-232 non dovrebbe essere schizzinosa :p
Devo solo stare attento al caso in cui trasmetta una sfilza di "1", perchè in quel caso lì avrei dei problemi.
Potrei dimensionare il condensatore in modo che si carichi con un tempo superiore ad una quantità ragionevole di "1" di seguito e metterci un pull-down perchè si scarichi più in fretta. Potrebbe essere?
Eh c'avevo pensato...
Solo che avrei dei problemi con i conflitti tra le comunicazioni... diciamo che una delle postazioni dei sensori rilevi che c'è bisogno di acqua, inviando così un pacchetto al "cervello". Ma nello stesso tempo il "cervello" stava inviando qualcosa ad un'altra delle postazioni, oppure alla pompa. In quel caso lì c'è un bel conflittone... se usassi solo un filo per tutto, tx-rx-alim, sarei nella cacca. Se usassi tx e rx, non sarei comunque in una situazione fantastica perchè un conflitto sulla stessa linea può comunque avvenire, ma diciamo che si dimezza la probabilità che avvenga. Se poi aggiungo, come temo di dover fare, una linea che segnali la trasmissione in corso, ho risolto il problema. A meno che... se usassi il tx per l'alimentazione e l'rx per un altro segnale... naaa... troppa pippa, una piattina da 4 fili non ha mai dato fastidio a nessuno :D
Eh sì avevo notato... :p
I conflitti sono facilmente estirpabili,il segreto sta nel non dare alcuna possibilità di iniziativa ai dispositivi slave :D
Deve essero solo il master a domandare ad un preciso slave una determinata informazione e solo questo deve rispondere !
Un esempio tipico di messaggio su seriale potrebbe essere:
[header][indirizzo][lunghezza][comando][dato][checksum][footer]
dove:
header = un carattere a tua scelta per iniziare il messaggio es '>'
indirizzo = indirizzo del dispositivo da interpellare
lunghezza = lunghezza del messaggio
comando,dato,checksum = corpo del messaggio
footer = carattere di terminazione es. '\n'
Il dispositivo interpellato rispondera con un messaggio simile indirizzato al master, ti assicuro che in questo modo puoi tranquillamente utilizzare una sola linea senza alcun problema di conflitto ;)
Per curiosità, che microcontrollori utilizzerai?
Praticamente questo accrocchio mi serve per poter iniziare a progettare un sistema di irrigazione estremamente fico e intelligente, dotando ogni vaso di un sistema di sensori di temperatura-umidità-luce-timer da interfacciarsi con una unità centrale che li imposta, li controlla, registra gli eventi e comanda le elettrovalvole e la pompa del serbatoio.
omg :doh:
internatelo :doh:
per la cronaca, io sono Gpc, non Jpc :D ma fa niente :p
JPC.....JVC! :asd:
Specificamente, la B e' quella che viaggia a 800 MHZ, sai, per non avere problemi di banda con le valvole dei fiori.
Che peraltro non e' che assorbano pochissimo, per cui non penso te la caverai trasferendo una continua sulla RS-232. Piuttosto pensa a batterie ricaricabili o piccole celle solari (piu' batterie, perche' vuoi bagnare di notte, in genere, per questioni di evaporazione) e eventualmente comanda wireless.
Hm, tralasciando le scemenze sulla firewire :D , anche io credevo che le elettrovalvole consumassero parecchio... tuttavia, dopo aver comprato una centralina da 50€ con elettrovalvola da rubinetto alimentata da una pila a 9V e garantita per il funzionamento di una intera stagione con una singola batteria, mi sono ricreduto.
Comunque potrei anche farci girare 10A sulla 232, basterebbe poi non arrossire quando qualcuno ti chiede come mai hai usato cavi da 5mm^2 per la seriale :asd:
Fai un giro sul solito sito di Home Depot e dovresti trovare tutto cio' che ti serve. Poi chiaro che non lo compri li', ma almeno trovi tutte le parole chiave necessarie per le ricerche successive.
Se non vuoi partire da home depot, parti cercando "garden watering", "watering system", "automatic watering" e via dicendo.
Buona fortuna.......
Grazie per il suggerimento, poi guardo...
I conflitti sono facilmente estirpabili,il segreto sta nel non dare alcuna possibilità di iniziativa ai dispositivi slave :D
Deve essero solo il master a domandare ad un preciso slave una determinata informazione e solo questo deve rispondere !
Un esempio tipico di messaggio su seriale potrebbe essere:
[header][indirizzo][lunghezza][comando][dato][checksum][footer]
dove:
header = un carattere a tua scelta per iniziare il messaggio es '>'
indirizzo = indirizzo del dispositivo da interpellare
lunghezza = lunghezza del messaggio
comando,dato,checksum = corpo del messaggio
footer = carattere di terminazione es. '\n'
Il dispositivo interpellato rispondera con un messaggio simile indirizzato al master, ti assicuro che in questo modo puoi tranquillamente utilizzare una sola linea senza alcun problema di conflitto ;)
Beh sì, anche quello si può fare, tuttavia so che ci sono rogne ad usare una comunicazione di questo tipo perchè la sto implementando al lavoro... vabbè che là uso l'SPI che è la più grande pippa mentale che sia stata concepita, dove praticamente è il master che deve "tirare fuori" la risposta dallo slave inviando il clock e, di conseguenza, deve sapere in anticipo cosa risponderà lo slave... bah... comunque dai, direi che quattro fili non sono così troppi. Comunque posso fare una cosa simile anche con una seriale normale, in fondo.
Per curiosità, che microcontrollori utilizzerai?
Eh, gli atmel pensavo... Ho sempre lavorato coi PIC in maniera assolutamente artigianale, solo col programmatore. Ora che ho iniziato ad utilizzare l'emulatore è tutto un altro discorso, dato che al lavoro mi fanno usare gli atmel con lo IAR. Non ho trovato una cosa simile per i PIC, e la cosa mi scoccia perchè ne ho un mare a casa (sample gratuti spediti per i più improbabili progetti :p ), però non credo che riuscirei a tornare indietro dopo essermi abituato così bene...
omg :doh:
internatelo :doh:
Perchè? :stordita:
Guarda che è una storia da matti tutti gli anni... A casa sono già diversi anni che devo fare un impianto da matti su tre piani con la gomma e mio nonno che la va ad aprire una volta al giorno, poi ora che ho le mie piante a Forlì me le sono dovute riportare tutte indietro (sai cosa vuol dire girare con una palma sul sedile del passeggero su una mercedes? Avevo tutte le foglie sul cruscotto, per guardare il navigatore dovevo spostarle e ad ogni curva dovevo tenerla perchè non si ribaltasse... :fagiano: anche perchè quando le ho portate erano piccole, ora sono triplicate), qui in montagna i fiori sul balcone sono stagionali, qualunque pianta sia, perchè poi nessuno può darci acqua... e, d'altra parte, voglio evitare scene come quella del balcone dei miei vicini qui in montagna di ieri sera, dove s'è avviato l'impianto d'irrigazione mentre fuori diluviava... per il terzo giorno di fila :D
n 1 timer meccanico di recupero
n 2 relè omron con zoccolo
cavi vari
due elettrovalvole da lavatoviglie di recupero
:fagiano:
per ora l'igrometro sono io, ma è tutto predisposto per inserirlo appena mi invento qualcosa :fagiano:
n 1 timer meccanico di recupero
n 2 relè omron con zoccolo
cavi vari
due elettrovalvole da lavatoviglie di recupero
:fagiano:
per ora l'igrometro sono io, ma è tutto predisposto per inserirlo appena mi invento qualcosa :fagiano:
E allora vedi che chiedi che venga rinchiuso per invidia verso il mio bellissimo progetto? :sofico:
La differenza è che io voglio una cosa che possa andare anche con serbatoio, perchè per esempio in montagna non possiamo lasciare l'acqua aperta per dei mesi senza nessun controllo, quindi ho bisogno di comandare una pompetta e delle elettrovalvole di quelle piccoline, anche di quelle che schiacciano semplicemente in tubo di silicone, per ogni vaso.
Invece per la casa dovrei fare una cosa mista, ossia una elettrovalvola grande per il giardino e un sistema di valvole più piccole per i vasi.
Non le trovo le elettrovalvole su Home Depot :sob:
Non le trovo le elettrovalvole su Home Depot :sob:
http://www.homedepot.com/prel80/HDUS/EN_US/jsearch/searchResults.jsp?CNTTYPE=PROD_META&N=2984+5691&BV_SessionID=@@@@1756501881.1155314899@@@@&MID=9876&BV_EngineID=cceeaddiiflkkdkcgelceffdfgidgmj.0&CNTKEY=misc%2fsearchResults.jsp&pos=n18
http://www.homedepot.com/prel80/HDUS/EN_US/jsearch/searchResults.jsp?CNTTYPE=PROD_META&N=2984+5691&BV_SessionID=@@@@1756501881.1155314899@@@@&MID=9876&BV_EngineID=cceeaddiiflkkdkcgelceffdfgidgmj.0&CNTKEY=misc%2fsearchResults.jsp&pos=n18
Le avevo trovate, ma non sono quelle che stavo cercando... almeno, dalle immagini non sembrano quelle.
Quelle che stavo cercando hanno questo aspetto:
http://img-europe.electrocomponents.com/images/C313194-02.jpg
oppure questo per quelle piccole:
...non trovo una foto... :p
Però mi servirebbero bistabili, per quel motivo che dicevo del consumo, ossia che si aprano e chiudano con un solo impulso.
Beh sì, anche quello si può fare, tuttavia so che ci sono rogne ad usare una comunicazione di questo tipo perchè la sto implementando al lavoro... vabbè che là uso l'SPI che è la più grande pippa mentale che sia stata concepita, dove praticamente è il master che deve "tirare fuori" la risposta dallo slave inviando il clock e, di conseguenza, deve sapere in anticipo cosa risponderà lo slave... bah... comunque dai, direi che quattro fili non sono così troppi. Comunque posso fare una cosa simile anche con una seriale normale, in fondo.
Io a lavoro ho usato diverse volte dei protocolli simili (quasi sempre su 485 half duplex) e non ho mai avuto problemi, in teoria dovrebbe essere uno dei sistemi più semplici di comunicazione m2m ;)
Il principio è semplice:
- il master invia una richiesta e si mette in ascolto
- lo slave (normalmente in rx) legge il messaggio ed invia una risposta
- terminato l'invio lo slave si rimette in ascolto
Eh, gli atmel pensavo... Ho sempre lavorato coi PIC in maniera assolutamente artigianale, solo col programmatore. Ora che ho iniziato ad utilizzare l'emulatore è tutto un altro discorso, dato che al lavoro mi fanno usare gli atmel con lo IAR. Non ho trovato una cosa simile per i PIC, e la cosa mi scoccia perchè ne ho un mare a casa (sample gratuti spediti per i più improbabili progetti :p ), però non credo che riuscirei a tornare indietro dopo essermi abituato così bene...
Cerca bene che lo IAR per i pic lo trovi :D
A parte questo, gli atmel (penso stai usando degli AVR) sono ottimi microcontrollori :)
Io a lavoro ho usato diverse volte dei protocolli simili (quasi sempre su 485 half duplex) e non ho mai avuto problemi, in teoria dovrebbe essere uno dei sistemi più semplici di comunicazione m2m ;)
Il principio è semplice:
- il master invia una richiesta e si mette in ascolto
- lo slave (normalmente in rx) legge il messaggio ed invia una risposta
- terminato l'invio lo slave si rimette in ascolto
Sì, se hai un sistema di comunicazione asincrono non ci sono problemi, ma, come dicevo, sull'ISP degli atmel è solo il master che manda il clock e quindi il master deve sapere in anticipo quanti byte leggere dallo slave e quando iniziare a leggerli... insomma, 'na pugnetta :D
Che lavoro fai, per curiosità?
Cerca bene che lo IAR per i pic lo trovi :D
A parte questo, gli atmel (penso stai usando degli AVR) sono ottimi microcontrollori :)
C'è lo IAR per i PIC? Ma dai, non lo sapevo proprio! Mi dai qualche info in più, anche in pvt, su dove cercarlo e che emulatori poi si devono usare (tipo quelli su ebay, per esempio)?
Gli AVR sono ottimi sì, però secondo me in certe cose i PIC sono più pratici... poi sai cosa? Io usavo il PIC-C che era comodissimo perchè aveva un sacco di librerie già pronte, mentre invece lo IAR non ha nulla di nulla, anche solo se devi usare una 232 devi farti le librerie. Un po' 'na palla...
Sì, se hai un sistema di comunicazione asincrono non ci sono problemi, ma, come dicevo, sull'ISP degli atmel è solo il master che manda il clock e quindi il master deve sapere in anticipo quanti byte leggere dallo slave e quando iniziare a leggerli... insomma, 'na pugnetta :D
Che lavoro fai, per curiosità?
Per il sistema di irrigazione la comunicazione è asincrona :p
Per il progetto SPI che stai portando avanti a lavoro tutto dipende dalla struttura dei messaggi, se non hanno un campo che indica la lunghezza del messaggio il divertimento è assicurato :D
Comunque sono progettista HW e SW in un'azienda "terzista", progettiamo e produciamo su richiesta di aziende di prodotto.
La maggior parte del tempo sviluppo i firmware ma mi capita spesso anche di lavorare sull'hardware.
C'è lo IAR per i PIC? Ma dai, non lo sapevo proprio! Mi dai qualche info in più, anche in pvt, su dove cercarlo e che emulatori poi si devono usare (tipo quelli su ebay, per esempio)?
Hai PVT :D
Per il debug l'unica soluzione a portata casalinga è un debugger Jtag, per i pic c'è il "padellino" (quello che somiglia a una scatoletta di caramelle ) che dovrebbe chiamarsi ICD2 ed è della microchip (~250€ nuovo), di aziende esterne forse la softech ne fa qualcuno ma non ne sono sicuro.
PS. l'ICD2 è delicatissimo in ditta ne abbiamo bruciati 2 (non sono stato io però :D )
Gli AVR sono ottimi sì, però secondo me in certe cose i PIC sono più pratici... poi sai cosa? Io usavo il PIC-C che era comodissimo perchè aveva un sacco di librerie già pronte, mentre invece lo IAR non ha nulla di nulla, anche solo se devi usare una 232 devi farti le librerie. Un po' 'na palla...
Come il 99% degli altri microcontrollori :muro: :cry:
Ma forse è meglio così, a volte le librerie le scrivono con le natiche, una volta avevo usato una spritnf (o qualcosa di simile) di un compilatore per un texas instruments e questa allocava una marea di memoria (dinamicamente :doh: ) tanto da andare a sovreascrivermi lo stack :D
Per il sistema di irrigazione la comunicazione è asincrona :p
Per il progetto SPI che stai portando avanti a lavoro tutto dipende dalla struttura dei messaggi, se non hanno un campo che indica la lunghezza del messaggio il divertimento è assicurato :D
Eh ma il problema è la risposta, anche perchè poi mi hanno chiesto di fare tutto su interrupt, quindi non ho potuto fare una semplice routine che legge i primi caratteri e tira fuori la lunghezza della risposta, poi volevano meno campi possibili perchè la trasmissione doveva essere breve... insomma, un sacco di palle...
Comunque sono progettista HW e SW in un'azienda "terzista", progettiamo e produciamo su richiesta di aziende di prodotto.
La maggior parte del tempo sviluppo i firmware ma mi capita spesso anche di lavorare sull'hardware.
Ah, insomma, fai praticamente quello che sto facendo io solo che io non voglio farlo :cry: io voglio fare l'elettronico, me ne frega molto poco di passare delle giornate a programmare in C... :rolleyes:
Hai PVT :D
Per il debug l'unica soluzione a portata casalinga è un debugger Jtag, per i pic c'è il "padellino" (quello che somiglia a una scatoletta di caramelle ) che dovrebbe chiamarsi ICD2 ed è della microchip (~250€ nuovo), di aziende esterne forse la softech ne fa qualcuno ma non ne sono sicuro.
PS. l'ICD2 è delicatissimo in ditta ne abbiamo bruciati 2 (non sono stato io però :D )
Come il 99% degli altri microcontrollori :muro: :cry:
Ma forse è meglio così, a volte le librerie le scrivono con le natiche, una volta avevo usato una spritnf (o qualcosa di simile) di un compilatore per un texas instruments e questa allocava una marea di memoria (dinamicamente :doh: ) tanto da andare a sovreascrivermi lo stack :D
Sì è vero, ma la comodità di fare un "print()" quando devi scrivere su un display con lcd piuttosto che farsi tutte le librerie partendo da capo? :D
Eh ma il problema è la risposta, anche perchè poi mi hanno chiesto di fare tutto su interrupt, quindi non ho potuto fare una semplice routine che legge i primi caratteri e tira fuori la lunghezza della risposta, poi volevano meno campi possibili perchè la trasmissione doveva essere breve... insomma, un sacco di palle...
Un campo "lunghezza" o un "end of trasmission" sarebbe consigliato comunque :)
L'interrupt interviene dopo ogni byte ricevuto (o almeno normalmente è così, sugli atmel, a dire il vero, non ho mai lavorato direttamente io ma dei miei colleghi) nella routine di interrupt esegui la lettura della lunghezza e il gioco è fatto :p
In teoria:
- dopo aver inviato il messaggio in trasmissione il master avvia la ricezione ( lo slave (se ha fatto in tempo) ha già riempito lo shift register con il primo byte dopo aver ricevuto il messaggio di richiesta)
- terminato l'invio sia il master che lo slave riceveranno un'interrupt, il primo legge dal suo shift register quanto ricevuto, il secondo carica un'altro byte sullo shift register.
- terminata la ricezione il master spegne il clock (man mano che riceve deve discriminare i byte che contengono la lunghezza del messaggio)
Se ti capita che il primo byte ricevuto sia "sporco" (lo slave non ha fatto in tempo dopo la ricezione a caricare lo shift register), sarebbe cosa buona e giusta dotare i messaggi di un header in modo da riconoscere l'inizio o al limite un breve delay tra trasmissione e ricezione.
Ah, insomma, fai praticamente quello che sto facendo io solo che io non voglio farlo :cry: io voglio fare l'elettronico, me ne frega molto poco di passare delle giornate a programmare in C... :rolleyes:
Fidati, ti servira molto più di quanto credi, anche in prospettiva di diventare progettista HW only ;)
Nel nostro gruppo di lavoro capita molto spesso che gli hardwaristi chiedano ai firmwaristi chiarimenti per capire come verranno gestiti certi blocchi hw, e guai a quando non lo fanno, saltano fuori certe magagne ... :D
(è anche vero il contrario però, da noi lavorava un softwarista che non capiva un volatile di hardware ... per lui il watch-dog era quasi un difetto da risolvere, lo resettava ovunque, anche su interrupt :asd: :eek: )
Sì è vero, ma la comodità di fare un "print()" quando devi scrivere su un display con lcd piuttosto che farsi tutte le librerie partendo da capo? :D
Pigrizia rulez :asd:
Un campo "lunghezza" o un "end of trasmission" sarebbe consigliato comunque :)
L'interrupt interviene dopo ogni byte ricevuto (o almeno normalmente è così, sugli atmel, a dire il vero, non ho mai lavorato direttamente io ma dei miei colleghi) nella routine di interrupt esegui la lettura della lunghezza e il gioco è fatto :p
In teoria:
- dopo aver inviato il messaggio in trasmissione il master avvia la ricezione ( lo slave (se ha fatto in tempo) ha già riempito lo shift register con il primo byte dopo aver ricevuto il messaggio di richiesta)
- terminato l'invio sia il master che lo slave riceveranno un'interrupt, il primo legge dal suo shift register quanto ricevuto, il secondo carica un'altro byte sullo shift register.
- terminata la ricezione il master spegne il clock (man mano che riceve deve discriminare i byte che contengono la lunghezza del messaggio)
Se ti capita che il primo byte ricevuto sia "sporco" (lo slave non ha fatto in tempo dopo la ricezione a caricare lo shift register), sarebbe cosa buona e giusta dotare i messaggi di un header in modo da riconoscere l'inizio o al limite un breve delay tra trasmissione e ricezione.
No no, ti prego, chiudiamo qui che mi viene la nausea :D
eppoi l'ho già fatto, funziona, sono tutti felici perchè sono riuscito a fare tutto su interrupt, risposta compresa, l'ho fatto implementando una mini macchina a stati e hanno avuto quasi un orgasmo per cui ci metto una pietra, no, una lapide sopra :p Sono in vacanza e, viste le soddisfazioni e il clima, il cassettino cerebrale "lavoro" l'ho blindato.
Fidati, ti servira molto più di quanto credi, anche in prospettiva di diventare progettista HW only ;)
Nel nostro gruppo di lavoro capita molto spesso che gli hardwaristi chiedano ai firmwaristi chiarimenti per capire come verranno gestiti certi blocchi hw, e guai a quando non lo fanno, saltano fuori certe magagne ... :D
(è anche vero il contrario però, da noi lavorava un softwarista che non capiva un volatile di hardware ... per lui il watch-dog era quasi un difetto da risolvere, lo resettava ovunque, anche su interrupt :asd: :eek: )
LOL :D
E' vero, serve certamente, ma il problema è quando al 99% fai quello... insomma, io ho una buona preparazione anche di elettronica analogica, perchè mi è sempre piaciuta, e sinceramente conosco pochissime persone che se la sanno cavare con i circuiti analogici (non che sappia fare chissà che, però insomma, me la cavo), l'elettronica digitale è moooolto più semplice, e vedo che generalmente si sa fare solo quella. Poi, di norma, l'elettronico cosa fa? Scrive software... :rolleyes: ma ciccia, l'elettronico fa l'elettronica, poi potrà anche saper fare qualcosa di programmazione, ma sempre finalizzata al suo lavoro e chiaramente mai ai livelli di chi la programmazione l'ha studiata a fondo. Insomma, a me toccherà fare tutta una serie di driver per una sorta di piattaforma hardware, ma io gli ho detto, io li faccio, ma non ho certamente le conoscenze di un informatico per fare un lavoro del genere. Anche perchè, solo per una applicazione semplice come quel protocollo di comunicazione di cui parlavo prima, mi sono reso conto che io l'avrei fatto in un modo mentre, in realtà, c'erano molti altri modi per farlo. Diciamola tutta, io vengo dal basic come impostazione di programmazione, poi mi son fatto un po' di VB e quindi un paio di programmi in assembler per i pic, poi C, sempre per i pic, rigorosamente lineare e senza interrupt. Tutto questo perchè piaceva a me, non perchè l'abbia studiato... e qui mi vengono a parlare di macchine a stati, routine su interrupt e pippe varie. Niente di trascendentale una volta che l'ho capito, ma se c'è un corso di laurea apposta non possono pretendere che io, che ho studiato altro -e voglio fare ben altro- sappia fare bene un lavoro del genere... o sto dicendo delle scemenze?
Pigrizia rulez :asd:
Si chiama ottimizzazione dei tempi :O :asd:
l'elettronica digitale è moooolto più semplice
Se non ci sono correnti di perdita & compagnia bella :asd:
se c'è un corso di laurea apposta non possono pretendere che io, che ho studiato altro -e voglio fare ben altro- sappia fare bene un lavoro del genere
Pensa a quei poveri informatici che invece si divertono più con i timing di una DRAM che con TRIO o SQL.....:stordita: :D
Se non ci sono correnti di perdita & compagnia bella :asd:
Ma nemmeno, perchè al 99% chi lavora con l'elettronica digitale prende componenti già pronti su cui altri hanno risolto quei problemi e tutto ciò, o quasi, di cui si deve occupare è "mettere assieme i pezzi". Nelle applicazioni umane, quanto meno. L'elettronica analogica è moooolto diversa da questo, è praticamente la differenza che passa tra un lavoro meccanico e ripetitivo e un'arte.
Pensa a quei poveri informatici che invece si divertono più con i timing di una DRAM che con TRIO o SQL.....:stordita: :D
Beh, se mi dicessi di informatici che si divertono a creare circuiti stampati o progettare amplificatori ti darei ragione, ma i timing di una DRAM è pure roba da informatico :fagiano:
L'elettronica analogica è moooolto diversa da questo, è praticamente la differenza che passa tra un lavoro meccanico e ripetitivo e un'arte.
Il montare pezzi può nascondere più insidie di quello che sembra, perchè i pezzi non sono "blocchi" di un sistema con la loro simpatica funzione di trasferimento che li riassume perfettamente, devi sempre tener conto della fisica sotto, altrimenti prima o poi qualcosa salta :D
Io ho fatto un corso di elettronica dei sistemi digitali e posso dirti che l'analogica saltava fuori dovunque appena si "spingeva" con certi requisiti o di robustezza o di performance o di consumo ;)
ma i timing di una DRAM è pure roba da informatico :fagiano:
Lo so, ma vallo a dire ai softwaristi....."DRAM, cavolo è?" :asd:
Il montare pezzi può nascondere più insidie di quello che sembra, perchè i pezzi non sono "blocchi" di un sistema con la loro simpatica funzione di trasferimento che li riassume perfettamente, devi sempre tener conto della fisica sotto, altrimenti prima o poi qualcosa salta :D
Io ho fatto un corso di elettronica dei sistemi digitali e posso dirti che l'analogica saltava fuori dovunque appena si "spingeva" con certi requisiti o di robustezza o di performance o di consumo ;)
Guarda, ti posso assicurare che, nella pratica, l'elettronica digitale la puoi dare in mano anche ad una persona che non sa nemmeno cosa sia un transistor... E' questione di livello dell'applicazione: nell'elettronica digitale sei a diversi livelli sopra ai problemi di compatibilità, pilotaggio, adattamenti di impedenze, etc. Usi oggetti già pronti che sono solo da collegare. Della fisica non importa niente a nessuno, anzi, manco sanno cosa sia a momenti (anche senza a momenti...). Nel momento in cui la vai a studiare, sono d'accordo che qualche richiamo (molto alla buona) all'analogica sia necessario, solo per il fatto che la digitale è un caso particolare dell'analogica, tuttavia quando ci vai a lavorare ti assicuro che non solo te ne strafreghi, proprio te la puoi dimenticare.
Ah, insomma, fai praticamente quello che sto facendo io solo che io non voglio farlo :cry: io voglio fare l'elettronico, me ne frega molto poco di passare delle giornate a programmare in C... :rolleyes:
sogna :asd:
sogna :asd:
Mi sa che si sveglino prima gli altri, quando non mi vedono più... :asd:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.