Arduino Pro Mini 3v 8Mhz - Problema con i2c

International Italiano Generale
1

Ciao, il titolo è un pò generico, ma data la lunghezza non potevo fare meglio.

Mi sono arrivate le arduino pro mini, a 3v e 8 mhz, perfetto le provo e sembra tutto ok... ma...

In pratica ho un circuito dove devo usare molto la rete i2c, avendo sensori tutti uguali, quindi con lo stesso indirizzo, ho usato un 74hc4067, un multiplexer a 16 canali analogici, con un impedenza sui 60 Ohm, quindi dovrebbe essere trascurabile.

Il clock lo mando diretto a tutti i dispositivi, la linea dati invece la multiplexo per ciascun dispositivo, a proposito ho 12 sensori uguali e una memoria 24c04wp.

Il tutto a 5 volt col nano funzionava benissimo. Ora invece con le mini dipende, nel senso che se trasmetto (uso la radio) i dati, questi arrivano correttamente solo con la usb attaccata al computer, tramite adattatore esterno UART / USB con logica a 3V.

Mentre se alimento con una batteria lipo e regolatore pololu a 3v3 il tutto funziona male.

Che vuol dire funziona male ? Vuol dire che la radio (una rfm69hcw) mi trasmette una serie di caratteri, di questi alcuni sono fissi, codificati in memoria, altri vengono letti in analogico e altri provengono dalla memoria i2c (24c04). Ora, funziona tutto tranne i dati che vengono dalla memoria, ho provato ad abbassare la velocità del bus a 10 kbaud e cosi pare funzionare... però è troppo lenta per gestire tutto il resto in modo accettabile.

Ho pensato a problemi di tensione passando dal nano a 5v alle mini a 3v... però allora perchè se collego l'adattatore al pc funziona (sempre a 3v intendo) ?

Premetto che ho fatto tuttele misure del caso e le tensioni sono stabili, le ho ben filtrate, ho messo i ceramici vicino agli integrati, e la batteria è carica.

2

Nessuno ? ? ?

Vi aggiorno, la cosa si fa sospetta, alimentandolo a batteria e avendo saldato un condensatore e una resisitenza in parallelo tra GND e RESET, ora se prima alimento e poi dopo un paio di secondi premo il reset a mano, funziona correttamente.

Mi chiedo, che sia un qualche problema dei regolatori pololu ? Sono questi: S7V8F3
Magari qualche oscillazione che si stabilizza dopo un po... oggi se riesco porto su l'oscilloscopio e vedo.

3

Scusate, ma provenendo dal mondo pic mi è sorto un dubbio... ma l'arduino parte senza reset ?
Cioè, con i pic ero abituato a mettere semrpe un condensatore tra RESET e GND e una resistenza di pullup sempre sul RESET, in modo che al momento dell'accensione il micro si resettava all'indirizzo zero.

Ora, se questa benedetta scheda non c'è un condesatore verso massa e qui il dubbio.

Ho controllato pure con oscilloscopio e sonda logica, in sostanza collegando la usb si vedono le transazioni sul bus i2c che va a scrivere e leggere sulla memoria. Tutto ok fin qui. I periodi del clock sono d 1uS basso e 1.5uS alto, e fanno 2.5uS che in effetti corrisponde al clock di 400.000Hz.

Quando alimento a batteria invece parte qualcosa ma è disturbato, addirittura il clock viene tirato verso GND a un certo punto della comunicazione.

4

dukeluca86:
Scusate, ma provenendo dal mondo pic mi è sorto un dubbio... ma l'arduino parte senza reset ?

Si, c'è un'apposita logica per il POR.

Con un oscilloscopio, verifica che il segnale in uscita dai Pololu sia pulito e non ci siano auto-oscillazioni.

Invece, per la parte I2C, perché non fai le cose PULITE ed utilizzi un multiplexer fatto apposta per I2C?

Guglielmo

5

Ciao Guglielmo, ah ok, quindi risolto il problema del reset.

L'alimentazione l'ho controllata, c'è un ripple di circa 20mV, ma essendo un regolatore switching penso che sia fisiologico. Il dubbio mi era venuto perchè avendo due pololu, uno che regola i 3v3 l'altro che regola i 5v, avevo pensato che magari uno partisse prima dell'altro, al momento purtroppo non ho una seconda sonda per provarli insieme e vedere i tempi di avvio.

Lo strumento che ho è un tds2002c che presi ad una ghiottissima occasione dalla cina, da un universita che lo dismetteva. La sonda logica invece è una sealae logic analyzer clone ovviamente.

