Hallo, was sind denn die üblichen verdächtigen wenn man auf der suche nach einem uC ist der eine FPU haben soll und möglichst wenig pins hat? Benötige an IO eigentlich nur einen 8Bit ADC mit mind. 100kS/s und zwei I2C. Also prinzipiell würden ich da ja mit z.B. 16 Pins insgesamt auskommen, 32 oder 48 wären auch noch i.O.
Vllt. so Richtung STM32F3. Weiß aber grade nicht genau wie viele Pins die haben. Aufjedenfall viel ADC und so und auch FPU. Ist aber ARM Cortex-M4.
Klaus schrieb: > was sind denn die üblichen verdächtigen wenn man auf der suche nach > einem uC ist der eine FPU haben soll und möglichst wenig pins hat? Brauchst du nur eine FPU, egal wie dünn und langsam, oder brauchst du Rechenleistung? Minimum bei den STM32F3 wäre LQFP48.
:
Bearbeitet durch User
A. K. schrieb: > Brauchst du nur eine FPU, egal wie dünn und langsam, oder brauchst du > Rechenleistung? Minimum bei den STM32F3 wäre LQFP48. Am schönster wären ja ca. 2 Mio. float-Multiplikationen pro Sekunde + ein paar Integer Operationen. Wenn es das nicht gibt muss ich mir etwas anderes überlegen.
Klaus schrieb: > Am schönster wären ja ca. 2 Mio. float-Multiplikationen pro Sekunde + > ein paar Integer Operationen. Das langt locker.
Wo kommt denn dein Input für die benötigten 2 MFLOPS her? Aus dem 8bit-ADC? Fällt mir gerade schwer nachzuvollziehen, wozu du pro 8bit-Wert 20 float-Operationen benötigt... Eventuell ist da noch Spielraum, dass Programm zu vereinfachen?
Möglicherweise käme er mit Festkommarechnung und einem dsPIC33 aus. Die gibts auch in DIP18/SO20. Das ist zwar nicht kleiner als LQFP48, hat aber weniger Pins.
:
Bearbeitet durch User
kein Gast schrieb: > Wo kommt denn dein Input für die benötigten 2 MFLOPS her? Aus dem > 8bit-ADC? > Fällt mir gerade schwer nachzuvollziehen, wozu du pro 8bit-Wert 20 > float-Operationen benötigt... Eventuell ist da noch Spielraum, dass > Programm zu vereinfachen? das mit den 100kS/s stimmt doch nicht so ganz wenn ich genau darüber nachdenke. Ich will einen CCD Zeilensensor mit 128px mit mindestens 20kHz auslesen, muss aber nicht immer alle 128px verarbeiten oder überhaupt wandeln. Hatte ursprünglich an 128 x 100kS/s gedacht ^^
@ Klaus (Gast) >nachdenke. Ich will einen CCD Zeilensensor mit 128px mit mindestens >20kHz auslesen, muss aber nicht immer alle 128px verarbeiten oder >überhaupt wandeln. Hatte ursprünglich an 128 x 100kS/s gedacht ^^ Und was führt dich dann zu der Annahme, unbedingt eine FPU zu benötigen? Festkommaarithmetik ist oft deutlich sinnvoller.
Falk Brunner schrieb: > Und was führt dich dann zu der Annahme, unbedingt eine FPU zu benötigen? > Festkommaarithmetik ist oft deutlich sinnvoller. Das sehe ich anders. Beispielsweise sind auf einem ATmega 32Bit-float Rechnungen schneller als 64Bit-Integer (IAR als Compiler). Warum soll ich mich mit dem eingeschränkten Wertebereich und evtl. Genauigkeitsverlust durch Unterlauf herum ärgern wenn ich dadurch keine Geschwindigkeitsvorteile habe. Zumal es mir bei privaten Projekten völlig egal ist ob ein uC 1,50€ kostet oder 8€.
@ Klaus (Gast) >Das sehe ich anders. Beispielsweise sind auf einem ATmega 32Bit-float >Rechnungen schneller als 64Bit-Integer (IAR als Compiler). Wirklich? Sind die FLoat-Rechungen so gut optimiert oder die 64 Bit so schlecht? Wobei 64 Bit auf dem avr gcc bisher sehr schlecht waren, auch 32 Bit war nicht sehr gut. > Warum soll >ich mich mit dem eingeschränkten Wertebereich und evtl. >Genauigkeitsverlust durch Unterlauf herum ärgern wenn ich dadurch keine >Geschwindigkeitsvorteile habe. Zumal es mir bei privaten Projekten >völlig egal ist ob ein uC 1,50€ kostet oder 8€. Ja, natürlich.
Klaus schrieb: > was sind denn die üblichen verdächtigen wenn man auf der suche nach > einem uC ist der eine FPU haben soll und möglichst wenig pins hat? Ti C2000 Serie, so zum Beispiel TMS320F28062PN im 80LQFP für eta 5,00EUR@1k. rgds
Klaus schrieb: > 8Bit ADC mit mind. 100kS/s und zwei > I2C LPCexpresso board mit Programmer für 24€: Schafft 180kS/s mit 12bit ADC
Man beachte die Aufgabenstellung >das mit den 100kS/s stimmt doch nicht so ganz wenn ich genau darüber >nachdenke. Ich will einen CCD Zeilensensor mit 128px mit mindestens >20kHz auslesen, muss aber nicht immer alle 128px verarbeiten oder >überhaupt wandeln. Hatte ursprünglich an 128 x 100kS/s gedacht ^^ Wozu braucht man hier so viele Float-Operationen?
Microchip hat ganz tolles Patent: Ein µC mit weniger Pins als die Datenleitung Bits hat. Das heißt für die anderen Hersteller: 8 Bit µC: Mindestens 8 Pins 16 Bit µC: Mindestens 16 Pins 32 Bit µC: Mindestens 32 Pins Oder halt Lizenzgebühr bezahlen...
Der schrieb: > Oder halt Lizenzgebühr bezahlen... Wieviel hat NXP für den LPC810 (32 Bits, 8 Pins) gezahlt? ;-)
Der schrieb: > Microchip hat ganz tolles Patent: Ein µC mit weniger Pins als die > Datenleitung Bits hat. Also entweder du hast eine Referenz darauf oder ich schieb das in Gedanken in die Rundablage. Sowas als Patent ist nicht mal im Gottesstaat haltbar.
:
Bearbeitet durch User
Schon wieder jemand, der nicht weiß, was er will. Die Anforderungen haben sich im Laufe des Threads doch schon geändert.
vielleicht weil die Auswahl eingeschränkt wurde...denkt doch einfach mal nach bevor ihr schreibt!!
Michael H. schrieb: > Der schrieb: >> Microchip hat ganz tolles Patent: Ein µC mit weniger Pins als die >> Datenleitung Bits hat. > > Also entweder du hast eine Referenz darauf oder ich schieb das in > Gedanken in die Rundablage. Sowas als Patent ist nicht mal im > Gottesstaat haltbar. U.S. Patent 5,847,450: http://www.google.com/patents/US5847450
A. K. schrieb: > Der schrieb: >> Oder halt Lizenzgebühr bezahlen... > > Wieviel hat NXP für den LPC810 (32 Bits, 8 Pins) gezahlt? ;-) Das kann ich dir leider nicht sagen, auf jeden Fall haben sie ein Patent darauf: U.S. Patent 5,847,450: http://www.google.com/patents/US5847450
Klingt aber so als würde das pro Port zählen, also zahlt da auch Atmel schön für seine Tinys...
Was es nicht alles an Patenten gibt... Aber dann kann es ja nicht lange dauern, bis jemand einen 32-Bit µC rausbringt, der intern mit einem kostensparenden 4-Bit Bus implementiert ist. Bei 200MHz Takt ist das immer noch schnell genug für viele Aufgaben. Es gab ja schon mal einen 8-Bit Motorola µC, der bitseriell implementiert war.
:
Bearbeitet durch User
Der schrieb: > Michael H. schrieb: >> Der schrieb: >>> Microchip hat ganz tolles Patent: Ein µC mit weniger Pins als die >>> Datenleitung Bits hat. >> >> Also entweder du hast eine Referenz darauf oder ich schieb das in >> Gedanken in die Rundablage. Sowas als Patent ist nicht mal im >> Gottesstaat haltbar. > > U.S. Patent 5,847,450: > http://www.google.com/patents/US5847450 Ob der Claim zu halten ist, wenn da jemand dran rütteln will? In der Patentbeschreibung wird immer mal wieder zwischen n-Bit Architecture und n-Bit Datenbus gewechselt. Diese sind aber nicht äquivalent (siehe 386er). "a microcontroller having an n-bit architecture with less than or equal to n pins coupled to the microcontroller " "Microcontroller having an n-bit data bus width with less than n I/O pins" Zudem: "an IC chip with a microcontroller having a data bus;" Nimmt schonmal alle Harvard Architekturen aus. ... Ergo ein Patent super für den Firmenwert und die Statistik, fachlich jedoch erst nach einer Prüfung durch Patentgerichte belastbar.
Maxx schrieb: > "an IC chip with a microcontroller having a data bus;" > > Nimmt schonmal alle Harvard Architekturen aus. Wieso? Auch die haben einen Datenbus. Sogar - in klassischer Vorstellung - exakt einen, obwohl das Patent nur mindestens einen verlangt. Auf dem anderen Bus sind Befehle unterwegs, nicht Daten. Man könnte aber einem 64-Bit µC einen z.B. 6 Bit breiten Peripheriebus spendieren, auf dass dann Horden von Juristen endlich einmal die auch unter Experten umstrittene Frage klären, was genau denn eine n-Bit Architektur ausmacht und was genau der Datenbus ist.
:
Bearbeitet durch User
Maxx schrieb: > Ergo ein Patent super für den Firmenwert und die Statistik, fachlich > jedoch erst nach einer Prüfung durch Patentgerichte belastbar. Ich frag mich ja, wo bei dem Patent die Schöpfungshöhe versteckt ist. Im wesentlichen beansprucht das Patent doch, Pins (am Gehäuse) über ein Konfigurationsregister (SFR, RAM, EEPROM, ...) mit unterschiedlichen Funktionalitäten belegen zu können, welche der µC in das Konfigurationsregister schreibt. Dabei werden die unterschiedlichen Funktionen durch entsprechend viele Funktion Blocks (FBs) geschaltet und durch das Konfigurationsregister gesteuert. Als Einschränkung ist die Anzahl der vorhandenen und so konfigurierbaren Pins <= der Bitbreite (des Datenbus') des µC. Ist das so etwas fundamental Neues, daß man das patentieren kann?
Patente waren VIELLEICHT vor langer Zeit mal eine sinnvolle Erfindung, um eben jene wirtschaftlich gewinnbringend nutzen zu können. Heute ist das längst ein zur Farce verkommenes System von Unsinn und Juristenkrieg. Mit technischer Innovation hat es längst nix mehr zu tun.
A. K. schrieb: > Maxx schrieb: >> "an IC chip with a microcontroller having a data bus;" >> >> Nimmt schonmal alle Harvard Architekturen aus. > > Wieso? Auch die haben einen Datenbus. Sogar - in klassischer Vorstellung > - exakt einen, obwohl das Patent nur mindestens einen verlangt. Auf dem > anderen Bus sind Befehle unterwegs, nicht Daten. Im Rechtsgebrauch sind es Daten. Im technischen Sinne sind es Daten (mit Struktur und Bedeutung). Sie werden typischerweise gar permanent im genannten uC in einem entsprechenden Speicher abgelegt. Das Patent verlangt übrigens exakt einen. "_An_ IC chip" "having a databus" die Bedeutung von "einem" kann an dieser Stelle nicht als "mindestens einen" ausgelegt werden, da diese Regelung dann auch auf das "An IC" ausgelegt werden müsste" und man folglich das ganze Patent ausser acht lassen kann wenn ein 2. IC mit der fehlenden Pinzahl existiert. > Man könnte aber einem 64-Bit µC einen z.B. 6 Bit breiten Peripheriebus > spendieren, auf dass dann Horden von Juristen endlich einmal die auch > unter Experten umstrittene Frage klären, was genau denn eine n-Bit > Architektur ausmacht und was genau der Datenbus ist. Korrekt. Bis dahin würde ich dem Patent nicht allzu viel technische Beachtung geben. Es ist ein Rechtsmittel, dessen technische Grundlagen a) schwammig definiert und deren Interpretation b) umstritten sind. Es müsste auch dei Weite der Gültigkeit geklärt werden. Jeder aktiver bzw. rechnende Sensor (z.B. Temperatur mit Feuchte Kompensation) an dem 1,2 oder 3 Wireinterface könnte ebenfalls unter die Definition uC mit IO Pins < Datenbusbreite fallen.
Johann L. schrieb: > Ist das so etwas fundamental Neues, daß man das patentieren kann? Bis zum juristischen Gegenbeweis offensichtlich schon. Ich frage mich freilich schon eine Weile, ob Bedeutung und Finanzierung von Patentämtern vom Durchsatz erteilter Patente abhängt. Sollte man vielleicht vom Durchsatz abgelehnter Patente abhängig machen. ;-) Jedenfalls hat das Patentamt es durchgewinkt. Netterweise sind es üblicherweise zwei Paar Stiefel (d.h. getrennte Prozesse), (1) einen Patentanspruch durchzusetzen und (2) ein Patent für ungültig zu erklären. (1) geht meist viel schneller, so dass das Ergebnis von (2) viele Jahre später kaum noch relevant ist und wohl auch keine rückwirkenden Konsequenzen auf bereits abgeschlossene Lizenzverträge hat.
Maxx schrieb: > Im Rechtsgebrauch sind es Daten. > Das Patent verlangt übrigens exakt einen. Dann ist die Sache ja total einfach und Microchip hat die Patentgebühren zum Fenster raus geworfen: Kein real existierender Prozessor der letzten Jahre hat exakt einen Bus. Auch nicht als von-Neumann und die Cortex-M Cores mit ihren getrennten Befehls- und Datenbussen sowieso nicht. Wenn alle Busse, die von Bits statt Insassen genutzt werden, Daten transportieren, dann sind das dieser Definition zufolge alles Datenbusse.
:
Bearbeitet durch User
Maxx schrieb: > Im Rechtsgebrauch sind es Daten. > Das Patent verlangt übrigens exakt einen. Gegen diese Interpretation spricht, dass Microchip besagtes Patent 2006 gegen Luminary Micro in Stellung gebracht hat, obwohl der Cortex M3 im Kern eine Harvard-Architektur hat. Ich weiss aber leider nicht, wie die Sache ausging.
:
Bearbeitet durch User
>Ob der Claim zu halten ist, wenn da jemand dran rütteln will?
Das gabs schon lange vor (dem Anmeldedatum) '96!
Fraglich, ob es da jemals ein Patent dafür gegeben hat.
MCUA schrieb: > Fraglich, ob es da jemals ein Patent dafür gegeben hat. Unnötig, da prior art ein Patent auch ohne vorheriges Patent ungültig macht. Andernfalls könnte man heute noch das Rad patentieren. NB: Welcher Vorgänger käme da in Frage? 4-Bitter und Motorolas bitseriellen 6805 sollte man dabei vorsorglich ignorieren.
:
Bearbeitet durch User
Das Patent ist doch eh sehr speziell: - Jeder Funktion Block (FB) ist mit genau einem Pin verbunden. - Jeder FB hat nur eine Konfigurationsleitung. - Jeder FB hat nur eine Leitung zum µC. Hat man auf dem IC zum Beispiel eine UART, die an mehreren Pins (TxD, RxD) hängt und auch mehrer Leitungen zum µC hat (zum Datenregister), passt das schon nicht mehr in das o.g. Schema, denn der UART läßt sich nicht in der gezeigten Art in FBs "faktorisieren".
A. K. schrieb: > Dann ist die Sache ja total einfach und Microchip hat die Patentgebühren > zum Fenster raus geworfen: rolleyes Neben rechtlichen und technischen Aspekten gibt es immer noch politische, marketingtechnische und vielleciht rein personelle Aspekte eventuell für ein solches Patent. In einem offiziellen Patentverfahren möchte ich behaupten ist dieses Patent nicht durchsetzbar. Im Rahmen eines größeren Patentstreits mit dem Ziel eines Vergleichs oder Lizenzverhandlungen über eine Reihe von Patenten aber sicher probates und wirksames Mittel.
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.