TauLabs/PicoC: Ansteuerung RGB LEDs WS2812

ernieift

Erfahrener Benutzer
#42
Ich glaube James ist noch nicht so weit. Aber es gibt wohl schon ein paar Prototypen.

Falls es mit dem Timing zu kritisch wird, warum nicht einfach einen kleinen Protokollübersetzer (ATtiny85@8MHz) nehmen.
Der hat genug RAM für 128 LEDs (braucht kein Schw…). Den kann man mit Arduino programmieren und einfach die Neo Pixel-Library nehmen (Kosten < 2€). Einen IC braucht es sowieso. Die Baudrate wäre sich nicht so kritisch, geht eh nur Softserial (9600Baud, ca. 1,1ms pro Byte).
Funktion könnte so aussehen:
Zustand IDLE: warte auf Daten
Zustand RECEIVE: Empfange alles in den Puffer und setze mit jedem Byte den Timeout zurück. Falls Timeout (5ms) abgelaufen, und mehr als 2 Bytes da, dann SEND. sonst zurück auf IDLE
Zustand SEND: schicke den Pufferinhalt je nach Empfang (muss durch 3 Teilbar sein) per LIB und gehe in IDLE.

Bei 3ms pro LED kann man in 100ms immer noch 30 LEDs schreiben. Das sollte reichen. Bei mehr sind die Akkus schnell alle.
Das Ganze kann man vorher auf einem normalen Arduino testen und den Source dann auf den ATtiny übertragen.
Das sollte es sein. Man muss nur noch einen UNO o.ä. zum Programmer für ATtiny umbasteln. In PicoC kann man einfach hintereinander die LED-Daten wegschicken oder als Paket aus dem Puffer, wie man möchte…
 

cGiesen

