Eigenentwicklung um 24 Bit Daten aus Datei parallel auszugeben

Klaus schrieb:
> - Der ESP hat nur ca 320kb Speicher, da wirds mit einem Array in dieser
> Größe schwer.

50000 Werte à 24 Bit sind 150 kiByte. Wo ist das Problem?

Klaus schrieb:
> Wie kann ich elegant 24 Bit Daten aus einer Datei einlegen und diese an
> 24 Pins mit der gewünschten Geschwindigkeit parallel ausgeben?

Mit einem 32 bit Prozessor, der auch 32 bit Ports hat, wie AVR32.

Noch eleganter per zeitgebergetriggetem DMA.

Ansonsten 3 8 bit ports in der nötigen Geschwindigkeit laden und per 
Clock-Impuls am 25 Ausgang zeitgleich in ein 24 bit Latch ubertragen.

Da muss der Prozessor halt deutlich schneller sein.

Klaus schrieb:
> Die STM können meines Wissens auch nur 16 Bit. Jemand eine Idee?

Die Ausgabepin im Multiplex betreiben.
Schon der 8-Bit µP von Intel 8008 hat seine PIN so verwaltet.

Ich habe einen STM32H7.
Der kann 1MByte im Ram Speichern. Genug um die Daten im Ram zu halten.
Der hat 'Up to 168 I/O ports with interrupt capability'.
Warum nimmt man nicht einfach 24 GPIOs davon, und legt die Bitmuster an?
Der hat 480 MHz Taktfrequenz. Das müßte doch alles reichen.

RP2040

hat 26 GPIO Pins
hat mehr als genug Speicher
hat DMA und PIO (könnte die Daten mit 100MHz rausjagen)
lächelt müde bei der Aufgabenstellung und weiß gar nicht was er mit 
seinen zwei Kernen denn nun anfangen soll. Am besten schlafen.

Gut, ist nicht besonders günstig, kostet immerhin als fertiges Teil 
4,10€

c-hater:
> Z.B. könnte ein RP2040 mit links und 40 Fieber all den Quatsch
> machen, bloß im letzten Schritt würde er scheitern, weil er
> schlicht nicht genug GPIOs hat.

Hmmm... überseh ich da was?  Der RP2040 hat 30 freie GPIOs.  Der Pi-Pico 
klaut 4 davon für internen Kram (leider so, dass nur noch 23 in Folge 
frei sind).

foobar schrieb:
> c-hater:
>> Z.B. könnte ein RP2040 mit links und 40 Fieber all den Quatsch
>> machen, bloß im letzten Schritt würde er scheitern, weil er
>> schlicht nicht genug GPIOs hat.
>
> Hmmm... überseh ich da was?  Der RP2040 hat 30 freie GPIOs.  Der Pi-Pico
> klaut 4 davon für internen Kram (leider so, dass nur noch 23 in Folge
> frei sind).

Korrekt:

GPIO_00…GPIO_15
GPIO_16…GPIO_22
GPIO_26…GPIO_26

Macht 26 Stück. Aufeinander folgend ist bei der Aufgabenstellung jedoch 
unnötig, da man so etwas sowieso direkt von der Hardware erledigen 
lässt.
Hat man mitgekauft, da kann man sie auch benutzen.

> GPIO_26…GPIO_26
was natürlich:
GPIO_26…GPIO_28
heißen soll.

Klaus schrieb:
> folgende Aufgabenstellung: Ich bekomme 24 Bit Daten in einer Datei
> geliefert. Ca 50.000 Werte, tendentiell eher mehr.
> Diese Werte möchte ich aus der Datei auslesen, in einem Array speichern
> und parallel an 24 Pins ausgeben. Geschwindigkeit mind 500khz, am
> liebsten 1 MHz.

Na, dann tue es doch. Hier wird dich niemand daran hindern wollen.

Klaus schrieb:
> Bevor ich nun viel viel Zeit mit einem weiteren Versuch vergeude, hier
> mal die Frage: Wie kann ich elegant 24 Bit Daten aus einer Datei
> einlegen und diese an 24 Pins mit der gewünschten Geschwindigkeit
> parallel ausgeben?

So etwas ist die falsche Frage. Die eigentliche Frage wäre, auf welche 
Weise deine geheimnisvollen Daten von irgendeinem Verbraucher zur 
Kenntnis genommen werden sollen. Also wie stellst du dir das angedachte 
Interface vor?

