Hallo,
ich hab hier eine Konstantstromquelle (LED-Treiber) mit 1,4A und einen
ARM7 µC, der ein (COG) 128x64px LCD mit UC1601SA ansteuert ...
Mein Problem ist nun, dass das LCD einwandfrei funktioniert, wenn die
Konstanstromquelle ausgeschaltet ist. Ist sie eingeschaltet gibt es
Übertragungsfehler über den SPI-Bus.
Das LCD ist per SPI angebunden und hat keine offenen Eingänge, die
Signal treiben alle sauber - nachgemessen mit Oszi.
Spannungsversorgung (inkl Masse) sind seperat.
Wenn ich den Treiber in der Hand halte, scheint die Übertragung zu
funktionieren, leg ich sie weg, gibts plötzlich wieder Fehler ...
Weiß jemand, was man da machen kann?
Grüße,
Thomas
Thomas schrieb:> Wenn ich den Treiber in der Hand halte, scheint die Übertragung zu> funktionieren, leg ich sie weg, gibts plötzlich wieder Fehler ...
Klingt nach offenen Eingängen des MC.
Prinzipiell sind offenen Eingänge nicht sehr schlimm, sie erhöhen nur
den Stromverbrauch.
Deshalb muß da noch ein Softwarefehler hinzukommen, z.B. Interrupts
dafür enabled oder beim Einlesen nicht ausmaskiert.
Anfänger vergessen sehr oft, alle anderen Pins zu maskieren, wenn sie
nur einen Pin einlesen wollen und werten dann immer den ganzen Port aus.
Das geht schief.
Peter
Peter Dannegger schrieb:> Klingt nach offenen Eingängen des MC.> Prinzipiell sind offenen Eingänge nicht sehr schlimm, sie erhöhen nur> den Stromverbrauch.
Jap, ist ein Mini-ARM7-Board, Marke Eigenbau, und ich verwende es
praktisch bei jedem neuen Projekt, seit ungefähr 3 Jahren.
Die meisten Pins sind tatsächlich offen, weil ich sie nicht gebraucht
hab. Ich kann mal die SAM7-Internen Pullups für die unbenutzten Pins
aktivieren und schauen, ob sich dann dadurch was ändert ...
Hmm ... offener Pin mit Interrupt aktiviert? Zu 95% nicht, das werde ich
aber prüfen ... Aber ich seh auch nicht, wie das das SPI stören würde
...
Der µC hängt sich auch nicht auf oder sowas, sobald ich den LED-Treiber
ausschalte, fängt sich auch das LCD wieder ...
Grüße,
Thomas
Btw ... beim 10pol Flachbandkabel zum LCD ist jeder 2te Pin GND.
Vlt fängt das ja irgendwelche Störungen ein, weil die beiden Potentiale
für µC+LCD und LED-Treiber getrennt sind ...
A. K. schrieb:> Was mir an der Platine als Erstes auffällt ist das was mir dort nicht> auffällt: Kondensatoren zwischen VDD/GND dicht an den entsprechenden> Pins.
Bei welcher Platine?
Auf der LED-Platine gibs die 100nF direkt an der Versorgungsspannung und
einen 10uF Tantal, auf der ARM7-Platine gibts 5*100nF und 2*4,7uF auf
der Unterseite des Moduls, direkt an den Spannungspins.
100nF-Cs hab ich mir beim LED-Treiber gespart, wobei sie wohl nicht
falsch wären ...
Thomas schrieb:> Bei welcher Platine?
Der Controller-Platine. Wenn die hinten sind, dann ok, aber vor vorne
sind die eben nicht zu erkennen.
Ein Schaltbild funktioniert in Bildform viel viel besser als in
Textform.
Ich hab das Problem gefunden ... War software ...
Vlt interessiert es jemanden:
Es gibt 2 Funktionen, die Daten oder Kommandos an das LCD schicken:
1
voidlcd_command(charc)
2
{
3
AT91F_PIO_ClearOutput(AT91C_BASE_PIOA,SPI_CD);
4
spi_SendData(0,c);
5
}
6
7
voidlcd_data(charc)
8
{
9
AT91F_PIO_SetOutput(AT91C_BASE_PIOA,SPI_CD);
10
spi_SendData(0,c);
11
}
und die spi_SendData-Funktion:
1
voidspi_SendData(u8adr,u16data)
2
{
3
volatileunsignedintsr;
4
5
do
6
{
7
sr=AT91C_BASE_SPI->SPI_SR;
8
}while(!(sr&AT91C_SPI_TXEMPTY));
9
10
unsignedinttdr=0;
11
tdr|=AT91C_SPI_LASTXFER;
12
tdr|=(adr&0x0000000f)<<16;
13
tdr|=(data&0x0000ffff);
14
AT91C_BASE_SPI->SPI_TDR=tdr;
15
}
Das Problem war, dass nach dem Transfer eines Datums/Kommandos gleich
neue Daten verschickt wurden. Es wird davon ausgegangen, dass die
spi_SendData-Funktion so lange wartet, bis der TX-Buffer leer ist.
Das, was aber passieren kann - und das war anscheinend haarscharf an der
Grenze - war, dass das Bit SPI_CD (Selektion Datum/Kommando)
gesetzt/gelöscht wurde, wenn der SPI-Transfer noch nicht beendet war,
weil an der Stelle nicht gewartet wurde, dass der TX-Buffer leer ist.
Erstaunlicherweise hat es immer funktioniert, wenn die 5W-LED und der
Treiber aus waren, aber nur selten, wenn sie an waren.
Lustig sowas ;-)
Erst durch Messung der Signale im Zeitbezug zueinander bin ich dem auf
die Spur gekommen ... Ich dachte wirklich, irgendwas wäre weich oder
falsch konfiguriert oder fehlerhafte Hardware ...
Vielen Dank an alle, die versucht haben mir zu helfen, auch wenns zum
Schluss garnicht die Hardware war ...
Grüße,
Thomas
Simon K. schrieb:> Finde ich ne lustige Idee übrigens, sieht ziemlich "low cost" aus. Das> Objektiv vorne kriegt man ja auch günstig von Pollin o.ä. wenn ich nicht> irre.
Ich hab das Objektiv für 6EUR bei Eb*y ersteigert :)
Glaub, das teuerste ist da nur das selbstgebastelte µC-Board und da kann
man ja eigentlich alles hernehmen, was man möchte.
Ansonsten hab ich die LED vom Reichelt (7EUR), Kleinkram für den
LED-Treiber (5EUR), einen alten CPU-Kühler, ein paar Linsen von
Astromedia (1,50EUR pp), ein polnisches 128x64px LCD für 8,50EUR ...
Für vieles reicht so ein monochromer LowRes-Beamer aus :)
Grüße,
Thomas
Thomas schrieb:> Ich hab das Problem gefunden ... War software ...
...
Das ist sehr schön, daß auch mal jemand etwas Feedback gibt.
Man sollte meinen, sowas wäre selbstverständlich, wenn man andere um Rat
fragt.
Aber leider herrscht heutzutage fast nur Schweigen im Walde. Man sollte
in der Schule ein Fach Höflichkeit und Freundlichkeit in den Lehrplan
aufnehmen, es täte Not.
Hast jetzt nen dicken Pluspunkt bei mir.
Peter
