Porterweiterung per SPI

Jul 30, 2007 101 Replies

"Joerg" schrieb:

Klingt aber in meinen Ohren ein bischen wie:"Eine Katze und mein Radio sind auch im Grunde identisch, denn es gibt in dieser Welt ja nur die wenigen Elemente, die im Periodensystem aufgezeichnet sind und der Rest ist blosse Statistik, inhomogene Verteilungen..."

Natürlich kann man sagen, dass die Digitalbausteine auf denen Automaten implementiert werden auch nix anderes sind als schnelle Analogtechnik.

Aber Modelle sollen ja gerade neben ihrer praktischen Anwendbarkeit auch Unterscheidungsfähigkeit fördern, nicht verwischen.

Wobei ich, zurück zu den Automaten, denke, dass der Unterschied zwischen 'diskret' und 'stetig' hier gar nicht mal so wichig ist, sondern:

Der Begriff "Automat" impliziert für mich vor allem, dass die Übergangsbedingungen zwischen den einzelnen Zuständen modellierbar sind. Grad' das macht ja den Automaten nach meinem Verständnis aus bzw. dieses Modell nützlich.

Da haperts doch bei Analogschaltungen, da geht das nur in toto über die Übertragungsfunktion.

Beispiel: Selbst wenn wir annehmen dass ein simpler Verstärker ein Eingabealphabet (Eingangssignal U) in ein (endlich oder nicht, egal) Ausgabealphabet (A * U) überführt und dabei verschiedene innere Zustände annimmt (etwa, wie weit er momentan gerade ausgesteuert wird) so ist der Übergang von einem inneren Zustand zum anderen nicht "einzeln" modellierbar sondern nur insgesamt für die ganze Maschine = Verstärker. (Beim invertierenden OP z.B. über zwei Widerstände). Natürlich kann man nun Großsignal- und Kleinsignalverstärker bauen, aber was am Ende rauskommt gilt immer für den gesamten Automat, hupps, Verstärker natürlich.

Gerade das scheint mir ein wichtiger Unterschied zu sein! Der lineare Automat bekommt seine Funktionalität durch die detaillierte Modellierung der Übergangsbedingungen verpasst, nicht so sehr durch die Anzahl der nodes; diese minimiert der Entwickler ja sogar so weit es geht (Mealy statt Moore u.s.w). Wichtig ist, dass die Übergänge zwischen den Zuständen frei modellierbar sind.

Diese freie Modellierbarkeit der Übergangsbedingungen verweist auf eine hohe Abstraktionsebene des Modells, also denke ich Vergleiche auf 'niedriger Hardwareebene' sind dann doch etwas fehl am Platz oder besser, wenig nützlich oder aussage- kräftig.

Was mir noch zu 'Automat und Analogtechnik' einfällt:

Man unterscheidet ja deterministische und nicht deterministische Automaten (bei denen dann ein Übergang von einem Zustand in den anderen möglich, aber nicht zwingend ist, übrigens unabhängig davon ob der Prozess der das steuert selbst deterministisch oder nicht ist...).

Da ist bei Analogtechnik auch immer beides vermischt, nicht? Denn neben der gewünschten deterministischen Funktion (U_aus = A * U_ein) gibt's da ja immer stochastische Anteile (Rauschen) und systematische Anteile (Temperaturdrift etwa) die sozusagen untrennbar, natürlich modellierbar in Grenzen, in der 'Analogmaschine' drin sind.

Das Automatenmodell setzt hier aber schon eine vollzogene Trennung vor- aus (Die Automatenzustände driften nicht mit der Temperatur und rauschen auch nicht:), auch dies ein Hinweis auf eine höhere Modell-Abstraktions- und praktische Implementationsebene.

Automatenmodell ist dann wohl erst sinnvoll in einer 'digitalen' Welt anwendbar (Solange der Störspannungsabstand stimmt und kein Ground bounced:) und dort auch erst ab einer gewissen Abstraktionsebene (die Zeit muss mit rein, nicht rein kombinatorisch).

