LPCxpresso - Kurzbericht

[Hemi]

Okay, werde ich mal ausprobieren.

Zur Not habe ich noch ein Decoder-Board von Sparkfun, dieses hier: klick mich, damit kann ich es dann auch mal testen, falls was mit der Hardware sein sollte.

Ich werde es heute mal anders testen und zwar die Platine vollständig abstecken und einfach die Leitungen messen. In der while einfach 0xAA oder sowas senden und auf dem LA schauen, was ankommt und vor allem den Takt prüfen.

Grüße
Heinrich

 

[dino03]

Hallo,

warum soll am SPI-Clock nen Takt anliegen wenn zB keine Daten übertragen werden müssen ?
Es ist ja quasi kein synchroner Bus mit Start-Stop-Kennung auf dem Datenpin sondern die Datenbits werden angelegt und mit den Flanken des SCK eingetaktet. Keine Datenbits zu übertragen = kein Takt.

Gruß
Dino

 

[Cassio]

Hallo,

warum soll am SPI-Clock nen Takt anliegen wenn zB keine Daten übertragen werden müssen ?

Hallo Dino!

So sehe ich das ja auch....
Darum habe ich mich ja auch gefragt, warum Daten über MOSI gesendet werden und die Clock in der Zeit Low ist?

Grüße,
Cassio

 

[dino03]

Hallo,

So sehe ich das ja auch....
Darum habe ich mich ja auch gefragt, warum Daten über MOSI gesendet werden und die Clock in der Zeit Low ist?

das mit dem Takt von 3,8MHz und der Sample-Rate von 4 MHz sehe ich ähnlich kritisch wie Cassio.
Ich hab mal nen kleinen Bereich aus dem SCK-Signalrausgeschnitten ...

... der Takt ist extrem unregelmäßig. Man sieht erst kurze Impule nach High und dann ab der Hälfte kurze Impulse nach Low. Ich tippe mal auf einen Schwebungseffekt vom SCK-Signal zum Sampletakt des Analyzers. Ich würde als absolutes Minimum den 2-3fachen Sampletakt gegenüber der kleinsten vorkommenden Zeitspanne vorsehen. Das ist dann aber auch schon stark geknautscht. Eher der 4fache Sampletakt. Vor allem mußt du das ja so sehen ...

3,8MHz SCK = 0,26µs Periodendauer = 0,13µs High / 0,13µs Low
Wenn man jetzt mit 4MHz Sampletakt abtastet dann liegt zwischen den Abtastungen die Periodenzeit des Sampletaktes.
Also 4MHz Sampletakt = 4MSamples/s = alle 0,25µs eine Abtastungen.

Merkst du was ? Das kann garnicht gut gehen. Also als absolutes Minimum 8MHz Sampletakt um überhaupt alle Wechsel des SCK-Signals mitzubekommen. Eher mehr. Dann wäre jede 0,125µs eine Abtastung. Das ist zwar auch noch ziemlicher Grütz bei zu messenden Zeiten von 0,13µs aber wenigstens geht einem nix durch die Lappen.

Ich tippe mal das der Analyzer bei deiner Messung mehr interpoliert und geschätzt hat als das er die wirklichen Signalabläufe angezeigt hat.

Gruß
Dino

 

[Hemi]

Sodelle, ich habe was getestet. Erstmal habe ich folgendes probiert:

-> lesen von einem Byte vom USB-Stick: 2ms
-> lesen von 256 Byte vom USB-Stick: 2ms oder 5ms, immer im Wechsel (WTF???)
-> lesen von 1kB Daten vom USB-Stick: 5ms
-> lesen von 2kB Daten vom USB-Stick: 6ms

Interessant...

Dann, war SPI an der Reihe. Ich habe die Platine abgesteckt und einfach in der while ein Byte (0xAA) über SPI gesendet, die Geschwindigkeit war 400kHz:



Und hier mit 5MHz:



Ich glaube, da stimmt was nicht. Bei 5MHz ist der Takt sehr unregelmäßig...

Ich habe dabei ein komplett neues Projekt angelegt und nur SPI aktiviert.

Ideen?

Grüße
Heinrich

 

[dino03]

