Hallo, takte den Atmega128 mit internen 8 Mhz und versuche dig. Videodaten einzulesen. Meine Pixelrate ist im Moment 10µs/Pixel. Doch ich hab das Gefühl, der µC kommt nicht mit.
Bei 8MHz macht er maximal 8 Millionen Befehle pro Sekunde, das sind in 10µs 80Takte - das sollte locker reichen. Was machst Du denn mit den Daten? Und mit welcher Programmiersprache arbeitest Du? Markus
Ich arbeite mit ICCavr, also mit C. Ziel ist es, die Pixel des ersten bildes Bildes in einem externem SRAM zu speichern und danach immer die pixel des neuen Bildes mit denen des alten Bildes zu vergleichen. Externes SRAM deswegen, weil ich 80x60 Pixel hab. Weiß leider auch noch nicht, ob die Zugriffe auf das ext. SRAM schnell genug sind?! Außerdem will ich den AVR mit 3,3V betreiben. Ist es vielleicht doch möglich ihn dann mit 16 MHz zu takten? Oder zumindest mit 12 oder so? Holger
Wenn Du das Bild ein bischen kleiner machst oder z.B. nur mit 4Bit Graustufen speicherst, dann sollte das auch ins interne RAM passen. Poste doch mal die entsprechenden Codeabschnitte posten könntest, dann kann man vielleicht mehr sagen. Hast Du Dir schonmal den erzeugten Assemblercode angesehen? Zum Takt: Im Datenblatt unter "Typical Characteristics/Active Supply Current" (S. 336) wurden die Graphen für 3,3V bis 10MHz gezeichnet. Markus
Hab noch keinen richtigen Code, mitlerweile kann auch den Wert einlesen. Keine Ahnung woran das wieder lag. Hab mal ins Datenblatt auf die Seite geschaut.Die gehen doch bis 20 MHz!? Oder seh ich da was falsch? Bin mir nicht sicher ob ich auf 4Bit runter gehen kann oder ob ich das Bild kleiner machen kann; (lieber nur wenns unbedingt nötig ist.) Dauert denn das mit dem externen SRAM so lange?? Assembler kann ich leider nicht, vielleicht würde sich da später noch was optimieren lassen?
Genau, die Datenblätter zeigen Meßwerte bis 20MHz. Privat würde ich einfach ausprobieren, wie weit es noch zuverlässig läuft, beruflich ist das immer so eine Sache. Mit dem externen RAM habe ich keine Erfahrung, aber 10µs sollten da schon drin sein. Das RAM selbst ist ja sicherlich 100x schneller. Assembler-Optimierungen kann man natürlich später auch noch machen; mir ging es aber eher darum, daß Du einen Eindruck davon gewinnst, was denn Dein Compiler da so tut.
ich steh auf der Leitung, welche Video-Daten kommen mit 10us/Pixel. Wenn ich die "schlechteste" Videoauflösung (FBAS) betrachte hat eine Zeile 64us für Sync, Burst und Bildinhalt. Auf die etwa 50us Bildinhalt kommen normalerweise etwa 720 Pixel. Oder seh ich den Wald vor lauter Bäumen nicht? Grüsse leo9 PS.: L-Typen (also die für 3,3V spezifizierten) laufen offiziell nur bis 10MHz, alles drüber "kann" funktionieren.
Also, ich habe einen digitalen Cmos-chip mit original CIF-Auflösung.
Die ist mir aber immer noch zu hoch, bzw. brauch ich sie nicht so
hoch.
Auch brauch ich keine 25 frames/sec.
Also hab ich als erstes mal meine Pixelclock auf ganz langsam gesetzt
(10 µs / periode).
Mit der Pixelclock komme ich jetzt auch gut mit. Doch das VSYNC-Signal,
das beim Bildwechsel kurz auf 1 geht krieg ich nicht mit. Mit dem Oszi
sehe ich aber immer ein kurzes zucken auf 1.
Ich will so lange warten, bis VSYNC von 0 auf 1 wechselt. Doch
irgendwie bleibt er immer in der ersten while-Schleife drin.
Mein Code:
#define VSNYNC (PINF&0x40)>>6; // Signal ist auf PORTF6
------------------
void main()
{
DDRF=0x00;
while(VSYNC==0){}
while(VSYNC==1){}
}
-------------------
Kann es sein, dass (PINF&0x40)>>6;) zu lange braucht?
Ein einfaches RS-Flipflop am VSYNC-Signal sollte helfen. Das VSYNC-Signal ist also am SET angeschlossen und setzt das FlipFlop, wenn das Signal kommt. Du liest es nun mit deinem AVR aus und resettest es dann (wobei du hierfür dann einen extra Pin brauchst).
Ich nehme mal an, das ICCavr es nicht viel besser macht als mein WinAVR: 193:main.c **** while(VSYNC==0){} 685 .LM65: 686 .L18: 687 02f0 80B1 in r24,32-0x20 688 02f2 9927 clr r25 689 02f4 8074 andi r24,lo8(64) 690 02f6 9070 andi r25,hi8(64) 691 02f8 082E mov _tmp_reg_,r24 692 02fa 892F mov r24,r25 693 02fc 000C lsl _tmp_reg_ 694 02fe 881F rol r24 695 0300 990B sbc r25,r25 696 0302 000C lsl _tmp_reg_ 697 0304 881F rol r24 698 0306 991F rol r25 699 0308 892B or r24,r25 700 030a 91F3 breq .L18 194:main.c **** while(VSYNC==1){} 702 .LM66: 703 .L22: 704 030c 0699 sbic 32-0x20,6 705 030e FECF rjmp .L22 Der braucht 16 Zyklen (wenn ich mich nicht verzählt habe) für die Schleife! Bei 16MHz Takt wird das Signal also nur einmal pro us abgefragt, das dürfte zu wenig sein. while(VSYNC==1){} wird hingegen ganz toll optimiert. Schreib doch mal: #define VSNYNC (PINF&0x40) // Signal ist auf PORTF6 ------------------ void main() { DDRF=0x00; while(VSYNC==0){} while(VSYNC!=0){} } ------------------- Das führt bei mir zu: 193:main.c **** while(VSYNC==0){} 685 .LM65: 686 .L18: 687 02f0 069B sbis 32-0x20,6 688 02f2 FECF rjmp .L18 194:main.c **** while(VSYNC!=0){} 690 .LM66: 691 .L22: 692 02f4 0699 sbic 32-0x20,6 693 02f6 FECF rjmp .L22 ideal optimiert und die Funktion ist die gleiche. Sollte der Impuls immer noch zu kurz sein, hilft ein flankengetriggerter Interrupt, es sollte eigentlich auch gehen den Interrupt garnicht freizugeben und in der Warteschleife das Flag zu pollen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.