grüss euch, ich habe mich bis jetzt mit den standard-8051 controllern befasst. doch auf dauer sind die 8 bit doch langweilig... deshalb frage ich mich, ob es etwas ähnliches wie 8051er gibt, das ebenso einfach zu handhaben ist (leichter hardware-aufbau, gratis-software wie assembler usw. verfügbar), billig und - mit 16 bits (oder natürlich mehr, aber ich denke das wird schwer auf lochraster aufzubauen). diesbezüglich habe ich es mir zwar schon überlegt, einen prozessor wie den 80186 oder 286 zu nehmen, aber die idee habe ich inziwschen wieder fallen lassen. zu kompliziert... hat jemand von euch eine idee?
Ich bin im Moment ebenfalls dabei, auf 16 Bit-Controller umzusteigen, habe mir von der Fa. Beck den IPC ausgeguckt (SC12), da das den Einstieg sehr erleichtert. Kern: 80186, läßt sich mit C (Borland C-Compiler) und Pascal (TP 7.0) compilieren, Mutitasking-DOS. Ausserdem hat er eine eingebaute Ethernet-Schnittstelle, und das wichtigste für mich war: es gibt eine tolle Seite von go-black, wo sehr viel Beispiele (mit Schaltplan/Software) zur Verfügung getellt wird. z.b. Anbindung an CF-Card, Intenet-Anbindung...
@werner: das liest sich toll... aber ich denke mal, der controller ist alles andere als billig? ausserdem scheint mir multitasking reichlich kompliziert zu sein (täusche ich mich?). ist es möglich so ein board auf lochraster zu bauen? ein wichtiges kriterium, denn ich habe nicht vor, ein fertiges board zu kaufen. da geht ja der ganze bastelspass verloren ;)
Der Preis des Controllers beträgt bei Beck 89 Euro netto. Das coole an dem Chip ist, es läßt sich sehr wohl auf Lochraster aufbauen (32Pin-DIP-Gehäuse) und braucht nur 5V Versorgung (ausserdem keine weitere Zusatzbeschaltung (zb. ext. Quarz). Wenn man mit dem Chip ans Netz will, ist nur noch ein Übertrager erforderlich (ca. 6 Euro) und fertig. Ich habe mir den Chip auch erst im Dezember zugelegt und gleich mal eine CF-Karte angeschlossen (Platine habe ich selber gemacht), hat fast auf Anhieb geklappt (kleines Problem: Die CF-Karte muss formatiert sein). Da ich bisher nur mit 8051'ern gearbeitet habe, und nicht sooo viel Zeit habe, fiel die Wahl auf diesen Chip. Auf der Internetseite www.goblack.de ist alles sehr gut dokumentiert (angefangen von der Beschreibung des Chips und dessen Möglichkeiten bis hin zu einer Einführung in C (was ich dabei auch lernen möchte). Ziel des ganzen ist dann eine Haussteuerung mit diesem Chip.
was ich noch vergessen habe zu erwähnen: es sollte möglichs ein, den controller direkt zu programmieren (also ohne spezielles programmiergerät). beim 8051 habe ich eine relativ elegante lösung gefunden: man legt code- und datenspeicher übereinander und kann dann über den UART-anschluss per RS232 eine hex-datei oder was auch immer runterladen und im RAM speichern. reset und schon läuft das programm... so etwas sollte natürlich auch möglich sein. ein controller, den ich zum programmieren immer aus der fassung nehmen muss wäre reichlich mühsam.
Den SC12 kann man ohne Programmiergrät betreiben, einfach die Datei entweder per Netzwerk oder seriell rüberschieben und fertig.
@werner: nun, die fast 90 € sind dann doch ein bisschen viel (das sind immerhin über 130 schweizer franken ;)). wenn ich bedenke, dass ich meinen teuersten 8051er (den SAB-C517A von siemens) für 22 franken bekommen habe, ist das schon ein etwas grosser unterschied. aber ansich wäre der chip ne überlegung wert, wenn eine abgespeckte version ohne LAN und multitasking existiert (beides benötige ich nicht und werde es wohl kaum programmieren können).
Tobias Plüss wrote: > ich habe mich bis jetzt mit den standard-8051 controllern befasst. doch > auf dauer sind die 8 bit doch langweilig... Was ist denn daran bloß so langweilig ? Hast Du wirklich schon alles gemacht, dann aber her mit den Beispielen. Ethernet, CAN, MP3, I2C, Frequenzmesser, Grafikdisplay, Matrixtastatur, Scheduler, FAT32, PWM, Motorsteuerung, Automatisierung, Robotik usw. braucht hier alle naselang jemand, immer her damit. Ich lern auch gerne dazu. Ich finde, der 8051 kann nie langweilig werden. Ich könnte Tag und Nacht programmieren, wenn ich bloß die Zeit dazu hätte. Ich habs ja schonmal gesagt, für 16-Bitter sehe ich Null-Potential. Da sind einfach die ARM7 (LPC2xxx) zu populär. Bloß deren Interruptsystem ist nicht sonderlich praxisorientiert (spurious Interrupts, kein automatisches Löschen der Flags), sonst gehen sie aber. Also entweder 8-Bitter mal richtig ausloten oder gleich 32Bit. Peter P.S.: Schau Dir mal die Silabs 8051-er an, die haben richtig Power unterm Hintern (100MIPS). Selbst so ein kleiner C8051F330 (DIP-20 Gehäuse) läßt manchen anderen MC ganz schön alt aussehen.
Multitasking: habe ich auch noch nix mit gemacht. Ohne Lan: kostet genausoviel (aber doppelte Geschwindigkeit) Ich habe mal bei Beck nachgefragt, ob es günstigere Möglichkeiten gibt: ==> NEIN. Ich habe mich vor allem wegen der Lan-Geschichte dafür entschieden, da ich im Moment keine Lust habe, mich mit dem ganzen Protokoll-Zeugs zu beschäftigen, ich aber einen Webserver bauen will, und dazu taugt der ganz gut.
@peter: das mag sein, aber es ist z.b. unnötig aufwendig, wenn man schon nur mal einen 12-bit ADC-wert evrrechnen möchte. oder mit float-zahlen.... ich weiss, das ist nicht so professionell, aber im geschäft übe ich auf einem controllerboard mit dem motorola MC68332. der hat 32 bit... und wenn ich sehe, was ich damit alles kann, dann sieht der 8051 doch recht alt aus. aber der 8051 hat natürlich auch seine vorteile. leicher assembler,, bitmanipulationsbefehle (was der 68332 leider nicht hat...), einfach zum aufbauen... möchte halt mal auch noch was anderes anschauen als nur die 8 bit ;)
> das mag sein, aber es ist z.b. unnötig aufwendig, wenn man schon nur mal > einen 12-bit ADC-wert evrrechnen möchte. Was bitte ist daran aufwendig? Macht doch alles der Compiler...
Tobias Plüss wrote: > @peter: > das mag sein, aber es ist z.b. unnötig aufwendig, wenn man schon nur mal > einen 12-bit ADC-wert evrrechnen möchte. oder mit float-zahlen.... Ne, dann sind nicht die Bits Dein Problem, sondern die Programmiersprache. Ob 12, 16, 32 Bit oder float, das macht doch der C-Compiler. Das hat nicht das geringste mit der internen Datenbreite zu tun. Wenn Du nicht gerade alle Schleifenzähler als float deklarierst, sondern immer den Datentyp nimmst, der günstig ist, dann stehen Dir auch bei 8Bit alle Wege offen. Lerne erstmal C, dann kannst Du ja immer noch auf 16 oder 32bit umsteigen. Anders gesagt, ohne ne leistungsfähige Programmiersprache nützen Dir interne 16 oder 32 Bit nicht das Schwarze unterm Fingernagel (so hart es klingen mag, aber so ist es nunmal). Peter
Schon klar, aber ADC-Wert berechnen klingt jetzt nicht nach Extrems-Performance, so dass Assembler Sinn macht.
@alibi: ich sage ja auch nicht, dass ich extreme performance möchte. das mit dem adc war ja auch nur ein beispiel. wie willst du auf einem 8051 mit überschaubaren code gleitkommazahlen verwenden? das geht nicht. dann musst du irgendwie mit integer-artihmetik dich herumschlagen und dann werden deine werte automatisch grösser und du musst einzelne zahlen über x register hin verteilen. also ich für meinen teil finde das sehr mühsam, denn auf einem 68332 nehme ich für eine solche ebrechnung lediglich irgendein register und das läuft, weil 32 bit. aber der 68332 ist teuer und der aufbau auf lochraster nicht möglich.
@peter: ich kann c, ich verwende den sdcc. aber ich habe flot-berechnungen nicht zum laufen gebracht... immer wenn ich etwas berechnete und dann auf dem lcd ausgegeben habe ist anstelle des richtigen resultats die meldung <NO FLOAT> aufgetaucht. ist ja auch egal... natürlich sind 8 bit mikrocontroller nicht übel. aber ich finde es gerechtfertigt, auch mal was anderes ausprobieren zu wollen ;)
Tobias Plüss wrote: > aber ich habe flot-berechnungen nicht zum laufen gebracht... immer wenn > ich etwas berechnete und dann auf dem lcd ausgegeben habe ist anstelle > des richtigen resultats die meldung <NO FLOAT> aufgetaucht. Nö, das liegt nicht am 8Bitter, sondern daran, daß Du das Compiler-Manual nicht gelesen hast. Interessant, daß er dann wenigstens die richtige Fehlermeldung ausgibt und nicht einfach nur abstürzt. Standardmäßig werden die float Funktionen nicht dazugelinkt, sondern man muß sie erst mit den angegebenen Compilerschaltern aktivieren. Das hat den Grund, daß ein "Hello World" nicht gleich 8kB groß sein muß, sondern schon in nen AT89C2051 (2kB) passen soll. Peter P.S.: float ohne printf braucht beim Keil nur etwa 1kB. Ich haber daher auch einige AT89C2051 Projekte, die intern float benutzen. Daher kostet der Keil eben auch etwas.
@peter: ja das mag sein. ist ja auch egal, lass uns nicht mehr darüber streiten ;) du hast ja gesagt, wenn schon sollte man besser 32 bit mikrocontroller verwenden. kannst du mir dazu mal einen konkreten nennen? würde mich doch interessieren, wenns auch wahrscheinlich nicht möglich ist, sowas mal schnell zu basteln.
Der 68332 kostet afaik um die 10€, ist also nicht teuer. Auf lochraster geht der natürlich schwer, aber geht ;) Und Multitaskingsachen, z.b. beim ipc, macht doch eh das OS. Man muss halt nur einige Dinge beachten, die nicht so schnell passieren können, als wenn man nur ein Programm drauf laufen hat.
Tobias Plüss wrote: > ist ja auch egal, lass uns nicht mehr darüber streiten ;) Ich wollte gar nicht streiten, sondern nur aufzeigen, daß sämtliche bisher genannten Probleme definitiv nicht in den 8 Bits fußen sondern allesamt andere Ursachen haben. Daher sind sie weder mit 16 noch mit 32 Bit zu beheben. > du hast ja gesagt, wenn schon sollte man besser 32 bit mikrocontroller > verwenden. > kannst du mir dazu mal einen konkreten nennen? Ich benutze zur Zeit den LPC2292 auf ner 4-Layer Platine (CAN, Ethernet: LAN91C96). Es sollen aber irgendwann auch LPC2xxx im PLCC-44 rauskommen, die könnte man dann in Standard-Sockel stecken. In der Regel ist aber >8Bit nur in SMD (TQFP, BGA). Peter P.S.: Den LAN91C96 habe ich schon am 8051 benutzt (8Bit-Bus, internes Adreßlatch), also mit Null Zusatzbeschaltung.
@peter: ich denk mal, wenn >8 bit in smd ist, wirds auch plcc-typen geben? oder täusche ich mich da?
@SiO2: du hast den 68332 für 10€ gesehen? man staune... das einzige angebot für einen MC68332 habe ich für 70 franken (45 €) gesehen.
Tobias, >> ich kann c, ich verwende den sdcc. aber ich habe float-berechnungen nicht >> zum laufen gebracht... immer wenn ich etwas berechnete und dann auf dem >> lcd ausgegeben habe ist anstelle des richtigen resultats die >> meldung <NO FLOAT> aufgetaucht. Die standard printf Funktion kann beim SDCC aufgrund von Speichermangel nur bei externem XRAM verwendet werden, deshalb <NO FLOAT>, ist doch nett vom Compiler das er dir das sagt. Aber, printf_fast_f (Bestandteil von SDCC) kann es ;-)) Beispiel: printf_fast_f ("%f ", meine_float_variable); Das geht auch im Speichermodell small da die Funktion sehr "schlank" ist. @ Peter, toll was der Keil so alles kann, der SDCC kanns auch, allerdings erheblich preiswerter ;-))
Tobias, mir fällt gerade auf das wir das Thema schon mal diskutiert hatten, leider hast du dann auf deinen Thread nicht mehr reagiert. Wie dem auch sei, siehst ja meine Antwort. Zu 16 BIT, muß ich Peter recht geben, ich programmiere AVR's, 8x51 Derivate und die 16 BIT MSP Typen. Das tut sich alles nichts. Wenn, dann nimm nen 32 BIT Controller. Allerdings hat C, SDCC und 8x51 noch eine ganze Menge zu bieten.
Joe wrote: > @ Peter, toll was der Keil so alles kann, der SDCC kanns auch, > allerdings erheblich preiswerter ;-)) Das ist ja erfreulich zu hören. Mein Keil ist von 1995 und damals war der SDCC kaum der Rede wert. Ich hab als Freeware nur den AVR-GCC in Gebrauch und da ist in 2kB mit float absolut nichts zu machen. Da muß es mindestens schon ein ATmega8 sein. Und beim ARM7 darf man dann nicht mehr aufs Flash schauen, das geht weg wie warme Semmeln. Es sollten mindestens 256kB sein. Peter
Ja Peter, der SDCC hat sich wirklich gemacht. Ich kenne den Keil nur aus den 80ern unter DOS. Ich weiß auch das er gut ist, aber für manch einen einfach nicht bezahlbar. Ich habe die SDCC Entwicklung eine Weile verfolgt und mich an BUG reports beteiligt. Mittlerweile ist der SDCC aus meiner Sicht sehr gut. Noch erfreulicher ist die Reaktionsgeschwindigkeit der Sourceforge Jungs bei Problemen. Selbst an einem Sonntag Abend bekam ich nach 3 Stunden einen BUGfix. Allerdings ist Lesen, Lesen, Le... angesagt. Und statt meckern konstruktive Mitarbeit. Auf diese Weise werden ja die freien Compiler besser und besser. AVRGCC macht sich aus meiner Sicht auch nicht schlecht. Auf kleinen MC's muß man halt wissen was geht und was nicht. Also ich bin den Sourceforge Kollegen jedenfalls dankbar für Ihre Tools.
@joe: ja du hast recht, das thema hatten wir schon mal... allerdings ging es dabei eher darum, ob man einen 80186 für solche anwendungen verwenden kann und wie oder ob das zu komplex ist. ich hab mich dann noch etwas weiter mit dem thema befasst, und tatsächlich scheint es uf den ersten blick einfacher zu sein, einen solchen prozessor richtig zu beschalten, dass alles läuft, als es ist. übrigens: danke für den tipp mit printf_fast_f. scheint einen versuch wert zu sein ;) ich schau mich aber auf jeden fall noch weiter nach neuen controllern um... es juckt mich in den fingern, mal was neues anzufangen ;) aber ich hab nicht gesagt, dass ich mich den 8051ern abwenden werde. die haben definitiv ihre vorteile. es grüsst tobias
Tobias, dann laß dein Ergebnis mal hier einfließen, wenn irgendetwas nicht funktioniert dann sag bescheid, ich helf dir beim SDCC ;-))
ok ich meld mich bald wieder... aber nicht mehr heute, denn jetzt ist feierabend ;) irgendwann muss ich auch noch zu abend essen ;)
tag auch, habe erst vor kurzem in einer ausgedienten steuerung einen HD68HC000 gefunden. ein 16/32 bit controller im plcc 68 gehäuse! genau sowas hab ich gesucht ;) kennt jemand von euch ne website, die sich mit solchen controllern befasst? ich programmiere im geschäft zwar auf einem motorola prozessor MC68332, der ja aus der selben familie stammt, aber mit dem entwurf von boards für einen 68000 habe ich (noch) keine erfahrung. wenn jemand was weiss... ich freue mich über jede auskunft ;) grüsse tobias
HD68HC000 ist kein Controller, sondern ein nackter Mikroprozessor. An den musst Du noch Takterzeugung, Peripherie, Speicher (RAM & ROM) sowie etliche Logik anschließen, bevor auch nur ein bisschen Programm läuft. Der asynchrone Bus des 68K macht das Design auch nicht gerade einfach; aber Beispiele dafür findest Du in sehr alten c't-Ausgaben. Heft 7/88, Seite 156 beschrieb den c't EPAC/68000, einen Einplatinenrechner mit 68000 drauf. Die (damals noch existierende) Konkurrenz "mc" aus dem Franzis-Verlag hatte einen EMUF 68K (oder so ähnlich) im Programm.
ja das meinte ich eigentlich... ram und rom muss dran. und dann nat¨rlich noch irgend eine I/O-möglichkeit... im web gibts nichts schalues dazu meinst du? gegoogelt habe ich bereits. ;)
Bitte 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.