Ich glaube, da stimmt was nicht. Bei 5MHz ist der Takt sehr unregelmäßig...

5MHz = 0,2µs Periodendauer = alle 0,1µs eine Flanke.
12MHz Samplefrequenz ... alle 0,083µs eine Abtastung.

1. Es ist kein ganzzahliges Vielfaches (5MHz zu 12MHz) also läuft das alles auseinander und du hast Schwebungseffekte in der Darstellung

2. Mach die Abtastfrequenz doch mal auf volle Pulle (24MHz)

3. Stell mal auf der rechten Seite bei "Measurement" die Error-Anzeige mit an und sieh dir bei den Zeiten des Clock-Signals die Fehlerrate in Prozent bei der zeitlichen Auflösung an. Ich tippe mal das du da hinten rüberfällst.

Siehe hier ...

schau mal auf die obere Angabe "Width". Weil ich den Impuls nur mit 2-3 Samples erfassen konnte habe ich einen zeitlichen Fehler von 34% in der Messung und Darstellung. Wenn du also mit solchen kleinen Sampleraten gegenüber dem zu messenden Signal arbeitest mußt du dich nicht über diese grützige Darstellung wundern. Was meinst du wohl warum ich bei meinem neuen Oszi auf eine möglichst hohe Samplerate (2GS/s) geachtet habe ...

Also laß die Analyzer-Büchse doch mal richtig was tuen. Die hohen Sampleraten hast du doch schließlich mitbezahlt. Dann nutze sie doch auch.

Gruß
Dino

 

[Hemi]

Hi Dino,

habe ich gemacht.

Bei Width habe ich zwischen +/- 50% bis 34%
Bei Period habe ich zwischen +/-5% bis 20%
Bei Frequency habe ich zwischen +/-6% bis 34%.

Ist es das, was Du meinst?

Ich versuche morgen den SPI auf ein ganzzahliges Wert zu bringen und schauen, was da passiert.

Grüße
Heinrich

 

[dino03]

Au weia !

Ja genau das. Das wär so als wenn du sagen würdest ...
Der Schrank ist 1m breit. Könnte aber auch 2m breit sein
oder
das Spiel dauert 90min oder 180min ( die armen Fussballer)
also wunder dich nicht über die mistige Anzeige.

Traue keinem Meßwert bei dem du nicht weißt wie groß der Meßfehler ist !

Was ist da bei dir passiert ...

Durch einen Schwebungseffekt (zwei unterschiedliche Frequenzen die nahe aneinander sind) wandert dein Samplezeitpunkt langsam über dein Meßsignal. Da du nur wenige Abtastungen machst bekommst du dein Meßsignal nicht sauber auf die Anzeige. Am Anfang wo dein Takt laut der Anzeige ausfällt ist es lediglich so das du zufällig in diesem Bereich nur zu den Zeitpunkten sampelst bei denen das Meßsiglan zufällig grade Low ist. Du siehst also durch die zu kleine Samplefrequenz die High-Zustände des Clocksignals nicht. Sie sind für dich in der Messung unsichtbar. Sie sind aber trotzdem vorhanden. Ich würde mal sagen wenn du den Datenstrom auf MOSI und MISO interpretieren hättest lassen (Datenbytes anzeigen lassen) dann wäre da noch mehr Grütze bei rausgekommen und dir wär ohne den Zwischenschritt der grauen Haare gleich ne Glatze gewachsen.

Also IMMER ! möglichst hohe Samplerate wählen. Wenn du dann einen längeren Zeitraum einlesen willst kannst du immer noch gemäßigt runterdrehen oder besser mehr Bytes aufzeichnen (größere Sampledatei).

Ich gebe mal folgende Voraussage ab ... Wenn du bei der oben angegebenen Messung weiter nach rechts scrollst dann wirst du irgendwann einen Bereich sehen der dauerhaft auf High liegt. Dann setzt der Takt wieder ne zeitlang ein, dann kommt wieder ein Bereich mit Low, ... usw ... es wiederholt sich also immer weiter.

Gruß
Dino

 

[Hemi]

Hallo Dino,

