Hallo, brauche für eine Application zwei UARTs. Wir haben den 87C51U2 noch am Lager, soll aber nicht mehr verwendet werden. Leider sind unsere Softies noch auf dem 80c51 Tripp, weil schon jahrelange Erfahrung. Daher dachte ich zuerst an den P89LPC954 von NXP, könnte aber wegen nur 16kB erasable flash etwas eng werden. Im Post Beitrag "Microcontrollerwahl", war mal die Rede von MSP430xxx oder PIC18Fxx. Bei TI fand ich u. a. den LM3S628. Wie gesagt alles schön und nich zu teuer (Schmerzgrenze, ca. 3Euro), wenn nur nich die c51 Sache wäre. Vielleicht gibt es doch noch einen µC mit c51 Core der 2UARTs Onboard hat und nicht zu teuer ist. Hoffe mal es hat jemand schon mal so was in der Art eingesetzt und kann mir den Typ posten.
>brauche für eine Application zwei UARTs.
Man kann auch eine 2. UART per Software realisieren. Es kommt auf die
Datenrate und sonstige Forderungen an. 9600Bd sollten kein Problem sein.
@Tauwetter ahja, hört sich interessant an, zweite ser. wäre RS485 für PELCO. Habe noch keine gescheite Spec bzgl. Baudrate gefunden, soviel ich weiß 9600bps, mein Kollege sprach aber mal davon dass sie dass in einer älteren App mit 56kbps betrieben haben
@Hans Meier cooler Link, muss mich jetzt mal durchquälen, sieht aber nich schlecht aus
Viele 8051 haben ein PCA, damit kann man prima ne SW-UART proggen. Welche Baudrate brauchst Du denn? Peter
Ich selbst hab mit 8051 angefangen( MSC1210), bin jetzt aber zu PIC für industrielle Designs von Microchip übergewechselt. Wenn man sich "Sofwerker" eh mit Programmierung auskennt, sollte es nicht das einzige Argument sein. Ein Kollege von mir Programmiert seit Jahren PIC und hat innerhalb von drei Tagen einen 8051 Kern programmiert. Also kann es nicht so schwer sein, auf eine andere Prozessorfamilie umzusteigen. ( Meine Meinung ist, wenn man erst mal mit dem 8051 klar kommt, wir man das eine oder andere bei Microchip mit Wohlgefallen zur Kenntnis nehmen und schätzen lernen.) Für ein Industriedesign würde ich immer den Prozessor einsetzen, der für die Anwendung am besten passt, und nicht den, den ich "schon immer" verwendet habe. Die Entwicklungsumgebung von Microchip ist übrigens kostenlos ( Bis auf einen Programmer für 24€ oder eine ICD2 - also Debugger/Programmer - für 200€)
@Frankman: Der Meinung bin ich auch. Sollte ja nicht sooo schwer sein, sich mal auf einen neuen Core einzuarbeiten und somit auch ein wenig mit der Zeit zu gehen. Früher oder später sind die Controller mit den uralt-Cores dann von Abkündigungen betroffen oder so schweineteuer geworden, dass man sie nicht mehr einsetzen kann. Und dann ist das Gejammer groß. Wenn ein Softwareentwickler nicht den geistigen Sprung von einem 8051 auf z.B. einen Cortex schafft, dann ist er meiner Meinung nach fehl am Platz oder einfach nur stinkfaul! Und da hilft meiner Meinung nach nicht, sich zu verbiegen, um es diesen Herrschaften so bequem wie möglich zu machen, sondern mal ein gezielter Tritt in den Arsch, dass sie sich bewegen :-)
Von SiLabs gibts ebenfalls 8051-Derivate, manche mit zwei Hardware-UARTs, die meistens laufen standardmäßig mit etwa 24,5MHz (interner Oscillator 0,5-2%), einige Derivate können bis zu 100Mhz. Und viel weitere Peripherie vorhanden (SPI, ADC, DAC, I2C, PCA, USB), je nach Derivat eben. Falls die Jungs also auf dem 8051-Kern beharren (der keineswegs schlecht ist), wäre das eine Anlaufstelle... Ralf
Frankman schrieb: > Ein Kollege von mir Programmiert seit Jahren PIC und hat innerhalb von > drei Tagen einen 8051 Kern programmiert. Also kann es nicht so schwer > sein, auf eine andere Prozessorfamilie umzusteigen. Kann ich mir gut vorstellen. Wer sogar mit dem umständlichen PIC klarkommt, schafft spielend auch andere MCs. Ich hatte mal den umgekehrten Weg versucht, vom 8051 zum PIC12, hab aber schnell aufgeben müssen. Wenn man erstmal 8051 gewohnt ist, ist einem der PIC viel zu kompliziert. Heutzutage kann man die PICs aber auch in C programmieren, da nimmt einem dann der Compiler viele Schrecklichkeiten (Banking, RETLW, ..) ab. Aber manchmal möchte man doch mal im Assemblerlisting nachsehen, was der Compiler so macht. Bei AVR und 8051 gelingt das recht gut, PIC ist dagegen starker Tobak. Deshalb nehme ich auch unter C keine PICs. Peter
Schrotty schrieb: > Wenn ein Softwareentwickler nicht den geistigen Sprung von einem 8051 > auf z.B. einen Cortex schafft, dann ist er meiner Meinung nach fehl am > Platz oder einfach nur stinkfaul! Um z.B. ein paar Relais zu schalten, muß man nicht gleich nen Cortex nehmen, nur weil der hip ist. Man braucht für jede CPU+Toolchain erstmal Einarbeitungszeit, aber das Produkt sollte möglichst schon gestern fertig sein. Auch laufen Steuerungen oft noch in 5V-Technik, weil die auf lange Produktzyklen ausgelegt sind und daher noch mit alten Komponenten zusammenarbeiten müssen. Beim 8051 muß man sich auch keine Sorgen wegen Abkündigungen machen, da kommen jedes Jahr neue Typen raus. Peter
>Um z.B. ein paar Relais zu schalten, muß man nicht gleich nen Cortex >nehmen, nur weil der hip ist. Richtig, aber dafür braucht man auch selten zwei UARTs Ausserdem schrieb ich ja bewusst "z.B." es kann natürlich auch jeder andere Core sein. Aber wenn der Cortex 1,50 kostet und der 8051 doppelt so viel, dann kann man schonmal drüber nachdenken. Und wenn die Funktion so simpel ist, dann sollte es auch kein Ding sein, es auf jedem Core laufen zu lassen, OHNE sich vorher großartig mit dem Core auseinandergesetzt zu haben. Das "richtet" dann schon der Compiler. Okay, man muss in´s Datenblatt schauen, um zu wissen, wie man einen IO-Port setzt. Aber das muss ich auch, wenn ich unterschiedliche 8051 Derivate verschiedener Hersteller verwende. Ausserdem gibt es für jeden "modernen" Prozessor mittlerweile supersimple Toolchains mit ausführlichen Beispielen, wo man innerhalb einer Stunde imstande sein sollte, eine LED blinken zu lassen. Was lange Produktlebeszyklen angeht, da kann ich auch ein Lied von singen, aber gerade DARUM rate ich, bei einer Neuentwicklung auf moderne Technologien zu setzen, da diese erst am Beginn ihrer "Lebensdauer" sind und nicht schon zum dritten mal reanimiert wurden. <-bissle übertrieben, ich weiss :-)
Nachtrag: Die Zeit, in der DoubleUart verweifelt nach einem 8051-Derivat sucht, welches seinem SW-Entwickler "genehm" ist, könnte sinnvoll dazu verwendet werden, die Toolchain für einen anderen Prozessor in Betrieb zu nehmen und schonmal den einen oder anderen Blick in´s DB zu werfen.
Hallo, um die Diskussion nochmal auf zugreifen: Ich habe mir noch zwei Optionen überlegt, da die Stückzahl nun als eher gering eingeschätzt wird: 1.) Verwendung des 87C51U2 und Speichererweiterung, habt ihr mir dazu einen Link? 2.) einen µC als Master einsetzen, der die Hauptkommunikation über die erste RS485-Schnittstelle bewätigt und am System hängt, der zweite µC arbeitet als Slave und bedient lediglich die PELCO-Schnittstelle
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.