Von Fujitsu gabs auch mal einen netten kleinen DSP. War wohl extra für BT gestrickt, und dann auch so vermarktet worden. Leider bald wieder eingestampft. Für lowerend Audio-Bastler wäre er der ideale kleine DSP gewesen, da sogar die AD/DA auf dem Chip. Hieß irgendwas mit Whisper.
Es gibt noch den Audio-DSP von
formatting link
Macht mit seinen 24 Bit Combochips bis 50kHz hochklassiges Audio. Allerdings eingentlich eher ein DSP-FIR Filter. Er kann kaum mehr. Schade, da günstig in allen Belangen.
Dieses ewige Hickhack wegen der Kosten für die Entwicklungsumgebung ist einfach nur nervig und unverständlich. Wollen die nun Chips verkaufen oder nicht? Mir schwant da, daß diese Preise nur zur Abschreckung unattraktiver Kleinkunden eingeführt wurden. Damit hat man dann schonmal die Bastler und ihren Support los. Filtern der email-Adressen beim Login tut dann das übrige. GMX und die anderen werden nicht akzeptiert, z.B. bei Micronas.
100% auf der nach unten offenen kapitalistischen Richterskala.
Man kann sogar mit TLL-IC's ein Videospiel bauen, in einer der Elektor-Ausgaben so um 1978 war das als Artikel drin, ich hab' das zu meiner Schulzeit gelesen ;-) Allerdings war der Computer mit SC/MP doch interessanter ;-)
Ich hab' die Jahreszahl mal bewußt stehen gelassen, damit klar wird, wie alt diese Technik wirklich ist, wir unterhalten uns hier bei den 8/16 Bit Microcontrollern locker um eine
25-30 Jahre alte Technologie, auch 8048 & Co kamen damals auf.
Das man das alles machen kann ist klar, ich hab' damals auch DRAM-Leiterkarten zu meinem 6502/Z80 Kombi- Computer selbst gefädelt, die 56 kByte RAM waren damals schon _sehr_ viel Speicher, Floppy ging per Spezial-UART Controller und das Disk-OS für den 6502 hatte ich selbst geschrieben (Z80 war CP/M). Irgendwann kam dann ein Z80 ECB System mit sagenhaften
1 MByte RAM dazu.
Man kann bestimmt aucht das TFT per Transistorgrab ansteuern (Röhren könnte etwas problematisch werden, Spannung und Takt ;-)
NUR: Zumindest mich reizt das nicht mehr, ich betrachte inzwischen das Reinquetschen_mit_Gewalt von Software auf unterdimensionierte Hardware als verlorene Lebenszeit und die Welt bringt es auch nicht weiter.
Wenn absehbar ist, dass es wirklich nur einen PIC oder
8051 braucht, dann nehm ich den auch, wenn es aber nach mehr riecht, dann wird eben was größeres verbaut.
Man baut eine Maschine schließlich auch nicht nur aus M3-Schrauben zusammen, Motto: "ich nehme keine M6".
Es gibt genügend CPU's, die preiswert sind und mit denen soetwas gescheit geht. Aus Erfahrung mit "ich hätt gern noch unbedingt dieses Feature" Kunden rate ich inzwischen dazu, den Speicher (und somit Adressraum) jedenfallls um den Faktor zwei bis drei überzudimensionieren. Das füllt sich schon ganz von alleine, ob man will, oder ob man nicht will. Die Kunden sind da sehr einfaltsreich ...
Und, was hat der Krampf dann gebracht ? Irgendein bedeutendes Problem gelöst ? Die Energiekriese beseitigt ? ;-)
Prozessoren wie ARM & Co sind erfunden, man kann sie nutzen. Dichte FPGAs sind erfunden, man kann sie nutzen.
Und wer zu träge ist, um neue Architekturen und Sprachen zu erlernen, dem empfehle ich, sich eher in Branchen wie dem Schreinerhandwerk oder Weinbau umzusehen, da hat das "das haben wir schon immer so gemacht, das haben wir noch nie anders gemacht" durchaus seine Berechtigung. In der Elektronik ist man mit dem zwanghaften Festhalten an
20 bis 30 Jahre alter Technik schnell aus dem Geschäft.
Gruß Oliver
P.s.: Es gibt durchaus _einige_ Möglichkeiten, wie man heutige CPU's und Controller besser machen kann, siehe z.B. die hier von mir schon mal angeschnittene automatische Compilierung von Funktionsvarianten und Auswahl der für eine Konstellation schnellsten zur Laufzeit per CAM. Die modernen FPGA-Bausteine bieten da wirklich ganz hervorragende Möglichkeiten, neue Architekturen realitätsnah zu testen, und die FPGA-Software ist zumindest für die kleinen und mittleren FPGAs kostenlos aus dem Web ladbar (Webpack). Vor 20 Jahren hätte man von den Möglichkeiten nur geträumt, ich empfehle, die Träume wahr werden zu lassen, statt auf dem ewig Gestrigen rumzureiten.
|> Mir schwant da, daß diese Preise nur zur Abschreckung unattraktiver |> Kleinkunden eingeführt wurden. Damit hat man dann schonmal die Bastler |> und ihren Support los. Filtern der email-Adressen beim Login tut dann |> das übrige. GMX und die anderen werden nicht akzeptiert, z.B. bei |> Micronas.
Apropos Micronas:
Micronas ist eine Firma, die nur für Leute gern produziert, die mindestens eine Million Chips abnehmen. Allen anderen kommen sie ziemlich arrogant entgegen, selbst erlebt... Und da sie von Heuschrecken regiert werden, sind sie sich auch nicht zu schade, eine erst vor zwei Jahren zugekaufte Firma, die einen recht guten und konkurrenzfähigen h264-STB-Decoder entwickelt hat, mit ca. 1 Monat Vorankündigung einzustampfen. Es hat halt noch etwas an der SW gefehlt, aber das war den Damagern wohl nicht glaubhaft zu machen.
Meine Anwendung geht inzwischen im wesentlichen und wird verkauft, die Chips sind noch länger verfügbar, daher ist das jetzt nur ärgerlich, aber nicht schlimm.
Aber die (zumeist kleineren) anderen Firmen, die mit dem Chip gerade am Entwickeln eines Produkts sind (da gibt es mindestens noch fünf), können froh sein, wenn sie das nicht mit in den Bankrott reisst. Allein die Entwicklungs-HW hat mehrere 10k$ gekostet.
Das war jedenfalls mein letzter eindesignter Micronas-Chip...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
In article , Henry Kiefer writes: |> Georg Acher schrieb:
|> > Das war jedenfalls mein letzter eindesignter Micronas-Chip... |> |> Hättest du mich vor 2-3 Jahren zu Micronas gefragt, wäre dir das |> erspart geblieben.
Ja, man sollte lernfähig sein. Ich war es noch nicht. In der DR Box 1 (entwickelt ca. 1999, dann verkauft von Terratec) steckt als DA-Wandler der DAC3550 drin. Der hat auch lustige Effekte beim Umschalten von 48 auf 24kHz produziert. Da scheint es ihm intern die PLLs etwas versetzt zu haben und er hat die I2S-Daten je nach Laune ein Bit nach links oder rechts verschoben gewandelt. Kann recht laut werden... Anfragen bei Micronas haben ausser "haben wir noch nie gehört, können wir uns gar nicht vorstellen" nichts ergeben. Und nachdem da ja nur einige tausend Stück abgenommen wurden, blieb das auch unterm Support-Radar.
Ich habe Wochen lang rumgefummelt. Am Ende war es dann ein 220pF-C gegen GND an einer I2S-Leitung in Verbindung mit einer fummeligen Reset-Sequenz. Nein, Reflektionen, Setup/Hold oder gar falsche Taktflanke war es alles nicht.
|> Firmen wie Microchip haben vorgemacht, das man auch mit vielen oftmals |> Kleinkunden genug Substanz zusammenkriegt. |> |> |> Mit meinen Prognosen liege ich meist richtig. Hier heißt sie einfach, |> das es Micronas in 10, max. 20, Jahren nicht mehr gibt.
Ich tippe 5.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Ich lese gerade "iWoz" von Steve Wozniak, sehr schönes Buch. Da beschreibt er z.B. wie er den Floppycontroller des Apple II entwickelt hat und wie stolz er auf ihn war. Ein Pong-Spiel hatte er sich auch für zuhause selbstgebaut, nachdem er es mal als Arcade-Spiel gesehen hatte, bevor es die überhaupt zu kaufen gab.
Ich konnte Mittwoch übrigens mein EZ430-F2013 in der Conrad-Filiale abholen. Am Wochenende bin dann endlich dazu gekommen, die Software zu installieren und mir ist wieder aufgefallen wie wenig ich IDEs mag. Naja, schaunmer mal, ob ich da einen Einstieg finde.
Gruß Henning (der bei Reichelt gleich noch einen MSP430-F2013 in DIP bestellt hatte)
Hab' ich schon in Erwägung gezogen, flashen muß ich ja aber trotzdem mit dem IAR-Tool, die USB-FETs (vor allem meines mit Spy-by-Wire) laufen WIMRE noch nicht mit dem alternativen Flashtool.
Mensch, da habe ich aber ein Thema aufgegriffen. Wollte hier ja nicht als Troll durchgehen, aber danke an alle, die sich beteiligt haben.
Demnach komme ich zunächst zu dem Schluss, dass ich mich mal mit den ARM Controllern befassen werde. Also werde ich erstmal damit ein kleines bis mittleres Projekt machen, um mich mit den Entwicklertools ein wenig vertraut zu machen und die Architektur zu verstehen. Das TFT verschiebe ich dann erstmal.
Sonst ist die Ansteuerung ja vom Prinzip her doch verständlicher als ich dachte. Aber zum Leiterplattenentwurf- gibt es da eigentlich ein Tutorial dazu? Denn ich habe es zwar häufig gemacht und auch erfolgreich, jedoch gibt es so viele Dinge zu beachten, die ich z.Z. immer mehr nach gut dünken mache. Zum Beispiel ab wann wird die von Oliver angesprochene Massefläche benötigt? Ab wann wirken sich Induktivitätsbeläge aus und wie findet man dennoch einen Weg? Das alles zusammengefasst in einem Werk zu haben wäre von Vorteil.
WinARM oder besser, setze Dir ein Linux-System (Debian Etch) auf und packe dort die scratchbox
formatting link
rein. Dann brauchst Du für die Emulation nur noch QEMU ;-).
Frag mal Tante Google, es gibt soviele fertige ARM-Boards, auch im DIL Format, zu vernünftigen Preisen wo quasi nur der Controller drauf ist, da lohnt das selbermachen nicht wirklich.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Das klingt sehr gut. Obwohl ich hier immer von einer Windowskiste schreibe verwende ich eigentlich nur Linux.
Aber QEMU- korrigiere mich, wenn ich falsch liege- das benötigt man doch nur, wenn man auf dem ARM auch ein Betriebssystem drauf hat, oder? Die Frage, die sich für mich nämlich z.Z. stellt ist: Ab wann braucht man eigentlich eins? Welche Vorteile bieten sich gegenüber dem selbstgeschriebenen Programm mit der typischen Endlosschleife an? Die einzelnen Prozesse und deren Prioritäten?- ist das alles? Denn Speicherverwaltung haben die meisten miniOS wie ucLinux nicht, oder?
Mit QEMU kann man ja Programme für den ARM-Controller unter x86 Linux laufen lassen. Das geht natürlich nur bedingt, denn die Ports usw. hat man ja nicht wirklich.
Ich arbeite überwiegend mit ARM9 Controllern. Und da habe ich einen Kernel 2.6.xx, Busybox, einige Lib's usw. drauf. Der Vorteil ist, dass Du Dich z.B. um TCP/IP nicht kümmern mußt. Allerdings ist das wirklich nur Linux-Programmierung auf einer anderen Hardware-Plattform.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
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.