ich habe Deinen Beitrag gerade erst gesehen, aber genau das ist mir gestern beim Zähneputzen auch eingefallen, dass es eigentlich ein völliger Schwachsinn ist, was er da anzeigt und nicht sein kann. Das würde bedeuten, dass jemand ständig den Takt vom SPI ändert, ähm, ja. Wenn ich mir dann noch die Bytes angeschaut habe, hat er einen völligen Schwachsinn angezeigt, irgendwas mit 0xFE oder 0xFA und so weiter, such es Dir einfach aus.

Ich denke, dass meine Geschwindigkeitmessung (lesen von X Bytes vom USB) genau so für den Popo ist. Muss sie mal wiederholen.

Ich werde mal den SPI mit 6MHZ (oder 4 MHz) takten und dann nochmal schauen.

Grüße
Heinrich

 

[Hemi]

Servus miteinander,

ich kam mal wieder dazu, mit meinem CM3 weiter zu spielen. Also, erstmal habe ich die optimale Blockgröße fürs Lesen vom USB-Stick ausgewählt. Ich habe die Größen von 512Byte, 1kB, 2kB, 4kB, 8kB und 16kB. Hier ist das Ergebnis:



Also, habe ich mich für einen Puffer von 4kB entschieden.

Dann habe ich mir die Taktung vom CM3 angeschaut und es etwas umkonfiguert, vor allem wegen SPI-Takt und siehe da, es klappt. Ich habe kaum noch aussetzer und der Klang ist echt sehr gut, besser, als ich dem Ding zugetraut habe. Da kommt richtig was raus, der Klang ist sehr angenehm. Ich habe es aber nur mit den suboptimalen Sennheiser HD-418 getestet. Bei den langsamen und ruhigen Passagen, habe ich keine Aussetzer und alles ist top. Wenn es aber schnell und dynamisch wird, kommen leichte Aussetzer. Ich weiß jetzt auf jeden Fall, dass es am SPI-Takt liegt. Ich bin noch nicht so ganz durchgestiegen, wie das mit der Taktung vom CM3 funktioniert.

 

[Hemi]

Sodelle, ich habs endlich auf die Reihe bekommen. Es tut ohne Aussetzer und ohne Probleme, auch bei 5MHz SPI-Takt. Das Problem waren die Klammern.

Falsch:

#define DREQ_STATUS()		(LPC_GPIO2->FIOPIN  >> 7) & 0x01

Und so sollte es aussehen:

#define DREQ_STATUS()		((LPC_GPIO2->FIOPIN  >> 7) & 0x01)

So ein Mist, ich habe vielleicht geflucht.

Die Taktung vom CM3 ist jetzt nun auch klar.

 

[Cassio]

Hallo Heinrich!

Gratuliere zum gefunden Fehler!

Ich kann mir gut vorstellen, dass du geflucht hast!
Wie schnell übersieht man mal ein paar kleine Klammern.

Geht mir manchmal mit Punkt, Komma und Semikolon unter BASCOM auch so.


Viel Spaß weiterhin!
Cassio

 

[Hemi]

Hallo Cassio,

danke danke. Das Dümmste ist, man findet es nicht so schnell. Ich habe schon alles ausprobiert, sogar den Bus durchgemessen. Naja, man achte auf die Klammern.

Aber ich muss sagen, der Chip gefällt mir, der Klang ist echt gut. Und vor allem, er frisst echt alles. Habe gerade eine OGG-Datei auf den USB-Stick kopiert und spiele sie ab, es geht ohne Probleme.

Werde jetzt mal einen Scan für Files einbauen, dass man einfach den USB-Stick reinsteckt und durch die Files hüpfen kann. Und dann halt noch LCD und Joystick für die Navigation

 

[dino03]

danke danke. Das Dümmste ist, man findet es nicht so schnell. Ich habe schon alles ausprobiert, sogar den Bus durchgemessen. Naja, man achte auf die Klammern.

tröste dich. Mir ist sowas mit den Ports beim ATmega passiert. Da stand dann folgendes ...
DDRB = &B0011.0110
und es mußte heißen
DDRB = &B0011_0110
ich hab da auch schon defekte Ports vermutet und alles mögliche getestet und durchgemessen. Hat mich mehrere Tage gekostet bis ich drauf gekommen bin. Das schlimmste - über Copy/Paste hat sich der Fehler über zwei Projekte verteilt.