Und wie schnell du womit und von was für einem Datenträger du eine Datei 
lesen kannst, können dir ale Anderen hier nicht beantworten, denn soweit 
reicht die hiesige Glaskugel nicht.

W.S.

Hui...hier ist ja eine sympathische Atmosphäre :-D
Ich habe es tatsächlich genau so formuliert wie es werden soll, und 
nicht anders.
Ich habe eine Datei mit z.B. 50000 24Bit Werten. Diese iss in das Ding 
rein, wie ist eigentlich egal. Am ESP32 habe ich die Datei per 
Webinterface in den Spiffs geladen und von da weiter in ein Array 
geschoben. Beim ESP klappt tatsächlich alles super, nur der RAM ist zu 
klein für ein größeres Arrayind die Hardware kann keine 24Pins liefern. 
Daher die Sondierung mit welcher Hardware ich dasganhe vernünftig lösen 
kann. Möchte ungerne wieder etwas entwickeln und am ende merken das Esso 
gar nicht klappt.
Ob die Hardware 10, 100 Euro oder mehr kostet wäre tatsächlich egal in 
dem Fall. Hauptsache das ganze läuft anständig.
Bisher hört sich für mich die Geschichte mit dem STM32H7 gut an. Oder 
tatsächlich ein FIFO an den ESP hängen

Falk B. schrieb:
> FIFO ist Unsinn, denn dann sind die Daten nach einem Durchlauf weg.

Unfug,
der Eingang Retransmit (RT) wurd bereits erfunden.

Jörg W. schrieb:
> Sollte aber auch einer sein, der nicht (wie viele STM32) auf nur 16-bit
> IO kastriert worden ist. Atmel-ARMs können das an sich (nicht nur deren
> AVR32).

Wobei das letztlich wahrscheinlich ueber den Handschacke abgefangen 
werden koennte. Auch bei der synchronen Ansteuerung bei 32bit Ports gibt 
es ja Momente mit ungueltigen Zwischenmustern, die man auf 
Empfaengerseite abfangen muss. Wobei ich dir trotzdem Recht gebe dass 
man darauf schauen soll, um nicht das Timing unnoetig zu 
verkomplizieren.


> Andere Frage ist: was für ein Handshake wird gebraucht? Es wird ja nicht
> genügen, die Daten mit maximal möglicher Rate auf 24 Portpins
> rauszukegeln, sondern irgendwie muss man der Datensenke ja auch
> mitteilen, dass da jetzt gültige Daten vorliegen.

Sorry: Handshake

Es gibt keinen Handshake. Es kommen die 24 Bit an 24 Pins raus und gehen 
direkt an 24Pins eines VectorModukatirs. Daher sollte die Taktrate schon 
stabil sein.

Nein, gar nichts. Das Teil reagiert einfach auf die 24 Bit die am 
Eingang anliegen

Klaus schrieb:
> VectorModukatirs


Wäre es so schwer zu sagen welches Bauteil du genau meinst?

Denn ein paralleles Interface ist ggf. gar nicht notwendig: "3-wire or 
4-wire SPI supporting up to a 61.44 MHz SPI clock speed"

Sprich das Teil kannst du direkt an einen Raspberry Pi 4 packen und 
glücklich sein. Kein uC, einfach nur direkt rausschreiben über einen 
Kernel Treiber. Oder muss es ein ganz exotischer IC sein welcher 2ct 
günstiger ist und dafür 20€ Schaltungskosten und 100000€ Arbeit 
verursacht?


https://www.analog.com/en/products/admv4821.html#product-overview

Wenn es eine einmalige Sache ist (oder selten Updates), dann die Daten 
in ein EEPROM packen (bzw. 2 16-Bit) und die Adressen durchnudeln.

Da braucht es dann keinen Prozessor, nur einen Zählerbaustein.

Onkel Ted schrieb:
> Sprich das Teil kannst du direkt an einen Raspberry Pi 4 packen und
> glücklich sein. Kein uC, einfach nur direkt rausschreiben über einen
> Kernel Treiber. Oder muss es ein ganz exotischer IC sein welcher 2ct
> günstiger ist und dafür 20€ Schaltungskosten und 100000€ Arbeit
> verursacht?

https://www.kratosmed.com/gmcatalog/microwave-iq-vector-modulators-and-bi-phase-modulators/series-73-12-bit-digital-and-series-74-analog-high-dynamic-iq-vector-modulators