Klar, auf niedriger Abstraktionsebene mag man an Gemeinsamkeiten denken, allerdings wirds dann auch wieder trivial (siehe ganz ganz oben, die Katze und das Radio).

|> Man unterscheidet ja deterministische und nicht deterministische |> Automaten (bei denen dann ein Übergang von einem Zustand in den |> anderen möglich, aber nicht zwingend ist, übrigens unabhängig davon |> ob der Prozess der das steuert selbst deterministisch |> oder nicht ist...).

Das mit nicht-deterministisch ist aber nicht wirklich mit Rauschen zu vergleichen. Denn jeder NEA mit spontanen Epsilon-Übergängen kann in einen deterministischen Automaten überführt werden...

Was man bei dem ganzen Automatengedöns berücksichten muss, ist dass die "theoretischen" Automaten eigentlich dazu da sind, in einem bezeichneten Endzustand zu landen, also zu überprüfen, ob eine Zeichenfolge der Grammatik entspricht. Der Weg dahin ist recht uninteressant. Daher kann man sich die Epsilon-Übergänge auch zunutze machen, mehrere Möglichkeiten quasi gleichzeitig auszuprobieren. Der Gag an den Epsilons ist ja, dass man sie praktischerweise immer dann spontan nimmt, wenn der Weg tatsächlich in einen Endzustand führt ;-)

Bei einem "technischen" Automaten dagegen ist fast immer auch die Ausgabe über den Weg in den Endzustand wichtig. Designierte Endzustände zB. bei Protokoll-Statemachines sind auch meistens auch gar nicht vorhanden oder nur im Fehlerfall benutzt.

Georg Acher, acher@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

"Joerg" schrieb:

:)

Einer meiner Kunden sitzt in Stockport, Vorort von Manchester. Üblicher- weise komme ich dort nachts an und werde nachts wieder zum Flughafen gebracht, aber einmal war es doch anders: Auf meine Frage "Was für ein typisches Souvenier könnte ich denn noch besorgen in den paar Stunden, die noch verbleiben" gab's erst lange Gesichter bei den Herren Ingenieueren (wohl ne unübliche Frage?) und dann unisono: "Ein T-shirt

*Manchester United* natürlich!" :))

(Ich hatte mir dann eine Kaffetasse aus dem 'tourist information' geholt *g*)

Upps. Doch ne ganze Menge... (Mal überschlagen: Bei 100 Ohm für Treiberausgang gedaumpeilt und 50 mal sagenwirmal 15p Eingang&stray angesetzt komme ich auf w/2pi ganz deutlich unter 4 MHz... Also direkt mal gefragt: Wie hoch ist die reale Transferrate bei 50 devices SPI?)

Stimmt, das ist die Restriktion bei I2C. SPI ist schnell, ja.

Ich sag mal kurz, was ich mache und meine Einschätzung der beiden seriellen Buskonzepte folgt daraus. Wer was anders macht, schätzt dann natürlich anders, klar!

Erstens: Ich verwende in meinen Projekten nur 8-pin und 18-pin uC. Grösser kommt/kam nicht auf die teure Platine, bisher!

18pin heisst: 14 oder 13 I/O, also ausreichend für alles (parallel+decode) 8 pin heisst: 4 oder 3 I/O und für gar nix ausreichend ausser I2C.

Die Notwendigkeit der Hardwareadressierung bei SPI (über decoder auf chip enable) ist dann das k.o.-Kriterium: Die kleinen Bausteine haben keine portpin mehr frei und die "Grossen" brauchen es nicht, da parallel schneller und vor allem billiger.

Der Vorteil von I2C ist halt, dass es bei zwei Leitungen bleibt, der Rest ist Software!