Erfahrener Benutzer
#45
Ich könnte ko***n, jetzt kommen meine Chips doch erst nächste Woche :(
Könnte ein Transistor nicht doch reichen? Wenigsten als Provisorium.
 

ernieift

Erfahrener Benutzer
#51
Wem die Sache mit der hohen Baudrate und dem Inverter zu fehleranfällig ist, da habe ich mal was vorbereitet:

https://github.com/ernieift/NeoPixel_Transceiver

Der geht nicht nur für picoC.
Einfach RGB-Daten mit 9600Baud schicken. Wenn 3ms nichts mehr kommt, macht der ATtiny das komplette Timing aus dem
Puffer heraus. Wer jetzt denkt, 9600Baud sind sehr lahm:
9600Baud machen 960Zeichen/s. 960/3 = 320 LEDs/s. Also 3,125ms pro LED + 3ms Pause fürs update.
Der ATiny85 hat 512Bytes RAM. Das sollte für 100 LEDs reichen. Die kann man dann immer noch 3x pro Sekunde refreshen. Höhere Baudraten habe ich noch nicht probiert, eventuell geht da auch noch mehr.
Ich schreibe jetzt noch eine kleine Demo in picoC und dann gibt's morgen ein Video.

Viel Spass damit
ernieift
 

cGiesen

Erfahrener Benutzer
#52
Geilomat

Es klappt, danke Jens!!!

Die Schaltung mit einem 2n3904 und zwei 3k3 (1k hatte ich nicht mehr :( )
Ich habe bei Masse und 5V die Leitung angekratzt und einen Lötpunkt aufgesetzt, so braucht ich nicht so viel fummeln.

Eingeschrumpft nimmt alles wenig Platz weg.

In Action:
 

Anhänge

Zuletzt bearbeitet:

cGiesen

Erfahrener Benutzer
#53
Ich nutze die Library jetzt für nur 3 LEDs
Ab und an kommt sie durcheinander. Da kommt statt dem Rot mal eine andere Farbe auch der 3 LED.
Mir ist es jetzt auch ein paarmal passiert, dass ich keinen Zugriff mehr auf PicoC hatte.
Ich musste stromlos machen, damit ich weiter spielen konnte.
Anfangs ist die Telemetrie weiter gelaufen, einmal (oder zwei?) war die dann aber auch weg.

Das alles aber nur, wenn ich die Schleife laufen lasse.

Nutze ich nur die Library und setzt die Werte einzeln:
Code:
setLED(0,255,0,0);
setLED(1,100,100,100);
setLED(2,255,0,0);
sendLED();
dann klappt das wunderbar.

Was mich wundert, warum die Verbindung verloren geht.
So außergewöhnlich ist die Schleife doch gar nicht?!?!
Die macht doch 'nur' ein Fader mit Rot.

Aber vielleicht ist die Idee mit dem ATTINY doch besser.

@ernieift Kannst Du da einen Service anbieten?
Spricht ein paar fertig machen und verschicken?
 

cGiesen

Erfahrener Benutzer
#54
Ich habe noch keine Idee, wie ich die Endlosschleife bauen muss, aber hier kann ich schonmal anzeigen, ob ich gearmed habe oder nicht.

Code:
#include "system.h"

/* WS2812 library */
#define nLED 3
unsigned char bufLED[nLED*8];


void setLED(unsigned short n, unsigned char r, unsigned char g, unsigned char b) {
	if (n < nLED) {
		unsigned short offset = 8*n;
		bufLED[offset++] = (((g&0x80)>>7)|((g&0x40)>>3)|((g&0x20)<<1))^0xdb;
		bufLED[offset++] = (((g&0x10)>>4)| (g&0x08)    |((g&0x04)<<4))^0xdb;
		bufLED[offset++] = (((g&0x02)>>1)|((g&0x01)<<3)|((r&0x80)>>1))^0xdb;
		bufLED[offset++] = (((r&0x40)>>6)|((r&0x20)>>2)|((r&0x10)<<2))^0xdb;
		bufLED[offset++] = (((r&0x08)>>3)|((r&0x04)<<1)|((r&0x02)<<5))^0xdb;
		bufLED[offset++] = ( (r&0x01)    |((b&0x80)>>4)| (b&0x40)    )^0xdb;
		bufLED[offset++] = (((b&0x20)>>5)|((b&0x10)>>1)|((b&0x08)<<3))^0xdb;
		bufLED[offset++] = (((b&0x04)>>2)|((b&0x02)<<2)|((b&0x01)<<6))^0xdb;


	TestValSet( bufLED[8*n] );


	}
}


void sendLED() {
	ChangeBaud(2100000);
	SendBuffer(bufLED, sizeof(bufLED));
}	


/* end of RGB-LED library */


short r=0,g=0,b=0;


if (armed())
{
	setLED(0,170,0,0);
	setLED(2,170,0,0);
 } else
{
	setLED(0,0,170,0);
	setLED(2,0,170,0);
}


	setLED(1,170,0,0);


sendLED();
delay(500);
Jetzt fehlt nur doch der GPS Status, Failsafe & Batterie, dann habe ich das, was ich erstmal haben wollte.
 

ernieift

Erfahrener Benutzer
#55
Hallo Carsten,

eine Endlosschleife geht doch mit while(1){}. Hört aber nie wieder auf! Wenn Du das noch mit einem Hochlaufstart verbindest, dann kommst Du an PicoC nur noch über die settings und anschliessenden reset ran.
Wenn Du noch Probleme mit dem Zustandsautomaten hast, dann schau Dir doch mal den Neo Pixel_Tranceiver an. Da ist einer drin.
Ich würde die while(1) Schleife nicht nehmen (würde ich jedenfalls vermeiden), nimm doch sowas wie den Flightmodeschalter. Du kannst ja zählen, wie oft Du den benutzt und nach dem 30. Mal das Script beenden. Oder schau Dir einfach den TestVal an. Den kannst Du doch über Telemetrie mit einem Abbruchwert beschreiben. Nach dem Reset ist der immer null. Damit läuft Dein Script auf dem Acker bis der Akku leer ist und beim Basteln kannst Du jederzeit stoppen.
 

cGiesen

Erfahrener Benutzer
#56
Wenn Du noch Probleme mit dem Zustandsautomaten hast, dann schau Dir doch mal den Neo Pixel_Tranceiver an. Da ist einer drin.
das sagt mir leider nichts? Was ist das mit gemeint?
Ist das etwas, was noch nicht im Wiki ist?

Wegen PicoC macht es nicht Sinn, sowas wie einen Reset Knopf in der GUI zu haben, also Dein Vorschalg wie mit der TestVal in der FW Hardcoded?
 

cGiesen

Erfahrener Benutzer
#58
Da hast Du mich falsch verstanden.
Ich meinte die Zustände von Taulabs (siehe PicoC Thread)

Das ich nur Daten schreibe, wenn sich Zustände geändert haben werde sich schon schaffen.
Ich muss diese ja parallel überwachen.
 

ernieift

Erfahrener Benutzer
#59
Was den Abbruch von Scripten angeht: geht nicht. Der Interpreter wird angesprungen und rotiert solange er was interpretieren kann oder einen Fehler findet. Für Endlosschleifen ist ein Delay sehr hilfreich. Du kannst ja auch einen windowsrechner mit einem simplen Basicprogramm zur lärmenden Höllenmaschine machen wenn Du nicht ein paar CPU% dem System überlässt.
 

cGiesen

Erfahrener Benutzer
#60
Ich habe gedacht, das der Interpreter auch in einer Art Schleife arbeitet.
Da hätte man dann so einen Stopp rein machen können.

Ansonsten geht das mit der Testval ja sehr gut.
Idee, diese Variable in das PicoC Widget hoch heben, das man einfach dran kommt.

Ich setze diese jetzt beim Start auf 1 und lasse den Script solange laufen, bis sie 0 ist.

Wenn ich jetzt in der GUI ein Feld hätte wäre das Cool, geht aber sicher auch über den Browser.

Kanst Du mir bei der Frage noch helfen?
http://fpv-community.de/showthread.php?56213-TauLabs-PicoC-Scripting&p=717713&viewfull=1#post717713
 
FPV1

Banggood

Oben Unten