Das wäre z.B. so ein Exemplar. Weiß jedoch nicht was es an der 
Aufgabenstellung ändert

Klaus schrieb:
> Das wäre z.B. so ein Exemplar. Weiß jedoch nicht was es an der
> Aufgabenstellung ändert

Analog control (Series 74)

Wirf eine 24 Bit Soundkarte/DAC drauf.

Ansonsten gibt es von NI usw. Karten für sowas.

Onkel Ted schrieb:
> Wirf eine 24 Bit Soundkarte/DAC drauf.
>
> Ansonsten gibt es von NI usw. Karten für sowas.

Habe es ja mit dem ESP32 über i2s (Sound) gemacht. Klappt wunderbar, das 
ding hat nur einfach keine 24Pins, sonst wäre ich fertig.

Was wäre eine solche Karte?

Klaus schrieb:
> Onkel Ted schrieb:
>
>> Wirf eine 24 Bit Soundkarte/DAC drauf.
>> Ansonsten gibt es von NI usw. Karten für sowas.
>
> Habe es ja mit dem ESP32 über i2s (Sound) gemacht. Klappt wunderbar, das
> ding hat nur einfach keine 24Pins, sonst wäre ich fertig.
> Was wäre eine solche Karte?

Nach einem DAC sind 24 Bit doch eine einzige Leitung. Wozu willst du da 
24 Pins?

Könnte mir gut vorstellen, dass die 24 Bit intern als 
Widerstandsnetzwerk DAC verschaltet sind.

Die beiden Dacs sind aber doch im Modulator verbaut. Wenn ich an den 
analogen Teil käme wäre es kein Problem, so aber muss ich mit jeweils 12 
Bit durch den DAC = 2x12 Leitungen.

Beeindruckender kompletter Overkill.

Eine schnelle SPI-Schnittstelle, drei Schieberegister (74xx595), vier 
I/O-Leitungen (drei zum Adressieren der einzelnen Schieberegister und 
eine, um die RCLK-Leitung aller drei Register anzusteuern) würde völlig 
ausreichen.

Wenn man darauf vertraut, daß alles synchron abläuft, kann man auch auf 
die Adressierung verzichten. Nach je drei via SPI übertragenen Bytes 
wird die RCLK-Leitung angesteuert.

Der SPI-Takt muss nur etwas höher sein als 12 MHz, um die geforderten 
500 kHz Datenrate einhalten zu können.


Mehr ist nicht nötig. Ein ESP32 sollte dafür genügen, oder muss man die 
Software dafür so umständlich schreiben, daß 170 kiByte dafür nicht 
genügen?

Meine Idee nachdem es im ESP32 eigentlich alles schön gebaut 
ist...könnte ich per SPI auf 3 Schieberegister a 8 Bit gehen und das 
ordentlich gepuffert und getaktet ausgeben? Habe noch nie mit 
Schieberegistern gearbeitet

Klaus schrieb:
> Die beiden Dacs sind aber doch im Modulator verbaut. Wenn ich an
> den analogen Teil käme wäre es kein Problem, so aber muss ich mit
> jeweils 12 Bit durch den DAC = 2x12 Leitungen.

"Analog control (Series 74)"

Schau das Schaltbild an, die Series 74 bietet eben genau das, zwei 
analoge Eingänge mit 0-10V.

Du hast mir der Series 73 einfach nur das falsche Modell gekauft.

Oh, da waren wir gleich schnell mit gleichem Gedanken. Ich kann den 
ESP32-S3 nehmen, der ist bis auf die parallele Ausgabe komplett fertig 
und hat 8MB PSRAM

Klaus schrieb:
> könnte ich per SPI auf 3 Schieberegister a 8 Bit gehen und
> das ordentlich gepuffert und getaktet ausgeben?

Klaus schrieb:
> Oh, da waren wir gleich schnell mit gleichem Gedanken.


Aber Ernst war mit der allerersten Antwort nach 20 Minuten 'nen guten 
3/4 Tag schneller! ;)

Εrnst B. schrieb:
> Drei SN74HCS595 o.Ä per SPI (+DMA?) befüllen?
>
> Ein STM32 mit >24MHz am SPI ist ja keine Seltenheit...