Zur Geschwindigkeit des Busses: Wenn ich den seriellen Bus dort einsetze wo er nötig ist wg. Pinmangel habe ich i.d.R. auch keine SPI-Hardware on chip d.h. ich muss eh alles per bit-banging machen. Da passen 100bit/s klasse, 400 ist Luxus, zumal der uC ja noch etliches Anderes machen soll ausser Transfer. Dazu kommt, dass typische slaves ihre eigenen Wartezeiten mitbringen (AD-Wandler.... serielles EEPROM gar gigantische

5ms/Schreibzyklus und mehr. (Ok, gibt FRAM, aber boutique wie du zu sagen pflegst :) ). 4Mbit vs. 400kBit ist Faktor 10, aber zwischen us und ms liegt Faktor 10°3;. Ich meine, das relativiert sich dann doch...

Wenn es schneller gehen soll und muss, dann halt ein paar cent mehr für den 18pinner + Platinenfläche und gleich parallel ausgeführt.

Natürlich würde ich auch, wenn wirklich nötig, den nächst 'höheren' uC nehmen. Aber oft ist es nicht nötig von der Rechenzeit her... Nur Portpin sind immer knapp...

Um aber 50 Bausteine per SPI anzusteuern, als Beispiel, brauche ich weitere 6 Portpin für decode in SPI, dann könnte ich es auch gleich parallel machen wenn ich die hätte zumal die Software (bei fehlender SPI HW) das auch viel besser ünterstützen würde...

Also Fazit: Ich sehe den Sinn von SPI nicht so richtig! Ausser, dass ein paralleler Bus auch Platinenfläche braucht, ok. Aber da gibt's auch Möglichkeiten (ich baue sowas dann gerne in 3-D... nein, nicht teurer Multilayer sondern Steckmodule o.Ä. wenn möglich :)

Na ja, ich hab ja auch nicht behauptet dass SPI schlecht wär, sondern eher... nicht vergleichbar. SPI hatte ich bisher nie eingesetzt bzw. wenn doch mal etwas in diese Richtung (Schulungsboard) dann schnell selbst gestrickt, z.B. mal 8 Siebensegmentanzeigen über einen 164er SR und 139er decode gemultiplext, das ist so simpel dass es sich nicht Bus schimpfen darf...

Und den grossen Vorteil von I2C sehe ich darin, dass es bei zwei Leitungen bleibt, der Rest ist SW!

Hallo Ruediger,

[...]

Der Prozessor kann derzeit nur bis 4MHz, der Bus ist aber auf viel mehr ausgelegt. Bei 4MHz sehen die Flanken schoen knusprig aus. Da sind aber noch Buffer zwischen, es ist nicht so, dass alle 50 Stellen kapazitiv an MOSI und SCLK saugen.

Ok, dann relativiert sich das alles. Ein normaler kleiner uC kann eh keinen Bus mit Megahertzen bedienen. Da sitzt bei uns schon was dickeres drin.

Ja, aber wenn sich der Bus schon mal aufhaengen kann, dann ist es fuer unsere Designs nicht so geeignet (Medizinelektronik).

Kann man gerissener machen. Z.B. indem die ersten 8 bit eines SPI Transfers immer in ein seriell-parallel Register gehen und das uebernimmt das Schalten.

Ich bin eher ein Freund der "Kuchenblechtechnik". Alles flach und billig.

Allerdings ist neben den erwaehnten Aufhaengern die Auswahl an Chips nicht mehr so dolle. In Europa weiss ich das nicht, die Hersteller dort haben teilweise ihre Web Sites so verbockt, dass man nicht mehr sieht, was sie anbieten.

Gruesse, Joerg http://www.analogconsultants.com
  • Joerg [07-08-04 03:16]:

Die µCs, mit denen ich bisher zu tun hatte (AVR), können SPI mit f/2 als Master und f/4 als Slave, je nach Chip also bis zu 10MHz.

"Lars Noschinski" schrieb:

Die mid-range PICs haben, bis auf die allerkleinsten dieser 'Familie', natürlich auch passende HW on chip. Nennt sich 'master synchronous serial port' und kann wahlweise als I2C oder SPI konfiguriert werden. Da ist die maximale clock rate dann f/4, also 5 Mbit/s bzw. bei den 18er PICs dann 10 Mbit/s.

