Da ist eine kuchenblechgroße Platine mit 625 x 74HCT164 SMD. Das sind 8 Bit Schieberegister, alle hintereinander geschaltet. Die Taktfrequenz kommt aus einem 1MHz Quarzgenerator. Das Digitalsignal am Eingang wird um 625 x 8 / 1MHz = 5ms verzögert. Wie kann man diese "Wahnsinnsplatine" ersetzen?
Frickelprinz schrieb: > Wie kann man diese "Wahnsinnsplatine" ersetzen? Du..gar nicht. Bei Dir reicht es ja nicht einmal um vernünftig zu trollen.
Am besten mit einem beliebigen Mikrocontroller, freie Auswahl sozusagen. Falls Du wenig Erfahrung hast nimmst Du z.B. Arduino, das bekommt man wohl hin.
Daten mit µC empfangen, parallel in 3 62256er schreiben, am /RST der 62256er wackeln, wieder von vorne. Ist doch easy ...
Es gab schon lang vor dem 174 Schieberegister wie https://www.ebay.de/itm/331806924463 aber damit genau 5000 zusammenzustückeln ist schwer, ich weiss nicht ob dieses 1MHz kann https://www.haje.nl/product_info.php/view/all/sort/7d/language/en/products_id/1828 Also würde man das heute wohl mit einem FPGA bauen. Da dein Chip aber bloss 4 Pins bräuchte, sind FPGA uneffektiv. Ein simpler uC, mit 16 MHz getaktet, kann das auch leisten. Bloss wenn diese 16hz synchron zum 1 MHz Clock sein müssen, also per PLL, wird das wieder schwieriger. Ich bleibe beim FPGA wie LFXP2-5E-5TN144C, obwohl man eigentlich das nimmt, was einem der Fitter vorschlägt in der Toolchain.
MaWin schrieb: > Bloss wenn diese 16MHz synchron zum 1 MHz Clock sein müssen, dann greift man dem uC mit etwas Hardware unter die Arme.
Die 1MHz als Takt für eine SPI Schnittstelle nehmen und die Daten in einem Ringspeicher ablegen. Nachdem 625 Byte eingelesen wurden, mit dem ältesten Wert anfangen alles wieder auszugeben. Im Prinzip also ein im µC programmiertes FIFO.
:
Bearbeitet durch User
Frickelprinz schrieb: > Da ist eine kuchenblechgroße Platine mit 625 x 74HCT164 SMD. Das sind 8 > Bit Schieberegister, alle hintereinander geschaltet. Die Taktfrequenz > kommt aus einem 1MHz Quarzgenerator. Das Digitalsignal am Eingang wird > um 625 x 8 / 1MHz = 5ms verzögert. > Wie kann man diese "Wahnsinnsplatine" ersetzen? Wurde ja schon mehrfach gesagt. uC CPLD+SRAM FPGA Such dir was aus. Mario M. schrieb: >> Bloss wenn diese 16MHz synchron zum 1 MHz Clock sein müssen, > > dann greift man dem uC mit etwas Hardware unter die Arme. Eben. Mit einem Schieberegister als 74HC595 am Ein- und Ausgang kriegt man die Wortrate auf läppische 125 kHz runter. Das kann ein uC problemlos einlesen, speichern und wieder ausgeben, es reicht ein ATmega 328 ala Arduino. Experten wie unser C-hater macht's bestimmt auch ohne Schieberegister in ASM mit nem ATtiny85 ;-)
Ich habe in alten™ Zeiten tatsaechlich mal mit D191, das muesste zum 7491 aequivalent sein, ein 4 x 48 bit FIFO zusammenbauen muessen. Der D191 war der Kaefer der Wahl, da er per Package die groesste :) Kapazitaet hatte. Die zwischengespeicherten Daten stammten von einem C520 ADC und wurden dann auf eine Digitalkassette mit SIF1000 Interface geschrieben und dienten der Auswertung von Daten eines Gel-Aminosaeurenanalyzers. Aber HCT164? Zu den Zeiten haette man kaum ein knappes Kilo von diesen Kaefern nehmen muessen. Also ein Troll! Oder ein Bild vorzeigen!
Cartman schrieb: >> 74HC595 am Ein- und Ausgang > > Am Eingang wohl kaum... Aber sicher. Seriell rein, parallel zum uC raus. OK, am Ausgang braucht es eher ein 165er Schieberegister, Parallel rein, seriell raus. Dazu noch ein /8 Teiler, welcher den Synchron/Ladetakt erzeugt. Damit ist alles nach außen auf dem 1 MHz Takt synchronisiert. Oder gleich brute force mit einem SRAM, 8x625=5000 Bytes sind heute Peanuts und man kann die ungenutzten 7 Bit in den Skat drücken. Braucht aber auch 2 Adresszähler und Logik.
Falk B. schrieb: > Oder gleich brute > force mit einem SRAM, 8x625=5000 Bytes sind heute Peanuts und man kann > die ungenutzten 7 Bit in den Skat drücken. Braucht aber auch 2 > Adresszähler und Logik. Im FIFO alles drin.
> Aber sicher. Seriell rein, parallel zum uC raus. Stimmt. > am Ausgang braucht es eher ein 165er Schieberegister Die Stelle wars also.
Falk B. schrieb: > Experten wie unser C-hater macht's bestimmt auch ohne > Schieberegister in ASM mit nem ATtiny85 ;-) Nö, zu wenig RAM für die Aufgabe. ATtiny824 z.B. würde aber reichen. 14-Pinner ist auch immer noch deutlich kleiner als ein Kuchenblech. Das Asm-Programm für die Aufgabe hätte ca. 40 Zeilen, das meiste davon für die passende SPI-Konfiguration.
Am einfachsten waere wohl die zweckentfremdete Nutzung eines MN3207. Der brauchte dann nur noch einen Taktgenerator.
Warum bitte willst du das ersetzen? Solange alles geht gibt es doch keinen Grund dafür? Es ist einfacher ein Schieberegister zu tauschen als einen BGA FPGA! Auch so eine Sache die man bedenken sollte: Reparierbarkeit! Was wird mit den Schieberegistern gemacht? LEDs ansteuern? Es bringt nichts diese Platine kompakter zu machen wenn das "drumherum" trotzdem Kuchenblechgröße hat.
Andre G. schrieb: > Was wird mit den Schieberegistern gemacht? > LEDs ansteuern? Einziger Sinn der Riesenplatine ist ein TTL-Signal um (1MHz-Quarz-genau) 5000us zu verzögern. Die Platine hat ein Praktikant vor Jahren entworfen, ätzen lassen und von Hand bestückt. Die Platinendaten sind verschollen und können nicht wiederhergestellt werden. (Lieber Gott mach, dass das so bleibt) Mit uC habe ich Berührungsängste, wenn es nur ein paar Zeilen in C sind, warum mag die niemand hier mal aufschreiben?
Vielleicht so?
1 | init_spi_as_slave(); |
2 | while (1) { |
3 | tx = fifo_read(); |
4 | while (!(SPSR & (1<<SPIF))); |
5 | rx = SPDR; |
6 | SPDR = tx; |
7 | fifo_write(rx); |
8 | }
|
> Mit uC habe ich Berührungsängste
Hast du dir den MN3207 ueberhaupt schon angesehen?
Ein winzich kleines Kaeferchen. DIL8 glaub ich...
Frickelprinz schrieb: > warum mag die niemand hier mal aufschreiben? Es ist einfach zu warm! Einfach und günstig wäre für Dein Problem ein RP2040 Pico-Board mit Arduino IDE oder Python programmiert. Bit0 eines Arrays mit 5000 Elementen wird mit internem 1 MHz Takt mit dem Eingangspegel an der Stelle "n" beschrieben und an "n+1" ausgelesen und auf den Ausgang geschrieben. Die Hardware kostet fünf Euro + Versand. Bis das Teil bei Dir auf dem Tisch liegt, sollte sich auch jemand für die Software gefunden haben. Mußt allerdings sagen, ob Dir das gefällt.
Cartman schrieb: > Hast du dir den MN3207 ueberhaupt schon angesehen? Nicht nötig. Abgesehen von anderen Defiziten kann er nur bis 500 kHz getaktet werden.
Frickelprinz schrieb: > Wie kann man diese "Wahnsinnsplatine" ersetzen? Warum willst du sie ersetzen, welchen Vorteil versprichst du dir davon? Was hängt denn an den parallelen Ausgängen der Schieberegister? Frickelprinz schrieb: > Mit uC habe ich Berührungsängste, wenn es nur ein paar Zeilen in C sind, > warum mag die niemand hier mal aufschreiben? Weil du erstens noch nicht darum gebeten hast und zweitens völlig unklar ist, wozu das ganze gut sein soll. Man kann nur dann sinnvoll programmieren, wenn klar ist, was das Programm tun soll.
Stefan ⛄ F. schrieb: > Man kann nur dann sinnvoll > programmieren, wenn klar ist, was das Programm tun soll. Frickelprinz schrieb: > Einziger Sinn der Riesenplatine ist ein TTL-Signal um (1MHz-Quarz-genau) > 5000us zu verzögern. Ist das so schwer zu verstehen?
m.n. schrieb: > Ist das so schwer zu verstehen? Es klingt halt stark nach einer halben Beschreibung. Soll das heissen, dass die ganze Platine nur 4 Anschluss-Pins hat? 1) GND 2) VCC (wie viel Volt?) 3) Daten Eingang 4) Daten Ausgang Und die ganze parallelen Ausgänge der Schieberegister sind wirklich ungenutzt? Ich frage erneut nach, weil ich das kaum glauben mag. Schon in den 70er Jahren gab es dafür bessere und billigere Bauteile.
Stefan ⛄ F. schrieb: > Schon > in den 70er Jahren gab es dafür bessere und billigere Bauteile. Ich höre:
m.n. schrieb: >> in den 70er Jahren gab es dafür bessere und billigere Bauteile. > Ich höre "Bis 1972 war der 1103 RAM das meistverkaufte Chip auf dem Markt" http://computer.51itpx.com/Hardware/RAM---Karten-und-Motherboards/History-of-Memory-RAM-.html https://en.wikipedia.org/wiki/Intel_1103 Mikroprozessoren, um diese anzusprechen, gab es natürlich auch längst.
Fifo wurde genannt. Es reicht ein 1k*8 Typ. - Eingangssignal an D0 - Ausgang Q0 an D1 - Ausgang Q1 an D2 usw. - Signalausgang ist Q7. - Write- und Read-Clock verbinden. Mit z.B. dem IDT72220 könnte ich mir das vorstellen: https://www.renesas.com/us/en/products/memory-logic/fifo-products/synchronous-fifos/72220-1k-x-8-syncfifo-50v Solche Bausteine scheinen allerdings dünn gesät zu sein ...
Frickelprinz schrieb: > Einziger Sinn der Riesenplatine ist ein TTL-Signal um (1MHz-Quarz-genau) > 5000us zu verzögern. Die Platine hat ein Praktikant vor Jahren > entworfen, ätzen lassen und von Hand bestückt. Und was macht man damit insgesamt? Verzögerungsleitung für Audioeffekte?
Stefan ⛄ F. schrieb: > m.n. schrieb: >>> in den 70er Jahren gab es dafür bessere und billigere Bauteile. >> Ich höre > > "Bis 1972 war der 1103 RAM das meistverkaufte Chip auf dem Markt" > http://computer.51itpx.com/Hardware/RAM---Karten-und-Motherboards/History-of-Memory-RAM-.html > https://en.wikipedia.org/wiki/Intel_1103 > > Mikroprozessoren, um diese anzusprechen, gab es natürlich auch längst. Wäre dennoch ein erheblicher Aufwand gewesen. Aber es gab FIFOs mit mindestens 64 Bit, gegen Ende der 70er sicher auch mit deutlich mehr.
HildeK schrieb: > Fifo wurde genannt. Es reicht ein 1k*8 Typ. > - Eingangssignal an D0 > - Ausgang Q0 an D1 > - Ausgang Q1 an D2 usw. > - Signalausgang ist Q7. > - Write- und Read-Clock verbinden. > > Mit z.B. dem IDT72220 könnte ich mir das vorstellen: > https://www.renesas.com/us/en/products/memory-logic/fifo-products/synchronous-fifos/72220-1k-x-8-syncfifo-50v > > Solche Bausteine scheinen allerdings dünn gesät zu sein ... NOS bekommt man noch einiges mehr.
Dieter W. schrieb: > Die 1MHz als Takt für eine SPI Schnittstelle nehmen und die Daten in > einem Ringspeicher ablegen. > Nachdem 625 Byte eingelesen wurden, mit dem ältesten Wert anfangen alles > wieder auszugeben. Die Idee ist ja genial! DANKE!
> Solche Bausteine scheinen allerdings dünn gesät zu sein ...
Hab noch einiges davon rumzuliegen.
Bei Interesse sehe ich nach, was da ist.
Eduard I. schrieb: > Die Idee ist ja genial! DANKE! Dann zeigt dem TO Deine Schaltung und Dein Programm. Dann wäre auch ihm geholfen. HildeK schrieb: > NOS? Nicht Ohne Sahne.
HildeK schrieb: > Mit z.B. dem IDT72220 könnte ich mir das vorstellen: Wie kommt man mit Bausteinen, die intern fest auf 1024 (1K) eingestellt sind, genau 5000 Zyklen Verzögerungszeit?
m.n. schrieb: > HildeK schrieb: >> Mit z.B. dem IDT72220 könnte ich mir das vorstellen: > > Wie kommt man mit Bausteinen, die intern fest auf 1024 (1K) eingestellt > sind, genau 5000 Zyklen Verzögerungszeit? Man nimmt einfach 1,6384 MHz Takt.
H. H. schrieb: > Man nimmt einfach 1,6384 MHz Takt. Wenn's kein E5 an der Zapfsäule gibt nimmst Du bestimmt einfach Diesel.
m.n. schrieb: > H. H. schrieb: >> Man nimmt einfach 1,6384 MHz Takt. > > Wenn's kein E5 an der Zapfsäule gibt nimmst Du bestimmt einfach Diesel. Hast mal wieder nichts kapiert.
m.n. schrieb: >> Hast du dir den MN3207 ueberhaupt schon angesehen? > > Nicht nötig. Abgesehen von anderen Defiziten kann er nur bis 500 kHz > getaktet werden. Zaehl die anderen Defizite doch mal auf! Auf etwas zu verweisen ohne es zu benennen erinnert mich an die Rhetorik von inkompetenten Fachschulingenieuren. Dessen Spruch war dann immer: "Das wuerde jetzt zu sehr ins Detail fuehren." Nur das dann bei expliziter Nachfrage keine Details mehr kamen. Womoeglich reichen 2 µs Jitter ja, Und das er fuer ein rein "digitales" Durchreichen auch 1 MHz Takt vertraegt, ist zumindest recht wahrscheinlich. Seine nahen Artverwandten, die TDA1022 waren auch analog noch recht gut bei 1 MHz Takt, wenn er sonst der Spezifikation entsprach.
Falk B. schrieb: > Die Software sind zwei Dutzend Zeilen in C. Lieber ein paar mehr Zeilen und einen nackten Mega88 mit internem Takt. H. H. schrieb: > Hast mal wieder nichts kapiert. Wann denn noch?
m.n. schrieb: > HildeK schrieb: >> NOS? > > Nicht Ohne Sahne. Ich glaube er ist einfach angetrunken.
Cartman schrieb: > Zaehl die anderen Defizite doch mal auf! Mangelnde Grenzfrequenz reicht Dir nicht? Das ist Beweis genug. Das 1024 != 1000 ist Dir bekannt? Oder können alle Vorgaben des TO ignoriert werden?
Das digitale Signal hat nach der Delayline einen Jitter von 1 µs. Mit einem auf 1.024 MHz erhoehtem Takt waeren es 0.976 µs. Ich kann mich natuerlich taeuschen, wuerde aber denken dass es schlicht egal ist. Ich kann natuerlich nicht dafuer garantieren dass ein MN3207 noch bei 1 MHz arbeitet, meine Erfahrungen mit dem TDA1022 stimmen mich da aber optimistisch.
Cartman schrieb: > Das digitale Signal hat nach der Delayline einen Jitter von 1 µs Jitter? rms? Das wäre ja eine Taktperiode bei 1 MHz, also völlig unbrauchbar.
> Das wäre ja eine Taktperiode bei 1 MHz, also völlig > unbrauchbar. Naja was erwartest du? Der Taktgenerator auf dem Ofenblech versorgt nur die Schieberegister. Ein digitales Eingangssignal hat keine Beziehung zu diesem Takt. Der Abtastzeitpunkt ist dafuer quasi zufaellig.
Stefan ⛄ F. schrieb: > Was hängt denn an den parallelen Ausgängen der Schieberegister? NICHTS Außer das Qh mit den A+B Eingängen des nächsten verbunden ist. Das Signal wird immer weitergereicht, nach 625 Chips ist der Weg zu Ende, es sind bei 1MHz Taktung 5000us vergangen. Diese Platine ist ein absolutes Einzelstück, viel zu teuer und aufwendig, für das was es leistet. "WAHNSINN"
wenn es kein FIFO sein kann, muss man es diskret machen: kleiner RAM und getrennte Schreib- und Leseadresszähler, die beim Start mit dem genauen Adressoffset von 5000 Takten geladen werden. Passt auch locker in einen kleinen FPGA. Es soll wohl auch FPGA-Cores mit SR und FIFO von definierbarer Länge geben...
Cartman schrieb: >> Das wäre ja eine Taktperiode bei 1 MHz, also völlig >> unbrauchbar. > > Naja was erwartest du? > Der Taktgenerator auf dem Ofenblech versorgt nur die Schieberegister. > Ein digitales Eingangssignal hat keine Beziehung zu diesem Takt. > Der Abtastzeitpunkt ist dafuer quasi zufaellig. Achso. Ok. Das kann dann aber nur zuverlässig funktionieren, wenn die Datenrate niedriger ist.
HildeK schrieb: > Fifo wurde genannt. Es reicht ein 1k*8 Typ. > > Eingangssignal an D0 > Ausgang Q0 an D1 > Ausgang Q1 an D2 usw. > Signalausgang ist Q7. > Write- und Read-Clock verbinden. Das reicht nicht, man muss nach dem Start den Read-Clock für 5000 Takte sperren, sonst kommt das Byte vom Eingang gleich wieder am Ausgang raus.
Dass der 1MHz Takt nicht synchron zum Digitalsignal am Eingang ist, der Abtastzeitpunkt ist damit "quasi" zufällig ist durchaus gewollt. Aber wenn man jetzt eine andere Schieberegisterlänge hätte, dann wäre auch eine andere Taktfrequenz ok, hauptsache man kommt auf 5000us. Hätte man z.B. ein 8k Byte RAM und einen 13 Bit Addresszähler so wäre die notwendige Taktfrequenz 1,6384MHz. Von dem 8 Bit breiten RAM würde man jetzt wohl nur 1 Bit verwenden. Erstens das Bit lesen und ausgeben, dann zweitens das Digital Signal ins Ram schreiben und drittens den Addresszähler um eins erhöhen. Benötigt ganz schön viel "Logik". Kann man das nicht mit einem ATtiny im 8Pin Gehäuse erschlagen? Wenn der jetzt mit einem externen 16MHz Quarz läuft, wie soll man da das Programm auf 1MHz synchronisieren? Kann ein Timer-Interrupt soooooooo schnell sein?!?!
Man könnte meinen, dass Du den von Dir gestarteten Thread gar nicht mitgelesen hast.
Deshalb nimmt man ja auch einen FPGA. Da kann mann alles ohne viel Gehirnschmalz innerhalb von zwei Stunden auf den Punkt passend machen.
> "Bis 1972 war der 1103 RAM das meistverkaufte Chip auf dem Markt"
Die meissten 1103 landeten im Speicher von Grossrechnern.
Wer sich mal die noetige Aussenbeschaltung angesehen hat,
weiss warum. Das kleine Kerlchen brauchte sogar externe
Leseverstaerker, von den p-MOS Logikpegeln gar nicht zu reden.
Und klar, fuer 1 oder 4 MByte Speicher braucht es eine Menge 1103...
Cartman schrieb: >> "Bis 1972 war der 1103 RAM das meistverkaufte Chip auf dem > Markt" > > Die meissten 1103 landeten im Speicher von Grossrechnern. > Wer sich mal die noetige Aussenbeschaltung angesehen hat, > weiss warum. Das kleine Kerlchen brauchte sogar externe > Leseverstaerker, von den p-MOS Logikpegeln gar nicht zu reden. Es gab ja auch schon diese: https://de.wikipedia.org/wiki/2102_(Elektronik)
Bernd G. schrieb: > Deshalb nimmt man ja auch einen FPGA. Da kann mann alles ohne viel > Gehirnschmalz innerhalb von zwei Stunden auf den Punkt passend machen. Ach verdammt. Ich habe es nun in 20 Minuten auf dem AVR gelöst. Gruß Jobst
Jobst M. schrieb: > Ach verdammt. Ich habe es nun in 20 Minuten auf dem AVR gelöst. So würde ich das auch angehen, aber der Geilheitsfaktor einer Lösung mit einem Controller ist überhaupt nicht vergleichbar mit dem einer Leiterplatte mit 625 ICs. Georg
Früher (vor elektrischen speichern, so in den 50ern) hat man mittels URohr an einer Seite eingespeist und nach Schallgeschwindigkeit am andere rausgenommen und wieder eingespeist. Bei Quecksilber braucht man so ein 3m URohr Aber nein, wenn der Takt des uC ausreicht, sind es 10-zeiler, wenn man ein Byte per spi senden/empfangen kann und RAM hat
1 | int main(void) |
2 | {
|
3 | static int a[625], i; |
4 | |
5 | InitSPI(); |
6 | spi_snd=a[i]; |
7 | for(;;) |
8 | {
|
9 | if(++i>623) {i=0;} |
10 | spi_snd=a[i]; |
11 | while(!spi_rx_ready); |
12 | a[I]=spi_rcv; |
13 | }
|
14 | }
|
> Es gab ja auch schon diese: > https://de.wikipedia.org/wiki/2102_(Elektronik) In grossen Mengen konnte der 1103 seinen Hauptvorteil ausspielen: Seine geringe Leistungsaufnahme wenn nur gelegentlich refresht werden musste. Also z.B. ein ganzes Kuchenblech voll von den Dingern. So ein 2102 als statisches nMOS-RAM ist da ungleich verfressener. Mit einem Kuchenblech voll haette man auch gleichzeitig eine gute Heizung gehabt. Aber fuer die wenigen kByte an den damaligen Controllern war der 2102 sicher die einfachere und bessere Wahl. Wenn einen der Aufwand nicht stoerte, konnte man den 1103 aber durchaus auch benutzen.
> aber der Geilheitsfaktor einer Lösung mit > einem Controller ist überhaupt nicht vergleichbar mit dem einer > Leiterplatte mit 625 ICs. Der Praktikant hat beim Design aber auch klaeglich versagt. An die SR-Ausgaenge haetten natuerlich noch LEDs gehoert. Schon allein zu Diagnosezwecken, wo denn das Bit versackt wenn mal was kaputt ist. Ausserdem haette man dann die Bits durch die Gegend flitzen sehen...
Cartman schrieb: > Ausserdem haette man dann die Bits durch die Gegend flitzen sehen... 5ms ...? Man könnte auch 25x 4062 nehmen ... *Hrrrhrrch** Gruß Jobst
H. H. schrieb: > m.n. schrieb: > >> HildeK schrieb: >>> Mit z.B. dem IDT72220 könnte ich mir das vorstellen: >> >> Wie kommt man mit Bausteinen, die intern fest auf 1024 (1K) eingestellt >> sind, genau 5000 Zyklen Verzögerungszeit? > > Man nimmt einfach 1,6384 MHz Takt. Und dadurch ändert sich die Anzahl der Zyklen?
Percy N. schrieb: > Und dadurch ändert sich die Anzahl der Zyklen? Nö, die ist aber für die Aufgabe auch völlig unwichtig. Wichtig ist offenbar nur die Verzögerungszeit (check) und ggf. die Samplefrequenz, die beim Nachbau mindestens 1MHz sein sollte, aber durchaus auch größer sein kann, ohne an der Funktion der Sache was zu ändern (check). Ich würde trotzdem einen geeigneten µC nehmen. Der liegt im Gegensatz zu irgendwelchen historischen Exoten-ICs nämlich immer in der Bastelkiste rum. D.h.: die Sache wäre in einer halben Stunde voll funktionsfähig fertig.
Beitrag #7132744 wurde vom Autor gelöscht.
m.n. schrieb: > Wie kommt man mit Bausteinen, die intern fest auf 1024 (1K) eingestellt > sind, genau 5000 Zyklen Verzögerungszeit? Guter Einwand! H. H. schrieb: > Man nimmt einfach 1,6384 MHz Takt. Muss das nicht zur Datenrate des Eingangssignals passen? Oder man muss deutlich überabtasten und das erfordert wieder mehr Speichertiefe. Mario M. schrieb: > Das reicht nicht, man muss nach dem Start den Read-Clock für 5000 Takte > sperren, sonst kommt das Byte vom Eingang gleich wieder am Ausgang raus. Genau so guter Einwand 😀! Tja, da war ich wohl zu unüberlegt. Bleibt nur noch Software, SW kombiniert mit HW nach Falk B. oder FPGA. Oder eine immer noch hohe Zahl von Einzelbausteinen mit 64Bit-Shift Registern (CD4031 oder CD4517). Ja, geht nicht auf ohne Rest auf; man braucht noch einen HC164 zusätzlich. Sind dann immerhin statt 625 Bausteine 'nur' noch 79. c-hater schrieb: > Ich würde trotzdem einen geeigneten µC nehmen. Da würde dein permanenter Wunsch in Assembler zu programmieren gut passen, auch für die kleineren µCs: ≥ 256Byte RAM und den Shift- oder Rotatebefehlen. Frickelprinz schrieb: > Dass der 1MHz Takt nicht synchron zum Digitalsignal am Eingang ist, der > Abtastzeitpunkt ist damit "quasi" zufällig ist durchaus gewollt. Wie groß ist denn die Datenrate des Eingangssignals?
Ich hoffe ja mal, dass der Aufwand gerechtfertigt ist und nicht ein simples RC-Glied mit einem Schmitt-Trigger/Komparator dahinter auch die 5 ms Verzoegerung hinkriegen wuerde.
Cartman schrieb: >> "Bis 1972 war der 1103 RAM das meistverkaufte Chip auf dem Markt" > Die meissten 1103 landeten im Speicher von Grossrechnern. Es ging darum, dass M.n. offenbar zweifelte, dass es in den 70er Jahren bereits RAM gab. Wenn es 1972 schon welche als Massenware gab, dann danach erst Recht. Bis 1979 ist ja noch eine große Zeitspanne für weitere Entwicklungen.
HildeK schrieb: > Muss das nicht zur Datenrate des Eingangssignals passen? Oder man muss > deutlich überabtasten und das erfordert wieder mehr Speichertiefe. Leider fehlen uns immer noch die Anforderungen, deswegen kann man den Vorschlag mit der höheren Taktfrequenz nicht bewerten.
Cartman schrieb: > Ich hoffe ja mal, dass der Aufwand gerechtfertigt ist und nicht > ein simples RC-Glied mit einem Schmitt-Trigger/Komparator dahinter > auch die 5 ms Verzoegerung hinkriegen wuerde. Aber nur für einen einzigen Impuls. In 625x8=5000 passen max. 2500 Impulse rein. Bei 1MHz Takt ist die max. Verzögerung der Eingangsimpuls-Vorderflanke <1us, die max. Verzögerung der Eingangsimpuls-Hinterflanke ebenfalls <1us. Wenn außer TTL-Pegel keine weiteren Bedingungen gelten, ist die Aufgabe u.a., mit einem Mikrocontroller lösbar. Blackbird
Stefan ⛄ F. schrieb: > Es ging darum, dass M.n. offenbar zweifelte, dass es in den 70er Jahren > bereits RAM gab. Dieses alte Gammelzeug, ick lach mir schräg! Welche Zugriffszeit hatten die denn? 15 oder 12 ns? Und welche Hochleistungs-CPUs gab es dazu? 1 MHz Taktfrequenz oder sogar 2 MHz? Und dazu noch ein 2708? Stefan ⛄ F. schrieb: > Leider fehlen uns immer noch die Anforderungen, deswegen kann man den > Vorschlag mit der höheren Taktfrequenz nicht bewerten. Was willst Du denn groß bewerten? Frag den TO doch besser, wie er die 625 HCT164 angesteuert hat? Wurde auch der Takt passend verzögert? Welche zusätzliche Verzögerung ergibt sich durch nicht berücksichtigte Durchlaufzeiten? HildeK schrieb: > Tja, da war ich wohl zu unüberlegt. Das ist doch überhaupt nicht schlimm. In der Regel hast Du ja konstruktive Vorschläge.
m.n. schrieb: > HildeK schrieb: >> Tja, da war ich wohl zu unüberlegt. > > Das ist doch überhaupt nicht schlimm. In der Regel hast Du ja > konstruktive Vorschläge. Oh, ein Lob 😀. In der Regel hoffentlich ja. Falls die Aufgabenstellung ausreichend gut beschrieben ist, ist die Chance auf eine brauchbare Antwort schon mal größer. Aber es bleibt trotzdem ein Unterschied zwischen einer ersten, schnellen Lösungsidee und z.B. dem längeren Nachdenken über das Problem, wenn man ein eigenes Projekt angeht.
m.n. schrieb: > Stefan ⛄ F. schrieb: >> Es ging darum, dass M.n. offenbar zweifelte, dass es in den 70er Jahren >> bereits RAM gab. > > Dieses alte Gammelzeug, ick lach mir schräg! > Welche Zugriffszeit hatten die denn? 15 oder 12 ns? > Und welche Hochleistungs-CPUs gab es dazu? 1 MHz Taktfrequenz oder sogar > 2 MHz? Und dazu noch ein 2708? Schreib doch einfach, dass du keinerlei Ahnung von dieser Zeit hast.
H. H. schrieb: > Schreib doch einfach, dass du keinerlei Ahnung von dieser Zeit hast. Wozu? Um mir Dir und Stefan F. ein Triumvirat zu bilden? Dem TO nützt das nichts. Vergiss es, Alter! Frickelprinz schrieb: > Kann man das nicht mit einem ATtiny im 8Pin Gehäuse erschlagen? Sag mal: Suchst Du eine praktikable Lösung - dafür hast Du diverse Vorschläge bekommen - oder willst Du Dein Ansinnen ad absurdum führen?
> Es ging darum, dass M.n. offenbar zweifelte Ach so. Ich hab mich schon gewundert wieso der 1103 ploetzlich im Fokus stand. Natuerlich kann man mit dem auch einen FIFO bauen. Ob man aber 2 Zugriffe in 1 µs hinbekommt? Da muesste man wohl doch nochmal das Datenblatt konsultieren. > > Welche Zugriffszeit hatten die denn? 15 oder 12 ns? > Schreib doch einfach, dass du keinerlei Ahnung von dieser Zeit hast. ++
HildeK schrieb: > Da würde dein permanenter Wunsch in Assembler zu programmieren gut > passen, auch für die kleineren µCs: ≥ 256Byte RAM und den Shift- oder > Rotatebefehlen. Wenn du denn Thread richtig gelesen hättest, wäre dir aufgefallen, dass ich bereits einen ATtiny85 wegen RAM-Mangel abgelehnt hatte und statt dessen einen ATtiny824 vorgeschlagen hatte, eben weil der genug RAM für die Aufgabe hat. Weiterhin wäre dir aufgefallen, dass ich bei dem Programmaufwand schon rein zeilenzahlmäßig den Schwerpunkt auf SPI gelegt habe. Womit sich deine idiotischen Spekulationen über Shift- oder Rotate-Befehle auch in Luft auflösen. Sprich: Lerne Lesen. Dann erst Schreiben.
> Wie groß ist denn die Datenrate des Eingangssignals?
Als Erfahrungswert aus der Praxis: Man kann man ein asynchrones
Datensignal mit 9600 Baud "unfallfrei" ueber eine 64k synchrone
Standleitung uebertragen. Mehr als Pegelwandler von RS-232
zu z.B. X.21 braucht es dabei nicht.
Bei 1 MHz wuerde es dann eine 115200 Baud Nachricht schaffen.
Aber keine Ahnung was der TO da durchschiebt :).
Beitrag "Re: Schieberegister ersetzen" Hier die Software dazu, sollte funktionieren. Wenn es keinen externen 1 MHz Takt gibt, kann man an Pin 15 (PB1/OCR1A) einen 1 MHz Takt abgreifen.
1 | #include <avr/io.h> |
2 | |
3 | #define F_CPU 8000000
|
4 | #define FIFO_SIZE 622 // FIFO size in bytes, total delay is FIFO_SIZE+3
|
5 | |
6 | uint8_t fifo[FIFO_SIZE]; |
7 | |
8 | int main(void) { |
9 | int i; |
10 | uint8_t din; |
11 | |
12 | DDRB = (1<<PB1); // OCR1A, aux clock output |
13 | DDRD = 0xFF; // output data |
14 | i=0; |
15 | |
16 | // init timer 1, mode 14, Fast PWM, ICR1
|
17 | // prescaler 1
|
18 | // generate 1 MHz aux clock on OCR1A
|
19 | |
20 | TCCR1A = (1<<COM1A1) | (1<<WGM11); |
21 | TCCR1B = (1<<WGM12) | (1<<WGM13) | (1<<CS10); |
22 | ICR1 = 7; |
23 | OCR1A = 3; |
24 | |
25 | while(1) { |
26 | while(!(PINB & (1<<PB0)) ); // wait for sync |
27 | din = (PINC & 0x3F) | (PINB & 0xC0); |
28 | fifo[i++] = din; |
29 | if (i == FIFO_SIZE) i=0; |
30 | PORTD = fifo[i]; |
31 | }
|
32 | }
|
PB1 ist ORC1A out, wartest aber auf PB0? Sollte, nach erfolgtem sync die Die schleife nur einmal laufen? Müsste man While(1) dann nicht auf LOW Pegle am sync-Pin abfragen? Fällt mir so auf und ich frag einfach mal.
1 | while((PINB & (1<<PB1))) { |
2 | while(!(PINB & (1<<PB1)) ); // wait for sync |
3 | din = (PINC & 0x3F) | (PINB & 0xC0); |
4 | fifo[i++] = din; |
5 | if (i == FIFO_SIZE) i=0; |
6 | PORTD = fifo[i]; |
7 | }
|
So, dachte ich.
1 | while(1) { |
2 | while(PINB & (1<<PB1)); // wait for sync |
3 | while(!(PINB & (1<<PB1)) ); // wait for sync |
4 | din = (PINC & 0x3F) | (PINB & 0xC0); |
5 | fifo[i++] = din; |
6 | if (i == FIFO_SIZE) i=0; |
7 | PORTD = fifo[i]; |
8 | }
|
oder eher so, (sry)
:
Bearbeitet durch User
Na jedenfalls, das bei fallender Flanke des 1Mhz Taktes die wile Schleife genau einmal durchläuft und nicht bei LOW-Pegel die Schleife, sooft sie es eben schafft und bei H-Pegel nix macht. Oder liege ich da falsch, sowas wir Flanken oder LoW-Level-gesteuert. Weiss wer, was ich meine? ;)
Axel R. schrieb: > PB1 ist ORC1A out, wartest aber auf PB0? Ja sicher. > Sollte, nach erfolgtem sync die Die schleife nur einmal laufen? Ja. > Müsste man While(1) dann nicht auf LOW Pegle am sync-Pin abfragen? Nö. Der Sync kommt von IC4, der ist HIGH aktiv (1 aus 10 Dekoder). Die Schaltung ist ja eigentlich auf einen externen 1MHz Takt ausgelegt. Daß der Datenstrom NICHT synchron zum 1 MHz Takt ist, wurde erst später bekannt. Darum der Hilfstakt von 1 MHz an PB1.
Falk B. schrieb: > Der Sync kommt von IC4, der ist HIGH aktiv Und es ist ausgeschlossen, dass PB0 immer noch HIGH ist, nachdem die Schleife durchlaufen wurde und er das nächste Mal abgefragt wird? Ich denke, Axel hat schon recht, dass man erst auf LOW und dann auf HIGH warten muss, um sicher zu stellen, dass der Body nur einmal bei steigender Flanke ausgeführt wird, und nicht wieder und wieder, solange der HIGH-Pegel ansteht.
:
Bearbeitet durch User
R. M. schrieb: > Falk B. schrieb: >> Der Sync kommt von IC4, der ist HIGH aktiv > > Und es ist ausgeschlossen, dass PB0 immer noch HIGH ist, nachdem die > Schleife durchlaufen wurde und er das nächste Mal abgefragt wird? Ja, denn das Signal bleibt nur 1us high, wird ja vom 1MHz Eingangstakt geschaltet. Die Schleife braucht ca. 30 Takte bei 8 MHz. Der Schieberegisterzyklus dauert 8 Takte @1MHz = 8us = 64 Takte @ 8MHz. > Ich denke, Axel hat schon recht, dass man erst auf LOW und dann auf HIGH > warten muss, um sicher zu stellen, dass der Body nur einmal bei > steigender Flanke ausgeführt wird, und nicht wieder und wieder, solange > der HIGH-Pegel ansteht. Nö, wenn man die restlichen Zeiten sicher kennt.
Hier die Eagledateien incl. Layout. 80x60mm^2 und alles in bastlerfreundlichen DIL-Gehäusen, was will man mehr? J1 ist optional.
Falk B. schrieb: > Hier die Eagledateien incl. Layout. 80x60mm^2 und alles in > bastlerfreundlichen DIL-Gehäusen, was will man mehr? J1 ist optional. > (https://www.mikrocontroller.net/attachment/564173/FIFO_1MHz_Layout.pdf) Falk... hast Du etwa einfach den Autorouter angeworfen ohne vor-/nachzuarbeiten (GND/VCC)? Schäm Dich! :D
Magnus M. schrieb: > Falk... hast Du etwa einfach den Autorouter angeworfen ohne > vor-/nachzuarbeiten (GND/VCC)? > > Schäm Dich! Geht's noch? Schau mal in die Eagle Datei und markiere GND und +5V. Nur weil +5V und GND nicht komplett parallel geführt sind, heißt das nicht, daß alles Mist ist. Wichtig ist die kurze Anbindung der Abblockkondensatoren, und die ist gegeben. Es gibt auch, oh Schreck, keine Massefläche! 8-0 Aber die ist bei der Schaltung überaus entbehrlich.
:
Bearbeitet durch User
Falk B. schrieb: >>> 8-0 >> Was bedeutet das? > https://en.wikipedia.org/wiki/List_of_emoticons Danke
Dieses Gebastel mit dünnsten Leiterbahnen und Platinenätzerei muß nun wirklich nicht sein. Wie oben angedeutet, kann man ein fertiges Pico-Board mit RP2040 nehmen und ein einfaches Arduino-Programm draufspielen. Der RP2040 ist so schnell, daß dieses simple delayMicroseconds() vielleicht schon reicht. Abhängig, ob man externen Takt oder genaues internes Timing verwenden möchte, kann man die Flankenerkennung bzw. Timerinitialisierung noch ergänzen. Da ich dieses Arduino-Zeugs schrecklich finde, habe es nicht getestet. Der TO könnte auch selber noch etwas beitragen.
Falk B. schrieb: > Hier die Software dazu, 1MHz per Timer zu erzeugen damit man es als SCK verwenden könnte ist schick, aber gab es nicht eine Lösung mit dem AVR als SPI Slave ohne weitere Hardware ?
1 | int n=0; |
2 | uint8_t fifo[625]; |
3 | DDRB=(1<<PB1); // OCR1A, aux clock output |
4 | TCCR1A =(1<<COM1A1)|(1<<WGM11); |
5 | TCCR1B =(1<<WGM12)|(1<<WGM13) | (1<<CS10); |
6 | ICR1=7; // je nach Quartz |
7 | OCR1A=3; |
8 | pinMode(MISO,OUTPUT); |
9 | // CPOL und CPHA nach Wunsch setzen
|
10 | SPCR|=(1<<SPE); |
11 | data[n]=SPSR; |
12 | data[n]=SPDR; |
13 | while(1) |
14 | {
|
15 | while(!(SPSR&(1<<SPI))) ; |
16 | data[n++]=SPDR; |
17 | if(n>624) n=0; |
18 | SPDR=data[n]; |
19 | }
|
sollte ausreichen und gehen.
MaWin schrieb: > sollte ausreichen und gehen. Vielleicht. Vielleicht auch nicht. Denn das SPI arbeitet nicht lückenlos, selbst mit taktgenau optimiertem Assembler. Damit gibt es zumindest zusätzlichen Jitter bei der Abtastung. Ob der kritisch ist, weiß ich nicht. GGf. könnte man den UART im SPI Mode laufen lassen, der ist dann in beide Richtungen doppelt gepuffert und kann damit lückenlos arbeiten.
MaWin schrieb: > aber gab es nicht eine Lösung mit dem AVR als SPI Slave ohne > weitere Hardware ? Das Problem ist, daß die meisten AVRs nur ein Geizhals-SPI haben ohne Sendepuffer. Es könnte vielleicht klappen, wenn man die Sendedaten schon in ein Register legt und direkt nach dem Ready-Bit abfragen rauspustet. Ein AVR mit 20MHz hätte dann dafür 10 Zyklen Zeit. Falls der AVR die 1MHz selber erzeugen darf, ginge auch die UART als gepufferter SPI-Master (ATmega88).
Ich würde ein kleines MachXO2 nehmen (das kleinste reicht aus) und vorn und hinten einen Pegelwandler dran schnallen. Ergebnis: absolut taktsynchron... ;-) Und die VHDL-Beschreibung? Gade mal 14 Zeilen:
1 | library IEEE; |
2 | use IEEE.STD_LOGIC_1164.ALL; |
3 | |
4 | entity sr5ms is |
5 | port( signal clk, inp : in std_logic; |
6 | signal outp : out std_logic); |
7 | end sr5ms; |
8 | |
9 | architecture Behave of sr5ms is |
10 | signal sr : std_logic_vector (4999 downto 0) := (others=>'0'); |
11 | begin
|
12 | sr <= sr(4998 downto 0) & inp when rising_edge(clk); |
13 | outp <= sr(4999); |
14 | end; |
Lothar M. schrieb: > Ich würde ein kleines MachXO2 nehmen (das kleinste reicht aus) und vorn > und hinten einen Pegelwandler dran schnallen. Ergebnis: absolut > taktsynchron... ;-) Is ja Schmuuuuuu!!! ;-)
Falk B. schrieb: > Vielleicht auch nicht. Denn das SPI arbeitet nicht > lückenlos, selbst mit taktgenau optimiertem Assembler. Genau. Bei denn ollen AVRs kann man das SPI knicken. Es ist nicht in der Lage, "lückenlos" mit Vmax zu agieren. Das klappt allenfalls als Master und dann auch nur bei Nutzung der USARTs im SPI-Master-Modus, nicht aber bei Nutzung der eigentlichen SPI-Hardware. Aber mein Vorschlag für den ATtiny824 kam natürlich nicht aus der Hüfte, sondern nach Durchdenken des Problems. Besagter Tiny hat nämlich (neben genug RAM) auch das neuzeitliche SPI (was endlich so ist, wie es eigentlich schon immer hätte sein müssen). Sprich: mindestens double buffered für Senden und Empfangen. Und damit ist dann die Aufgabe ein Witz, der sich halt in 40 Zeilen Asm (oder meinetwegen auch in 25 Zeilen C) abhandeln läßt.
> Lothar M. schrieb: >> Ich würde ein kleines MachXO2 nehmen > Was kostet der Programmer dafür? Den hat man doch ohnehin.
Rente mit 76 schrieb: >> Lothar M. schrieb: >>> Ich würde ein kleines MachXO2 nehmen >> Was kostet der Programmer dafür? > > Den hat man doch ohnehin. So wie andere 625St 74HC164.
c-hater schrieb: > Falk B. schrieb: > >> Vielleicht auch nicht. Denn das SPI arbeitet nicht >> lückenlos, selbst mit taktgenau optimiertem Assembler. > > Genau. Bei denn ollen AVRs kann man das SPI knicken. Jaja, das übliche Gelaber. Für 99% aller Anwendungen muss der SPI-Takt nicht lückenlos sein. Und selbst für solche Tricks wie ein VGA-Terminal ist es gut genug!
Falk B. schrieb: > Jaja, das übliche Gelaber. Für 99% aller Anwendungen muss der SPI-Takt > nicht lückenlos sein. Na ja, es geht nicht um den Takt, der kommt eh extern und nur hilfsweise als intern erzeugte 1MHz, sondern das Datensignal, es kommt ein Byte rein, löst einen Interrupt aus, und bevor der nächste Takt kommt muss das Byte ausgelesen werden und das demnächst rauszuschiebende Byte reingeschrieben werden. Aber es sollte in diesem Anwendungsfall auch mit dem alten SPI ohne Buffer funktionieren, im Gegenteil, das macht die Latency-Berechnung vielleicht einfacher
Falk B. schrieb: > Jaja, das übliche Gelaber. Für 99% aller Anwendungen muss der SPI-Takt > nicht lückenlos sein. Und selbst für solche Tricks wie ein VGA-Terminal > ist es gut genug! Hier haben wir aber nunmal eine Anwendung, wo er es sein müsste... Selbst bezüglich des VGA-Terminal ist deine Aussage übrigens nicht korrekt. Allenfalls wenn man VGA auf einen kleinen Subset reduziert, nämlich einige Textmodi... Hier kann man die SPI-Lücke eben einfach so legen, dass der VGA-Peer an der entsprechenden Stelle sowieso kein Bildaten erwartet, weil von vornherein feststeht, dass hier eine Leerspalte zu erscheinen hat. Nur dadurch wird das möglich. Sprich: du hast noch sehr viel zu lernen, bevor du mit mir auf meinem Niveau diskutieren kannst...
MaWin schrieb: > Aber es sollte in diesem Anwendungsfall auch mit dem alten SPI ohne > Buffer funktionieren Nein, tut es nicht. Du kannst mit dem SPI der klassischen AVR keinen kontinuierlichen seriellen Datenstrom schreiben. Oder gar lesen. No way. Gibt die Hardware einfach nicht her.
Lothar M. schrieb: > Ich würde ein kleines MachXO2 nehmen (das kleinste reicht aus) und vorn > und hinten einen Pegelwandler dran schnallen. Na ja, da fehlt jetzt nur noch das Layout. Zeig mal ;-) Lothar M. schrieb: > absolut taktsynchron... ;-) Was immer das heißen mag ...
m.n. schrieb: > Na ja, da fehlt jetzt nur noch das Layout. Zeig mal ;-) Nimm den im 25-ball WLCSP (2.5 x 2.5 mm).
Peter D. schrieb: > Nimm den im 25-ball WLCSP (2.5 x 2.5 mm). Nicht schlecht! Da kann mit mit einem Tropfen Lötzinn alle Pins miteinander verbinden. Absolut synchron!
c-hater schrieb: > Sprich: du hast noch sehr viel zu lernen, bevor du mit mir auf meinem > Niveau diskutieren kannst... Ich bin UNWÜRDIG, Ohhh Meister!!!! (Leute gibt's)
c-hater schrieb: > Nein, tut es nicht. Du kannst mit dem SPI der klassischen AVR keinen > kontinuierlichen seriellen Datenstrom schreiben. Oder gar lesen. No way. > Gibt die Hardware einfach nicht her. Ich hab's noch nicht gemacht, aber see da kein Problem The system is single buffered in the transmit direction and double buffered in the receive direction. This influences the data handling in the following ways: 1. New bytes to be sent cannot be written to the data register (SPDR) / shift register before the entire shift cycle is completed. 2. Received bytes are written to the Receive Buffer immediately after the transmission is completed. 3. The Receive Buffer has to be read before the next transmission is completed or data will be lost. 4. Reading the SPDR will return the data of the Receive Buffer. After a transfer is completed the SPI Interrupt Flag (SPIF) will be set in the SPI Status Register (SPSR). This will cause the corresponding interrupt to be executed if this interrupt and the global interrupts are enabled. Setting the SPI Interrupt Enable (SPIE) bit in the SP aus https://ww1.microchip.com/downloads/en/Appnotes/Atmel-2585-Setup-and-Use-of-the-SPI_ApplicationNote_AVR151.pdf
Beitrag #7134790 wurde von einem Moderator gelöscht.
Beitrag #7134792 wurde von einem Moderator gelöscht.
Beitrag #7134852 wurde von einem Moderator gelöscht.
Beitrag #7134867 wurde von einem Moderator gelöscht.
Peter D. schrieb: > Lothar M. schrieb: >> Ich würde ein kleines MachXO2 nehmen > Was kostet der Programmer dafür? Um die 20€. Und wenn man das FPGA-Zeugs mal kapiert hat, dann findet man laufend Anwendungen dafür. m.n. schrieb: > Lothar M. schrieb: >> Ich würde ein kleines MachXO2 nehmen (das kleinste reicht aus) und vorn >> und hinten einen Pegelwandler dran schnallen. > Na ja, da fehlt jetzt nur noch das Layout. Zeig mal ;-) Ja, wenns sein muss, dann fädle ich das dead bug mäßig mit dem kopfüber gelegten QFP. Sind ja nur ein paar Pins nötig. Aber es muss ja nicht sein, denn es gibt ja die geschickten Breakout-Platinchen für fast jedes Gehäuse. > Lothar M. schrieb: >> absolut taktsynchron... ;-) > Was immer das heißen mag ... Da war die Rede von einem 1MHz Takt. Aber wenns nicht aufs ppm ankommt, dann kann man auch den internen Oszillator des MAchXO nehmen. Falls sich jemand fragt, was da gelöscht wurde: es war nur unsachliches und unflätiges Zeug. Schade um den Speicherplatz...
Lothar M. schrieb: > Um die 20€. Und wenn man das FPGA-Zeugs mal kapiert hat, dann findet man > laufend Anwendungen dafür. Sicher nicht schlecht, wenn man es braucht und verstanden hat ;-) Lothar M. schrieb: > denn es gibt ja die geschickten Breakout-Platinchen Darum hatte ich ja den RP2040 vorgeschlagen. Da kostet die fertige "Baugruppe" keine fünf Euro, ist gut verfügbar und kann im 1/10" bequem verdrahtet/versteckbrettet werden. Zwar nicht so elegant wie Dein FPGA-Programm, können auch da die IO-Pins mit hohem Takt schnell wackeln. Egal, der TO ist wohl auch damit überfordert.
Lothar M. schrieb: > Falls sich jemand fragt, was da gelöscht wurde: es war nur unsachliches > und unflätiges Zeug. Schade um den Speicherplatz... Das magst du so sehen. Andere sehen das anders. Bedauernswert ist höchstens die Eskalation. Aber: das, was wirklich an Fakten da war, hast du ja nicht "weggemoddet". Also sehe ich hier durchaus den Willen, bei aller Löscherei wenigstens die Fakten zu retten. Und die sprechen für sich selbst. Leider aber eben nur für kompetente Leser. Der Rest kann das nicht unbedingt erkennen, würde aber bei der Lektüre der weggelöschten Postings vielleicht zumindest nachdenklich werden... Auch "Unflat" könnte hier einen Nutzen haben...
Angehängte Dateien:
-
Delay_5ms.png
2 KB -
Delay_Zoom.png
2,1 KB -
CLK_1MHz.png
1,9 KB
Auch wenn es keine Raketenwissenschaft ist, hier die Software für die Einchiplösung mittels AVR, getestet mit Arduino Uno/ATmega 328P. Daten in PD0(TXD0) rein und an PD1(TXD0) verzögert raus. Es sind auch fast exakt 5ms, naja, 5,004 wenn mein Oszi richtig mißt. Anbei die Bilder. Kanal 1 ist der Eingang, Kanal 2 der verzögerte Ausgang. Auf dem 3. Bild sieht man den lückenlosen SPI Takt an PD4.
1 | #include <avr/io.h> |
2 | |
3 | #define F_CPU 16000000
|
4 | #define BAUD0 1000000
|
5 | |
6 | // USART in SPI Mode
|
7 | #define UBRR0_VAL ((F_CPU+BAUD0)/(BAUD0*2)-1)
|
8 | #define BAUD0_REAL (F_CPU/(2*(UBRR0_VAL+1)))
|
9 | #define BAUD0_ERROR ((BAUD0_REAL*1000)/BAUD0-1000)
|
10 | |
11 | #if ((BAUD0_ERROR>10) || (BAUD0_ERROR<-10))
|
12 | #error Systematic baud error above 1% which is too high!
|
13 | #endif
|
14 | |
15 | #define FIFO_SIZE 625 // FIFO size in bytes, total delay FIFO_SIZE * 8 * 1/BAUD0
|
16 | |
17 | uint8_t fifo[FIFO_SIZE]; |
18 | |
19 | int main(void) { |
20 | int i; |
21 | uint8_t din; |
22 | |
23 | DDRB = (1<<PB1); // for TEST only, OC1A, 33Hz test signal |
24 | DDRD = (1<<PD4) | (1<<PD1); // TXD0, XCK0 |
25 | i=0; |
26 | |
27 | // for TEST only
|
28 | // init timer 1, mode 14, Fast PWM, ICR1
|
29 | // prescaler 8
|
30 | // generate test signal on OCR1A
|
31 | |
32 | TCCR1A = (1<<COM1A1) | (1<<WGM11); |
33 | TCCR1B = (1<<WGM12) | (1<<WGM13) | (1<<CS11); |
34 | ICR1 = 60000; |
35 | OCR1A = 30000; |
36 | |
37 | // init USART#0 in SPI mode
|
38 | |
39 | UCSR0B = (1<<RXEN0) | (1<<TXEN0); |
40 | UCSR0C = (1<<UMSEL01) | (1<<UMSEL00); |
41 | UBRR0H = UBRR0_VAL >> 8; |
42 | UBRR0L = UBRR0_VAL; |
43 | |
44 | while(1) { |
45 | while( !(UCSR0A & (1<<UDRE0)) ); // wait for free tx buffer |
46 | din = UDR0; |
47 | fifo[i++] = din; |
48 | if (i == FIFO_SIZE) i=0; |
49 | UDR0 = fifo[i]; |
50 | }
|
51 | }
|
Frickelprinz schrieb: > Da ist eine kuchenblechgroße Platine mit 625 x 74HCT164 SMD. Das sind 8 > Bit Schieberegister, Eine solche Anforderungen wurde bei einem Kunden mal mit einer Reihe von Spartan 3A-FPGAs gelöst. Allerdings auch deshalb, weil es ein kompliziertes Protokoll gab und die noch etwas mehr tun mussten, als nur schieben. Der Preis der FPGAs lag damals UNTER dem Equivalent derselben Zahl von Schieberegister-ELementen.
Jürgen S. schrieb: > Der Preis der FPGAs lag damals UNTER dem Equivalent derselben Zahl von > Schieberegister-ELementen. Geiz. Damals. Heute hingegen "gibt es das FPGA nicht mehr, während er die 164 fast gratis kriegt". So kann man sich mit zu esoterischen Bausteinen in der Zeit der Chipknappheit auch ins Knie schiessen.
MaWin schrieb: > Jürgen S. schrieb: >> Der Preis der FPGAs lag damals UNTER dem Equivalent derselben Zahl von >> Schieberegister-ELementen. > > Geiz. > > Damals. > > Heute hingegen "gibt es das FPGA nicht mehr, während er die 164 fast > gratis kriegt". > > So kann man sich mit zu esoterischen Bausteinen in der Zeit der > Chipknappheit auch ins Knie schiessen. Hmmm, ein ECHTER MaWin aus dem Lehrbuch, der schon vor 20 Jahren alle moderen Digital-ICs gehaßt hat. Du nutzt doch sicher eine PDP-11, um deine Beiträge hier zu verfassen, nicht?
Andrea B. schrieb: > Dual-Port-Ram + Zähler + ein paar Inverter könnten auch reichen. Sind aber deutlich aufwändiger als ein IC . . . .
Falk B. schrieb: > // USART in SPI Mode Du schummelst. Das ist eben nicht die normale SPI-Einheit. > Auf dem 3. Bild sieht man den lückenlosen SPI Takt an PD4. Denn genau das ist mit der nicht möglich. Dass es mit USART im SPI-Mode geht, hatte ich bereits hier: Beitrag "Re: Schieberegister ersetzen" erwähnt.
Von allen möglichen Lösungen muss unbedingt die schlechteste gewählt werden. Mit ungeeigneten Bauteilen.
:
Wiederhergestellt durch Moderator
Rente mit 76 schrieb: > Von allen möglichen Lösungen muss unbedingt die schlechteste gewählt > werden. Mit ungeeigneten Bauteilen. Derart sinnlose Kommentare kommen immer anonym. Offenbar schämst du dich dafür. Gut so.
:
Wiederhergestellt durch Moderator
Nein, ich schäme mich nicht, warum auch?. Ein Controller muss mit viel Trickserei zur gewünschten Funktion gebracht werden. Lothars 12 Zeilen weisen doch den richtigen Weg. Klar, einfach und ohne Handstände. Ich gehe davon aus, dass es hier am Verständnis von ein paar VHDL-Zeilen hapert.
c-hater schrieb: > Nein, tut es nicht. Du kannst mit dem SPI der klassischen AVR keinen > kontinuierlichen seriellen Datenstrom schreiben. Würde es gehen, wenn der SPI im Slave-Mode läuft und ein Timer vom AVR die 1 MHz erzeugt und man dessen Ouput-Pin mit dem SPI-Clock des AVR verbindet? Dann wäre der Takt doch starr, und der AVR müsste nur schnell genug zum richtigen Zeitpunkt in das Transfer-Register schreiben. Wenn das nicht funktionieren würde, könnte man den AVR ja niemals als SPI-Slave verwenden, oder?
Stefan ⛄ F. schrieb: > Rente mit 76 schrieb: >> Von allen möglichen Lösungen muss unbedingt die schlechteste gewählt >> werden. Mit ungeeigneten Bauteilen. > > Derart sinnlose Kommentare kommen immer anonym. Offenbar schämst du dich > dafür. Gut so. Du solltest Dir Deinen missionarischen Eifer für die Elektronik aufheben. Dort ist er von viel höherem Nutzen als das hiesige Windmühlenflügel-Bekämpfen.
Falk B. schrieb: > Hmmm, ein ECHTER MaWin aus dem Lehrbuch, der schon vor 20 Jahren alle > moderen Digital-ICs gehaßt hat. So so. http://www.armory.com/~rstevew/Public/Pgmrs/GAL/_ClikMe1st.htm
Lothar M. schrieb: > Ich würde ein kleines MachXO2 nehmen (das kleinste reicht aus) Hmmm. https://www.latticesemi.com/Products/FPGAandCPLD/MachXO2 Der kleinste ist der XO2-256, der hat keine EBR RAM Blocks und nur 2kbit distributed RAM, das geht schon rein numerisch nicht. In der Doku habe ich nichts gefunden, was dessen Nutzung als Schieberegister erlaubt, so wie es die Xilinx-FPGAs können mit den SRL16. Der kleinste XC3S50AN hätte genügend und hätte auch seinen Config Flash on board. Ok, im "Memory Usage Guide for MachXO2 Devices" gibt es wohl auch eine Möglichkeit, mittels "IPexpress Flow" ein Schieberegister zu erzeugen, was dann aber über distributed RAM + Zusatzlogik zusammengebaut wird. Geht schon, schafft der VHDL-Compiler aber vermutlich nicht automatisch.
MaWin schrieb: >> Hmmm, ein ECHTER MaWin aus dem Lehrbuch, der schon vor 20 Jahren alle >> moderen Digital-ICs gehaßt hat. > > So so. > > http://www.armory.com/~rstevew/Public/Pgmrs/GAL/_ClikMe1st.htm Besser kann man es nicht beweisen ;-) Auch 1998 waren GALs schon alt wie der Wald und moderne CPLDs und FPGAs ziemlich weit verbreitet, wenn gleich nicht unter Bastlern. Aber auch das kam SEHR schnell anfang der 2000er Jahre. Aber was soll, diese sinnlose Diskussion hatten wir schon VOR 2000 in de.sci.electronics.
Rente mit 76 schrieb: > Ein Controller muss mit viel Trickserei zur gewünschten Funktion > gebracht werden. Das stimmt doch garnicht! > Lothars 12 Zeilen weisen doch den richtigen Weg. Wenn man sich Lieferzeit (derzeit wohl unendlich), Preis + Lieferzeit für ein breakout-Board und Zeit für die Einarbeitung ansieht, merkt man schnell, daß der "richtige Weg" eine Sackgasse ist. MaWin schrieb: > http://www.armory.com/~rstevew/Public/Pgmrs/GAL/_ClikMe1st.htm Einen Link auf den eigenen Text zu setzen, ist ein ganz schlechtes Argument! Was sagte mal Jürgen Manger sinngemäß: "Dem Erwin habe ich den Hergang des Unfalls so genau erzählt - der kann das jetzt bezeugen."
> Wenn man sich Lieferzeit (derzeit wohl unendlich), Preis + Lieferzeit > für ein breakout-Board und Zeit für die Einarbeitung ansieht, merkt man > schnell, daß der "richtige Weg" eine Sackgasse ist. Das ist alles eine Frage des Standpunktes: für den Neueinsteiger gilt das mit dem Controller genau in gleicher Weise. Für mich es einfach: bei mir liegen sowohl Lattice- als auch Xilinxschaltkreise in ausreichender Menge auf Lager. Irgendeine ebenfalls vorhandene Leiterplatte aus der normalen Produktion bekommt einen zusätzlichen Ein- und Ausgangsdraht... Die Vorteile des FPGA: absolute Passgenauigkeit zu den Anforderungen, andere Taktfrequenzen können einfach angepasst werden. Das ist keine Sackgasse, sondern einfach geistige Trägheit bzw. Verfettung. Mit VHDL hättest du dich ja schon längst mal vertraut machen können. Es ist aber wie in der Autoindustrie: wir machen lieber das, was wir immer schon gemacht haben und wundern uns am Ende, dass wir wieder alles verschlafen haben.
Beitrag #7136912 wurde von einem Moderator gelöscht.
Beitrag #7136924 wurde von einem Moderator gelöscht.
Beitrag #7136930 wurde von einem Moderator gelöscht.
Beitrag #7136943 wurde von einem Moderator gelöscht.
Beitrag #7136946 wurde von einem Moderator gelöscht.
Falk B. schrieb: > Der kleinste ist der XO2-256, Stimmt, der ist zu klein, ein 640er sollte es schon sein. > Geht schon, schafft der VHDL-Compiler aber vermutlich nicht automatisch. Das Design ging für einen 640er ohne Fehlermeldung durch den Synthesizer. Der Ressourcenvetbrauch ist plausibel. m.n. schrieb: >> Lothars 12 Zeilen weisen doch den richtigen Weg. > Wenn man sich Lieferzeit (derzeit wohl unendlich), Preis + Lieferzeit > für ein breakout-Board und Zeit für die Einarbeitung ansieht, merkt man > schnell, daß der "richtige Weg" eine Sackgasse ist Nur mal angenommen, das träfe für die uC-Lösung auch zu... Wenn der TO weder uC noch FPGA kann, dann ist er mit dem FPGA schneller am Ziel. Denn ich weiß schon jetzt (ohne ihn je implementiert zu haben) absolut sicher, dass dieser Zwölfzeiler garantiert so funktionieren wird wie ich es erwarte. Denn es gibt in FPGAs nichts Einfacheres als ein Schieberegister. Und der Witz: der Zwölfzeiler lässt sich nicht nur auf einem Lattice-FPGA implementieren, nein das geht auch auf einem Xilinx, Efinix, Intel, oder sonst irgendeinem FPGA. BTW: was da gelöscht wurde, trug nichts zur Sache bei, es war nur unnötiger Hickhack. BTW2: lassen wir doch den TO entscheiden, welcher Weg ihm der liebste ist.
:
Bearbeitet durch Moderator
Rente mit 76 schrieb: > Die Vorteile des FPGA: absolute Passgenauigkeit zu den Anforderungen, > andere Taktfrequenzen können einfach angepasst werden. > Das ist keine Sackgasse, sondern einfach geistige Trägheit bzw. > Verfettung. > Mit VHDL hättest du dich ja schon längst mal vertraut machen können. Wenn Du mich persönlich meinst, da kennst Du meine Anforderungen garnicht geschweige denn die passgenaue Lösung. Und was ich bislang mit PALs, GALs und FPGAs gemacht habe, weist Du auch nicht. Was Lothar da oben geschrieben hat, kann man auch nachvollziehen, ohne explizit mit VHDL etwas zu tun zu haben. Es nützt aber nur demjenigen, der, wie Du selber schreibst, die Sachen schon auf dem Tisch zu liegen hat. Den oben erwähnten Programmer für 20 € finde ich bei keinem seriösen Händler. Ein breakout-Board zu > 80 € ist nicht lieferbar. Die ICs selber sind derzeit nicht verfügbar. Sie arbeiten mit 1,8 V, weshalb sie ohne Pegelwandler nicht einsetzbar sind. Bei der Auswahl muß man aufpassen, nicht gerade ein BGA-Gehäuse zu erwischen. Das findest Du jetzt alles gut? Wie gezeigt gibt es Lösungen mit einem AVR (5 V und DIL-Gehäuse). Mein "Programmvorschlag" auf einem RP2040 (ebenfalls steckbar und in Stückzahlen erhältlich) läuft sogar mit diesem dämlichen Arduino-Zeugs, ohne daß man wissen muß, was dabei passiert und daß das Programm 58 kB groß ist (Kopfkratz).
Shifter schrieb: > Wie wäre es wenn der TO ein Foto der Platine machen würde? Geht nicht, das war doch nur ein Hoax.
m.n. schrieb: > Den oben erwähnten Programmer für 20 € finde ich bei keinem seriösen > Händler. Ein breakout-Board zu > 80 € ist nicht lieferbar. Die ICs > selber sind derzeit nicht verfügbar. Sie arbeiten mit 1,8 V, weshalb sie > ohne Pegelwandler nicht einsetzbar sind. Wer etwas nicht machen will findet Ausreden, wer es tun will einen Weg. m.n. schrieb: > Wie gezeigt gibt es Lösungen mit einem AVR (5 V und DIL-Gehäuse). Schon die ursprüngliche Leiterplatte war in SMD. Warum sollte jetzt jemand wieder bedrahtete Bauteile wollen. Und genausowenig kommen die 5V vom TO. Wenn die Platine in den letzten 25 Jahren entstanden ist, dann können das auch locker 3,3V sein...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und auch die 5V kommen nicht vom TO. > > Wenn die Platine in den letzten 25 Jahren entstanden ist, dann können > das auch locker 3,3V sein... Frickelprinz schrieb: > 74HCT164 Die betreibt man nicht mit 3,3V.
Lothar M. schrieb: > Wer etwas nicht machen will findet Ausreden, wer es tun will einen Weg. Und wer nur maulen will drischt hohle Phrasen.
H. H. schrieb: > Frickelprinz schrieb: >> 74HCT164 > Die betreibt man nicht mit 3,3V. Stimmt. Also stimme ich der Mehrheit zu: das mit dem FPGA ist keine gute Idee. Das sollten nur die machen, die es bereits können und die Bauteile zur Hand haben. Percy N. schrieb: > Und wer nur maulen will drischt hohle Phrasen. qed
:
Bearbeitet durch Moderator
Lothar M. schrieb: > das mit dem FPGA ist keine gute > Idee. Das sollten nur die machen, die es bereits können und die Bauteile > zur Hand haben. Grundsätzlich ist es schon eine gute Idee, denn FPGAs sind die Bauteile, bei denen es an Flipflops nicht mangelt, ebenso wie bei den großen CPLDs. Aber bei beiden gilt: man muss sie programmieren können; nicht nur den passenden Programmer haben sondern auch die Sprache beherrschen. Das gilt natürlich auch für die µC mit der Softwarelösung. Wobei: in manchen Firmenphilosophien sollen Softwarelösungen vermieden werden (Upgrade, ggf. remote) während programmierbare Hardware kein Problem darstellte.
HildeK schrieb: > Lothar M. schrieb: >> das mit dem FPGA ist keine gute >> Idee. Das sollten nur die machen, die es bereits können und die Bauteile >> zur Hand haben. > > Grundsätzlich ist es schon eine gute Idee, denn FPGAs sind die Bauteile, > bei denen es an Flipflops nicht mangelt, ebenso wie bei den großen > CPLDs. Er dreht seine Fahne doch nach dem Wind. Mal ja, mal nein, da kann man nicht diskutieren. Auch, daß derzeit die benötigte Hardware zu angemessenen Preisen nicht verfügbar ist, wird gerne ignoriert.
> Auch, daß derzeit die benötigte Hardware zu angemessenen Preisen nicht > verfügbar ist, wird gerne ignoriert. Ich könnte dir einen LCMXO2-1200HC-4TG100C spenden. Der braucht auch nur eine einzige Spannung: 3,3 V. Ist dir aber wahrscheinlich zu neumodisch. Porto bezahle ich auch, aber höre bitte mit deinem Wehklagen auf. Vllt findet sich noch jmd, der für lau einen passenden Programmer loswerden will.
HildeK schrieb: > Grundsätzlich ist es schon eine gute Idee, denn FPGAs sind die Bauteile, > bei denen es an Flipflops nicht mangelt, ebenso wie bei den großen > CPLDs. Das blöde ist halt, dass FPGA Hersteller keinerlei Augenmerk auf klein und billig legen. Im Gegenteil, lange war externes EEPROM und externer Takt notwendig. Wir brauchen hier ein IC mit 4 Anschlüssen, VCC, GND, DIN und DOUT, eventuell externem CLK. Als uC gibt es 6-polige und Dinger ab 3ct, na sagen wir unter 50ct. Als FPGA gibt es Minimum QFN48 und es geht bei 10$ los. Was soll man mit 43 unbenutzen Anschlüssen ? FPGA ist halt für völlig andere Anwendungen, z.B. in realtime den DSL Datenstrom abertausender Nutzer in Frankfurt nach Inhalt zu untersuchen, ZIP oder BASE64 zu decodieren, DES zu entschlüsseln, darin Schlüsselworte zu suchen, Inhalte auszutauschen und wieder zu verpacken so dass der Anwender nichts merkt, und das ganze muss rekonfigurierbar sein wenn ein neues Verschlüsselungsformat aufkommt oder auch nur neue Suchworte. Da werden sowieso ganze Schränke voller Chips zum koste-es-was-es-wolle Preis aufgestellt.
Was mich an den FPGAs und CPLDs extrem nervt, daß die so kurzlebig sind. Ständig werden Typen abgekündigt und die Ersatztypen sind nicht kompatibel, d.h. die Source und die Platinen müssen angepaßt werden. Man merkt deutlich, daß die für Nischenmärkte gedacht sind und nicht für langfristige Projekte. Für ein Gerät haben wir einen hoffentlich lebenslangen Vorrat an FPGAs eingekauft, weil der Entwickler nicht mehr zugreifbar ist und das Projekt auch nicht dokumentiert ist. Ich hab noch 5 Stück PZ5064 liegen, das waren mal super stromsparende 5V CPLDs mit guten Tools. Die Ersatztypen von Xilinx haben haufenweise Ärger gemacht. Der Fitter hat sich tagelang ohne Ergebnis abgeqält und es mußte ein Typ mit doppelter Anzahl Macrozellen eingesetzt werden, der natürlich nicht pinkompatibel war. Ein Fremdentwickler hatte mal PEELs PA7572 verwendet, die gab es nach kurzer Zeit auch nicht mehr zu kaufen. Zum Glück ist das Projekt eingestampft worden. Ich nehme daher lieber Mikrocontroller, die gibt es in der Regel viele Jahrzehnte lang gut zu kaufen. Und kosten dann auch keine Mondpreise, wie ältere FPGAs oder CPLDs.
Was für ein Blödsinn.
Leute, der Frickelprinz hat sich das letzte Mal vor 100 Einträgen
gemeldet, in Summe eh nur 3x und dabei ist er NULL - auf keine einzige
Antwort eingegangen.
>> Helft doch lieber denen die auch lesen was Ihr schreibt.
Gruß
M.
Rente mit 76 schrieb: > Porto bezahle ich auch, aber höre bitte mit deinem Wehklagen auf. Deine Missioniererei ist ja schon frech. > Vllt findet sich noch jmd, der für lau einen passenden Programmer > loswerden will. Vielleicht, vielleicht auch nicht. Vergiss es! Ich bekomme mein Probleme auch ohne Lockangebote gelöst.
> Ich bekomme mein Probleme auch ohne Lockangebote gelöst.
Das Schieberegister war doch gar nicht dein Problem.
Ich habe mich nur rein rhetorisch geäußert.
Bist du immer so leicht zu triggern?
Peter D. schrieb: > Was mich an den FPGAs und CPLDs extrem nervt, daß die so kurzlebig sind. > Ständig werden Typen abgekündigt und die Ersatztypen sind nicht > kompatibel, d.h. die Source und die Platinen müssen angepaßt werden. Die meisten FPGAs/CPLDs sind 20 Jahre verfügbar, teilweise länger. > Man > merkt deutlich, daß die für Nischenmärkte gedacht sind und nicht für > langfristige Projekte. Was ist denn für euer Gnaden "langfristig"? 100 Jahre? Welche CPU, PC etc. ist 20 Jahre aktuell? > Für ein Gerät haben wir einen hoffentlich lebenslangen Vorrat an FPGAs > eingekauft, weil der Entwickler nicht mehr zugreifbar ist und das > Projekt auch nicht dokumentiert ist. Das ist dann euere Schlampigkeit und kein allgemeines Problem. > Ich nehme daher lieber Mikrocontroller, Äpfel und Birnen und so . . .
Peter D. schrieb: > weil der Entwickler nicht mehr zugreifbar ist und das > Projekt auch nicht dokumentiert ist. Wegwerftechnik und ein Wegwerfprogrammierer, was kann man da schon erwarten? Georg
Beitrag #7139182 wurde von einem Moderator gelöscht.
Beitrag #7139191 wurde von einem Moderator gelöscht.
Man könnte auch sachlich widersprechen. Ich weiß nicht, warum das manchen hier so schwer fällt ... Ich stelle mir immer vor, dass der, mit dem ich diskutiere, dem ich widerspreche oder den ich zu widerlegen versuche, dass ich den persönlich kenne und er vor mir in z.B. einer Besprechung sitzt. Dann stimmen automatisch der Ton und die Ausdrücke ...
HildeK schrieb: > Man könnte auch sachlich widersprechen. Ich weiß nicht, warum das > manchen hier so schwer fällt ... Weil sie eine Persönlichkeitsstörung haben. > Ich stelle mir immer vor, dass der, mit dem ich diskutiere, dem ich > widerspreche oder den ich zu widerlegen versuche, dass ich den > persönlich kenne und er vor mir in z.B. einer Besprechung sitzt. > Dann stimmen automatisch der Ton und die Ausdrücke ... Mag sein, aber REAL ist das nicht so, denn für die Meisten ist die Distanz und optische Annonymität ein gutes Medium, mal so richtig die Sau rauzulassen.
Beitrag #7139233 wurde von einem Moderator gelöscht.
Beitrag #7139247 wurde von einem Moderator gelöscht.
Beitrag #7139273 wurde von einem Moderator gelöscht.
Falk B. schrieb: >> Für ein Gerät haben wir einen hoffentlich lebenslangen Vorrat an FPGAs >> eingekauft, weil der Entwickler nicht mehr zugreifbar ist und das >> Projekt auch nicht dokumentiert ist. > > Das ist dann euere Schlampigkeit und kein allgemeines Problem. Man kann sich nicht immer nur die Rosinen rauspicken. Man muß auch mal Fremdentwicklungen in die Produktion überführen und ist dann schon froh, wenigstens das Jedec-File zu bekommen.
Sorry liebes Forum, dass ich mich nicht mehr gemeldet habe. Habe extreme Gesundheitsprobleme. Mit manchen Antworten bin ich extrem überfordert und weiß oft nicht, was ist Ernst und was ist Trollerei!!! Warum kann ein uC mit 3 Portleitungen (Daten rein, Daten raus, 1MHz_Clock) das nicht bit für Bit rübertakten, warum externe Schieberegister ?
Frickelprinz schrieb: > Warum kann ein uC mit 3 Portleitungen (Daten rein, Daten raus, > 1MHz_Clock) das nicht bit für Bit rübertakten, warum externe > Schieberegister ? Du willst doch jedes Bit für 5ms verzögern, also muss es für 5ms zwischengespeichert werden. Bei 1MHz Takt gehen in der Zeit aber 4999 weitere Bits ein bis das erste wieder ausgegeben werden darf. Bisher wurde das durch das Durchtakten durch deine fast endlose Schieberegisterkette erledigt. Jetzt kann man mit dem µC viel leichter Bytes, also 8 Bit auf einmal verarbeiten als einzelne Bits. Er müsste dann einen RAM-Speicher für mindestens 5000 Bytes haben, wobei nur 1/8 der Bits genutzt werden. Bei den größeren µCs gibt es das, bei den kleinen ist es üblicherweise weit weniger, oft nur 128 256 512 Bytes. Das reicht auch nicht mit dem externen Schieberegister. Daher der Vorschlag von Falk B., einen Mega88 zu nehmen, der hat immerhin 1 kByte RAM. Das ist auch das Mindeste was man haben muss, denn der µC braucht auch noch RAM für seinen Stack oder für Variablen; wobei für diese Aufgabe wird das (geschätzt) sehr wenig sein. Mit dem externen Schieberegister muss man dann nur noch 5000/8 Speicherstellen im RAM haben, dafür muss man eben die Bits in einem Byte mit einem Hilfsmittel, hier dem externen Schieberegister, ausgeben und muss nur mit 1MHz/8 das Schieberegister neu laden. So hat auch der µC achtmal mehr Zeit für seine Verarbeitung. Das selbe gilt auch fürs Lesen der Eingangsdaten: zuerst mal acht Bits in das Schieberegister mit 1MHz eintakten, dann in den Prozessor einlesen und speichern. Dann kommen die nächsten acht in die nächste RAM-Zelle. Sind alle 625*8 abgespeichert, also nach 5000 Takten, wird das zuerst eingelesene ins Ausgabeschieberegister geladen und von dort seriell ausgetaktet.
Sorry Hilde, du möchtest hier den Hardwareoverkill mit externen Schieberegistern verteidigen, dabei liegen längst 2 Lösungen unter geschickter Verwendung der microcontrollerinternen Hardwarefunktionen vor, die das Problem viel intelligenter lösen, oder eben auch eines FPGA.
MaWin schrieb: > Sorry Hilde, du möchtest hier den Hardwareoverkill mit externen > Schieberegistern verteidigen Sehe ich anders, er hat einfach nur die Frage beantwortet, ohne den Lösungsansatz zu bewerten. > warum externe Schieberegister ?
Frickelprinz schrieb: > Warum kann ein uC mit 3 Portleitungen (Daten rein, Daten raus, > 1MHz_Clock) das nicht bit für Bit rübertakten, warum externe > Schieberegister ? Mein erster Vorschlag hier Beitrag "Re: Schieberegister ersetzen" Beitrag "Re: Schieberegister ersetzen" Dazu die Software Beitrag "Re: Schieberegister ersetzen" Dabei bin ich davon ausgegangen, daß zum 1Mbit/s auch ein SYNCHRONER Takt existiert. Damit man das mit einem kleinen Mikrocontroller ala AVR verarbeiten kann, braucht er ein wenig Hilfe, denn die 1Mbit/s mit EXTERNEM Takt LÜCKENLOS einlesen ist schwierig bis unmöglich. Später kam von dir die Aussage, daß der Takt ASYNCHRON zum Datenstrom ist. Damit wird es einfacher und es reicht der AVR allein, er kann mittels UART im SPI Modus LÜCKENLOS einen 1Mbit/s Datenstrom ASYNCHRON abtasten, speichern und wieder ausgeben. Beitrag "Re: Schieberegister ersetzen" Wenn dir das DIL28 Gehäuse (35x10mm^2) zu "groß" ist, nimm das TQFP32 (9x9mm^2) oder hard core QFN mit 5x5mm^2 oder super hard core BGA mit 4x4mm^2. Wenn DAS keine Verkleinerung deines Kuchenblechs ist, weiß ich es auch nicht.
MaWin schrieb: > Sorry Hilde, du möchtest hier den Hardwareoverkill mit externen > Schieberegistern verteidigen, dabei liegen längst 2 Lösungen unter > geschickter Verwendung der microcontrollerinternen Hardwarefunktionen > vor, die das Problem viel intelligenter lösen, oder eben auch eines > FPGA. 1. HildeK - nix Hilde. 2. Ich verteidige gar nichts, ich habe ihm nur erklärt, warum ein einfaches Einlesen und wieder Ausgeben nicht geht. 3. Ich habe ihm erklärt, warum in dieser einen Lösung außen noch zwei Schieberegister sind. 4. Ich habe schon weit oben ein FPGA vorgeschlagen.
Frickelprinz schrieb: > Warum kann ein uC mit 3 Portleitungen (Daten rein, Daten raus, > 1MHz_Clock) das nicht bit für Bit rübertakten, warum externe > Schieberegister ? Nochmal ganz einfach, mit externem Takt, ohne Schieberegister, ohne FPGA und ungetestet:
1 | #define FIFO_LEN 5000 // 5000 * 1 µs
|
2 | #define FIFO_IN 0 // Pin0
|
3 | #define FIFO_OUT 1 // Pin1
|
4 | #define FIFO_CLK 2 // 1 MHz an Pin2
|
5 | |
6 | uint8_t fifo[FIFO_LEN]; |
7 | uint32_t fifo_index; |
8 | |
9 | void setup() |
10 | {
|
11 | pinMode(FIFO_IN, INPUT); |
12 | pinMode(FIFO_OUT, OUTPUT); |
13 | pinMode(FIFO_CLK, INPUT); |
14 | }
|
15 | |
16 | void loop(void) |
17 | {
|
18 | while(digitalRead(FIFO_CLK)); // auf 0-Pegel warten |
19 | while(!digitalRead(FIFO_CLK)); // auf positive Flanke warten |
20 | digitalWrite(FIFO_OUT,fifo[fifo_index]); // verzoegerten Wert schreiben |
21 | fifo[fifo_index] = digitalRead(FIFO_IN); // neuen Wert lesen |
22 | if(++fifo_index >= FIFO_LEN) fifo_index = 0; // und wieder von vorne |
23 | }
|
Frickelprinz schrieb: > Warum kann ein uC mit 3 Portleitungen (Daten rein, Daten raus, > 1MHz_Clock) das nicht bit für Bit rübertakten Kann er doch. Mögliche Lösungen wurden genannt. Er braucht halt nur genug RAM, um ca. 625x8Bit zwischenzuspeichern. > warum externe > Schieberegister ? Die hingegen braucht er nicht. Entweder nimmt man SPI-like-Peripherie als Schieberegister (sinnvoll!) oder man macht's in Software (nicht sinnvoll, da nahezu alles Devices mit genug RAM auch eine geeignete SPI-Einheit haben). Aber selbst, wenn man zwingend auf ein völlig ungeeignetes Teil wie etwa ATmega8 @8MHz angewiesen wäre (bei dem das halt nicht der Fall ist), könnte man noch eine reine Software-Lösung umsetzen. Es würde tatsächlich gerade so reichen. Dich aber wohl maximal überfordern...
m.n. schrieb: > ungetestet Ja, für diese einfache Lösung muss man halt einen µC nehmen, der schnell genug getaktet ist und nicht von irgendwas für mehr als 500ns unterbrochen wird (und bei diesen 500ns wirds schon arg kritisch mit dem Abtasttheorem). Fazit: das, was es derzeit als Arduino gibt, schafft das nicht. Und auch bei einem nackten AVR hätte ich da so meine Bedenken bei der Fifo-Verwaltung...
:
Bearbeitet durch Moderator
Falk B. schrieb: > denn die 1Mbit/s mit EXTERNEM Takt LÜCKENLOS einlesen ist schwierig bis > unmöglich. In C würde ich zustimmen, in Assembler ist es einfach. Es reicht eine ISR, die auf den SPI-Interruptvektor gelegt wird. Damit erhält man eine Latenz von 4-5 Takten, wenn das Hauptprogramm in einer Endlosschleife wartet. Die ganze Programmlogik kann in diese ISR. Schätzungsweise ca. 20 Zeilen Assemblercode.
avr schrieb: > In C würde ich zustimmen, in Assembler ist es einfach. Nein, ist es nicht. Jedenfalls nicht bei einem AVR8 @8Mhz. > Es reicht eine > ISR Schon geloosed. Allein der Interruptrahmen dauert 8 Takte, d.h.: ALLE 8 Takte, die überhaupt verfügbar sind, wenn man mit 1MHz samplen muss. Die ISR kann also überhaupt keinen Nutzcode ausführen. Dazu kommt dann noch der "Straftakt" in main(). D.h.: allein schon das Konzept, das irgendwie mit Interrupts lösen zu wollen, ist völliger Schwachsinn, der schlicht nicht funktionieren kann.
avr schrieb: > Falk B. schrieb: >> denn die 1Mbit/s mit EXTERNEM Takt LÜCKENLOS einlesen ist schwierig bis >> unmöglich. > > In C würde ich zustimmen, in Assembler ist es einfach. Es reicht eine > ISR, die auf den SPI-Interruptvektor gelegt wird. Damit erhält man eine > Latenz von 4-5 Takten, wenn das Hauptprogramm in einer Endlosschleife > wartet. Die ganze Programmlogik kann in diese ISR. Schätzungsweise ca. > 20 Zeilen Assemblercode. Na dann mach das mal, bau eine Lösung für das gegebene Problem und teste. Dann reden wir weiter.
:
Bearbeitet durch User
Lothar M. schrieb: > Fazit: das, was es derzeit als Arduino gibt, schafft das nicht. Stimmt nicht, denn "Arduino" ist so mehrdeutig heutzutage. Das ist schon LANGE nicht mehr nur der "olle" AVR, da sind auch viele andere, DEUTLICH potentere CPU, u.a. der PR2040. > bei einem nackten AVR hätte ich da so meine Bedenken bei der > Fifo-Verwaltung... Es gibt eine getestete Lösung. Beitrag "Re: Schieberegister ersetzen"
Lothar M. schrieb: > Fazit: das, was es derzeit als Arduino gibt, schafft das nicht. Und auch > bei einem nackten AVR hätte ich da so meine Bedenken bei der > Fifo-Verwaltung... Falsches Fazit, man muss ja nicht digitalRead/digitalWrite auf dem Arduino nutzen, SPI hat der auch, und die Programme wurden gezeigt, da muss man nicht FUD einsteuen. Aber was soll man vom FPGA Fanboy schon anderes als Desinformation erwarten. Immerhin: mit dem fertigen VHDL code weiss Frickelprinz auch da, was ihn erwartet, nur scheint er's nicht zu lesen.
MaWin schrieb: > Immerhin: mit dem fertigen VHDL code weiss Frickelprinz auch da, was ihn > erwartet, nur scheint er's nicht zu lesen. Dürfte eh' nur ein Traffic-Troll sein...
c-hater schrieb: > Schon geloosed. Allein der Interruptrahmen dauert 8 Takte, d.h.: ALLE 8 > Takte, die überhaup Schade, ich hatte von dir mehr Kompetenz erwartet. Die Interruptlatenz beträgt 4 Takte (RTFM) bis zur ersten ausgeführten Instruktion. Deinen Straftakt habe ich einkalkuliert. Was auch immer dein Interruptrahmen ist - Register sichern muss man nicht, wenn das Programm sonst nichts macht. Und wie schon geschrieben steht die Funktion im Interruptvektor. Falk B. schrieb: > Na dann mach das mal, bau eine Lösung für das gegebene Problem und > teste. Dann reden wir weiter. Brauche ich nicht und kann ich gerade auch nicht. Ich möchte nur Möglichkeiten aufzeigen und kann zumindest beweisen, dass die Lösung funktioniert.
avr schrieb: > Falk B. schrieb: >> Na dann mach das mal, bau eine Lösung für das gegebene Problem und >> teste. Dann reden wir weiter. > > Brauche ich nicht und kann ich gerade auch nicht. Ich möchte nur > Möglichkeiten aufzeigen und kann zumindest beweisen, dass die Lösung > funktioniert. Nö, kannst du nicht, du plapperst nur. Ein Beweis sieht anders aus. Außerdem ist das mit 4 Takten Latenz falsch, da hab ich mich auch mal geirrt. Nach 4 Takten ist der PC in den Interrupt Vektor gesprungen. Dort steht dann je nach AVR Typ ein RJMP oder JMP, der 2 oder 3 Takte braucht. Dann erst beginnt die ISR. Ist aber egal, eine ISR ist bei dem Problem schlicht Unsinn, da die CPU so oder so NICHTS anderes tun kann und muss. Old school polling ist einfacvher und besser, weil "taktschonenender".
avr schrieb: > Die Interruptlatenz > beträgt 4 Takte (RTFM) bis zur ersten ausgeführten Instruktion. Um Latenzen kümmert man sich erst, wenn überhaupt der Durchsatz gewährleistet ist. Ist er hier hier aber eben definitiv nicht. Du musst einfach begreifen, dass eine komplette Interrupbehandlung keinesfalls damit abgeschlossen ist, wenn der Nutzcode in der ISR zum Zuge kommt. Danach muss der noch ausgeführt werden. Und dann muß die ISR auch noch zurückkehren... Und der komplette Zyklus (ohne jeden Nutzcode!) kostet bei einem AVR8 halt (mindestens) 8 Takte. Bei AVR8 mit 22Bit-PC und/oder externem RAM auch mehr... Dazu kommt dann halt, quasi als Sahnehäubchen noch der "Straftakt" in main(). D.h.: unter 9 Takte für einen kompletten Interruptzyklus geht garnix. Und damit ist schon bei einer ersten überschlägigen Betrachtung des Problems vollkommen klar, das Interrupts unmöglich dessen Lösung sein können...
avr schrieb: > Schade, ich hatte von dir mehr Kompetenz erwartet. Hat er. avr schrieb: > Was auch immer dein Interruptrahmen ist RETI gehört z.B. dazu. Nochmal 4 Takte. Schwubbs: sind 8 Takte. Sowas. Gruß Jobst
Falk B. schrieb: > Dort steht dann je nach AVR Typ ein RJMP oder JMP, der 2 oder 3 Takte > braucht. Nein, an der Stelle steht zum Beispiel
1 | out SPIDR, r0 |
2 | rjmp SPI_ISR |
Der nächste Interruptvektor wird geopfert, was hier kein Problem darstellt. r0 wird für die ISR reserviert. Bei 1MHz SPI-Takt hat man @8MHz CPU 64 Takte pro ISR. Das reicht dicke aus. Das eigentlich FIFO braucht keine 20 Takte. Polling würde auch gehen, braucht im worst case wahrscheinlich 6 Takte. Jobst M. schrieb: > Hat er. Nein, hat er wohl nicht. Sonst würde er verstehen, von was ich rede.
Beitrag #7140445 wurde von einem Moderator gelöscht.
c-hater schrieb im Beitrag #7140445: > avr schrieb: > >> Nein, hat er wohl nicht. Sonst würde er verstehen, von was ich rede. > > Du Spasst begreifst nicht, wovon alle Wissenden reden... Dass nämlich > eine Funktion nicht damit endet, dass ihr Nutzcode ausgeführt wird... Das ist vollkommen uninteressant, weil die Zeit vollkommen ausreicht. Das wurde schon durch das usart Beispiel von Falk bewiesen. Das einzig interessante ist, ob die Latenz für lückenlose SPI Übertragung als Slave reicht. Und das ist der Fall.
avr schrieb: > Polling würde auch gehen, braucht im worst case wahrscheinlich 6 Takte. Polling ist das einzige was geht. Und ist nicht ganz einfach umzusetzen. Die innerste Schleife braucht (vollständig ausgerollt) tatsächlich nur 6 Takte. Bietet also genug "Platz", um den Code der äußeren Schleifen in den verbleibenden zwei Takten unterzubringen. Aber man muß schon etwas an Erfahrung haben, um das unfallfrei umzusetzen...
avr schrieb: > Das ist vollkommen uninteressant, weil die Zeit vollkommen ausreicht. > Das wurde schon durch das usart Beispiel von Falk bewiesen. Das einzig > interessante ist, ob die Latenz für lückenlose SPI Übertragung als Slave > reicht. Und das ist der Fall. Nö, denn der AVR kann als SPI-Slave nicht so schnell getaktet werden, dazu braucht es mindestens einen x4 Takt. Also müßte man aus den externen 1MHz per EXTERNER Pll 4MHz machen. Alles machbar, aber ganz sicher nicht die Einchip-Lösung.
Falk B. schrieb: > Nö, denn der AVR kann als SPI-Slave nicht so schnell getaktet werden, > dazu braucht es mindestens einen x4 Takt. Also müßte man aus den > externen 1MHz per EXTERNER Pll 4MHz machen. Alles machbar, aber ganz > sicher nicht die Einchip-Lösung. Es gibt keinen externen Takt. Auch auf der Kuchenblechplatine war der Takt asynchron zur Aussenwelt. Daher ist seit der Salamischeibe die Lösung noch einfacher geworden.
Falk B. schrieb: > Also müßte man aus den externen 1MHz per EXTERNER Pll 4MHz machen Interner RC-Oscillator bei 8MHz? Ich hab das Gefühl wir reden gerade aneinander vorbei.
avr schrieb: >> Also müßte man aus den externen 1MHz per EXTERNER Pll 4MHz machen > > Interner RC-Oscillator bei 8MHz? Ich hab das Gefühl wir reden gerade > aneinander vorbei. In der Tat. Wir erinnern uns. Beitrag "Re: Schieberegister ersetzen" >>denn die 1Mbit/s mit EXTERNEM Takt LÜCKENLOS einlesen ist schwierig bis >> unmöglich. >In C würde ich zustimmen, in Assembler ist es einfach. Also. Bau eine lösung, welche ein Datensignal, welches mit einem dazugehörigen, sychronen Takt in einen AVR eingelesen wird und wieder ausgegeben wird. Lückenlos bei 1 Mbit/s.
MaWin schrieb: > Es gibt keinen externen Takt. Auch auf der Kuchenblechplatine war der > Takt asynchron zur Aussenwelt. > > Daher ist seit der Salamischeibe die Lösung noch einfacher geworden. Stimmt, aber Mr. AVR meint, das wäre in ASM einfach. Ich bezweifle, daß man es überhaupt hinbekommt, auch mit 16 MHz CPU-Takt.
Falk B. schrieb: > Stimmt nicht, denn "Arduino" ist so mehrdeutig heutzutage. Das ist schon > LANGE nicht mehr nur der "olle" AVR, da sind auch viele andere, DEUTLICH > potentere CPU, u.a. der PR2040. Aber genau denen traue ich noch weniger deterministisches Echtzeitverhalten zu. Auf jeden Fall nicht, wenn hintenrum das Arduino-System sein Housekeeping macht.
Falk B. schrieb: > Stimmt, aber Mr. AVR meint, das wäre in ASM einfach. Ich bezweifle, daß > man es überhaupt hinbekommt, auch mit 16 MHz CPU-Takt. Das zeigt allerdings wieder mal erneut, dass du einfach keine Ahnung davon hast, was mit ASM möglich ist. Weil du es einfach nicht selber aktiv benutzt. Es geht mit 8MHz (natürlich mit Polling, nicht mit Interrupts), auch ohne ein geeignetes SPI-Device auszukommen. Also z.B. mit einem ATmega8 @ 8MHz, wo dein Code natürgemäß scheitern wird, mangels SPI-Master-fähiger USART. Ich bin bereit, einen entsprechenden Code zu liefern, wenn du im Gegenzug bereit bist, öffentlich, ausdrücklich und unwiederuflich zuzugeben, dass C zumindest insofern Dreck ist, als dass man damit REGULÄR nicht in der Lage ist, ALLES aus einer gegebenen Hardware herauszuholen. Ich meine, das ist natürlich eine Sache, über die man eigentlich sowieso nicht diskutieren müsste, da jeder mit hinreichender Kompetenz das sowieso weiss, aber ich möchte halt, dass du es EXPLIZIT und ÖFFENTLICH selber sagst. Deal?
Falk B. schrieb: > Stimmt, aber Mr. AVR meint, das wäre in ASM einfach. Ist es auch, SPI Slave mit externem Takt (der ggf. trotzdem von innen stammt per PWM Pin) und schon btauchtan keine PLL. So wie ich die AVR Doku lese, muss der interne Takt 4 mal schneller sein als extern SCK rein kommt, aber 4MHz ist für einen AVR ja kein Problem, der Arduino macht 16, 20 ginge auch, und die SPI Einheit kann bis halben CPU Takt bekommen. > Ich bezweifle, daß > man es überhaupt hinbekommt, auch mit 16 MHz CPU-Takt. https://ww1.microchip.com/downloads/en/Appnotes/Atmel-2585-Setup-and-Use-of-the-SPI_ApplicationNote_AVR151.pdf
MaWin schrieb: > So wie ich die AVR Doku lese, muss der interne Takt 4 mal schneller sein > als extern SCK rein kommt, aber 4MHz ist für einen AVR ja kein Problem, > der Arduino macht 16, 20 ginge auch, und die SPI Einheit kann bis halben > CPU Takt bekommen Danke, exakt so war das gemeint. SPI Slave und der AVR läuft mit internem Takt auf 8 MHz. Und das Problem des einfach gepufferten Sendepuffers kann durch Interrupt mit maximal 5 Takte Latenz in Assembler gelöst werden. Wie genau habe ich oben beschrieben.
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.