Il problema non dovrebbe essere il multiplexer, ho fatto delle prove, con l'analizzatore logico e con l'silloscopio, si vede chiaramente che non ci sono ritardi alcuni tra ingresso e uscita del demux, ne cambiamenti della forma d'onda, nemmeno a 400.000 baud.

Non ho usato un multiplexer fatto apposta, perchè non ne ho trovati che mi possano gestire 16 canali come questo.

Inoltre ho provato a far lavorare fuori specifiche la memoria scrivendo con la funzione per settare il clock del bus i2c fino a 1Mhz (1.000.000) e funziona correttamente. (sempre che la funzione restituisca il vero oltre i 400.000).

Ho notato però due cose, una c'è che è diversità tra le due alimentazioni, quando alimento da usb il segnale data (ma forse pure clock, non ho controllato) parte alto fisso (e ce credo, ci sono le pullup).

Mentre se alimento da batteria e regolatore, si ha un picco che viene bloccato dal trigger dello strumento per una frazione di secondo, c'è sempre non è stato un caso fortuito. E' un po come il simbolo della nike al contrario, poi torna alto sempre per le pullup.

Terza cosa, avevo detto due ma me l'ero scordata questa, il pin di clock, prima del reset (per questo credevo non si autoresettasse all'avvio) appena collego l'alimentazione, da un clock fisso, poi appena resetto sparisce e compaiono i tentativi di comunicazione. Se riesco allego qualche foto.

I reset sono quelli forniti dal pin dtr del convertitore usb/uart, notare la diversità di lunghezza tra i due, i time/div sono diversi.
Pasteboard - Uploaded Image RESET SUL NANO
Pasteboard - Uploaded Image RESET SULLA MINI PRO
Pasteboard - Uploaded Image I2C DATA DOPO DEMUX
Pasteboard - Uploaded Image I2C DATA PRIMA DEMUX
Pasteboard - Uploaded Image SEQUENZA CORRETTA I2C
Pasteboard - Uploaded Image AVVIO CON RESET GIA PREMUTO A MANO

6

Ho fatto un passo avanti.

Ho trovato chi ha avuto problemi simili al mio sia su atmel che su altri micro tipo cypress.

In sostanza il bus rimane aperto. Ovvero uno slave lo mantiene aperto, o meglio, lo slave rimane a meta di una qualche transazione e si aspetta il resto. E a quel punto quando trasmette il master si trova fuori sincro, provando a dare uno stop mi riporta l'errore NAK when trasmitting address o una roba simile.

Ho risolto in parte facendo una cosa cosi:

  • assegno CLK e DATA come output
  • li mando bassi
    -aspetto 10 microsecondi
  • rendo CLK un ingresso
  • aspetto 10 usec
  • rendo DATA un ingresso
  • ripeto finché DATA non legge alto
  • riavvio la wire.begin

Cosi pare funzionare. Il perchè non mi è del tutto chiaro, forse l'alimentazione da usb è piu pulita o forse altro.

Altra soluzione potrebbe essere quella di alimentare solo il micro e in un secondo momento usare questo per dare alimentazione al resto delle periferiche, eeprom, sensori, demux e tutto il resto.

7

Alla fine ho risolto. Sembra che collegare i fili sia troppo rumoroso per l'arduino, probabilmente genera delle false partenze, e la memoria 24c04 è un pò sensibile a quanto pare. Mettere un interruttore ha risolto i problemi, nel senso che funziona adesso. Ho introdotto anche un pò di ritardo all'inizio, circa un secondo e ho gestito le alimentazioni in sequenza, facendole accendere col pin 4 del mini pro.

Ho però ancora un dubbio, mi da comunque un "NAK RECEIVED ON TRASMITTING ADDRESS" che in sostanza sono tutti zeri (7 zeri di indirizzo + TRASMISSIONE + NAK) al primo tentativo di comunicazione, poi sempre nel primo tentativo vengono trasmessi tutti i dati correttamente.

Me lo spiegate per favore ? Ho paura che possa generare problemi piu avanti.

8

Questa è quello che succede.

9

Guarda, per problemi sul bus I2C (device che restavano "appesi" e bloccavano il colloquio), a suo tempo io avevo trovato quanto ti allego.

Si tratta di una funzione da richiamare nel setup, dopo l'avvio, ma prima della Wire.begin() per fare il clear del bus ... ti da anche un codice di errore di ritorno se non ci riesce ... vedi se ti può essere utile.

Guglielmo

I2C_ClearBus.ino (4.4 KB)