Die setze ich halt nicht ein... oder andersrum: Die kann ja jeder einsetzen und programmieren (besser: konfigurieren), da braucht man mich nicht...

Na, einmal vor Jahren, hab ich doch sowas verwendet!

(Vorsicht, ab hier nur Anekdote)

Auf einem Schulungsboard das ich gemacht hatte. Kompletter Kleinrechner im Europaformat wurde das mit 4x4 Tastatur, PS2- Anschluss, RS232 Schnittstelle und Druckerport (den noch via PC-Brennprogramm automatisch gemultiplext für die Programmierung). Dann sechs Siebensegmentanzeigen auch simpelst über ein einfaches SR gemultiplext, eine Lauftext- anzeige rein in SW zu basteln war dann mal Hausaufgabe :) 'Mitten im Kurs', der war über ein halbes Jahr angesetzt, konnte man das Siebensegmentgeraffel einfach aus den Sockeln ziehen und dafür ein LCD einstöpseln und fest- schrauben... Dann I2C Bus und SPI sowie I/O nach aussen geführt, ein kompletter port noch mit Treibern verstärkt und in einer Ecke zwei Reedrelais zum potentialfrei klackern lassen, AD-Wandler mit vorgesetztem IA und I2C- DA auch noch drauf... immer noch ein nettes Spielzeug wie ich meine. Nehme ich heute noch gerne in die Hand wenn mal auf die Schnelle irgendwas angesteuert werden soll...

Nun gut, auf dieses board hatte ich mich nicht getraut einen der ganz kleinen PIC draufzusetzen, da wären die Schulungs- teilnehmer sonst wohl enttäuscht gewesen, dachte ich. Also hatte ich es für die 16F87x-Reihe ausgelegt, die haben dann alle möglichen Spielereien on chip (AD, viele Timer, UART, I2C, Capture-Compare, PWM u.s.w.).

Wär' aber *für die Schulung* doch besser gewesen, einen kleineren Baustein zu nehmen! Denn einige Zeit wurde doch damit vertrödelt, die Wochenendspielereien einiger Teilnehmer lauffähig zu bekommen. (Einer hatte sich z.B. ne Tuner auf das board aufgestöpselt und wollte jetzt unbedingt I2C lauffähig haben...).

'Vertrödelt' deswegen, weil die Umsetzung der Angaben aus einem datenblatt ja nicht wirklich 'programmieren' ist, mehr als etwas Sorgfalt braucht's da nicht...

Man hätte also in der Zeit, in der an der "unnützen" HW-on-chip gespielt wurde noch ein paar schöne Sachen machen können, z.B. die erstellte Mathebibliothek noch etwas aufstocken...

Daß _Du_ das nicht mehr siehst :-) Mit aktueller hard-und software geht das dann durchaus *SCNR*

Ja, ich weiß, dennoch sind viele websites Mist, unbestritten.

Ralph.

Hallo Lars,

Klar, auch einige MSP430 mit SPI Hardware auf dem Chip koennen flott kommunizieren. Aber ein uC wuerde sich an der hereinrauschenden Datenmenge verschlucken. Ueberlege mal: Nachdem wir unseren SPI hier eine Sekunde lang mit 4MHz bedient haben, sind rund eine halbe Million Datenworte zu verdauen, waehrend in der naechsten Sekunde nochmal eine halbe Million reinkommt.

Gruesse, Joerg http://www.analogconsultants.com

Hallo Ralph,

Hier hatte kuerzlich (gestern?) jemand berichtet, dass er bei NXP mit einer nagelneuen Firefox Version abblitzte. Tolle Leistung. IMHO gehoert dort die gesamte Web Design Gruppe entlassen und durch faehige Leute ersetzt. Es gibt keine Entschuldigung dafuer, das nach einem Monat immer noch nicht repariert zu haben. Wieso koennen bei uns in der Kirche die Kids eine gescheite Web Site aufbauen und ein hochbezahltes "professionelles" Team in den Niederlanden ist dazu nicht faehig?