Klar, paar Nanosekunden sind egal, aber generell sollen die 24 Bit 
zeitgleich an den Ausgängen anliegen. Wie gesagt, habs mit der i2s 
Schnittstelle des ESP32 gemacht...klappt absolut stabil. Es scheitert 
schlicht an den 24 Pins die nicht vorhanden sind.
Deshalb bin ich auf den ESP32-S3 geswitcht. Dieser hat jedoch keinen 
parallel Modus mehr in der I2S Schnittstelle, wurde in ein LCD Modul 
ausgelagert. Dieses kann jedoch nur 16 Bit parallel und es ist nach 
jedem Befehl eine (Leerzeile?). Also nach jedem Bitwort sind alle 
Ausgänge für einen Takt "low".
Nun suche ich einfach was, im Idealfall verwandtes, was mir 24 Bit 
parallel mit 1 Mhz stabil rauswerfen kann.
Werde mir den Ansatz anschauen den ESP32-S3 gepaart mit 3 
Schieberegistern a 8 Bit zu nutzen. Mal sehen was für Taktraten man über 
SPI hinbekommt

Wenn Q und I quasikontinuierliche Signale sind, duerfte ein kurzer 
Versatz zwischen der Q- und I-Aktualisierung nichts ausmachen. Dann 
haette man nur jeweils 12 Bit gleichzeitig auszugeben, das duerfte die 
Auswahl der Mikrocontroller deutlich erleichtern.

Jörg W. schrieb:

> Εrnst B. schrieb:
>> Deshalb hatte ich 74HCS595 vorgeschlagen
>
> Naja, es gibt ja mittlerweile endlos viele 74xx-Baureihen,
> da sind genügend schnelle dabei. Die Frage ist ja eher,
> was der ESP32 maximal durchpumpen kann.

24Bit lassen sich auch als 4 x 6 Bit darstellen; das passt
mit zwei Steuersignales (1xSchieben, 1xWrite für Latches)
auf einen 8-Bit-Port. Hardware-Aufwand sind 6 Schieberegister
und 3 Latches.
Eine 24Bit-Ausgabe erfordert m.E. 8 I/O-Befehle.

Jörg W. schrieb:

> Wenn schon, müsste das Steuersignal zur Übernahme
> auf den Ausgang für alle Latches das gleiche sein,
> sonst ist es nicht gleichzeitig.

Ja, klar, so war es gemeint: EIN Taktsignal zum
Schieben für alle sechs Schieberegister, und EIN
Schreibsignal für alle Latches. Logo.


> Allerdings dürfte das im Fall des ESP32 dann trotzdem
> wieder an den fehlenden Pins für so viele parallele
> Daten scheitern.

??? So viele?
Man braucht EINEN 8-Bit-Port. Der ist nicht da?!

Moin,
500kHz ist ziemlich lahm. Mit einem STM32F40x kannst du das in einen 
Timer packen und die Werte an 2-3 Ports ausgeben. Bei 168 Mhz Takt hast 
du 336 Takte... das reicht locker. Evtl. geht es sogar mit zwei DMAs, 
dann langweilt sich der MCU dabei sogar.

schönen Gruß,
Alex

Jörg W. schrieb:
> Wenn schon, müsste...

Müsste, könnte, würde... immerzu all diese Konjunktive.

Und das alles nur, weil der TO mit seiner grandiosen "Eigenentwicklung" 
zwar die Phantasie anregt, aber nicht wirklich konkret wird.

Ich vermute mal, daß da ein kaum halbgares Konzept dahinter steht, bei 
dem der TO an die Grenzen seiner Planungskraft gekommen ist und deshalb 
hier nachfragt, ob ihn jemand aus seinem eigenen Holzweg wieder 
herausholt.

Aber dazu müßte er das eigentliche Planungsziel erläutern und nicht 
mit düren Worten bloß "folgende Aufgabenstellung:" hinschreiben. Wir 
sind hier ja nicht in der Grundschule.

Eigentlich ist schon alles dazu gesagt.

W.S.

W.S. schrieb:
> Ich vermute mal, daß da ein kaum halbgares Konzept dahinter steht, bei
> dem der TO an die Grenzen seiner Planungskraft gekommen ist und deshalb
> hier nachfragt, ob ihn jemand aus seinem eigenen Holzweg wieder
> herausholt.

Nun, viel interessanter ist doch welche Wege (und welcher Aufwand) hier 
so vorgeschlagen werden für eine derart triviale Aufgabe.

Amüsant ist es allemal, daher Danke an alle emsig Mitwirkenden…

