Ja, deine Frage war ja wortwörtlich: "...wo tut er dann ein halbes Megabyte pro Sekunde hin?". Es ging erstmal nur ums 'verschlucken'.
Da hatte ich ne Antwort, nicht?
Du hattest nicht gesagt, *was* mit den 500k/s gemacht werden soll und auch nicht gefragt, *wie*.
Was soll denn damit gemacht werden? (FFT?)
Ich weiss ja noch nichtmal, ob die 4MBit/s gerade mal für insgesamt zwei Sekunden einlaufen oder permanent. Das wäre ein wichtiger Unterschied, Letzteres ein k.o. Kriterium für die ganz kleinen uC.
Ausserdem: Ausser für FFT wüsste ich jetzt nicht, wozu man überhaupt
4Mbit/s samplen muss.
Und auch da isses fraglich, wenn man sich die verfolgten Zwecke mal genauer anguckt.
This page uses the Isomorphic SmartClient application framework (Version
2, 4/17/02), which requires: ... Netscape Navigator version 4.5 - 4.79 on Microsoft Windows, Mac OS, and Unix (Limited support for Mac OS and Unix) ... Last updated April 17, 2002.
THIS SERVICE IS ONLY OPEN TO CUSTOMERS WHO HAVE DIRECT PURCHASING AGREEMENTS WITH NXP. If you do not have a direct account with NXP our network of global and regional distributors is available and equipped to support you with NXP samples. You can locate the NXP authorized distributor of your choice _here_.
Was genau damit passiert, darf ich nicht sagen. Aber es ist moderat. Fehlererkennung und so, und die Daten kommen auch nur einige Sekunden. Theoretisch ginge es also, aber nicht bei 20% freier CPU. Ein groesserer uC kann es packen.
Was ich mit dem ganzen nur andeuten wollte ist, dass SPI bei "voller Suppe" ueber die Grenzen eine zu kleinen uC gehen kann.
Das ist bei Infineon auch noch so, ganz grausam. Viele der Distries sind da sehr bemüht, aber werden vom Halbleiterhersteller nur ganz schlecht bedient... Wie das auf Dauer funktionieren soll ist mir auch nicht klar. Man schafft's als einfache Entwickler mit Missionsabsichten nicht mal bis zum Produktmanagement oder Marketingfritzen durchzukommen, um ihm mal zu erzählen, welch vielfälltige Gesichtspunkte bei einem Design-In so eine Rolle spielen... Das müssen ganz schlimme Strukturen sein in diesen großen Läden. Gruß Ing.olf
Ja, ging aber leider nicht, der hat nur 4 I/O. Ich brauchte alle sechs: Horizontal/vertikale Polarisation, High-/Lowband, dann DiSEqC In/Out (in diesem Fall wollte der Kunde nur in, ohwohl die SW 2.0 war) und drei pin für die kundenspezifische Sache.
Aber stimmt, für einen Standard LNB wäre ein 10F202 passend. Wenn die kundenspez. Sache rausfällt und noch n bischen Code optimiert wird, sogar in einen 204er.
Dann würde allerdings Jörg wieder mit dem Finger auf mich zeigen und sagen:" Siehste, sag' ich doch, 90% mindestens... :))
Na ja, für die Standardsachen bekommt man andererseits bereits fertig programmierte Bausteine von Eutelsat höchstpersönlich regelrecht hinterhergeschmissen...
P.S.: Ganz ausreizen mag ich das ROM auch nicht, ich halte mir immer gerne noch genügend Platz, um z.B. noch bei Bedarf mal eben ein paar Diagnoseroutinen hinzufügen zu können.
Von jeder Software die ich mal ausgeliefert habe und die noch irgendwo rumwerkelt, habe ich auch ein Referenzexemplar an uC incl. 'Testboard' hier rumliegen, der zusätzliche getestete Diagnoseroutinen enthält. Wenn's mal Probleme gibt nehme ich den mit und setze ihn beim Kunden ein (bzw. übwrspiele dessen Software), dann ein portpin abgelötet und LED angehängt und siehe da, die Maschine verrät dann per Blinkcodes was ihr u.U. nicht behagt.
Bei dem o.g. slave war's auch so: Kunde meines Kunden rückte mit embedded PC an und meinte, meine Software würde nicht richtig laufen, nur 'ab und zu mal'. Tschja! Der Diagnosechip blinkte dann: 'pulse count error' und 'parity bit error', letzteres war auch die Ursache für die Fehlfunktion.
Ging schneller, als bits am Speicheroszi zu zählen, was wir dann aber trotzdem noch gemacht hatten. Dummerweise trat der parity- Fehler in der DiSEqC-SW des embedded PC nur sporadisch auf, nicht regelmässig. Mussten wir ne ganze Weile 'singleshotten' bis es endlich mal deutlich zu sehen war.
Ging übrigens gut aus, die Geschichte: Nach Telefonat des Kundenkundeningenieurs mit seiner Firma und ausgedehnter Mittagspause war dann eine email mit neuer Software eingetroffen und ab da 'spielte' der embedded PC auch :)
Was sich ja auch in den finanziellen Ergebnissen dieser Firmen wiederspiegelt. Ich frage mich nur, ob und wann mal Leute mit Ahnung dort das Szepter uebernehmen. Bevor es zu spaet ist ....
Dann kann der Watchdog keinen reset mehr auslösen - man braucht also einen zweistufigen Watchdog: erst einen NMI, der den I2C-Transfer beenden kann, und dann ein Reset hinterher, für wenn die Software sich im NMI aufhängt. Ein gescheit funktionierender Reset wäre deutlich einfacher.
Wenn der I2C-Master kein uC ist, und der Reset von extern kommt, wird es noch kniffliger - viele PCI-Slave-Chips können heute ihre initiale Config aus einem EEPROM laden. Wenn dann während des Ladevorgangs ein weiterer Reset kommt (was die PCI-Spec definitiv nicht verbietet), werden die Register nicht korrekt geladen. Die Chips, die statt I2C ein TWI-EEPROM nehmen, haben diese Probleme nicht, brauchen aber 1-2 Pins Extra.
cu Michael
--
Some people have no respect of age unless it is bottled.
Wenn ein I2C master mitten in der Kommunikation aussteigt, warum auch immer, dann müssen die slaves halt von selbst wieder möglichst rasch alle Busleitungen freigeben und schnell in ihren Ausgangszustand zurückfinden (watchdog z.B.) und dann auf die nächste Start-Bedingung warten wie sonst ja auch.
Wenn slaves ewig auf nichtmehr eintreffende clocks warten, arbeiten sie halt fehlerhaft. Bei keinem Bussystem kann es sich eine Komponente erlauben, den Bus einfach ewig zu blockieren, das ist trivial.
Was ist jetzt überhaupt das Problem?
PCI-Slave? Von was für Systemen sprichst du?
PCI...???
statt Bus lieber Speicher nehmen??? Bahnhof?
TWI ist identisch mit I2C, ausser dass keine Lizenzgebühren fällig werden an Philips weil es ja anders heisst.
Geht es dir um eine fehlerhafte I2C Implementation auf einer PCI Karte?
"When a slave doesn't acknowledge the slave address (for example, it's unable to receive or transmit because it's performing some real-time function), the data line must be left HIGH by the slave. The master can then generate either a STOP condition to abort the transfer, or a repeated START condition to start a new transfer.
If a slave-receiver does acknowledge the slave address but, some time later in the transfer cannot receive any more data bytes, the master must again abort the transfer. This is indicated by the slave generating the not-acknowledge on the first byte to follow. The slave leaves the data line HIGH and the master generates a STOP or a repeated START condition.
If a master-receiver is involved in a transfer, it must signal the end of data to the slave- transmitter by not generating an acknowledge on the last byte that was clocked out of the slave. The slave-transmitter must release the data line to allow the master to generate a STOP or repeated START condition."
/Zitat Ende
Also drei argumentative Abschnitte:
Wenn der slave seine Adresse nicht mitbekommen hat --> nochmal.
Wenn der slave sich zwar angesprochen fühlte aber nun mitten im nettesten Gespräch keine Daten mehr bekommt --> nochmal.
Wenn der master sich lange genug angehört hat was der Slave so rückerzählt --> nächste Anweisung...
In allen Fällen: SDA darf vom slave nie über längere Zeit gepullt werden, was logisch ist denn damit blockiert er den Bus.
Und in allen Fällen: Nur der Master steuert die in den drei Ab- schnitten angesprochenen Zustände (Drum ist ER ja der master, er verteilt die Zigarre namens START bzw. STOP :)
Und eine STOP-Bedingung oder ein repeatet START des master bringt den slave stets in den idle-state zurück. Steht da doch dreimal, oder?
Etwas detaillierter zusammengefasst nach Abschnitt II:
Fall 1: Der Slave quittiert nicht, der Master startet neu via STOP bzw. repeated START. Soweit ok.
Fall 2: Der Slave quittiert nicht *weil der Master abgek..ähem*. Nach langer, langer Zeit hat der Master dann endlich resettet und... kommt mit einem START. Warum sollte er nach einem reset an STOP denken? Aber die ODER-Bedingung, die in allen drei Abschnittsfällen der oben zitierten Spec. steht, sollte dem slave bzw. dessen SM aus- reichen. Nicht?
Hängt alles daran, dass der Slave SDA loslässt. (SDK ja sowieso)! Oder?
(und dass der Entwickler der slave-SM den Abschnitt 7.2 gelesen hat)
Nicht bei 2ps... wie weit kommt das Licht im Vakuum in 2 ps? Die anderen Beispiele von mir sind genauso haarsträubend!
Man kann daraus natürlich schlussfolgern dass Softwareent- wickler immer furchtbar ineffizient anfangen, wenn solche Faktoren 'drin' sind.
Ja, sind sie! Fangen immer mit einer viel zu allgemeinen Lösung an, benutzen stets den langsamen, allgemeinen 'Standard- algorithmus' u.s.w. u.s.w. u.s.w.
Eine solche Optimierungsreihe hatte ich tatsächlich mal vor Jahren für eine Schulung durchgezogen, auf einem Kleinrechner mit
6509 Prozessor, 2 MHz Takt (CBM 610). Aufgabe: Das allseits beliebte Mandelbrötchen backen in 300x200 S/W, wenn ich die Auflösung recht erinnere.
Erste Lösung von den Teilnehmern 'straight forward' in Hochsprache umgesetzt: Man konnte zusehen wie die Pixel einzeln im Sekundentakt gesetzt wurden, bei höheren Iterationstiefen dann auch deutlich langsamer, gerne 10 Sekunden pro pixel und mehr... Nach 35 Stunden etwa war die Grundmenge fertig, 'tiefer reinge- zoomt' am inneren Rand der Menge hätte es ein vielfaches davon gebraucht, 100 oder 200 Stunden vielleicht. Natürlich nicht ausprobiert.
Dann das ganze Programm an Optimierungsmöglichkeiten durchgezogen, am Ende konnte man per Pfeiltasten durch die Menge reisen, fast...so alle acht, zehn Sekunden etwa ein kompletter Bildaufbau. Man hätte es sogar noch weitertreiben können, Symmetrieeigenschaften z.B. wurden gar nicht ausgenutzt bzw. getestet (nur Beschleunigungen implementiert, die immer funktionieren).
Das ist dann so etwa Faktor 10^4. Wenn auch ein Extrembeispiel, aber möglich. Mein Lieblingsspruch: "Faktor 10 geht immer!" (Irgendwann natürlich nicht mehr, aber irgendwann ist immer ein Schritt später, frühestens... *g*.)
Wenn eine Hardware zu 80% ausgelastet ist, ist das Ende der Fahnenstange in Sicht. Wenn eine Software sich 80% CPU Zeit schnappt, bedeutet das noch gar nix. Ein Optimierungsschritt weiter sieht das möglicherweise schon wieder ganz anders aus.
Hoffe, jetzt ist klarer geworden was ich ausdrücken wollte... und warum man eigentlich bei typischen Controlleraufgaben (Steuerungen, Kommunikation) am Ende immer leicht bei kleinen Bausteinen landen kann.
Harte "con's" sind fehlender Speicher, bei rechenintensiven Sachen auch fehlende schnelle Multiplikation.
Für einen Hahnenschrei ist fehlender Speicher schon eine harte Nuss, drum hatte ich dazu auch nix zu sagen, sicherlich keine leichte Aufgabe das zu machen. (Ich würde vielleicht in Richtung DPCM gehen...)
"Joerg" schrieb im Newsbeitrag news:OS7ui.44644$ snipped-for-privacy@newssvr12.news.prodigy.net...
Windows selbst (2.0, 3.1, 3.11) war rasend schnell, aus deinen Worten hoere ich Unkenntnis, du hast dich nie damit beschaeftigt, du hast dir nicht den Source-Code zu Windows angeguckt, du hast offenkundig nie versucht, dasselbe schneller zu implementieren.
Das Drama kam erst mit 32 bit Windows, als die guten Win16-Entwickler durch den unfaehigen Herrn David Cutler von DEC abgeloest wurden. Egal wo man reinguckt, die Implementation ist falsch und uneffizient und strukturell eine Katastrophe.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.