Am Ende ist das oft auf mangelnde Kompetenz in den oberen Etagen zurueckzufuehren.

Gruesse, Joerg http://www.analogconsultants.com

"Joerg" schrieb:

Fragt sich, ob als 'verdauen' auch erstmal 'schnell abspeichern' ausreicht?

Bei 8bit Daten und 4Mbit/s muss das SPI-RX Register ja nur alle 2us geleert werden und innerhalb von 2us kann ein uC doch locker 10 Befehle ausführen (200ns/Befehl bei kleinen und mid-range PICs, bei den 'grossen' PICs doppelt so schnell). Andere, modernere kleine Controller eher schneller...

Ich zähle mal ab, zur Grobeinschätzung:

  1. byte aus MISO Register auslesen, ab in den Accu damit.
  2. Interruptflag der SPI HW bedienen (d.h. Software 'quittiert')
  3. byte auf einen (Daten)port für SRAM legen
  4. an zweitem port Adresse hochzählen (oder ext. CNT wenn pin fehlen)
  5. SRAM auffordern das byte einzulesen, d.h. R/W pin setzen.
  6. und schnell wieder löschen.
  7. nop
  8. nop
  9. nop
  10. return from interrupt

Passt doch und hat sogar noch ein klein wenig Luft? Geht also, wenn während der Zeit nix anderes gemacht werden muss.

20% an CPU-Zeit wäre noch frei (rti braucht 2 Zyklen) wie man sieht, es wird also 20% der Zeit auf den nächsten Interrupt der SPI-HW gewartet, die ja inzwischen im Hintergrund munter weiter bits einschaufelt.

Würde also schon auch mit einem kleinen PIC mit SPI-HW gehen, oder übersehe ich was?

Schnelle Datenaquise wär natürlich nicht so toll über I2C, klar :)

Hallo Ruediger,

Noe, das waere so wie "unters Sofa geschmissen". Irgendwann drueckt dann was, wenn man sich aufs Sofa setzt.

Das laeuft bei uns teilweise im Page Modus ab. Da kommen massiv Bytes rein, ohne dass gross Handshake ablaeuft.

Wenn eine CPU schon fuer "House Keeping" zu 80% ausgelastet ist, dann wird es hoechste Zeit, sich nach etwas viel groesserem umzusehen.

Genau selbige brauchen wir in fast jedem Geraet. Geht bei uns ueber SPI locker mit einigen hundert kS/sec.

Gruesse, Joerg http://www.analogconsultants.com

Am 8/4/2007 5:44 PM schrieb Joerg:

Der Fisch faengt immer am Kopf zu stinken an...

have a nice day | Dummheit ist ansteckend, | Verstand wächst sich kaum fritz | zur Epidemie aus. schoerghuber | (Kazimierz Bartoszewicz)

Hallo Fritz,

Aber das andere Ende wird zuerst gestutzt ....

Gruesse, Joerg http://www.analogconsultants.com

"Joerg" schrieb:

Ging mir aber nur um die Aussage, ein kleiner uC könnte das nicht, würde sich verschlucken. Er kann das locker!

Und meine Abschätzung ging natürlich vom kleinsten uC aus, gibt ja wie gesagt auch schnellere.

(Und natürlich optimiert sich mein Vorschlag gleich mal locker um 50%, wenn man das bit-banging anders löst. War ja nur ne Überschlagsabschätzung...)

Ja, da kommt nun noch ein dritter Aspekt dazu den du glaube ich etwas übersiehst in deiner Argumentation:

Wenn du einen Programmierer fragst ob man eine bestimmte Software um den Faktor 10, 100, 1000 oder 10^4 schneller machen kann, wird er ernsthaft über deine Frage nachdenken. Und wahrscheinlich findet er auch eine Lösung. Er hat da einfach ziemlich viele Möglichkeiten, die Grenzen setzt seine Phantasie (und sein Wissen natürlich)!

