Eigentlich sollte dieses Wochenende eine Platine angekommen sein, aber ich habe wohl Karneval bei der Lieferzeit nicht berücksichtigt. Zeit also mich ein wenig weiterzubilden und mit meinem neuestem Devboard zu spielen:
formatting link
Bisher habe ich noch nie einen 8051 basierten Prozessor eingesetzt, gefällt mir aber sehr gut, was ich gestern und heute davon gelernt habe. In Verbindung mit LabView kann man viele Aufgaben recht leicht lösen, die hier immer mal wieder in der Newsgroup auftauchen, wie Abfrage von Temperatursensoren, Motorsteuerung usw.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Je nachdem wo sie wirklich gefertigt wird, kann auch das chinesische Neujahr reinspielen. Ist im Februar und die Festivitaeten dauern meist ueber eine Woche. Doch das wird beim Ausliefertermin eigentlich immer von Auftragnehmern eingerechnet, auch wenn sie nur eine Fassade fuer einen China-Fertiger sind.
Der 8051 ist m.W. immer noch der einzige uC, bei dem man zumindest von einigen Versionen 2nd Source bekommt. Das allein wird ihm zu langem Leben verhelfen, da lohnt sich IMHO die Einarbeit schon. Die Keil Tools sind allerdings nicht ganz billig,.
Wenn es nicht haargenau dieselbe Anschlussbelegung und Funktion sein braucht, dann gibt es mindestens 54 verschiedene Firmen mit mindestens 893 verschiedenen Typen, die alle auf der 8051 Architektur beruhen, nach einer Suche hier:
formatting link
. Scheint also tatsächlich sehr beliebt zu sein. Nach meinem kurzen Ausflug letztens zum PIC kann ich das auch verstehen, denn die Programmierung vom 8051 ist auch in Assembler gegenüber PICs eine Entspannungsübung :-)
Ja, das stimmt, aber SDCC sieht auch nicht schlecht aus. Bei Gelegenheit werde ich aber mal eins der vielen Forths, die es in 8051 Assembler schon gibt, versuchen auf dem Silabs-Chip zum laufen zu bringen.
Für eine vielseitiger verwendbare kleine Mess- und Steuerplattform könnte man zusätzlich ein externes SRAM anschließen, was beim 8051 bereits in der Architektur vorgesehen ist, und ein serielles Flash. Kostet jeweils nur wenige Euro und man hat dann für vielleicht 30 Euro Produktionskosten einen Kleinrechner mit 48 MIPS, 256 kB RAM (per Bank-Switching), 2 MB Flash (gibt da preiswerte, die mit bis zu 50 MHz SPI lesbar sind), vielen GPIOs und sonstigen Interfaces, 10-Bit ADCs, sowie Full-Speed USB-Anschluss. In Kombination mit einem kleinen FPGA wäre das eine optimale Kombination für meinen Signalgenerator, denn dann brauche ich nicht FPGA-Zellen und Strom für die in Hardware sowieso bessere CPU zu verschwenden und bekomme noch viel von der USB-Steuerung geschenkt, die in VHDL auch nicht mal eben am Wochenende programmiert wäre.
Bei 80kHz Systemtakt verbraucht der C8051F340 übrigens nur 55uA laut Datenblatt und bei 48MHz auch nicht allzuviele 28.5mA maximal, womit es für Batterieanwendungen gut geeignet wäre.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Waere schoen, wenn es so eine Liste gaebe, die "Form-Fit-Function" kompatible Varianten ausweist. Wo man also sagen koennte, wenn Atmel gerade keine auf Lager hat, kann ich auch bei x, y und z einkaufen. Dann kann man das Design daraufhin abzielen.
Nicht ohne Grund finde ich bei jedem zweiten Design Review wo ein uC drin ist einen 8051 in der Schaltung. In den restlichen Faellen mehrheitlich MSP430, manchmal auch einen PIC. Das sind alles Designs von anderen und irgendwie hat der 8051 dort den Ruf eines VW-Kaefers. Keine Rakete, aber gusseisern ;-)
Aber der SDCC ist nicht gerade toll. Für ernsthafte Anwendungen kommt eigenlich nur der Keil Compiler in Frage. Es gibt allerdings noch von einigen anderen Anbietern Compiler für 8051er, der Keil ist halt der Standard, das gesamte Paket aber nicht gerade günstig.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Bei den "kleinen" PLCC 44 wären AT89C51RD(ED) pinkompatibel mit NXP P89C66x und zu einem von Dallas, falls ich das noch richtig im Kopf habe. Den hatte ich mal ausgewählt, weil er halt von 4 Herstellern pinkompatibel zur Verfügung steht. Müßte ich gegebenenfalls nächste Woche im Büro mal schauen.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Ich hatte die bei PCB-Pool in Auftrag gegeben. War aber, trotz Karneval, doch pünktlich angekommen, nur hatte ich die blöderweise im Karton mit der Lötschablonenmaske übersehen gehabt, den ich zum Glück noch nicht weggeworfen hatte. Sobald also jetzt noch der Controller für den Reflow-Ofen kommt, wo ich leider keine Lieferzeitgarantie hatte, weswegen es wohl länger dauert, wird die Platine gebacken.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Sowas passiert doch heute täglich, oder übersehe ich irgendwelche negativen Auswirkungen?
Das erklärt natürlich die umfangreiche Ausstattung für die ARM Controller. Für ARM gibt es aber einen hervorragenden GCC, für Windows als Paket unter WinARM. Und sowas wie den LPC2194, mit dem liebäugele ich gerade etwas.
Aber das ist andere Technologie, mir fällt nur dabei ein, ich müßte mal mein PK51 wieder updaten.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Okay, ich muss gestehen, ich habe schon lange nicht mehr geschaut.
Vor 2-3 Jahren hatte ich mir den auch mal angeschaut und festgestellt, dass Programme wesentlich größer waren als mit dem Keil, was bei Micro- controllern immer ein wichtiger Aspekt ist. Und ich habe keine Lust den Assembler-Code noch zu Fuss zu optimieren. Das braucht man in der Regel beim Keil nie.
Die direkte Unterstützung von Bankswitching war auch nicht möglich. Beim Keil kann ich in der IDE schon angeben in welcher Bank die jeweilige Funktion oder Gruppe liegen soll. Den Rest macht der Compiler.
Die Keil IDE unterstützt halt auch alle möglichen Derivate mit Eigen- schaften die über die des Ur-8051er weit hinausgehen.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Ich benutzte schon seit vielen Jahren den von diesen hier.
formatting link
Hat mich noch nie im Stich gelassen; ist allerdings auch nicht ganz billig. Der Code ist wirklich hochoptimiert. Wenn man sich mal den ausgespuckten Assemblercode anguckt, würde man das meistens auch so machen. Ich finde ein g'scheiter Compiler ist wesentlich wichtiger als der Core. Da macht es auch nix, wenn's ein 8051 ist. So jetzt darf Oliver wieder lästern. ;-)
Soviel wird der nicht rausholen, vielleicht 2-3 mal schneller? Meist gibt es sowieso nur sehr wenige Hot-Spots, die wirklich sehr schnell ablaufen müssen und die kann man dann auch in Assembler schreiben. Für die meisten Anwendungen wird wohl auch mein angedachtes, interpretiertes Forth-System reichen, was besonders die interaktive Entwicklung im Mess- und Testgerätebereich vereinfachen sollte, wo ich das für angedacht habe.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
ich meine mit g'scheit, dass der Compiler ordentlichen Code abliefert (auch bei sehr komplexen Algorithmen ohne Fehler). Auf die Geschwindigkeit kommt's bei mir eher weniger an. Manchmal würd's sogar ein 32kHz Uhrenquarz tun.
Gibt es da tatsächlich C-Compiler, die fehlerhaften Code produzieren? Kann ich mir beim SDCC eigentlich nicht vorstellen, der sieht schon recht ausgereift aus. Mit meinem Forth-System wird das später dann nochmals leichter, eine fehlerfreie Übersetzung zu garantieren :-)
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Vor allem bei Interrupts! Und Dein Compiler gehört da auch zur besseren Wahl. Einen in dieser Preislage gab es doch noch, mir fällt der Name nicht mehr ein...
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Nein, fehlerhaft ist nicht gemeint. Ordentlicher Code muss es sein. Ich will nicht stundenlang manuell optimieren, das soll der Compiler machen wenn ich schon C verwende. Und das machen die sehr gut.
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.