Solange Klaus nur um den heißen Brei eiert solange wird das nichts. Ich 
halte den gesamten Thread für Sinnfrei.

> Ich halte den gesamten Thread für Sinnfrei.

Es gibt ja genug die über das hingehaltene Stöckchen springen...
Schon die Tatsache noch nie im Leben mal ein Schieberegister
benutzt zu haben, spricht da Bände.
Da ist wieder ein überforderter Informatiker am Werk.
Und wie alle Informatiker bringt er nichts, oder nur deutlich
suboptimales zustande.

... schrieb:
> überforderter Informatiker

Ob er überhaupt weiß was Eigenentwicklung ist?

PittyJ schrieb:
> Warum nimmt man nicht einfach 24 GPIOs davon, und legt die Bitmuster an?

Weil du nicht alle 24 Bit gleichzeitig Takt-Synchron ausgeben kannst. 
Das war doch die besondere Anforderung von Klaus.

Stefan ⛄ F. schrieb:
> PittyJ schrieb:
>> Warum nimmt man nicht einfach 24 GPIOs davon, und legt die Bitmuster an?
>
> Weil du nicht alle 24 Bit gleichzeitig Takt-Synchron ausgeben kannst.
> Das war doch die besondere Anforderung von Klaus.

Das gilt zwar für viele aber bei weitem nicht für alle Prozessoren.

Norbert schrieb:
> Das gilt zwar für viele aber bei weitem nicht für alle Prozessoren.

Ich rede vom STM32H7, den Pitty im gleichen Atmemzug nannte. Dessen 
GPIOs haben nur 16 Bit, wie bei allen (?) STM32.

Stefan ⛄ F. schrieb:
> Norbert schrieb:
>> Das gilt zwar für viele aber bei weitem nicht für alle Prozessoren.
>
> Ich rede vom STM32H7, den Pitty im gleichen Atmemzug nannte. Dessen
> GPIOs haben nur 16 Bit, wie bei allen (?) STM32.

Ah, OK, für den gilt's. ;-)

J. S. schrieb:
> es gibt auch noch D-Latches, eventuell zweistufig, dann kann man auch
> bequem 8 Bit sequentiell arbeiten.

Ganz Recht. Wäre schön, wenn der Klaus sich mal dazu äußern würde.

J. S. schrieb:
> es gibt auch noch D-Latches, eventuell zweistufig, dann kann man
> auch
> bequem 8 Bit sequentiell arbeiten.

Ja das stimmt.

Man kann eine ganze Schublade voller phantastischer Bausteine dran 
kleben.
Oder ein Kuchenblech voller Bausteine drum herum arrangieren.

(Man kann auch einfach etwas Passendes nehmen.)

Norbert schrieb:
> Man kann auch einfach etwas Passendes nehmen.

Was willst du dem J.S. damit sagen? Sein Vorschlag war völlig korrekt 
(wenn auch nicht neu). Man gibt die 24 Bit (nicht synchron) aus, dann 
einen Takt-Impuls an die D-Latches, die das synchron weiter leiten. 
Geeignet wären z.B. 3x 74HC273

Stefan ⛄ F. schrieb:
> Norbert schrieb:
>> Man kann auch einfach etwas Passendes nehmen.
>
> Was willst du dem J.S. damit sagen? Sein Vorschlag war völlig korrekt
> (wenn auch nicht neu). Man gibt die 24 Bit (nicht synchron) aus, dann
> einen Takt-Impuls an die D-Latches, die das synchron weiter leiten.
> Geeignet wären z.B. 3x 74HC273

Damit will ich sagen das man sich das ganze externe Gelumpe komplett 
sparen kann, wenn man von Anfang an den Prozessor richtig und den 
Anforderungen entsprechend auswählt.

Norbert schrieb:

> Damit will ich sagen das man sich das ganze externe
> Gelumpe komplett sparen kann, wenn man von Anfang
> an den Prozessor richtig und den Anforderungen
> entsprechend auswählt.

Genau.

Nur Idioten entwickeln Schaltungen aus einzelnen Bauteilen.
Der Fachmann verwendet IMMER AUSSCHLIESSLICH hochintegrierte
ICs.
Was nicht mit einem fertigen IC zu lösen ist, das ist
generell unlösbar! Basta!