Frag' das mal einen Hardwareentwickler: "200ns Befehlszyklus ist ja sehr schön aber kannst du den 20cent Controller nicht mal eben für 2ps Zykluszeit umbasteln?" oder "4Mbit/s SPI ist ja sehr schön aber kannst du das mal nicht eben schnell auf 40Gbit/s um- basteln?" "100MHz Oszi ist ja nett, aber kannst du den mal nicht eben schnell für 10 Gigahertz Bandbreite umbasteln?". Vermutlich lacht er dich aus, bestenfalls! Er hat da einfach wenig Möglichkeiten, die Grenzen setzt die Physik, die verfügbare Technik (und sein Wissen natürlich auch).

So gesehen haben die kleinen uC durchaus ihre Berechtigung. Man kann per Hardware (Wechsel vom kleinsten zum grössten Controller) gar nicht soviel 'rausholen' wie mit passender, das heisst hier vor allem _durchdachter_ Software!

Meine Arbeit als Programmierer: Wenn es soweit ist dass die Implementation _anfängt_ ist mein Job praktisch schon abgeschlossen. Meine eigentliche Arbeit sieht eher so aus:

Es fängt immer damit an, dass der Kunde gar nicht weiß was er will!

Dazu kommt, dass er eines dafür ganz sicher weiß und sich auch um keinen Preis ausreden lassen will: Das, was er wollen könnte kann nur auf dem grössten und komplexesten Baustein laufen den man überhaupt bekommen kann. Anders geht schonmal gar nicht!

Vermutlich denkt er: "Sieht so aus als ob ich ein Moped wollte aber zur Sicherheit nehm ich mal das Moped mit dem grössten Motor, dann kann ich das später noch zum Traktor oder zum Schnellboot umbauen".

Was natürlich Unsinn ist!

Tschja, das sind sozusagen die beiden Axiome mit denen meine Arbeit immer anfängt :)

Hab' auch schon oft erlebt dass der Kunde schon was vorliegen hatte, mit dem fettesten Baustein drin und am Ende der Geschichte konnte dann der kleinste Controller den Job ausgezeichnet erledigen. Und der Kunde war glücklich weil er die kompakte Lösung auch detailliert nachvollziehen konnte. (Kompakte Lösung ist immer auch die einfache Lösung).

Konkret mal bei einem Kunden: Er fing in Richtung 16F877 an ("den setzen wir schon woanders ein, auch wenn er dort praktisch nix zu tun hat" doch dann endeten wir bei einem 12C508 in seinem Produkt.

Ungefähr ein Unterschied wie zwischen Containerschiff und Faltboot, um mal mutig im Vergleichen zu sein. Jedenfalls: Der 16F877 ist der Grösste seiner Familie und hat alles an HW on chip, dazu Speicher satt und der 12C508 ist der kleinste seiner Familie und hat gar keine HW on chip ausser einem timer und einen Interrupt :)

Er hatte sich praktisch schon die Triebwerke für ein Space Shuttle eingekauft, aber was er wirklich brauchte war ein Schiffsdiesel für ein kleines Fischerboot. (Es war ein DiSEqC slave mit etwas housekeeping und noch ein paar ganz kundenspezifische Dinge dabei. Also state machine mit DiSEqC 2.0 Befehlsinterpreter im Wesentlichen. 350 bytes code am Ende!)

Nicht untypisch, sowas!

Ausserdem bekommt der Kunde noch Surplus mit der kleineren Lösung: Diese ist nämlich im Vergleich zur Lösung auf dem grossen Baustein die kompaktere, die sorgfältiger durchdachte und daher auch für den Kunden selbst besser zu durchschauende Lösung.

Am Ende ist er damit Glücklicher!

Das Thema ist mittlerweile mega-gähn. Bei mir funktioniert die web site mit dem aktuellen Firefox jedenfalls.

Gruß, Gerhard

Hallo Ruediger,

Aber wo tut er dann ein halbes Megabyte pro Sekunde hin? Unter den Teppich?

Wir haben hier eine fieseren Spruch: Ein Programmierer fuellt mit seinem Programm stets etwa 90% des verfuegbaren ROM aus, egal wie gross das ROM ist ;-)