Gruß
Dino

 

[Cassio]

Aber ich muss sagen, der Chip gefällt mir, der Klang ist echt gut. Und vor allem, er frisst echt alles. Habe gerade eine OGG-Datei auf den USB-Stick kopiert und spiele sie ab, es geht ohne Probleme.

Hallo Heinrich!

Welch ein Jammer, dass du zum Einen nicht in der Nähe wohnst..... wegen der Stammtischtreffen und
zum Anderen, dass du nicht in BASCOM programmierst.

Viel Spaß weiterhin!

Grüße,
Cassio

 

[Hemi]

Na ich kann ja auch nichts dafür, dass Ihr alle so weit weg wohnt

Aber ein CM3 in Bascom zu programmieren stelle ich mir recht spaßig vor.

Habe mir jetzt das hier bestellt, so kann ich dann mit dem I²C etwas spielen und schaue, wie er beim CM3 funktioniert.

Habe gestern noch die LCD-Lib aus einem anderen Projekt in den aktuellen importiert und es lief auf Anhieb, mit Grafik (normales Zeichnen) und auch Text. Werde noch ein Progressbalken und Zeitanzeige einbauen und dann noch die Navigation per Joystick.

 

[Hemi]

Hier sind noch npaar Bilder von meinem Versuchsaufbau:



Unten rechts ist die Decoderplatine und oben rechts ist der Debugger.



Seit gestern kann ich nun auch FLAC wiedergeben.

Dann habe ich doch was Schönes gefunden und zwar hat CM3 (können bestimmt auch andere) einen GPIO-Interrupt, der ausgelöst wird, wenn der Zustand eines x-beliebigen Pins des Ports 0 oder 2 sich ändert, ob auf rising oder falling edge kann man einstellen. Dann bei wird ein Interrupt ausgelöst und in dem schaut man nach, was passiert ist und reagiert entsprechend. Die Prio des Interrupts kann man ebenfalls einstellen. Ist zum Beispiel ganz nützlich für TouchScreen, damit man erkennt, dass man ihn berührt hat, ohne pollen zu müssen. Ist also ähnlich wie INT0 und INT1 beim AtMega.

 

[dino03]

Hi Hemi,

Dann habe ich doch was Schönes gefunden und zwar hat CM3 (können bestimmt auch andere) einen GPIO-Interrupt, der ausgelöst wird, wenn der Zustand eines x-beliebigen Pins des Ports 0 oder 2 sich ändert, ob auf rising oder falling edge kann man einstellen. Dann bei wird ein Interrupt ausgelöst und in dem schaut man nach, was passiert ist und reagiert entsprechend. Die Prio des Interrupts kann man ebenfalls einstellen. Ist zum Beispiel ganz nützlich für TouchScreen, damit man erkennt, dass man ihn berührt hat, ohne pollen zu müssen. Ist also ähnlich wie INT0 und INT1 beim AtMega.

nennt sich bei den ATmegas/tinys PCINT (PinChangeInterrupt). Der kann aber nur Änderungen erkennen. Man kann also nicht einstellen ob Falling oder Rising. Außerdem sind immer mehrere Pins zu Gruppen zusammengefaßt. Für jede Gruppe gibt es dann nur einen Interruptvektor.

Ist also ähnlich aber wesentlich kleiner angelegt.

Gruß
Dino

 

[Hemi]

Bei den CM3 ist es so, dass alle GPIO-Interrupts über den Vector EINT3_IRQn abgefangen werden. Und in der Routine muss dann geprüft werden, was passiert ist.

Und dass die Megas eben keine IRQ-Priorisierung können, oder gibt es welche, die das können?

 

[Hemi]

Theoretische Frage

Tach zusammen,

ich spiele gerade mit dem TouchScreen rum und hätte da eine grundsätzliche Frage. Und zwar bekomme ich ja vom Controller die Koordinaten, so weit so gut. Nur wie erkenne ich jetzt, was unter den Koordinaten liegt? Sprich was für ein Knopf "gedrückt" wurde? Wie macht Ihr das?

Danke & Grüße
Heinrich