Grummler schrieb:
> Norbert schrieb:
>
>> Damit will ich sagen das man sich das ganze externe
>> Gelumpe komplett sparen kann, wenn man von Anfang
>> an den Prozessor richtig und den Anforderungen
>> entsprechend auswählt.
>
> Genau.
>
> Nur Idioten entwickeln Schaltungen aus einzelnen Bauteilen.
> Der Fachmann verwendet IMMER AUSSCHLIESSLICH hochintegrierte
> ICs.
> Was nicht mit einem fertigen IC zu lösen ist, das ist
> generell unlösbar! Basta!

Wenn ich deinen Text korrekt interpretiere, dann ist dir das was du 
schreibst vermutlich noch nicht einmal peinlich. Sei's drum.

Die ›Fachmänn:innen‹ verwenden den bestmöglich passenden Lösungsansatz, 
Wenn der dann auch noch deutlich günstiger und einfacher im Aufbau ist, 
umso besser.

Wenige Beiträge zuvor zB. eine 35€-65€ Lösung im Gegensatz zu einer 4€ 
Lösung.

Aber jedes wie es mag.

Norbert schrieb:

>> Nur Idioten entwickeln Schaltungen aus einzelnen
>> Bauteilen. Der Fachmann verwendet IMMER AUSSCHLIESSLICH
>> hochintegrierte ICs.
>> Was nicht mit einem fertigen IC zu lösen ist, das ist
>> generell unlösbar! Basta!
>
> Wenn ich deinen Text korrekt interpretiere,

Erfahrungsgemäß ist das unwahrscheinlich. Ironie und
Sarkasmus werden nie richtig verstanden.


> dann ist dir das was du schreibst vermutlich noch nicht
> einmal peinlich. Sei's drum.

Über das Alter, in dem man mich mit "Schäm Dich!" mundtot
machen konnte, bin ich schon ein paar Wochen hinaus.

Also: Nein, das ist mir nicht peinlich.


> Die ›Fachmänn:innen‹ verwenden den bestmöglich passenden
> Lösungsansatz,

Nein, in der Regel nicht -- zumindest nicht im ersten
Anlauf.

Wenn man mit einem Projekt Neuland beschreitet -- und sei
das auch nur "persönliches" Neuland -- dann ist es solchen
Projekten WESENSEIGEN, dass man im Vorfeld eben noch NICHT
alle Anforderungen überblickt.
Entsprechend muss man häufig die gewählte (Teil-)Lösung
nachträglich erweitern und an die zwischenzeitlich neu
gewonnenen Erkenntnisse anpassen.

Dazu kommt, dass ein geeigneter großer Mikrocontroller,
der aktuell nicht lieferbar ist, deutlich weniger Wert
ist als ein "eigentlich" zu kleiner, der schon vorhanden
ist.

Es kann also eine Vielzahl von Gründen geben, warum "das
ganze externe Gelumpe" sinnvoll ist.

Norbert schrieb:

> Damit will ich sagen das man sich das ganze externe Gelumpe komplett
> sparen kann, wenn man von Anfang an den Prozessor richtig und den
> Anforderungen entsprechend auswählt.

Na toll. Diese Auswahl ist einfach.

Schon wesentlich schwieriger wird es, wenn man dann auch noch einen 
Prozessor auswählen will, der in absehbarer Zeit als Einzelstück 
lieferbar ist und (bei diese Randbedingung) keine 100€ oder gar noch 
mehr kostet...

Ja, die Spielregeln haben sich ein wenig geändert in den letzten 2 
Jahren...

Wenn du das nicht mitbekommen haben solltest: Guten Morgen, du 
Schnarchnase!

c-hater schrieb:
> Schon wesentlich schwieriger wird es, wenn man dann auch noch einen
> Prozessor auswählen will, der in absehbarer Zeit als Einzelstück
> lieferbar ist und (bei diese Randbedingung) keine 100€ oder gar noch
> mehr kostet...
>
> Ja, die Spielregeln haben sich ein wenig geändert in den letzten 2
> Jahren...
> Wenn du das nicht mitbekommen haben solltest:
> Guten Morgen, du Schnarchnase!

Sieh an, er nu wieder. In seiner allseits bekannten widerlichen Art.

Er ist verfügbar. Und er kostet als Prozessor allein 0,99€.
Für all diejenigen welche den Lötkolben auch gern mal an der falschen 
Seite anfassen. Platine: 4,10€
Aber was rede ich bei dir…

Jörg W. schrieb:
> und das ist letztlich an Einfachheit

> _kaum_
Da stimme ich dir zu!

> noch zu unterbieten.