Die Grenze setzt im allgemeinen ein anderer Faktor: $$

Sehe ich auch so, die Hauptarbeit beim Programmieren ist die Planung vorher. Und eine saubere Dokumentation von Anfang an.

Kenne ich ;-)

O-Ton bei einem Kunden im Februar, als sie die analoge Loesung sahen, wo vorher vier fette Signalprozessoren angedacht waren: "You mean, that's it?"

Gruesse, Joerg http://www.analogconsultants.com

"Joerg" schrieb:

Sagte ich doch schon im letzten posting, in externes statisches RAM. Ein paar cent musste dem kleinen Kerlchen schon spendieren an Zusatzhardware :)

Was ich da skizziert hatte mit den 10 Punkten, war praktisch eine Kopierroutine MISO >>> externes paralleles RAM. Eine Kopierroutine.

Was hattet ihr denn verwendet? Einen embedded PC?

:))

Na, ich aber nicht! Beweis: Mein DiSEqC slave benötigt 350 bytes ROM von 512 insgesamt verfügbaren, das sind 68% und damit weniger als 90%. q.e.d.

:))

Der letzte Speichervernichter in meiner Praxis war aber ausgerechnet ein Hardwareingenieur. Er wollte natürlich seine Finger auf bestimmte housekeeping Sachen behalten und hatte das dann für sich programmiert, mit riesigen Tabellen im ROM, irgendwelche Parametersätze für irgendwelche Dämpfungsglieder waren das glaub'. Und wie gesagt, sie frassen eine Unmenge an ROM weg, es war einfach schrecklich!

Alptraumerregend! :)

Ich hatte ihm dann vorgeschlagen, seine Messwerte einfach an ein Polynom seiner Wahl zu fitten und ich schreibe ihm dann eine Function, die ihm die Parameterwerte wieder passend ausspuckt wenn er ein Argument einfüttert. Die Koeffizienten seines Polynoms hätte er frei konfigurieren können, also immer noch die Finger voll drauf, die einzige Änderung wäre gewesen dass er seine Excel-Tabellen zusätzlich durch ein Polynomfitting hätte laufen lassen müssen.

Aber er wollte nicht! Seufz!

Alleine das hätte mal locker 60% des belegten ROM wieder freigeputzt. Doppelseufz!

Hallo Ruediger,

Ok, das geht. Aber dann sammelt sich das da nur wie der Krempel bei den Nachbarn in der Garage.

Einen, der in ein FPGA gegossen wurde.

Hatte ich auch schon mal. Alles per LUT gemacht, graeuslich. Erst als ich ihm die Funktion in MS-Works als Formel vorfuehrte, war er ueberzeugt.

Gruesse, Joerg http://www.analogconsultants.com

Hallo Gerhard,

Mega-gaehn? Ich glaube, es war Michael Ruebig. Wollte Samples ordern und flog bei der Registrierung raus mit dem Hinweis, IE zu benutzen.

Gruesse, Joerg http://www.analogconsultants.com

Moin!

Na und? Nicht alles muss großartig verdaut werden, bis es wieder ausgeschieden ist - es gibt auch Daten, die einfach so durchlaufen, wie Bier. :-) Hatte erst kürzlich ein Projekt, in dem $Hardware mit einem

200kByte/s-Datenstrom aus einer SD-Karte gefüttert werden musste. War mit einem ATMega88 kein Problem: 2 Hardware-SPIs, 12MHz @ 3,3V (kann mehr, aber Frequenz anderweitig vorgegeben) und groß genug fürs DOS-Geraffel. Die Hardware-SPIs liefen gleichzeitig, das Byte musste nur aus einem Register abgeholt und ins andere geschrieben werden und danach konnte der Controller sich wieder damit beschäftigen, Bytes und Sektoren zu zählen und ein paar andere Dinge zu erledigen. DIP28, EUR 1,88 @ 5Stk.

Gruß, Michael.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required