APA102 riduzione pin usati - segnale clock condiviso o comune

Ciao,
sto pensando di interfacciare 16 strisce led APA102 che non posso concatenare.
Molte di queste avranno il medesimo numero di led, altre qualcuno in più quindi quelle le gestirei isolatamente.
Per rientrare nel numero di pin disponibili della scheda che penso di usare, che per questioni di memoria disponibile sarà la Pro Midi 1284P, mi chiedevo se fosse possibile usare un solo pin per il clock di tutte le strisce con medesimo numero di led, se per farlo è necessario interfacciare con quanche circuito specifico o se proprio non è consigliabile farlo.
Altro dettaglio che può essere importante è che tra la MCU e le strisce il cavo di connessione è lungo almeno un metro, fino a 3/4 metri.

I segnali che arrivano dalla MCU per gli APA102 sono solo in ingresso verso di essi ... tu vuoi mandare gli stessi dati a tutti? Allora puoi mettere assieme sia il clock che i dati; oppure vuoi metterle in serie? Allora basta un pin di clock ed uno di data.

Se invece ciascuna deve avere i suoi dati separatamente devi ovviamente dare a ciascuna il clock solo quando serve perché, quando glie lo dai, comunque va a leggere i dati in ingresso e cerca di interpretarli.

Guglielmo

I dati e il clock sono assolutamente comuni quindi posso (e sarebbe un grande vantaggio in temini di velocità) usare un pin per i dati e uno per il clock, solo temevo che potessero esservi controindicazioni per eventuale distorsione del segnale dovuto alla lunghezza del cavo e/o all'assorbimento sul pin.
Grazie!

... al massimo se quelle in parallelo sono tante, mettici un buffer ... :wink:

Mah ... se non fai cavi di svariati metri ed usi una una bassa velocità di clock, non dovresti avere alcun problema ... al limite, come dice Etem, aggiungi un piccolo buffer :wink:

Guglielmo

Grazie mille, faccio prove sul banco e poi in base alla lunghezza dei cavi vedrò se aggiungere un buffer non invertente.

Quindi le strisce di pari numero di led devono produrre lo stesso effetto luminoso?

In caso contrario, non so se si possa comunque, barando spudoratamente, usare un clock comune, assicurandosi di non dare mai, alle strisce che non sono in fase di aggiornamento, 4 byte di zeri tutti assieme (cioè lo start frame). Forse in questo modo non arrivando mai lo start frame, le strisce potrebbero ignorare i dati in arrivo. Poi, prima di iniziare una nuova trasmissione, bisognerebbe dare un 1 per essere sicuri che i 4 byte di zero partano dal momento che decidiamo noi.

Sarebbe un trucco bistrucco, che forse potrebbe anche funzionare.

Maurizio

Si, spiego meglio, anche se sono un po' restio perché è una applicazione innovativa e non vorrei che qualcuno ne traesse spunto e la copiasse prima che depositi il brevetto, sono luci sotto scalini :smiley:

14 sono lunghe uguali e tre sono più lunghe perché sono del "ventaglio" che ruota tra le due rampe di scale.
L'idea mia è quella di definire un array di strutture che descrivano quali led accendere ogni step dell'animazione, con la possibilità di usare un unico segnale con un ciclo riesco a pilotare comunque tutte le strisce, limitando l'output verso le strisce basandomi su quanto definito nella struttura.
Quello che ho in mente è:

struct s_sequence
{
  byte nSteps;
  byte nLed;
  uint64_t bits[MAXNUMLED];
  byte enRed[MAXNUMLED];
  byte enGreen[MAXNUMLED];
  byte enBlue[MAXNUMLED];
};

struct s_sequence seqDef[NUMSCALIN];

For da zero a [massimi led possibili] e operazioni sui bit [bits] con accensione se il bit è a 1 e quale colore accendere dato dalla lattura dei tre array di byte di abilitazione.
In questo modo ogni striscia riceve i bit necessari.
Sto meditando se tenere la struttura così e mantenere separati quindi i dati e un clock unico o cambiare modo di lavoro e unificare tutto.
Se mantengo così ho più flessibilità di "animazione" scalino, led e colore.
Se cambio perdo la possibilità di differenziare le animazioni per scalino.
Tutto dipende dalle risorse HW/SW, con una MEGA la struttura non sta in memoria ma ho pin in abbondanza, con la Pro Midi devo verificare i pin disponibili ma dovrei starci dentro (devo interfacciare anche una SD e usare la seriale 1 per la comunicazione BUS485) e lato memoria ci sto dentro senza troppi problemi.

Tu sai che per gli apa102 devi mandare un certo preambolo ed un trailer calcolati correttamente in funzione del numero dei LED vero ? ? ?

Guglielmo

Si si, ho del codice stupendo a cui attingo :wink:

Definirò tre o quattro struct per questo scopo

Per ora ho provato una striscia per farmi un idea di massima sulle animazioni e sull'applicazione della mia idea, prima di procedere e prendere in pieno un muro ho preferito chiedere informazioni

fabpolli:
... non vorrei che qualcuno ne traesse spunto e la copiasse prima che depositi il brevetto ...

Fatto, grazie ... :stuck_out_tongue: :stuck_out_tongue: :stuck_out_tongue: :smiley:

( scherzo ovviamente :stuck_out_tongue_closed_eyes: )

Se i cavi devono viaggiare per tutta la scala, forse e' meglio che un minimo di buffer lo prevedi lo stesso ... ma dato che gli APA non sono critici come velocita', al contrario dei vari WS, basta che ti forniscano fronti puliti, poi puoi usare quello che preferisci ...

Credo, piccoli come sono, si potrebbe anche fare una microschedina "passante" da posizionare anche a meta strada se servisse, usando dei 74AHC2G125-Q100, che sono a due canali (tanto non servono bidirezionali come quelli degli I2C) ... anche meglio 74LVC2G125, fino a 50mA, il doppio, ma sono in VSSOP, 3x2mm ...

Allora la scala è annegata in un muro e i cavi passano dentro i corrugati predisposti, quindi in mezzo non posso mettere nulla, non ho modo di misurare ma credo che il cavo più lungo sia 3 metri, alla fine avevo maturato l'idea di mettere i buffer che male non fanno.
Non so se ha senso metterli attaccati alla striscia (ammesso che riesca a saldarli) per far arrivare i fronti il più puliti possibile.
Grazie, suggerimenti preziosi come sempre :slight_smile:

Se li devi mettere, mettili subito in uscita dall'arduino ...

Guglielmo

E se non li trovi gia fatti, te ne ho disegnate due versioni, con e senza enable … :wink:

BUF-2P.zip (37.3 KB)

Ok, grazie mille.
@Etemenanki appena recupero Eagle li guardo, grazie mille!

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.