Hallo Mädels, natürlich durchsuchte ich schon die Forensuche, habe aber zum 8051 nichts gefunden. Ich arbeite noch viel mit Original-8051 und 8051-Derivaten. Der 8051 ist ja nicht ausgestorben. Assembler und C, bin da recht fit. Der alte DOS-8051-Simulator von 1990 läuft nur noch auf meinem P3 mit Win-ME, aber ich möchte die alte Gurke nicht für jeden Scheiß anwerfen. Zumal ich da über den USB-Stick vom aktuell verwendeten Notebook immer die Daten transferieren muß. Auf meinem Notebook unter Vista läuft auf jeden Fall der SDCC erfolgreich, mit Batch-Programmierung und Geany als Bedienoberfläche und Editor. Jedoch kein Simulator. Auf den Seiten von Sourceforge gibt es zwar einen 8051-Simulator, aber der ist laut Beschreibung nicht voll funktionsfähig, und wird auch nicht mehr gewartet. Geld zum Kaufen kommerzieller Produkte habe ich nicht, da erwerbslos und erwerbsunfähig. Statt Simulation muß ich da mal seitenweise Papier verkritzeln, zur Handsimulation. OK, das geht auch, ist aber auf Dauer lästig. Hat mal jemand eine gute Idee?
Hast du schon probiert, den alten Simulator in dem Freeware Programm 'DOSBox' zu starten? (Simuliert prähistorische PCs für alte DOS Spiele).
Kein Name schrieb: > Hast du schon probiert, den alten Simulator in dem Freeware Programm > 'DOSBox' zu starten? (Simuliert prähistorische PCs für alte DOS Spiele). Danke, das mit der Dosbox klingt gut. Ich versuche gerade, sie bei Chip Online herunter zu laden. Das klappt noch nicht so recht, vielleicht ist deren Server im Augenblick überlastet. Statt dem, was ich will, landete ich in Werbung, z.B. Bundeswehr-Recruiting, als der Download wiederholt immer wieder bei 24kB unvollständig abbrach. Habe das jetzt mehrmals versucht, immer unvollständiger Download mit 24kB. Die wollen mir ein neues Thema aufzwingen, und mich von meiner Aufgabe ganz ab bringen. Was will ich mit 52 bei der Bundeswehr? Die Frührentner beraten? Na ja, you get what you pay for. Mal sehen, ob es doch noch mal klappt.
Also den Tag an dem die chip-Server überlasten möchte ich sehen... Schalt mal JS aus und versuch es erneuert. Mit aktuellem FF geht es prima, gerade getestet.
Wenns gar nicht geht (nicht lachen ;-)), versuchs mal hier http://www.computerbild.de/download/DOSBox-930358.html?dl=1
moin moin, @Wilhel, suchst Du was spezielles, so 105% simulieren für alle Typen, mit Interrupt und und und... wenn nicht, siehe da: http://forum.zerspanungsbude.net/viewtopic.php?f=50&t=5582 Mit Gruß Pieter
Wilhelm hast du eigentlich mal hier geschaut? http://mcu8051ide.sourceforge.net/ (oder meintest du den?)
troll schrieb: > Also den Tag an dem die chip-Server überlasten möchte ich sehen... > Schalt mal JS aus und versuch es erneuert. Mit aktuellem FF geht es > prima, gerade getestet. Es hat gestern Abend noch geklappt. Nach einer halben Stunde ging in meinem Explorer plötzlich ein Fenster auf, mit "Download speichern". Immerhin. Vielleicht lag es an meinem Mobilstick, der mal langsamer und mal schneller ist. Installiert habe ich mal noch nichts. Denn vielleicht kommen noch ganz andere Ideen. Aber ich hab dann schon mal alles parat. Pieter schrieb: > moin moin, > > @Wilhel, > > suchst Du was spezielles, so 105% simulieren für alle Typen, mit > Interrupt und und und... Ja. Mein fast 20 Jahre alter Simulator simulierte hauptsächlich die Siemens/Infineon-Derivate des 8051, also den 80(C)515(A) und den 80C517(A). Der alte Assembler und Simulator waren vom Otmar-Feger-Verlag in Traunstein, den gibt es anscheinend nicht mehr. Herr Feger hat seinen Ruhestand verdient. Aber diese Leute arbeiteten mit Siemens/Infineon zusammen, und stellten deren Bausteine vor. Assembler und Simulator stammen von den entsprechenden Buch-Disketten, sind aus dem Hause Ashling Microsystems, eine irische Firma, die wohl heute noch ganz vernünftige Tools z.B. für ARM machen. Die Buchreihe von Feger&Co. war sehr gut, Einband unverwüstlich robust, und die User Manuals der µC der 80515 und 80517 in Deutsch im Detail gut erklärt. Auch Grundlagen systematisch zum Entwicklungszyklus, und Anwendungen. Von den 80C515A und 80C517A hab ich noch jeweils eine Handvoll, und die tun es noch. Für meine Zwecke allemal. Immerhin waren sie in den 1990-er Jahren in Motorsteuergeräten von deutschen Nobelkarossen auch drinne. Die 80C517-Boards sind trotzdem interessant, haben nämlich LWL-Schnittstellen an der RS232. Womit ich auch ein Megabit/s relativ störungsfrei übertragen kann. Im Augenblick mache ich auf einem ollen 80515-Board ein paar kleine Spiele, um sie an eine sehr interessierte Person zu verschenken: Ich hatte vergangene Woche das Vergnügen, einen sehr präzisen Reaktionstester zu präsentieren. Die Begeisterung des Gegenübers war riesig. Sowas kann man in einem Laden nicht mal schnell kaufen. Die Software ist neu, das Board 22 Jahre alt. Da kommen jetzt noch Würfelspiele wie einfachsterweise schon mit dem alten elektronischen Würfel und ein Lottozahlengenerator mit drauf, und was mir noch so ein fällt. Den Simulator brauche ich eben mal, um den Bubble-Sort einmal befehlsweise durch laufen zu lassen, und zu schauen, ob da nicht irgendwas mal in den Stack-Bereich schreibt. Das passiert bei der indirekten Adressierung eben mal. Oder ein Shift-Programm, was eine Byte-Kette um ein Halbbyte nach oben shiftet, um eine Zahl daraus aus zu geben. Meistens klappt das aber bei mir noch so, eben ohne den Simulator. Den Bubble-Sort-Algorithmus für beliebig viele Zahlen erstellte ich heute in nur 20 Minuten in Assemblercode. Sowas muß ich nicht mal im Internet suchen, das dauert länger. Das ist doch was, oder??? Und kompakt und schnell, nachdem ich die Durchläufe erst mal auf Papier simulierte. Ich kann das alles noch, und werde immer noch besser. Komm jetzt bloß niemand mit Shellsort oder Quicksort. So exakt will ich das nicht, die Kiste ist in Assembler gigantisch schnell genug, für ein Würfelspiel. Den Bubblesort kennt eben jeder. Assembler, weil das Board nur 4kB Programmspeicher hat. Da muß alles hinein, mußte mich leider gegen C entscheiden. Mein Mikroprozessor-Prof., der es mit entwickelte, war genial: Der machte eine komplette Aufzugssteuerung in nur 30 Codebytes in Assembler. Die ersten 8080-Boards hatten auch nur 256 Bytes Code und 256 Bytes RAM. ;-) Das RAM auf dem Board war auch mal zur Programmausführung vorgesehen. Das Betriebssystem im originalen ROM erlaubte eine Eingabe des Maschinencodes über die Tastatur des Boards direkt in RAM-Adressen, was man vorher auf Papier ausklamüserte. Mehr als 30 Befehle machen da aber keinen Sinn mehr. Aber, es war ein komplettes Entwicklungssystem, für das man keinen PC brauchte. OK, es sind 8-bitter, und CAN und USB haben sie nicht. Das kann ich aber verkraften. Der 80C517A hat z.B. immerhin integrierte Hardware-Rechenperipherie (MDU), die ungefähr um den Faktor 100 schneller ist als Softwarealgorithmen, war speziell auf superschnelle Floating-Point-Arithmetik in Regelungsanwendungen ausgelegt, so Dinge sind auch mal ganz amüsant. Einen EPROMMER für die EPROMs habe ich auch noch, und arbeite für die Programmtests aber auch mit ROM-Bootloadern und ROM-Monitoren. Entwicklung auf alte Art, einen echten Debugger vermisse ich gar nicht mal. Erst wenn der EPROMMER mal defekt werden sollte, schaffe ich mir modernere Boards an. Fachkraft schrieb: > Wilhelm hast du eigentlich mal hier geschaut? > > http://mcu8051ide.sourceforge.net/ > > (oder meintest du den?) OK, ich schaue mir das an. Danke. Von Sourceforge habe ich auch den SDCC, wo ein Simulator µCSIM beschrieben ist. Aber der wird eben nicht mehr gewartet, und hat Bugs. Eine IDE brauche ich nicht mehr, Geany passt bereits gut, damit freundete ich mich richtig an.
moin moin,
>>"Den Simulator brauche ich eben mal, um den Bubble-Sort einmal
befehlsweise durch laufen zu lassen, und zu schauen, ob da nicht
irgendwas mal in den Stack-Bereich schreibt. Das passiert bei der
indirekten Adressierung eben mal. Oder ein Shift-Programm, was eine
Byte-Kette um ein Halbbyte nach oben shiftet, um eine Zahl daraus aus zu
geben."
jo, und genau so etwas habe ich mit meiner Fräsensteuerung auch im
Simulator laufen lassen.
Was genau so ein Simulator alles kann, oder muss ist doch vom
Hauptnutzer abhängig.
Meiner kann z.B. die 32Bit-MAC des C8051F36x. Geniales Teil, 16x16Bit
Integer in 2 Takten, 32Bit shift in 1 Takt.
...und das ganze bei 100MHz, 1Takt Core.
Mit Gruß
Pieter
> Meiner kann...
Auch selbst geschrieben? :)
Ich würd ja waaaahnsinnig gerne mal n paar Projekte mit dir durchziehen,
was solche Simulator/Assembler/etc.-Sachen angeht.
Da könnte man bestimmt astreine IDEs, etc. draus machen.
Ralf
Hallo Wilhelm, ich verstehe gut dass Du die 8051er gerne hast und Dir auch nicht unbedingt ausreden. Ich habe ja auch noch einige Varianten herumliegen. Aber neues möchte ich damit heutzutage auch nicht mehr bauen. Ich möchte Dir aber trotzdem vorschlagen auch wenn es für viele Projekte Overkill ist, Dir die STM32F10x Typen oder ähnliche NXP Cortex Typen der M3 Reihe anzusehen. Die sind spottbillig und weitreichend erhältlich. Nur schade dass es sie nicht im DIP Gehäuse gibt. Für ein Spottgeld kann man sich eine ST-Discovery Platine zulegen. Die hat einen angebauten JTAG Programmierer und Debugger. In China oder auf eBay gibt es eine sehr schöne Anschlussplatine. http://www.ebay.ca/itm/STM32F407VGT6-STM32-Cortex-M4-ARM-Development-Board-without-STM32F4DISCOVERY-/261050682608?pt=LH_DefaultDomain_0&hash=item3cc7d54cf0#ht_5601wt_1163 Mit CooCox gibt es eine freie Entwicklungsumgebung in Eclipse mit integrierten GDB Debugger und man kann wunderschön damit arbeiten. Angefangen habe ich mit Atollic Lite, welches aber seit neuestens auf 32KB beschränkt ist. Alles funktioniert wunderbar mit dieser (CooCox) Tool Chain. Man möchte dann JTAG Debuggen wirklich nicht mehr vermissen. Und das Tool funktioniert mit WinXP bis Win7. Ich habe bis jetzt noch alles zum Laufen gebracht und finde es lässt sich nach einiger Einarbeitungszeit ganz gut damit arbeiten. Alle Peripherien die man sich wünscht sind vorhanden. Viele digitale IO Pins sind auch 5V fähig. 12-Bit ADCs und eingebauter DAC sind auch nicht zu verachten. 1MB FLASH bis zu 96K RAM sind auch ganz praktisch. Bei 72MHz kann ich einen IO PIN mit 18MHz takten. Die RTC ist super genau und der Strom praktisch nicht messbar. Es ist also meine Meinung dass diese neue Generation von MCUs und Tools durchaus für den Heimgebrauch nützlich sind. Jedenfalls macht es mir Spass mit diesen MCUs zu arbeiten. Gruß, Gerhard P.S. Bitte jetzt nicht mit Steinen werfen;-)
DIP: LPC1114 http://avnetexpress.avnet.com/store/em/EMController/Microcontroller/NXP-Semiconductors/LPC1114FN28-102-12/_/R-5003286402656/A-5003286402656/An-0?action=part&catalogId=500201&langId=-3&storeId=500201&listIndex=-1&page=1&rank=0 Aber es werden auch immer noch sehr viele neue Projekte mit modernen 8051 gestartet: http://www.nxp.com/products/microcontrollers/8_16_bit_legacy/lpc900/#products
Gerhard. schrieb: > Hallo Wilhelm, > > ich verstehe gut dass Du die 8051er gerne hast und Dir auch nicht > unbedingt ausreden. Ich habe ja auch noch einige Varianten herumliegen. > Aber neues möchte ich damit heutzutage auch nicht mehr bauen. Warum nicht?
>> Aber neues möchte ich damit heutzutage auch nicht mehr bauen. > Warum nicht? Ich vermute mal, weil der Comfort bei den anderen MCUs größer ist... Schneller, dicker, etc. einfacher zu debuggen, usw. Ralf
Ralf schrieb: >>> Aber neues möchte ich damit heutzutage auch nicht mehr bauen. >> Warum nicht? > Ich vermute mal, weil der Comfort bei den anderen MCUs größer ist... > Schneller, dicker, etc. einfacher zu debuggen, usw. > > Ralf Genau! Nur der Nostalgie wegen würde ich ein Projekt mit einem 8051 Derivat machen. Ich habe noch ein paar 87C51 und alte 80C31 herumliegen. Nur braucht man zum Löschen des ersteren eine UV Lampe - Ist halt nicht so praktisch wie FLASH. Zu meiner Ehre muss ich allerdings hinzufügen das sich vor ein paar Jahren tatsächlich ein kleines Projekt damit gemacht habe. Also ganz so schlimm bin ich auch wieder nicht;-) Gerhard
Es gab auch mal bei Analog-Devices, die haben ja 8051-Derivate im Programm bei deren Tools einen Simulator für die 8051-er. Ob der noch im Angebot ist weiß ich momentan nicht, soll aber recht brauchbar sein. Kostenfrei war er...
@Gerhard: > Genau! Nur der Nostalgie wegen würde ich ein Projekt mit einem 8051 > Derivat machen. oO Also, ICH würd's mit nem 8051 machen, wenn ich ihn für geeignet halte + eine andere MCU oversized ist + der Preis des 8051 attraktiver ist + etc. > Ich habe noch ein paar 87C51 und alte 80C31 herumliegen. Nur braucht man > zum Löschen des ersteren eine UV Lampe - Ist halt nicht so praktisch wie FLASH. Keine Frage, alles vor Flash muss raus :) > Zu meiner Ehre muss ich allerdings hinzufügen das sich vor ein paar Jahren > tatsächlich ein kleines Projekt damit gemacht habe. Also ganz so schlimm > bin ich auch wieder nicht;-) Mit welchen Tools? Ralf
Hallo Ralf, Ralf schrieb: > @Gerhard: >> Genau! Nur der Nostalgie wegen würde ich ein Projekt mit einem 8051 >> Derivat machen. > oO Also, ICH würd's mit nem 8051 machen, wenn ich ihn für geeignet halte > + eine andere MCU oversized ist + der Preis des 8051 attraktiver ist + > etc. > Wenn ich aber einen MCU kaufen müsste dann würde ich doch etwas neueres mit FLASH haben wollen. Wenn's unbedingt 8051 sein soll gibt es sie ja auch mit FLASH (z.B. P89LPC936). Nur habe ich kein Programmiergerät dafür. Fuer PIC, AVR, STM32 habe ich schon alles. > >> Ich habe noch ein paar 87C51 und alte 80C31 herumliegen. Nur braucht man >> zum Löschen des ersteren eine UV Lampe - Ist halt nicht so praktisch wie FLASH. > Keine Frage, alles vor Flash muss raus :) Nein. Die werde ich doch nicht entsorgen. Nicht wenn ich sie schon herumliegen habe. Abgesehen davon habe ich noch etliche EPROMS Damit lassen sich durchaus noch nette Projekte verwirklichen. > >> Zu meiner Ehre muss ich allerdings hinzufügen das sich vor ein paar Jahren >> tatsächlich ein kleines Projekt damit gemacht habe. Also ganz so schlimm >> bin ich auch wieder nicht;-) > Mit welchen Tools? Eine 2001 Uraltversion von Keil in der Firma. Ist aber angenehm damit zu arbeiten. Bin noch der einzige der sich damit ab und zu beschäftigt. Gruß, Gerhard > > Ralf
moin moin, >>Keine Frage, alles vor Flash muss raus :) Nö, warum? Ich habe hier noch ein 30MHz-80552-Board mit RAM-Loader ( ansprechen wie 89C51ED2) rumliegen, zum Testen ideal. Warum soll das weg? >>UV-Lampe.. tja, früher gab es Straßenlampen mit HQL...der ideale EPROM-Löscher. Mit Gruß Pieter
@Gerhard & Pieter: Okay, natürlich kann man auch mit den EPROMs oder den Vor-Flash-Versionen der MCUs noch was machen. Ich hab mein Testboard aus der Ausbildung auch nicht weggeworfen. Irgendwo hab ich glaub ich sogar noch n UV-Löscher, brauch den aber nie. > Wenn ich aber einen MCU kaufen müsste dann würde ich doch etwas neueres > mit FLASH haben wollen. Wenn's unbedingt 8051 sein soll gibt es sie ja > auch mit FLASH. Das sehe ich anders. Es muss nicht etwas neueres sein, nur weils neuer ist. Warum soll ich einen Cortex-M0/M3 im QFP44 oder QFN33 verwenden, der einen externen Oszillator benötigt, wenn ich die gleiche Aufgabe mit einem 8051-Derivat mit internem Präzisions-Oszillator im SOIC16 gelöst bekomme? Achtung, Halbwissen: Ich habe noch nicht so große Erfahrung mit Cortex-Mx, ich bin erst an der Einarbeitung, aber das ist grad auf Eis. Es kann also sein, dass sich an der Ecke schon viel getan hat und es auch Cortex-MCUs im SOIC/SSOP Gehäuse und integriertem Oszillator gibt. Den 8051 würde ich im speziellen einfach deswegen nehmen, weil ihn besser kenne. Das wird sich mit Sicherheit in Richtung Cortex verschieben. > (z.B. P89LPC936). Nur habe ich kein Programmiergerät dafür. Ich verwende SiLabs MCUs, vielleicht wären die was für dich. Der Programmier-/Debugadapter kostet etwa 20-25€, wenn du ihn aus ToolStick-Komponenten aufbaust. Und die SiLabs MCUs haben ein breites Anwendungsspektrum. Natürlich gibt's auch dunkle Seiten, vergleicht man die Features mit dem Preis kann es durchaus vorkommen, dass die Cortex-MCUs gleich oder günstiger rauskommen. Bisher hält mich von den Cortex die Einarbeitung ab, da ich das ganze CMSIS-Geraffel noch nicht verstehe bzw. ich da ein paar Schwierigkeiten damit habe. Ralf
btw, einen 8050 Emu gäbe es auf meiner Homepage, falls ihn jemand braucht: http://sharpmz.org/za8050emu.htm
Verdammter Mist. Mit Dosbox geht gerade mal gar nichts. Mir fehlt da sowas wie ein Template anscheinend. Hat noch jemand eine Idee?
In der DOS-Box geht nicht alles wie im echten DOS. Vielleicht liegts daran.
Abdul K. schrieb: > In der DOS-Box geht nicht alles wie im echten DOS. Vielleicht liegts > daran. Ich hab jetzt 3 Stunden probiert, das kann doch nicht sein. Also es ist höchste Zeit für den Wurf auf den Müll. Was nix kostet, taugt nur manchmal, meistens nichts.
Autor anschreiben, Foren gucken. Dann erst Müll. Bezahlsoftware ist oft noch schlechter.
Abdul K. schrieb: > Autor anschreiben, Foren gucken. Dann erst Müll. Bezahlsoftware ist oft > noch schlechter. Also auf den Müll mit dem Teil. Es ist kein Demo-Projekt dabei, bzw. Beschreibung, wie man es genau macht. Pöööh, so einen Mist kenne ich im Laufe der Jahre schon. Die Autoren für ein Tool hatten keinen Bock mehr, genau zu erklären, wie es am Ende geht. Wie im Nachbarthread, wo ich dem Ralf mal mit einem selbst aufgesetzten SDCC-Projekt half. Ohne dies kann er sich erschießen, oder wochenlang was probieren, was in der Doku abstrakt steht. Es ist ungefähr so, als wenn es für eine Klausur keine Übungsaufgaben gäbe. Übelst, wirklich. Aber: Was nichts kostet, wenn auch Sourceforge, da haben sich einige Schwänze an ihren Tools dran aufgegeilt, und nicht überlegt, was ein User damit macht.
Ist leider oft so. Oftmals auch rein persönliche Gründe der Ersteller. Die Interessen wandern weiter bevor das Projekt komplett ist. Hier sind mir ältere Entwickler wirklich lieber. Die arbeiten nachhaltiger.
Wilhelm Ferkes schrieb: > Also auf den Müll mit dem Teil. Es ist kein Demo-Projekt dabei, bzw. > Beschreibung, wie man es genau macht. Also das soll ja wohl ein Witz sein, im Spiegel findest du deine Nase zu anfassen. Die Dosbox läuft normalerweise auf Anhieb (bis XP getestet) und ist ausgezeichnet dokumentiert. Wenn du ein Template benötigst, bist du der einzige User für so etwas. Doppelklick hast du probiert? ;-)
Guido schrieb: > Also das soll ja wohl ein Witz sein, im Spiegel findest du deine > Nase zu anfassen. Was soll der Müll? Faß deine eigene Nase an, oder den Schwanz, wenn dir danach ist. Besser wäre es gewesen, du hättest mal Schritt für Schritt beschrieben, wie es geht, wie ich ein Programm gestartet bekomme. Auf den Rest schei.... ich. Wirklich.
Wilhelm jetzt beruhige doch mal. Die DOSBox verwendet eine Konfigurationsdatei dosbox-0.74.conf. Dort werden alle Einstellungen vorgenommen. Bei mir unter Win7 liegt die in C:\Users\USERNAME\Appdata\local\DOSBOX Da ist am Ende der Datei ein Eintrag [autoexec] dort werden die Verzeichnisse gemountet auf die man von der DOSBox-Shell aus zugreifen kann. Bei mir ist das beispielsweise ein Eintrag mount C C:\DOSBOX Im Verzeichnis DOSBOX sind dann bei mir ein paar DOS-Anwendungen, in die man ganz normal per cd Verz wechseln kann und von dort aus starten kann (unter anderem ein paar alte DOS-Games; die laufen im DOS-Fenster einwandfrei). Also DOSBox ganz normal mit der Maus vom Startmenü aus starten und dann per Hand wie im DOS gewöhnt ins VZ wechseln das per mount hinzugefügt wurde und die jeweilige EXE starten.
Hallo Ralf, danke für alle Hinweise und Kommentar. Ralf schrieb: > @Gerhard & Pieter: > Okay, natürlich kann man auch mit den EPROMs oder den > Vor-Flash-Versionen der MCUs noch was machen. Ich hab mein Testboard aus > der Ausbildung auch nicht weggeworfen. Irgendwo hab ich glaub ich sogar > noch n UV-Löscher, brauch den aber nie. Das würde ich auch nicht tun. Leider habe ich in meiner Bastelkiste keine einzige EEPROM 8051er Bord. Deshalb fängt man man doch lieber mit etwas neuerem mit FLASH an. Ein MCU hat gegenüber einer traditionellen Anordnung mit externen EPROM und IO-Expandern den Vorteil einer wesentlich reduzierten EMC Verträglichkeit. > >> Wenn ich aber einen MCU kaufen müsste dann würde ich doch etwas neueres >> mit FLASH haben wollen. Wenn's unbedingt 8051 sein soll gibt es sie ja >> auch mit FLASH. > Das sehe ich anders. Es muss nicht etwas neueres sein, nur weils neuer > ist. Warum soll ich einen Cortex-M0/M3 im QFP44 oder QFN33 verwenden, > der einen externen Oszillator benötigt, wenn ich die gleiche Aufgabe > mit einem 8051-Derivat mit internem Präzisions-Oszillator im SOIC16 > gelöst bekomme? Deshalb ist es gut wenn man sich die Zeit nimmt und die Kanditaten vergleicht. Es gibt immer eine vom Typ her optimalen MCU. > > Achtung, Halbwissen: Ich habe noch nicht so große Erfahrung mit > Cortex-Mx, ich bin erst an der Einarbeitung, aber das ist grad auf Eis. > Es kann also sein, dass sich an der Ecke schon viel getan hat und es > auch Cortex-MCUs im SOIC/SSOP Gehäuse und integriertem Oszillator gibt. > Den 8051 würde ich im speziellen einfach deswegen nehmen, weil ihn > besser kenne. Das wird sich mit Sicherheit in Richtung Cortex > verschieben. Ich habe vor mir eine STM32 DIP Version selber auf einer Platine zu stricken. Da kann man gleich den JTAG Anschluss und die Ablock Cs, Quarz mit integrieren. > >> (z.B. P89LPC936). Nur habe ich kein Programmiergerät dafür. > Ich verwende SiLabs MCUs, vielleicht wären die was für dich. Der > Programmier-/Debugadapter kostet etwa 20-25€, wenn du ihn aus > ToolStick-Komponenten aufbaust. Und die SiLabs MCUs haben ein breites > Anwendungsspektrum. Natürlich gibt's auch dunkle Seiten, vergleicht man > die Features mit dem Preis kann es durchaus vorkommen, dass die > Cortex-MCUs gleich oder günstiger rauskommen. Bisher hält mich von den > Cortex die Einarbeitung ab, da ich das ganze CMSIS-Geraffel noch nicht > verstehe bzw. ich da ein paar Schwierigkeiten damit habe. > Die SiLabs MCUs habe ich mir angesehen. Sie mir allerdings für meine Projekte zu aufwendig und ich hätte gerne auch noch ein DIP Gehäuse. Allerdings sind sie mit ihren Single Clock cycle instructions super schnell. Dann habe ich mir noch mal den AT89C51Rx2 angesehen welcher von Peter Dannegger gerne eingesetzt wurde. Mit dem eingebauten Serial Bootloader und FLIP lässt sich der eingebaute FLASH sehr bequem programmieren. Externe EPROMS mag ich nicht mehr so gerne weil dann der ganze MCU Bus offen auf der Platine abstrahlt und die EMC Werte sich um einiges erhöhen. Bei MCUs ohne externe Busverdrahtung spart man sich das alles. Und man kann notfalls ohne richtige Platine was einfaches bauen. Der AT89C51 braucht kaum externe Beschaltung um funktionsfähig zu sein. Gerhard > Ralf
moin moin, den AT80C51ED2 habe ich vor den Silabs-Typen auch gerne eingesetzt. Mein Assembler kann den direkt (via COM) per Transfer ansprechen. Die Silabs-Typen werden über einen ED2-C2 Adapter geprogt. Mit Gruß Pieter
@Wilhelm: Was DosBox angeht, es gibt auch sog. Frontends, also quasi GUIs für DosBox, die das Konfigurieren einfacher gestalten: http://www.dosbox.com/download.php?main=1 Ich verwende D-Fend Reloaded, bin sehr zufrieden damit. @Gerhard: > Das würde ich auch nicht tun. Leider habe ich in meiner Bastelkiste > keine einzige EEPROM 8051er Bord. Deshalb fängt man man doch lieber mit > etwas neuerem mit FLASH an. Ein MCU hat gegenüber einer traditionellen > Anordnung mit externen EPROM und IO-Expandern den Vorteil einer > wesentlich reduzierten EMC Verträglichkeit. Ja, aber eigentlich ist mir das Board nur zu schade zum Wegwerfen :) Wobei ich zugeben muss, dass ich mehrere davon hab und entsprechende Anpassungen vorgenommen hab. In einem werkelt beispielsweise nicht mehr der originale 80C52, sondern ein AT89C51ED2 im DIP-Gehäuse. War einfach geschickt für Experimente :) > Deshalb ist es gut wenn man sich die Zeit nimmt und die Kanditaten > vergleicht. Es gibt immer eine vom Typ her optimalen MCU. Korrekt. Und wenn ich die eine Architektur besser kenne als die andere, werd ich das Projekt entsprechend mit der besser bekannten Architektur durchziehen, zumindest solange, bis ich die zweite Architektur in diversen Versuchsschaltungen besser kennen gelernt hab. > Ich habe vor mir eine STM32 DIP Version selber auf einer Platine zu > stricken. Da kann man gleich den JTAG Anschluss und die Ablock Cs, Quarz > mit integrieren. Hab ich mit FT232R und den USB-MCUs von SiLabs auch gemacht :) > Die SiLabs MCUs habe ich mir angesehen. Sie mir allerdings für meine > Projekte zu aufwendig und ich hätte gerne auch noch ein DIP Gehäuse. > Allerdings sind sie mit ihren Single Clock cycle instructions super > schnell. oO Wieso zu aufwendig? Sie haben ziemlich viel on-chip-Peripherie, das stimmt. Und ein DIP-Adapter ist schnell gekauft/geätzt. Und die F8xx-Serie gibt's im SOIC16 bzw. SSOP24-Gehäuse. > Dann habe ich mir noch mal den AT89C51Rx2 angesehen welcher von Peter > Dannegger gerne eingesetzt wurde. Mit dem eingebauten Serial Bootloader > und FLIP lässt sich der eingebaute FLASH sehr bequem programmieren. Stimmt, hab ich bei einigen Projekten während der Entwicklungsphase gern im Einsatz gehabt, bevor ich auf SiLabs umgestiegen bin - dort sind wenigstens alle MCUs gleich. Beispielsweise ist das SPI-IF vom ED2 nicht mit dem vom S8253 pinkompatibel. > Der AT89C51 braucht kaum externe Beschaltung um funktionsfähig zu sein. Und die SiLabs-MCUs brauchen noch weniger :) Lediglich der Debug-Anschluss ist verglichen mit dem ED2 aufwendiger. Ralf
Hallo Wilhelm, das hatte mich schon geärgert: Wilhelm Ferkes schrieb: > Pöööh, so einen Mist kenne ich im Laufe der Jahre schon. Die Autoren für > ein Tool hatten keinen Bock mehr, genau zu erklären, wie es am Ende > geht. Auf der Projektseite findest du fast als erstes ein Tutorial, aber das brauchst du vermutlich nicht. Installiere Dosbox und starte es und gib einfach "dir" ein, dann weißt du wie es läuft.
Hallo Ralf, Ralf schrieb: > @Wilhelm: > Was DosBox angeht, es gibt auch sog. Frontends, also quasi GUIs für > DosBox, die das Konfigurieren einfacher gestalten: > http://www.dosbox.com/download.php?main=1 > > Ich verwende D-Fend Reloaded, bin sehr zufrieden damit. > > @Gerhard: >> Das würde ich auch nicht tun. Leider habe ich in meiner Bastelkiste >> keine einzige EEPROM 8051er Bord. Deshalb fängt man man doch lieber mit >> etwas neuerem mit FLASH an. Ein MCU hat gegenüber einer traditionellen >> Anordnung mit externen EPROM und IO-Expandern den Vorteil einer >> wesentlich reduzierten EMC Verträglichkeit. > Ja, aber eigentlich ist mir das Board nur zu schade zum Wegwerfen :) > Wobei ich zugeben muss, dass ich mehrere davon hab und entsprechende > Anpassungen vorgenommen hab. In einem werkelt beispielsweise nicht mehr > der originale 80C52, sondern ein AT89C51ED2 im DIP-Gehäuse. War einfach > geschickt für Experimente :) Mir wäre das ewige EEPROM löschen und brennen auch zu zeitraubend. Wenn man dann keinen Zero Insertion Force Socket hat (Wie heisst das eigentlich auf Deutsch?) dann werden die armen pins ganz schön abgenutzt. > >> Deshalb ist es gut wenn man sich die Zeit nimmt und die Kanditaten >> vergleicht. Es gibt immer eine vom Typ her optimalen MCU. > Korrekt. Und wenn ich die eine Architektur besser kenne als die andere, > werd ich das Projekt entsprechend mit der besser bekannten Architektur > durchziehen, zumindest solange, bis ich die zweite Architektur in > diversen Versuchsschaltungen besser kennen gelernt hab. > >> Ich habe vor mir eine STM32 DIP Version selber auf einer Platine zu >> stricken. Da kann man gleich den JTAG Anschluss und die Ablock Cs, Quarz >> mit integrieren. > Hab ich mit FT232R und den USB-MCUs von SiLabs auch gemacht :) Ein Bild würde mich interessieren. > >> Die SiLabs MCUs habe ich mir angesehen. Sie mir allerdings für meine >> Projekte zu aufwendig und ich hätte gerne auch noch ein DIP Gehäuse. >> Allerdings sind sie mit ihren Single Clock cycle instructions super >> schnell. > oO Wieso zu aufwendig? Sie haben ziemlich viel on-chip-Peripherie, das > stimmt. Und ein DIP-Adapter ist schnell gekauft/geätzt. > Und die F8xx-Serie gibt's im SOIC16 bzw. SSOP24-Gehäuse. jetzt habe ich mir noch einmal die Silabs Sachen angesehen. Der C8051F501-IQ hat einige nützliche Peripherien unter der Motorhaube. Die FLASH-Groessen sind auch beachtlich. Die Preise bei D.K. sind spottbillig und sie haben guten Lagerbestand. Also in der Hinsicht spricht nichts dagegen. > >> Dann habe ich mir noch mal den AT89C51Rx2 angesehen welcher von Peter >> Dannegger gerne eingesetzt wurde. Mit dem eingebauten Serial Bootloader >> und FLIP lässt sich der eingebaute FLASH sehr bequem programmieren. > Stimmt, hab ich bei einigen Projekten während der Entwicklungsphase gern > im Einsatz gehabt, bevor ich auf SiLabs umgestiegen bin - dort sind > wenigstens alle MCUs gleich. Beispielsweise ist das SPI-IF vom ED2 nicht > mit dem vom S8253 pinkompatibel. Eine Übereinstimmung wäre auf alle Fälle angenehm. > >> Der AT89C51 braucht kaum externe Beschaltung um funktionsfähig zu sein. > Und die SiLabs-MCUs brauchen noch weniger :) > Lediglich der Debug-Anschluss ist verglichen mit dem ED2 aufwendiger. Welchen Debugger/FLASHer würdest Du andernfalls vorschlagen? Ist das der richtige zum anfangen? http://www.digikey.ca/product-detail/en/DEBUGADPTR1-USB/336-1182-ND/807653 Das IDE scheint ihn zu unterstützen. Gerhard > > Ralf
Hallo Gerhard, bei den Silabs brauchst Du einen Adapter auf JTAG oder C2. Der C8051F501 hat C2 als Prog-Schnitte. Proggen ist kein Problem, Debugger habe ich noch nicht gebraucht. Mit Gruß Pieter
Hallo Pieter, danke für den Hinweis. Werde mir die Details heute Abend näher ansehen. Bei PICS/AVR brauchte ich auch noch nie wirklich einen Debugger. Bei STM32 ist es allerdings recht nützlich. Jedenfalls scheint der Einstieg bei SiLabs Produkten relativ problemlos zu sein. Es ist übrigens schön dass die Teile noch 5V vertragen. Obwohl man sich an 3.3V Technik gewöhnt sind mir für viele Projekte 5V Versorgung immer noch lieber. Gruß, Gerhard Pieter schrieb: > Hallo Gerhard, > > bei den Silabs brauchst Du einen Adapter auf JTAG oder C2. > Der C8051F501 hat C2 als Prog-Schnitte. > Proggen ist kein Problem, Debugger habe ich noch nicht gebraucht. > > > Mit Gruß > Pieter
Hallo Gerhard, STM32...man müste Zeit haben. Einen Umsetzer AT89C51ED2 auf C2 zum proggen ist in meinem Assembler mit drin, Datei anbei. Auch gut F340: extern 5V -> interner Regler -> 3V3. Mit Gruß Pieter
Angehängte Dateien:
-
STM32-MINI_Oberseite.jpg
160 KB -
STM32-MINI_Unterseite.jpg
140 KB -
STM32-MINI_JTAG_Adapter.jpg
100 KB
Pieter schrieb: > Hallo Gerhard, > > STM32...man müste Zeit haben. > Einen Umsetzer AT89C51ED2 auf C2 zum proggen ist in meinem Assembler mit > drin, Datei anbei. > > Auch gut F340: extern 5V -> interner Regler -> 3V3. > > Mit Gruß > Pieter Hallo Pieter, danke für die Unterlagen. Kann sie erst zu hause laden weil ich hier nicht EAGLE(?) zur Verfügung habe. Anbei sind ein paar Bilder von einer kleinen STM32 Anschlussplatine mit dem STM32F103VE6 drauf und JTAG Adapter. Dazu kommt später noch eine Experimentieranschlussplatine damit man leichter an die Anschlüsse dazu kommt. Mit den STM32 kommt man ziemlich leicht zurecht weil es viele Beispiele von ST gibt (STD_Periphearal Library Projects) Mit diesen Beispielen lernt man sofort worauf es bei der Initialisierung ankommt. Direkter Registerzugriff ist auch kein Problem. Als freie Tool Chain bietet sich CooCox an. Die CAD/CAM (PR99SE) Unterlagen stelle ich gerne zur Verfügung falls jemand Interesse daran hat. Gruß, Gerhard
@Gerhard: > Mir wäre das ewige EEPROM löschen und brennen auch zu zeitraubend. Wenn > man dann keinen Zero Insertion Force Socket hat (Wie heisst das > eigentlich auf Deutsch?) dann werden die armen pins ganz schön > abgenutzt. 1. Die deutsche Bezeichnung ist Nullkraftsockel 2. War bei unseren Boards nicht nötig, im EPROM saß lediglich der Bootloader, welcher nach dem Programmdownload komplett ausgeblendet wurde (und mit ihm das EPROM) > Ein Bild würde mich interessieren. Mal schauen, was ich zaubern kann :) > jetzt habe ich mir noch einmal die Silabs Sachen angesehen. > sind spottbillig und sie haben guten Lagerbestand. Also in der Hinsicht > spricht nichts dagegen. Freut mich, wenn du was passendes gefunden hast. Ich find die Käfer echt gut. > Eine Übereinstimmung wäre auf alle Fälle angenehm. Durch die Crossbar bei den SiLabs MCUs kein Problem. > Welchen Debugger/FLASHer würdest Du andernfalls vorschlagen? > Ist das der richtige zum anfangen? Was ich meinte mit "aufwendiger" ist die 10-polige Stiftleiste mit Wanne, die du für den Debugger-Anschluss brauchst. Ich hab mir deswegen eine kleine Zwischenplatine auf LoRa gebastelt, bei der ich nur vier bzw. fünf Pins brauche. Bzgl. der Debugadapter selbst, dein Link ist der reguläre DA, wie er bei jedem Devkit dabei ist (deswegen lohnt sich's fast nicht den DA separat zu kaufen). Falls du kein Devkit dein eigen nennst, es gibt die sog. ToolSticks, davon brauchst du den BaseAdapter, und die Debug-Daughter. Beide haben Vor- und Nachteile (bei der TS-Variante kannst du z.B. Rx/Tx. des TS abgreifen und über eine separate SiLabs-Terminalanwendung den UART ansprechen). Ich hab beide Varianten im Einsatz. > Es ist übrigens schön dass die Teile noch 5V vertragen. Obwohl man sich > an 3.3V Technik gewöhnt sind mir für viele Projekte 5V Versorgung immer > noch lieber. Kenn ich :) Aber ich gewöhne mich langsam an Komplett-3V3-Designs. Ralf
Hallo Ralf, Ralf schrieb: > @Gerhard: >> Mir wäre das ewige EEPROM löschen und brennen auch zu zeitraubend. Wenn >> man dann keinen Zero Insertion Force Socket hat (Wie heisst das >> eigentlich auf Deutsch?) dann werden die armen pins ganz schön >> abgenutzt. > 1. Die deutsche Bezeichnung ist Nullkraftsockel Danke! Ich konnte mich einfach nicht erinnern. > 2. War bei unseren Boards nicht nötig, im EPROM saß lediglich der > Bootloader, welcher nach dem Programmdownload komplett ausgeblendet > wurde (und mit ihm das EPROM) > >> Ein Bild würde mich interessieren. > Mal schauen, was ich zaubern kann :) > Es würde mich auf alle Fälle interessieren. >> jetzt habe ich mir noch einmal die Silabs Sachen angesehen. >> sind spottbillig und sie haben guten Lagerbestand. Also in der Hinsicht >> spricht nichts dagegen. > Freut mich, wenn du was passendes gefunden hast. Ich find die Käfer echt > gut. > >> Eine Übereinstimmung wäre auf alle Fälle angenehm. > Durch die Crossbar bei den SiLabs MCUs kein Problem. Das kenne ich von anderen MCUs. Das ist extrem praktisch. Ich wünschte es wäre mehr verbreitet. > >> Welchen Debugger/FLASHer würdest Du andernfalls vorschlagen? >> Ist das der richtige zum anfangen? > Was ich meinte mit "aufwendiger" ist die 10-polige Stiftleiste mit > Wanne, die du für den Debugger-Anschluss brauchst. Ich hab mir deswegen > eine kleine Zwischenplatine auf LoRa gebastelt, bei der ich nur vier > bzw. fünf Pins brauche. > Bzgl. der Debugadapter selbst, dein Link ist der reguläre DA, wie er bei > jedem Devkit dabei ist (deswegen lohnt sich's fast nicht den DA separat > zu kaufen). Falls du kein Devkit dein eigen nennst, es gibt die sog. > ToolSticks, davon brauchst du den BaseAdapter, und die Debug-Daughter. > Beide haben Vor- und Nachteile (bei der TS-Variante kannst du z.B. > Rx/Tx. des TS abgreifen und über eine separate SiLabs-Terminalanwendung > den UART ansprechen). > Ich hab beide Varianten im Einsatz. Ich werde mich bei Gelegenheit mit den Einzelheiten vertraut machen. Jedenfalls ist es nicht aufwendiger wie alles andere. Ein Devkit habe ich nicht. Werde mir mal die Sachen bei Digi-Key/Mouser näher ansehen. Ich habe vor ein paar Jahren übrigens mit den Encore ZILOG MCUs gearbeitet. Die sind auch nicht schlecht. Habe dann eine kleine Experimentierplatine für die DIP-Gehaeuse dazu erstellt, die irgendwo im Forum vorgestellt ist. Die ganze IDE mit C-Compiler und Debugger gibt es kostenlos. Ein 12kB Projekt funktionierte auf Anhieb ohne große Mucken. > >> Es ist übrigens schön dass die Teile noch 5V vertragen. Obwohl man sich >> an 3.3V Technik gewöhnt sind mir für viele Projekte 5V Versorgung immer >> noch lieber. > Kenn ich :) > Aber ich gewöhne mich langsam an Komplett-3V3-Designs. Das muss ich schon seit einiger Zeit beruflich;-) Ist aber gar nicht so schlimm wie es am Anfang aussah. Nur die LCD Module wollen höhere "H" Pegel haben. Ohne Pegelumsetzer von 3.3V auf 5V gab es sofort Krach bei den meisten Modulen. In der Hinsicht sind die DOGM LCDs wieder sehr praktisch. Jetzt muss ich aber aufhören über den Zaun zu schauen. Ich bin nämlich der Ansicht dass man sich nicht zu sehr mit verschieden Typen verzetteln sollte. In der Firma machen wir PIC, AVR, STM32 und noch ARM7, aber keine 51er. Wenn man mit zu vielen Familien arbeitet kennt man sich am Ende mit keinem mehr richtig aus. Mit den PICs und AVRs ging es für allgemeine Projekte immer recht gut. Die AVR sind aber deutlich schlechter zum kriegen. Mit Mikrochip fährt mindestens bei uns in N.A. eigentlich besser. Die STM32, SiLab, und NXP sind auch keine Problem. Atmel ist mit Abstand am schwierigsten zu bekommen. Wahrscheinlich sind wir nicht groß genug;-) Naja, vielleicht mache ich den kommenden Winter was mit einem 8051er. Gruß, Gerhard > > Ralf
Hallo Ralf, ich habe mir das Schaltbild und Bord in EAGLE angesehen. Sieht nett aus und nochmals vielen Dank dafür. Das lässt sich auf alle Fälle leicht nachbauen. Ich nehme vorläufig an das sich die FW mit den Silab Tools bauen lässt. Gruß, Gerhard Pieter schrieb: > Hallo Gerhard, > > STM32...man müste Zeit haben. > Einen Umsetzer AT89C51ED2 auf C2 zum proggen ist in meinem Assembler mit > drin, Datei anbei. > > Auch gut F340: extern 5V -> interner Regler -> 3V3. > > Mit Gruß > Pieter
Moin zusammen, @Gerhard: > Es würde mich auf alle Fälle interessieren. Ich hoff ich komm heut abend zum Knipsen :) > Das kenne ich von anderen MCUs. Das ist extrem praktisch. Ich wünschte > es wäre mehr verbreitet. Welche MCUs wären das? Die SiLabs-Crossbar hat was für sich, v.a. bei MCUs mit wenigen Pins, da man nur das was man braucht rausführen kann. Einziger Wehrmutstropfen ist, dass die Reihenfolge der Funktionen vorgegeben ist. Ein SiLabs-Mitarbeiter meinte mal, dass sie versucht hätten, die Crossbar voll konfigurierbar zu machen, aber das hätte allein 80% des Dies gefressen. > Das muss ich schon seit einiger Zeit beruflich;-) Ist aber gar nicht so > schlimm wie es am Anfang aussah. Eben, so geht's mir auch - wobei's mir da auch egal ist, da stehen ja dann auch andere Sachen im Vordergrund. > Jetzt muss ich aber aufhören über den Zaun zu schauen. Ich bin nämlich > der Ansicht dass man sich nicht zu sehr mit verschieden Typen verzetteln > sollte. Kommt drauf an, es ist halt denke ich so, dass es immer einen Core gibt, der für eine bestimmte Aufgabe am besten geeignet ist. Ein paar davon zu kennen schadet nicht, genauso wie es nicht schadet die Hardware einer bestimmten "Schiene" immer mit dem gleichen Core aufzubauen. > In der Firma machen wir PIC, AVR, STM32 und noch ARM7, aber > keine 51er. Wenn man mit zu vielen Familien arbeitet kennt man sich am > Ende mit keinem mehr richtig aus. Das ist aber dann eher das Problem der Softwerker :) > Mit den PICs und AVRs ging es für allgemeine Projekte immer recht gut. Die o.g. Schiene. Wir haben 8051 (noch im Einsatz, aber nicht mehr für Neuprojekte), FreeScale CF V1/Vx, und I.MX. Die Konzernschwestern setzen auch AVRs ein. > Die AVR sind aber deutlich schlechter zum kriegen. Mit Mikrochip fährt > mindestens bei uns in N.A. eigentlich besser. Was ist N.A.? Nordamerika? :) > Die STM32, SiLab, und NXP sind auch keine Problem. Atmel ist mit Abstand > am schwierigsten zu bekommen. Wahrscheinlich sind wir nicht groß genug;-) Ja, ich halt auch nicht viel von Atmel. > Naja, vielleicht mache ich den kommenden Winter was mit einem 8051er. Ich mach eben noch die ein, zwei Home-Projekte, und dann will ich den Cortex-M3 mal mehr Aufmerksamkeit schenken - zusammen mit dem CMSIS-Geraffel, da steig ich noch nicht durch. > Hallo Ralf, > ich habe mir das Schaltbild und Bord in EAGLE angesehen. Sieht nett aus > und nochmals vielen Dank dafür. Das lässt sich auf alle Fälle leicht > nachbauen. Das hat Pieter reingestellt, nicht ich :) > Ich nehme vorläufig an das sich die FW mit den Silab Tools bauen lässt. Nope, das geht mit dem Assembler von Pieter. Wenn du's mit den SiLabs-Tools "nachproggen" willst müsstest du auf den entsprechenden Assembler anpassen. Ralf
Wenn es mit der DosBox nicht klappt, versuche es mal mit der VirtualBox. die gibt es kostenlos von Oracle und installier darin dein Win-ME.
moin moin,
>>Das hat Pieter reingestellt, nicht ich :)
waas,
so schlecht, dass Du nichts damit zu tun haben möchtest?
Mit Gruß
Pieter
@Pieter: >> Das hat Pieter reingestellt, nicht ich :) > waas, so schlecht, dass Du nichts damit zu tun haben möchtest? Doch, ist gut, keine Frage. Aber er hat sich beim falschen bedankt, der Dank gebührt dir :) Ralf
Habe jetzt nicht alle Beiträge gelesen. Ich mache den Kurs bei ET-Tutorials, der arbeitet mit dem kostenlosen Simulator uVision 4 von Keil: http://et-tutorials.de/872/download-und-installation-von-%C2%B5vision4keil/
Hallo Pieter, da habe ich aber in die Nesseln gesetzt. Ist mir gar nicht aufgefallen, aber es war schon spät;-) Gruß, Gerhard Pieter schrieb: > moin moin, > >>>Das hat Pieter reingestellt, nicht ich :) > > waas, > so schlecht, dass Du nichts damit zu tun haben möchtest? > > Mit Gruß > Pieter
Hallo Ralf, jetzt habe ich schon ein schlechtes Gewissen wie sich die Richtung des Threads verändert hat. Ralf schrieb: > Moin zusammen, > > @Gerhard: >> Es würde mich auf alle Fälle interessieren. > Ich hoff ich komm heut abend zum Knipsen :) Gut;-) > >> Das kenne ich von anderen MCUs. Das ist extrem praktisch. Ich wünschte >> es wäre mehr verbreitet. > Welche MCUs wären das? Die SiLabs-Crossbar hat was für sich, v.a. bei > MCUs mit wenigen Pins, da man nur das was man braucht rausführen kann. > Einziger Wehrmutstropfen ist, dass die Reihenfolge der Funktionen > vorgegeben ist. Das war ein groesserer PIC. Kann mich aber nicht an die Typenbezeichnung erinnern. Wenn es mir wieder kommt lasse ich Dich wissen. > Ein SiLabs-Mitarbeiter meinte mal, dass sie versucht hätten, die > Crossbar voll konfigurierbar zu machen, aber das hätte allein 80% des > Dies gefressen. Das kann ich mir vorstellen. > >> Das muss ich schon seit einiger Zeit beruflich;-) Ist aber gar nicht so >> schlimm wie es am Anfang aussah. > Eben, so geht's mir auch - wobei's mir da auch egal ist, da stehen ja > dann auch andere Sachen im Vordergrund. Welcome to the new world... > >> Jetzt muss ich aber aufhören über den Zaun zu schauen. Ich bin nämlich >> der Ansicht dass man sich nicht zu sehr mit verschieden Typen verzetteln >> sollte. > Kommt drauf an, es ist halt denke ich so, dass es immer einen Core gibt, > der für eine bestimmte Aufgabe am besten geeignet ist. Ein paar davon zu > kennen schadet nicht, genauso wie es nicht schadet die Hardware einer > bestimmten "Schiene" immer mit dem gleichen Core aufzubauen. Das stimmt. Bei mir war es der Einstieg zu den STM32. Bin froh dass es so kam. > >> In der Firma machen wir PIC, AVR, STM32 und noch ARM7, aber >> keine 51er. Wenn man mit zu vielen Familien arbeitet kennt man sich am >> Ende mit keinem mehr richtig aus. > Das ist aber dann eher das Problem der Softwerker :) Nicht unbedingt. Bei uns sind "Hardwerker" und "Softwerker" meisten in einer Person vereint. Das hat aber auch einen großen Vorteil weil man die Hardware und spätere Firmware schon von vornherein auf vielen Ebenen auf einander optimieren kann. Da denkt man schon beim Hardware Design daran wie kann man Port Pins so wählen dass sie sich auch einfach in der Firmware organisieren lassen. Das kam mir nach 2000 ganz groß in Begriff als ich meine erste PIC Schaltung in der Firma Entwurf. Ein Kollege machte die F.W. Es funktionierte alles bestens. Später aber, als ich anfing meine ersten Schritte mit den MCUs zu machen lernte ich an dieser Platine und mit seiner Source. Da gingen mir dann die Augen auf wie viele Klimmzüge mein Kollege machten musste (Lookup Tables...) um eine Gruppe Port Pins bit-gruppiert zu steuern. Da ich in meiner Unerfahrenheit die Port Gruppierung nicht wichtig genommen hatte. Das war mir eine persönliche Lehre. Seitdem denke ich bei neuen Design immer auch gleichzeitig mit wie das Steuerprogramm davon beeinflusst wird und ob man schon von vornherein die Logik vereinfachen kann. > >> Mit den PICs und AVRs ging es für allgemeine Projekte immer recht gut. Die o.g. > Schiene. Wir haben 8051 (noch im Einsatz, aber nicht mehr für Neuprojekte), > FreeScale CF V1/Vx, und I.MX. Die Konzernschwestern setzen auch AVRs ein. Der i.MX wird bei uns auch schon für ein groesseres Projekt in Betracht gezogen. > >> Die AVR sind aber deutlich schlechter zum kriegen. Mit Mikrochip fährt >> mindestens bei uns in N.A. eigentlich besser. > Was ist N.A.? Nordamerika? :) Ja. (Canada) > >> Die STM32, SiLab, und NXP sind auch keine Problem. Atmel ist mit Abstand >> am schwierigsten zu bekommen. Wahrscheinlich sind wir nicht groß genug;-) > Ja, ich halt auch nicht viel von Atmel. Ich arbeite an sich ganz gerne damit, aber alles andere ist nicht so schön. Ich habe ein paar kleine Home Projekte damit gemacht. > >> Naja, vielleicht mache ich den kommenden Winter was mit einem 8051er. > Ich mach eben noch die ein, zwei Home-Projekte, und dann will ich den > Cortex-M3 mal mehr Aufmerksamkeit schenken - zusammen mit dem > CMSIS-Geraffel, da steig ich noch nicht durch. Die CMSIS ist nicht so schlimm wie es aussieht. Arbeite Dich zuerst durch die Peripherie Beispiel Projekte und studiere die Peripherie Konfigurierung. Da alle Register in stm32f10x.h schon definiert sind, kannst Du direkt darauf zu greifen: GPIOn->BSRR = 0b0000101110010111; // Setz diese Port Pins high (wo bei n A,B..G die Ports gemeint sind GPIOA->BRR = 0x0020; // Damit ist port pin PA5 gemeint, pin wird ruecksetzt Damit lässt sich schön damit arbeiten. (User Manual Section 9.2.1) Z.B. Setz PA5 als Input Pin mit Pull-up GPIOA->CRL = 0x00800000; // PC15 als O/P P-P mit 10MHZ speed: GPIOC->CRH = 0x10000000; > >> Hallo Ralf, >> ich habe mir das Schaltbild und Bord in EAGLE angesehen. Sieht nett aus >> und nochmals vielen Dank dafür. Das lässt sich auf alle Fälle leicht >> nachbauen. > Das hat Pieter reingestellt, nicht ich :) > >> Ich nehme vorläufig an das sich die FW mit den Silab Tools bauen lässt. > Nope, das geht mit dem Assembler von Pieter. Wenn du's mit den > SiLabs-Tools "nachproggen" willst müsstest du auf den entsprechenden > Assembler anpassen. > > Ralf Gruß, Gerhard
Guido schrieb: > Hallo Wilhelm, das hatte mich schon geärgert: Hallo Guido, entschuldige meine Worte von Sonntag Abend, leider war ich etwas aufgebracht. Besser wäre es, dann überhaupt nicht ins Forum zu gehen. Auf jeden Fall bisher mal VIELEN DANK an ALLE, besonders den Tipp mit DOSbox. Wie sich für mich heraus stellte, sind das doch sehr professionelle Dinge, wie z.B. auch SDCC, oder so Programme wie OpenOffice. Auch wenn die nicht kommerziell sind. Also kein Ramsch von der Wühltheke. Diese Frage stelle ich mir jedoch immer, weil ich es eben oft vorher nicht ahne. Den Rest, was nach Sonntag hier noch kam, muß ich erst noch lesen. Es darf auch gerne über alles und jedes weiter diskutiert werden. Die DOSbox kostete mich gestern leider noch mal ein paar Stunden Beschäftigung, und sowas nervt halt manchmal gewaltig, das Tools-Setup, weil die eigentliche Arbeit, die Software weiter zu entwickeln, über diese Zeit still steht. Es ist eben eine Arbeitsunterbrechung. Aber ich lasse nicht immer locker, wenns nicht auf Anhieb funktioniert. Ja, man muß sich schon mal eine Weile mit den Manuals und der Konfiguration befassen. Aber hurra, es lohnte sich: Meine alten 8051-Entwicklungstools Assembler, Disassembler, Simulator, funktionieren in der DOSbox richtig prächtig, viel besser sogar, als auf dem letzten Rechner unter Win ME im DOS-Fenster. Und mindestens so gut, wie 1993 auf dem originalen 486. Auf jeden Fall schneller, wenn man das wünscht. Alles super. ;-) Der Ashling-Assembler gibt ja am Bildschirm noch 2 kuriose Meldungen an: Startzeit und Endzeit des Assembliervorganges. Auch wenn diese Zeitstempel sich nur auf die Uhrzeiten in Stunden, Minuten und Sekunden beschränken, und der Tag nicht mehr vor kommt. Ich sah viele Bildschirmausgaben heute erst zum ersten mal, als ich die Taktzyklen in DOSbox mal herunter schaltete. So war das früher also mal, man konnte seitenweise Ausgaben am Bildschirm beobachten, was das Tool im Augenblick gerade macht. Mein erster 486 im Jahr 1993 war dafür also schon zu schnell. ;-)
Wilhelm, ich dachte du meintest das DOS-Fenster ab Win2000, nicht das Programm DOSBox. So kann man sich irren.
@Gerhard: > jetzt habe ich schon ein schlechtes Gewissen wie sich die Richtung des > Threads verändert hat. Solange wir nicht vergessen dass Wilhelm immer noch einen empfehlenswerten Simulator sucht, sollte es kein allzu großes Problem sein. Ich hab mich wie gesagt relativ früh von Simulatoren verabschiedet, auf der echten Hardware oder zumindest einem Devkit zu "simulieren" find ich besser. Daher kann ich leider nicht direkt helfen. >> Ich hoff ich komm heut abend zum Knipsen :) > Gut;-) Getan - siehe Anhang :) Die Baugruppe mit den Stiftleisten ist komplett, ein FT2xxR-DIP-Adapter, Schaltung plus Layout selbst gemacht und auch schon mehrmals im Einsatz. Die Baugruppe ohne SL ist eine SiLabs F380 MCU mit der notwendigen Minimalbeschaltung plus ein paar optionaler Konfigurations-Lötbrücken - das Modul wartet noch auf seinen ersten Einsatz, daher fehlen die SL. Auch hier sind Schaltung und Layout selbst verbrochen :) > Nicht unbedingt. Bei uns sind "Hardwerker" und "Softwerker" meisten in > einer Person vereint. Bei uns leider nicht - ich würd auch gern mal in der Firma proggen, das ist mir bis jetzt aber nur für kleinere PC-Testprogramme gegönnt gewesen. > Das hat aber auch einen großen Vorteil weil man die Hardware und spätere > Firmware schon von vornherein auf vielen Ebenen auf einander optimieren > kann. Da denkt man schon beim Hardware Design daran wie kann man Port > Pins so wählen dass sie sich auch einfach in der Firmware organisieren > lassen. Das tue ich auch ohne dass ich der Progger bin - ich les mir das RM durch, und mache dem Softwerker Vorschläge, wenn es sich um ein neues Design handelt. Auf die Art muss ich nicht zweimal ans Layout, nur weil der Softie zu bequem ist ein paar Bits passend zu schubsen ;) Andersrum muss ich auch einiges mit dem Softie abstimmen, wenn ich z.B. aus EMV-Gründen der Meinung bin, dass ein paralleler Bus an einem anderen Port besser aufgehoben ist als es sonst üblich ist. > Seitdem denke ich bei neuen Design immer auch gleichzeitig mit > wie das Steuerprogramm davon beeinflusst wird und ob man schon von > vornherein die Logik vereinfachen kann. S.o. >> Was ist N.A.? Nordamerika? :) > Ja. (Canada) Taugt das Land was für Entwicker? > Die CMSIS ist nicht so schlimm wie es aussieht. Arbeite Dich zuerst > durch die Peripherie Beispiel Projekte und studiere die Peripherie > Konfigurierung. Ja, das werd ich langsam angehen. Ich muss erstmal unterscheiden lernen zwischen CMSIS- und Nicht-CMSIS (wobei ich Nicht-CMSIS momentan eher bevorzugen würde, weil's das auf anderen Controllern auch nicht gibt). @Wilhelm: > Auf jeden Fall bisher mal VIELEN DANK an ALLE, besonders den Tipp > mit DOSbox. Freut mich dass es geklappt hat. Hast du's manuell eingestellt oder mit nem Frontend? > Meine alten 8051-Entwicklungstools Assembler, Disassembler, Simulator, > funktionieren in der DOSbox richtig prächtig Da fällt mir ein: Verwendest du eine IDE für diese alten Tools? Ich hab hier auch ältere DOS-Assembler/Linker, die ich gern über eine IDE ansprechen würde. Ralf
Abdul K. schrieb: > Wilhelm, ich dachte du meintest das DOS-Fenster ab Win2000, nicht das > Programm DOSBox. So kann man sich irren. Das DOS-Fenster in Windows kannst du öffentlich verbrennen gehen. Der Ashling-Assembler von 1991 (oder Entwicklung 1983, es stand nur ein Copyright von 1991 drin, das weiß ich nicht genau?) spuckte unter Win ME im DOS-Fenster schon komische Zeichen mit aus, die nicht in die Ausgabe gehörten, die Ausgabe war furchtbar. So vermutete ich erst, daß auch der Zielcode Intel-Hex-File eine Macke hatte. Es war glücklicherweise nie. Also wirklich, Abdul, DOSbox, ich bin verblüfft. Es ist ausgezeichnet gut.
Ralf schrieb: > @Wilhelm: >> Auf jeden Fall bisher mal VIELEN DANK an ALLE, besonders den Tipp >> mit DOSbox. > Freut mich dass es geklappt hat. Hast du's manuell eingestellt oder mit > nem Frontend? Natürlich habe ich die Config von Dosbox mit dem Mount-Befehl für ein Verzeichnis ergänzt. Sowas kann ich noch. ;-) Das Testprojekt funzt fehlerlos. Ich habe heute gelesen, daß Hulk Hogan noch mit fast 60 sich behauptet, und alles platt walzt. Das ist doch was, oder?
Angehängte Dateien:
-
IMAG0019.jpg
66 KB -
IMAG0020.jpg
68 KB
Nachtrag: Grad gesehen, dass die Bilder nicht hochgekommen sind - neuer Versuch! Ralf
Hallo Ralf, danke für die Bilder. So einen FT232 Adapter für SK10 habe ich mir auch gemacht. Es lohnt sich fast nicht mehr selber zu bauen weil man diese Dinge als Bord oder fertiges USB<-> Serial CMOS Kabel von China für ein paar Dollar erstehen kann. Sicher der Kunde freut sich über die billigen Preise. Es ist wirklich schlimm wie die uns fertig machen. Das kann man natuerlich in breiter Weise verstehen. Nur sind wir letzten Endes die leidtragenden weil wir praktisch nur mehr in Nische Sachen wettbewerbsfähig sein können. Irgendwie stört mich diese Art von Niedrigst Preis Vermarktung. Da können wir bei uns nicht mehr mithalten. Sind bei Deiner 8051er Platine auch Pads für die Oszillatorbeschaltung vorhanden? Die mache ich immer gleich gerne drauf damit die Verbindungen schön kurz bleiben. Ich nehme sonst an dass Du meistens den internen Oszillator verwendest. Gruß, Gerhard Ralf schrieb: > Nachtrag: > Grad gesehen, dass die Bilder nicht hochgekommen sind - neuer Versuch! > > Ralf
Hallo Ralf, Ralf schrieb: > @Gerhard: >> jetzt habe ich schon ein schlechtes Gewissen wie sich die Richtung des >> Threads verändert hat. > Solange wir nicht vergessen dass Wilhelm immer noch einen > empfehlenswerten Simulator sucht, sollte es kein allzu großes Problem > sein. Ich hab mich wie gesagt relativ früh von Simulatoren > verabschiedet, auf der echten Hardware oder zumindest einem Devkit zu > "simulieren" find ich besser. Daher kann ich leider nicht direkt helfen. Ich auch nicht. > >>> Ich hoff ich komm heut abend zum Knipsen :) >> Gut;-) > Getan - siehe Anhang :) > Die Baugruppe mit den Stiftleisten ist komplett, ein FT2xxR-DIP-Adapter, > Schaltung plus Layout selbst gemacht und auch schon mehrmals im Einsatz. > Die Baugruppe ohne SL ist eine SiLabs F380 MCU mit der notwendigen > Minimalbeschaltung plus ein paar optionaler Konfigurations-Lötbrücken - > das Modul wartet noch auf seinen ersten Einsatz, daher fehlen die SL. > Auch hier sind Schaltung und Layout selbst verbrochen :) Danke. Habe sie mir schon angesehen. > >> Nicht unbedingt. Bei uns sind "Hardwerker" und "Softwerker" meisten in >> einer Person vereint. > Bei uns leider nicht - ich würd auch gern mal in der Firma proggen, das > ist mir bis jetzt aber nur für kleinere PC-Testprogramme gegönnt > gewesen. > Das ist wirklich schade. Ich finde es macht erst richtig Spaß wenn man alles zusammen erstellen kann. >> Das hat aber auch einen großen Vorteil weil man die Hardware und spätere > > Firmware schon von vornherein auf vielen Ebenen auf einander optimieren >> kann. Da denkt man schon beim Hardware Design daran wie kann man Port >> Pins so wählen dass sie sich auch einfach in der Firmware organisieren >> lassen. > Das tue ich auch ohne dass ich der Progger bin - ich les mir das RM > durch, und mache dem Softwerker Vorschläge, wenn es sich um ein neues > Design handelt. Auf die Art muss ich nicht zweimal ans Layout, nur weil > der Softie zu bequem ist ein paar Bits passend zu schubsen ;) > Andersrum muss ich auch einiges mit dem Softie abstimmen, wenn ich z.B. > aus EMV-Gründen der Meinung bin, dass ein paralleler Bus an einem > anderen Port besser aufgehoben ist als es sonst üblich ist. Was ist das "RM" - Irgendein Design Manual? Ich bin der Meinung dass diese Art von Zusammenarbeit für beide Seiten nur von Vorteil sein kann. Bei miniaturisierten Projekten kann die Pin Re-Konfigurierung hoch ausschlaggebend für ein gutes Layout sein. > >> Seitdem denke ich bei neuen Design immer auch gleichzeitig mit >> wie das Steuerprogramm davon beeinflusst wird und ob man schon von >> vornherein die Logik vereinfachen kann. > S.o. > >>> Was ist N.A.? Nordamerika? :) >> Ja. (Canada) > Taugt das Land was für Entwicker? Nur zum Teil. Kommt wirklich darauf an. Es gibt viele kleine Klitschen wo oft an interessanten Produkten und Projekten gearbeitet wird aber die Arbeitsbedingen nicht an Europaesche Vorstellungen herankommen. Da kann es regelmäßig ziemlich stressig werden. Auch die Arbeitssicherheit kann sehr problematisch sein. In Alberta ist der Energiesektor sehr groß. Da werden viele Fachleute in der Prozessindustrie gesucht. Die kontroverse Ölsandindustrie braucht natuerlich Unmengen an Personal. Bis 1990+ gab es bei uns jede Menge an Elektronikentwicklung in Großfirmen (Northern Telecom, Nova...) Das hat sich mit dem Abbau grundlegend ab 1990 geändert. Mit Free-Trade schlossen viele Betriebe. In groesseren Firmen ist es in der Hinsicht viel besser. Aber es ist oft Glücksache etwas zu finden was an alle Vorstellungen herankommt. In Nischen tut sich noch viel ist aber nicht immer sehr im Offenen. Ich habe das Glück seit 1998 in einer relative kleinen Firma (<40 AN) zu arbeiten wo gute Arbeitsbedingen herrschen und man sich richtig austoben kann. Das Arbeitsklima ist recht angenehm und die Kollegen sind nett. Ich bin der Ansicht dass in D wahrscheinlich im allgemeinen doch noch bessere Arbeitsmöglichkeiten vorherrschen wie in C. Bei uns ist das eher etwas Glücksache. Es hängt sehr von der persönlichen Situation ab. > >> Die CMSIS ist nicht so schlimm wie es aussieht. Arbeite Dich zuerst >> durch die Peripherie Beispiel Projekte und studiere die Peripherie >> Konfigurierung. > Ja, das werd ich langsam angehen. Ich muss erstmal unterscheiden lernen > zwischen CMSIS- und Nicht-CMSIS (wobei ich Nicht-CMSIS momentan eher > bevorzugen würde, weil's das auf anderen Controllern auch nicht gibt). Binde auf alle Fälle die Datei "stm32F10x.h" ein. Dort sind alle Register Definitions schon spezifiziert. Damit bekommst Du sofort bequemen Zugriff auf die Hardware Register. Der CMSIS Startup Code ist auch sehr praktisch. Die Library brauchst Du sonst nicht wirklich. Den Startup Code kann man sich auch selber schreiben, bin aber der Ansicht dass sich das nicht wirklich lohnt. Such im Internet nach "OpenBLT". Die haben eine wirklich guten Bootloader. Dieses Programm verwendet seinen eigenen Startup Code und kommt bis auf "stm32f10x.h" ohne CMSIS aus. Ich empfehle Dir OpenBLT herunterzuladen und das Programm zu studieren. Es ist ein Beispiel von sehr schön geschriebenem, effizienten Code. Du kannst Dir dann den Startteil als Template in Deinen eigenen Projekten als Startpunkt verwenden. Gruß, Gerhard > > @Wilhelm: >> Auf jeden Fall bisher mal VIELEN DANK an ALLE, besonders den Tipp >> mit DOSbox. > Freut mich dass es geklappt hat. Hast du's manuell eingestellt oder mit > nem Frontend? > >> Meine alten 8051-Entwicklungstools Assembler, Disassembler, Simulator, >> funktionieren in der DOSbox richtig prächtig > Da fällt mir ein: Verwendest du eine IDE für diese alten Tools? Ich hab > hier auch ältere DOS-Assembler/Linker, die ich gern über eine IDE > ansprechen würde. > > Ralf
Hi Gerhard, > danke für die Bilder. So einen FT232 Adapter für SK10 habe ich mir auch > gemacht. Es lohnt sich fast nicht mehr selber zu bauen weil man diese > Dinge als Bord oder fertiges USB<-> Serial CMOS Kabel von China für ein > paar Dollar erstehen kann. Ja, das Teil ist für einen Bekannten entstanden, der einen kleinen Bauteilversand hat. Es war halt billiger als die Dinger ein- und dann weiter zu verkaufen. > Sicher der Kunde freut sich über die billigen Preise. Es ist wirklich > schlimm wie die uns fertig machen. Das kann man natuerlich in breiter > Weise verstehen. Nur sind wir letzten Endes die leidtragenden weil wir > praktisch nur mehr in Nische Sachen wettbewerbsfähig sein können. > Irgendwie stört mich diese Art von Niedrigst Preis Vermarktung. Da > können wir bei uns nicht mehr mithalten. Die Jungs holen schwer auf - und mit ihnen auch ihre Löhne. Ich denke in ein paar Jahren sind die so weit wie wir jetzt - und wir sind soweit runtergeknüppelt, dass die dann vielleicht bei uns fertigen lassen. > Sind bei Deiner 8051er Platine auch Pads für die Oszillatorbeschaltung > vorhanden? Die mache ich immer gleich gerne drauf damit die Verbindungen > schön kurz bleiben. Ich nehme sonst an dass Du meistens den internen > Oszillator verwendest. Nein, bisher bin ich immer mit dem internen Oszillator ausgekommen, der auch bei den USB-MCUs stabil genug ist. Höchste verwendete Baudrate des UART 230400 Baud, funktioniert. > Das ist wirklich schade. Ich finde es macht erst richtig Spaß wenn man > alles zusammen erstellen kann. Deswegen bastel ich dann zuhause an Hard- und Software :) >> Taugt das Land was für Entwicker? > Nur zum Teil. Kommt wirklich darauf an. > ... Danke für den Erfahrungsbericht :) -> C also nur zum Urlaub ;) > Binde auf alle Fälle die Datei "stm32F10x.h" ein. Dort sind alle > Register Definitions schon spezifiziert. Damit bekommst Du sofort > bequemen Zugriff auf die Hardware Register. Der CMSIS Startup Code ist > auch sehr praktisch. Die Library brauchst Du sonst nicht wirklich. Den > Startup Code kann man sich auch selber schreiben, bin aber der Ansicht > dass sich das nicht wirklich lohnt. Muss mich da erstmal durchwurschteln. Die CMSIS-Implementierung für die NXP Controller hatte jedenfalls das #define für die Quarzfrequenz irgendwo versteckt, und mich hat das gekekst. Das gehört m.E. in eines der "oben" sichtbaren Files, zumal ich damals nicht rausgefunden hab, ob man den Wert einfach ändern kann/darf -> wenn man z.B. eine andere Frequenz verwendet. > Such im Internet nach "OpenBLT". Die haben eine wirklich guten > Bootloader. > ... > Du kannst Dir dann den Startteil als Template in Deinen eigenen > Projekten als Startpunkt verwenden. Danke für den Tip. Ralf
Hi Ralf, Ralf schrieb: > Hi Gerhard, > >> danke für die Bilder. So einen FT232 Adapter für SK10 habe ich mir auch >> gemacht. Es lohnt sich fast nicht mehr selber zu bauen weil man diese >> Dinge als Bord oder fertiges USB<-> Serial CMOS Kabel von China für ein >> paar Dollar erstehen kann. > Ja, das Teil ist für einen Bekannten entstanden, der einen kleinen > Bauteilversand hat. Es war halt billiger als die Dinger ein- und dann > weiter zu verkaufen. OK. Das stimmt. > >> Sicher der Kunde freut sich über die billigen Preise. Es ist wirklich >> schlimm wie die uns fertig machen. Das kann man natuerlich in breiter >> Weise verstehen. Nur sind wir letzten Endes die leidtragenden weil wir >> praktisch nur mehr in Nische Sachen wettbewerbsfähig sein können. >> Irgendwie stört mich diese Art von Niedrigst Preis Vermarktung. Da >> können wir bei uns nicht mehr mithalten. > Die Jungs holen schwer auf - und mit ihnen auch ihre Löhne. Ich denke in > ein paar Jahren sind die so weit wie wir jetzt - und wir sind soweit > runtergeknüppelt, dass die dann vielleicht bei uns fertigen lassen. Ich hoffe nicht dass es so weit kommt. In unserem Interesse wollen wir wünschen dass ihr Lebensstandard und Löhne so bald wie moeglich mit unseren vergleichbar werden. > >> Sind bei Deiner 8051er Platine auch Pads für die Oszillatorbeschaltung >> vorhanden? Die mache ich immer gleich gerne drauf damit die Verbindungen >> schön kurz bleiben. Ich nehme sonst an dass Du meistens den internen >> Oszillator verwendest. > Nein, bisher bin ich immer mit dem internen Oszillator ausgekommen, der > auch bei den USB-MCUs stabil genug ist. Höchste verwendete Baudrate des > UART 230400 Baud, funktioniert. Beindruckend. Das ist gut zu wissen. > >> Das ist wirklich schade. Ich finde es macht erst richtig Spaß wenn man >> alles zusammen erstellen kann. > Deswegen bastel ich dann zuhause an Hard- und Software :) Das verstehe ich recht gut. Welche Projekte interessieren Dich? > >>> Taugt das Land was für Entwicker? >> Nur zum Teil. Kommt wirklich darauf an. >> ... > Danke für den Erfahrungsbericht :) -> C also nur zum Urlaub ;) Ganz so schlimm ist es nicht. Vor 30 Jahren wie ich ankam war es noch relativ leicht was gutes zu finden und sich etablieren. Es hat sich über die Jahre hinweg auch hier sehr viel geändert. Es sind eben heutzutage viel weniger Firmen da die noch im eigenen Land funktionieren. > >> Binde auf alle Fälle die Datei "stm32F10x.h" ein. Dort sind alle >> Register Definitions schon spezifiziert. Damit bekommst Du sofort >> bequemen Zugriff auf die Hardware Register. Der CMSIS Startup Code ist >> auch sehr praktisch. Die Library brauchst Du sonst nicht wirklich. Den >> Startup Code kann man sich auch selber schreiben, bin aber der Ansicht >> dass sich das nicht wirklich lohnt. > Muss mich da erstmal durchwurschteln. Die CMSIS-Implementierung für die > NXP Controller hatte jedenfalls das #define für die Quarzfrequenz > irgendwo versteckt, und mich hat das gekekst. Das gehört m.E. in eines > der "oben" sichtbaren Files, zumal ich damals nicht rausgefunden hab, > ob man den Wert einfach ändern kann/darf -> wenn man z.B. eine andere > Frequenz verwendet. Mit den M3 Typen von NXP habe ich keine praktische Erfahrung. Beim STM32 findest Du einige vorgewählte Frequenzen für die Clockeinstellung in der Datei "system_stm32f10x.c" welche vom startup code automatisch gerufen wird ("SystemInit"). Die Vector Tabelle ist in "startup_stm32f10x_hd.s" zu finden (für Atollic TRUESTUDIO). > >> Such im Internet nach "OpenBLT". Die haben eine wirklich guten >> Bootloader. >> ... >> Du kannst Dir dann den Startteil als Template in Deinen eigenen >> Projekten als Startpunkt verwenden. > Danke für den Tip. Gruß, Gerhard > > Ralf
Hi Gerhard, > Das verstehe ich recht gut. Welche Projekte interessieren Dich? Die aktuellen sind grad ein kleiner PWM-Controller für LEDs und ein Lautstärkemesser, ebenfalls mit Controller. Desweiteren möchte ich bei Gelegenheit mal ein digitales Theremin bauen, hierzu hab ich mir auch ein paar PCBs gemacht, z.B. mit einem TLV320AIC23B. Ein UDA1320-Board sowie eins mit einem AD9833 fliegen auch noch rum :) Das wären dann z.B. die möglichen Kandidaten für die Soundausgabe des Theremins gewesen. Im Prinzip ist das Projekt an sich fast immer wurscht, solange das Thema interessant ist (z.B. eben Theremin). > Es sind eben heutzutage viel weniger Firmen da die noch im eigenen Land > funktionieren. Scheint so, ja :/ > Mit den M3 Typen von NXP habe ich keine praktische Erfahrung. Viel konnte ich bisher leider nicht damit machen. Schön ist halt, dass sie einen BL haben (den man allerdings auch komplett sperren kann, wenn man's falsch macht). Da SiLabs mittlerweile auch M3 im Angebot hat, werd ich mich aber wohl eher auf die konzentrieren - natürlich mit Crossbar :) Und wenn ich mich recht erinnere sogar entgegen anderer M3-Implementation ohne den krüppligen 16550-UART, sondern mit was gescheitem (müsst ich aber nochmal prüfen). Ralf
Hi Ralf, Ralf schrieb: > Hi Gerhard, > >> Das verstehe ich recht gut. Welche Projekte interessieren Dich? > Die aktuellen sind grad ein kleiner PWM-Controller für LEDs und ein > Lautstärkemesser, ebenfalls mit Controller. Desweiteren möchte ich bei > Gelegenheit mal ein digitales Theremin bauen, hierzu hab ich mir auch > ein paar PCBs gemacht, z.B. mit einem TLV320AIC23B. Ein UDA1320-Board > sowie eins mit einem AD9833 fliegen auch noch rum :) Das wären dann z.B. > die möglichen Kandidaten für die Soundausgabe des Theremins gewesen. > Im Prinzip ist das Projekt an sich fast immer wurscht, solange das Thema > interessant ist (z.B. eben Theremin). Deine Projekte sind wirklich faszinierend. Ein digitales Theremin dürfte ein ziemlich anspruchsvolles DSP Projekt sein. Das würde ich mir gerne anhören wollen. Gibt es Bilder davon? Die Antennenkonstruktion ist wahrscheinlich sehr kritisch. Ist der Lautstaerkemesser als richtiges VU Meter mit der notwendigen Ballistik konzipiert und mit welchem Prozessor? Macht der auch Spitzenanzeige? Welche Anzeige? Kann man auch I2S anschließen oder nur NF? Mich würde andrerseits ein 24-bit PCM/MP3 NF Recorder Projekt reizen. Mit dem F4 könnte es auch gut gelingen. Ein Arbeitskollege hat einen F4 basierten MP3 Player auf der Discovery Bord mit USB Memory zum laufen gebracht. Er verwendete ein MP3 Codec Library zur Umwandlung. Bei 192KB betrug die CPU Belastung weniger als 20%. Das ist sehr ermutigend. Die NF Qualität mit dem eingebauten Stereo DAC war gar nicht so schlecht. > >> Es sind eben heutzutage viel weniger Firmen da die noch im eigenen Land >> funktionieren. > Scheint so, ja :/ > >> Mit den M3 Typen von NXP habe ich keine praktische Erfahrung. > Viel konnte ich bisher leider nicht damit machen. Schön ist halt, dass > sie einen BL haben (den man allerdings auch komplett sperren kann, wenn > man's falsch macht). Ich habe nur Erfahrung mit dem LPC2148 in ARM7TDI Modus mit WINARM. > Da SiLabs mittlerweile auch M3 im Angebot hat, werd ich mich aber wohl > eher auf die konzentrieren - natürlich mit Crossbar :) > Und wenn ich mich recht erinnere sogar entgegen anderer > M3-Implementation ohne den krüppligen 16550-UART, sondern mit was > gescheitem (müsst ich aber nochmal prüfen). Die UARTS beim STM32 funktionieren alle ausgezeichnet. Mein letztes Projekt verwendete gleich drei davon mit RTS/CTS Handshake. Funktionierte vollkommen tadellos im simultanen Interrupt Betrieb. Gruss, Gerhard > > Ralf
Hi Gerhard, > Deine Projekte sind wirklich faszinierend. Ein digitales Theremin dürfte > ein ziemlich anspruchsvolles DSP Projekt sein. Das würde ich mir gerne > anhören wollen. Gibt es Bilder davon? Die Antennenkonstruktion ist > wahrscheinlich sehr kritisch. Das digitale ist ja nur in Planung :) Das analoge hab ich mal aufgebaut, allerdings sollte es mal in ein Gehäuse (momentan isses open-frame und die Antennen sind einfach Metallstäbe/-drähte). Such mal auf YT nach "theremin killed the radio star" :) Mein analoges hört sich natürlich bei weitem nicht so gut an (im Video wird wohl ein Synthesizer o.ä. verwendet), aber als Karaoke-Gimmick o.ä. isses sicherlich zu gebrauchen. Für das digitale möchte ich die Einzelkomponenten aufbauen und testen, und dann alles miteinander verknubbeln (daher auch die o.g. verschiedenen Schaltungen mit TLV..., UDA..., etc.). > Ist der Lautstaerkemesser als richtiges VU Meter mit der notwendigen > Ballistik konzipiert und mit welchem Prozessor? Macht der auch > Spitzenanzeige? Welche Anzeige? Kann man auch I2S anschließen oder nur > NF? Ich glaub ich hab den falschen Begriff verwendet :) Ich brauche keine db-Werte der Umgebungslautstärke o.ä., sondern einfach nur einen "Ausschlag", wenn in der Umgebung was geht, wobei die Empfindlichkeit etc. einstellbar sein soll. Und wie beim o.g. PWM-Controller handelt es sich auch hier um einen kleinen SiLabs 8051er. Die ersten Versuche waren schon ganz okay, nur leider fing der Mikrofon-Verstärker immer wieder das Schwingen an, und Analogtechnik ist nicht so mein Ding (deswegen auch digitales Theremin :) > Ein Arbeitskollege hat einen F4 basierten MP3 Player auf der Discovery > Bord mit USB Memory zum laufen gebracht. Er verwendete ein MP3 Codec > Library zur Umwandlung. Bei 192KB betrug die CPU Belastung weniger als > 20%. Das ist sehr ermutigend. Die NF Qualität mit dem eingebauten Stereo > DAC war gar nicht so schlecht. Cool. Das hört sich gut an. > Die UARTS beim STM32 funktionieren alle ausgezeichnet. Mein letztes > Projekt verwendete gleich drei davon mit RTS/CTS Handshake. > Funktionierte vollkommen tadellos im simultanen Interrupt Betrieb. Jaaaa, weil die von einer fertigen Lib bedient werden, oder? ;) Ralf
Hi Ralf, Ralf schrieb: > Hi Gerhard, > >> Deine Projekte sind wirklich faszinierend. Ein digitales Theremin dürfte >> ein ziemlich anspruchsvolles DSP Projekt sein. Das würde ich mir gerne >> anhören wollen. Gibt es Bilder davon? Die Antennenkonstruktion ist >> wahrscheinlich sehr kritisch. > Das digitale ist ja nur in Planung :) Das analoge hab ich mal aufgebaut, > allerdings sollte es mal in ein Gehäuse (momentan isses open-frame und > die Antennen sind einfach Metallstäbe/-drähte). Such mal auf YT nach > "theremin killed the radio star" :) Mein analoges hört sich natürlich > bei weitem nicht so gut an (im Video wird wohl ein Synthesizer o.ä. > verwendet), aber als Karaoke-Gimmick o.ä. isses sicherlich zu > gebrauchen. > Für das digitale möchte ich die Einzelkomponenten aufbauen und testen, > und dann alles miteinander verknubbeln (daher auch die o.g. > verschiedenen Schaltungen mit TLV..., UDA..., etc.). Der YT ist beeindruckend. Da kann man schon viel mehr damit machen als mit der Analog Version. Obwohl die analogen Theremenis eine mehr mysteriöse Klangnote haben. Bei einem Song der Beachboys wurde auch einer verwendet. > >> Ist der Lautstaerkemesser als richtiges VU Meter mit der notwendigen >> Ballistik konzipiert und mit welchem Prozessor? Macht der auch >> Spitzenanzeige? Welche Anzeige? Kann man auch I2S anschließen oder nur >> NF? > Ich glaub ich hab den falschen Begriff verwendet :) Ich brauche keine > db-Werte der Umgebungslautstärke o.ä., sondern einfach nur einen > "Ausschlag", wenn in der Umgebung was geht, wobei die Empfindlichkeit > etc. einstellbar sein soll. Und wie beim o.g. PWM-Controller handelt es > sich auch hier um einen kleinen SiLabs 8051er. > Die ersten Versuche waren schon ganz okay, nur leider fing der > Mikrofon-Verstärker immer wieder das Schwingen an, und Analogtechnik ist > nicht so mein Ding (deswegen auch digitales Theremin :) Beschreibe mal den Mikrophonverstärker. Vielleicht kann ich Dir irgendwie einen Rat geben. Die meisten Sachen lassen sich bezaehmen. Wenn es mit dem NF Recorder so weit kommt, muss ich mir auch darüber Gedanken machen. > >> Ein Arbeitskollege hat einen F4 basierten MP3 Player auf der Discovery >> Bord mit USB Memory zum laufen gebracht. Er verwendete ein MP3 Codec >> Library zur Umwandlung. Bei 192KB betrug die CPU Belastung weniger als >> 20%. Das ist sehr ermutigend. Die NF Qualität mit dem eingebauten Stereo >> DAC war gar nicht so schlecht. > Cool. Das hört sich gut an. > >> Die UARTS beim STM32 funktionieren alle ausgezeichnet. Mein letztes >> Projekt verwendete gleich drei davon mit RTS/CTS Handshake. >> Funktionierte vollkommen tadellos im simultanen Interrupt Betrieb. > Jaaaa, weil die von einer fertigen Lib bedient werden, oder? ;) Eigentlich nicht. Habe die StdPeriph. Lib nur zur Initialisierung der UART Peripherie verwendet. Alles andere ist von Hand gemacht. Gruß, Gerhard > > Ralf
Hi Gerhard, > Der YT ist beeindruckend. Da kann man schon viel mehr damit machen als > mit der Analog Version. Obwohl die analogen Theremenis eine mehr > mysteriöse Klangnote haben. Bei einem Song der Beachboys wurde auch > einer verwendet. Das IST die Analog-Version, nur eben ein Synthi hinten dran (sieht man dadurch, dass er immer wieder mit dem Fuß den Sound umstellt). Für das digitale T dachte ich mir, dass ich per DDS-Ansatz bestimmte Töne erzeugen kann, evtl. sogar mit mehreren Kanälen. Die Realisierung der kapazitiven Erkennung für die Antennen wird aber denke ich eher der große Brocken sein :) > Beschreibe mal den Mikrophonverstärker. Vielleicht kann ich Dir > irgendwie einen Rat geben. Die meisten Sachen lassen sich bezaehmen. Naja, momentan LR-Aufbau, der erste Versuch mit einem einzelnen OP-Amp war okay, aber ich wollte das Signal noch weiter verstärken. Also ein zweiter Op-Amp dran, und dann ging's los... Ich kann die Schaltung heut abend mal rauskramen und dir beschreiben, was ich genau machen will. >> Jaaaa, weil die von einer fertigen Lib bedient werden, oder? ;) > Eigentlich nicht. Habe die StdPeriph. Lib nur zur Initialisierung der > UART Peripherie verwendet. Alles andere ist von Hand gemacht. Hmmm... Ich wollte es auch von Hand machen, und bin dann zum Schluss gekommen, dass ein 16550-UART murks ist, weil man zwar ein Flag für Buffer-Leer hat, aber nicht für Buffer-Voll (Sendebuffer). Hab mir auch diverse Software-Treiber angeguckt, und fand es ziemlich krüpplig, wie der UART bedient werden muss. Allerdings waren das alles nur oberflächliche Begutachtungen! Wie gesagt, in die Tiefe gehen muss ich noch, dann wird vielleicht auch die "Akzeptanz" besser :) Ralf
Hi Ralf, Ralf schrieb: > Hi Gerhard, > >> Der YT ist beeindruckend. Da kann man schon viel mehr damit machen als >> mit der Analog Version. Obwohl die analogen Theremenis eine mehr >> mysteriöse Klangnote haben. Bei einem Song der Beachboys wurde auch >> einer verwendet. > Das IST die Analog-Version, nur eben ein Synthi hinten dran (sieht man > dadurch, dass er immer wieder mit dem Fuß den Sound umstellt). > Für das digitale T dachte ich mir, dass ich per DDS-Ansatz bestimmte > Töne erzeugen kann, evtl. sogar mit mehreren Kanälen. > Die Realisierung der kapazitiven Erkennung für die Antennen wird aber > denke ich eher der große Brocken sein :) Theremenis = Plural? ;-) Vielleicht lässt sich irgendwas mit den zahlreichen CAPSENSE MCUs machen. Ich hatte vor Jahren gute Erfolge mit dem leider nicht mehr erhältlichen QT300 SPI Capsensor von Quantum Research. Solange die Updates schnell genug sind könnte man das mit capsense ICs alles andere digital machen. > >> Beschreibe mal den Mikrophonverstärker. Vielleicht kann ich Dir >> irgendwie einen Rat geben. Die meisten Sachen lassen sich bezaehmen. > Naja, momentan LR-Aufbau, der erste Versuch mit einem einzelnen OP-Amp > war okay, aber ich wollte das Signal noch weiter verstärken. Also ein > zweiter Op-Amp dran, und dann ging's los... > Ich kann die Schaltung heut abend mal rauskramen und dir beschreiben, > was ich genau machen will. Versuche mal den zweiten OP relative zur ersten Stufe invertiert zu beschalten so dass die Phase vom Ausgangssignal 180 Grad gedreht ist. Sonst müsste man auch aufpassen dass z.B keine Verkopplungen zwischen der Bias-Beschaltung auftreten können wie es z.B. der Fall ist wenn zwei Stufen von einem gemeinsamen Spannungsteiler versorgt werden um den Ausgang auf Vcc/2 halten zu können. Solch ein Spannungsteiler muss unbedingt mit einem großen C abgeblockt werden. Vielleicht hilft Dir das etwas obwohl das alles Schüsse ins Blaue sind. > >>> Jaaaa, weil die von einer fertigen Lib bedient werden, oder? ;) >> Eigentlich nicht. Habe die StdPeriph. Lib nur zur Initialisierung der >> UART Peripherie verwendet. Alles andere ist von Hand gemacht. > Hmmm... Ich wollte es auch von Hand machen, und bin dann zum Schluss > gekommen, dass ein 16550-UART murks ist, weil man zwar ein Flag für > Buffer-Leer hat, aber nicht für Buffer-Voll (Sendebuffer). Hab mir auch > diverse Software-Treiber angeguckt, und fand es ziemlich krüpplig, wie > der UART bedient werden muss. Allerdings waren das alles nur > oberflächliche Begutachtungen! Wie gesagt, in die Tiefe gehen muss ich > noch, dann wird vielleicht auch die "Akzeptanz" besser :) Ich polle bei mir im Treiber nur die TXE-Flag bevor ich dem TX-Buffer das nächste Byte verpasse. Dann kann an sich nichts passieren weil ich erst dann das nächste Byte lade wenn der Buffer leer ist. Der Buffer-Voll Zustand wird implizit durch die TXE-Flag signalisiert, so wie ich das sehe. Wenn das letzte Byte abgegangen ist schalte ich den TXE interrupt aus bis neue Daten im Puffer eingetroffen sind. Mit dem FIFO habe ich noch nicht experimentiert. Den USART-DMA Betrieb habe ich auch noch nicht erforscht. Da habe ich auch keine Erfahrung damit. Ich verwende DMA z. Zt. nur beim ADC (12 Kanäle) was eine feine Sache ist. Mache Dir im Augenblick nicht zu viele Gedanken. Die UARTS haben sich bei uns schon seit langer Zeit im Betrieb sehr bewährt. Ich habe mir die Silab MCUs nochmals näher angesehen und finde die jetzt auch recht toll. Die ERRATA sind verblüffend kurz und nur von "MINOR" Wichtigkeit. Dagegen sind die ERRATA bei vielen anderen MCUs erschreckend voluminös;-) Die MCU Geschwindigkeit ist ja atemberaubend. (50 MIPS) Ich werde mir vielleicht einen Toolstick+Adapter zukommen lassen um damit einige Schritte zu tun. Wie ich schon herausgefunden hatte wird uVision vom IDE unterstützt. Die Initialisierung bei den Beispielprogrammen sieht ziemlich verständlich aus. Nur die Crosspoint Konfigurierung müsste ich gründlich studieren. Wie man sagt, der Appetit kommt mit dem Essen. Gerhard > > Ralf
Hi Gerhard, > Theremenis = Plural? ;-) Du hast den Begriff geprägt ^^ > Vielleicht lässt sich irgendwas mit den zahlreichen CAPSENSE MCUs > machen. Ich hab von den SiLabs-CapSense-MCUs die F7xx/F8xx/F92x hier, wobei ich bzgl. Näherung nur mit dem F9xx gespielt hatte. War ganz okay, aber aufgrund des "undefinierten" Versuchsaufbaus nicht aussagekräftig - aber er hat relativ gut reagiert. > Ich hatte vor Jahren gute Erfolge mit dem leider nicht mehr erhältlichen > QT300 SPI Capsensor von Quantum Research. Solange die Updates schnell > genug sind könnte man das mit capsense ICs alles andere digital machen. Ich denke auch, dass ein dedizierter Sensor mehr bringt. Eine CapSense-MCU könnte aber trotzdem die Bedien-Elemente bedienen (Wortspiel). > Versuche mal den zweiten OP relative zur ersten Stufe invertiert zu > beschalten so dass die Phase vom Ausgangssignal 180 Grad gedreht ist. Ich werd mir erst nochmal Gedanken um die komplette Verstärkerschaltung machen müssen und diese neu aufbauen - auf dem bereits bestehenden Board rumzufrickeln macht glaub ich keinen Sinn, das waren Versuchsaufbauen. > Der Buffer-Voll Zustand wird implizit durch die TXE-Flag signalisiert, > so wie ich das sehe. Seh ich nicht so, "Buffer leer" ist m.E. nicht so wichtig wie "Buffer voll". Man kann's aber so lösen, dass man einen Softwarebuffer hat, der n Bytes in den Hardwarebuffer schiebt, wenn das TXE-Flag aktiv ist, wobei n die Größe des Hardwarebuffers ist. Aber man braucht halt beknackterweise den Softwarebuffer um einen Hardwarebuffer zu bedienen. > Ich habe mir die Silab MCUs nochmals näher angesehen und finde die jetzt > auch recht toll. Die ERRATA sind verblüffend kurz und nur von "MINOR" > Wichtigkeit. Dagegen sind die ERRATA bei vielen anderen MCUs > erschreckend voluminös;-) Stimmt, Erratas gibt's kaum, und ein weiterer Vorteil anderen Herstellern gegenüber: die meisten Fehler werden sogar behoben!!! Bei z.B. Atmel hat fast jeder 8051 Bugs... > Die MCU Geschwindigkeit ist ja atemberaubend. (50 MIPS) Die haben auch welche mit 100MHz :) > Ich werde mir vielleicht einen Toolstick+Adapter zukommen lassen um > damit einige Schritte zu tun. Wie ich schon herausgefunden hatte wird > uVision vom IDE unterstützt. Korrekt, wobei es manchmal zu Inkompatiblitäten zwischen µV und SiLabs kommen kann, da µV logischerweise erst später seine DLLs updaten kann. Im Notfall dann einfach den Keil Compiler in die SiLabs IDE einbinden und von dort arbeiten. > Nur die Crosspoint Konfigurierung müsste ich gründlich studieren. Du meinst die Crossbar? Ist auch nicht wild. Wunsch-Peripherie aktivieren, Ports konfigurieren (Push-Pull/Open-Drain/etc.) und Crossbar einschalten. Dem besseren Verständnis hilft hier der ConfigWizard, den du auf silabs.com herunterladen kannst - dort kannst du dir die Crossbar-Konfiguration zusammen klicken, ebenso wie die Timer, Oszillator, UART, etc. Aber beachte: Immer den generierten Code gegen das Datenblatt prüfen!!! Der CW ist gut, aber nicht perfekt! Ralf
Hi Ralf, Ralf schrieb: > Hi Gerhard, > >> Theremenis = Plural? ;-) > Du hast den Begriff geprägt ^^ Nach einer D Wikipedia ist die Plural von Theremin "Theremine". Meine Schreibweise war nur ein typo. > >> Vielleicht lässt sich irgendwas mit den zahlreichen CAPSENSE MCUs >> machen. > Ich hab von den SiLabs-CapSense-MCUs die F7xx/F8xx/F92x hier, wobei ich > bzgl. Näherung nur mit dem F9xx gespielt hatte. War ganz okay, aber > aufgrund des "undefinierten" Versuchsaufbaus nicht aussagekräftig - aber > er hat relativ gut reagiert. Hier kommt es höchstwahrscheinlich auf Versuche an um eine brauchbare Lösung zu finden. > >> Ich hatte vor Jahren gute Erfolge mit dem leider nicht mehr erhältlichen >> QT300 SPI Capsensor von Quantum Research. Solange die Updates schnell >> genug sind könnte man das mit capsense ICs alles andere digital machen. > Ich denke auch, dass ein dedizierter Sensor mehr bringt. Eine > CapSense-MCU könnte aber trotzdem die Bedien-Elemente bedienen > (Wortspiel). Es ist fraglich ob diese Technik bei Theremine schon mal angewandt wurde. > >> Versuche mal den zweiten OP relative zur ersten Stufe invertiert zu >> beschalten so dass die Phase vom Ausgangssignal 180 Grad gedreht ist. > Ich werd mir erst nochmal Gedanken um die komplette Verstärkerschaltung > machen müssen und diese neu aufbauen - auf dem bereits bestehenden Board > rumzufrickeln macht glaub ich keinen Sinn, das waren Versuchsaufbauen. Vielleicht hilft ein anderer Aufbau. Wenn Du aber zwei Stufen nimmst, beschalte den zweiten OP-amp so dass die Ausgangsphase um 180 Grad gedreht ist, dann können etwaige Verkopplungen schon mal weniger Schaden anrichten. > >> Der Buffer-Voll Zustand wird implizit durch die TXE-Flag signalisiert, >> so wie ich das sehe. > Seh ich nicht so, "Buffer leer" ist m.E. nicht so wichtig wie "Buffer > voll". Man kann's aber so lösen, dass man einen Softwarebuffer hat, der > n Bytes in den Hardwarebuffer schiebt, wenn das TXE-Flag aktiv ist, > wobei n die Größe des Hardwarebuffers ist. Aber man braucht halt > beknackterweise den Softwarebuffer um einen Hardwarebuffer zu bedienen. Das verstehe ich. Um welche STM32 IC Type handelte es sich bei Dir übrigens? Dass das USART ähnlich dem 16550 ist, konnte ich aber übrigens im Referenzhandbuch nicht bestätigen. Wo steht das? Ich habe mir das Kapitel vom USART noch einmal zu Gemuete geführt und kann jetzt das Fehlen des Buffer-Voll Bits bestätigen. Im DMA Sendebetrieb dürfte sich das Problem aber besser lösen lassen weil man dann nur den DMA TX Datenpuffer mit den neuen Bytes und Anzahl von Bytes laden musst. Der DMA Controller operiert dann im Wechselspiel vom Status des TXE Flag Bits. Obwohl mir im Augenblick auch einiges nicht ganz klar ist. USART DMA Betrieb könnte aber ganz nützlich sein. >> Ich habe mir die Silab MCUs nochmals näher angesehen und finde die jetzt >> auch recht toll. Die ERRATA sind verblüffend kurz und nur von "MINOR" >> Wichtigkeit. Dagegen sind die ERRATA bei vielen anderen MCUs >> erschreckend voluminös;-) > Stimmt, Erratas gibt's kaum, und ein weiterer Vorteil anderen > Herstellern gegenüber: die meisten Fehler werden sogar behoben!!! > Bei z.B. Atmel hat fast jeder 8051 Bugs... Welche jahrelang oder überhaupt nie behoben werden... > >> Die MCU Geschwindigkeit ist ja atemberaubend. (50 MIPS) > Die haben auch welche mit 100MHz :) Aber nur 3.6V Typen? > >> Ich werde mir vielleicht einen Toolstick+Adapter zukommen lassen um >> damit einige Schritte zu tun. Wie ich schon herausgefunden hatte wird >> uVision vom IDE unterstützt. > Korrekt, wobei es manchmal zu Inkompatiblitäten zwischen µV und SiLabs > kommen kann, da µV logischerweise erst später seine DLLs updaten kann. > Im Notfall dann einfach den Keil Compiler in die SiLabs IDE einbinden > und von dort arbeiten. Ich installierte gestern das IDE von Silabs und band uV2 ein. Funktionierte tadellos. Meine alte Version von uV2 hat wahrscheinlich noch keinen Debugger Support für die C8051 die mich interessieren. > >> Nur die Crosspoint Konfigurierung müsste ich gründlich studieren. > Du meinst die Crossbar? Ist auch nicht wild. Wunsch-Peripherie > aktivieren, Ports konfigurieren (Push-Pull/Open-Drain/etc.) und Crossbar > einschalten. > Dem besseren Verständnis hilft hier der ConfigWizard, den du auf > silabs.com herunterladen kannst - dort kannst du dir die > Crossbar-Konfiguration zusammen klicken, ebenso wie die Timer, > Oszillator, UART, etc. > Aber beachte: Immer den generierten Code gegen das Datenblatt prüfen!!! > Der CW ist gut, aber nicht perfekt! Ich nehme mir vor die Crossbar- und MCU-Konfiguration von Anfang manuell zu handhaben. Da versteht man das ganze viel besser. Ich mag solche Wizards überhaupt nicht gerne. Da bin ich mir nie sicher. Spricht etwas dagegen dass ich mir den Toolstick+C582 Bord zukommen lassen will? Da könnte ich mit Leichtigkeit meine ersten Schritte tun. Den -582 Header File habe ich auch schon. Im Prinzip habe ich dann alles um etwas Hardware zum Laufen zu bringen. Gruss, Gerhard > > Ralf
Hi Gerhard, > Nach einer D Wikipedia ist die Plural von Theremin "Theremine". > Meine Schreibweise war nur ein typo. Macht ja nix, Hauptsache man weiss wovon wir reden :) > Hier kommt es höchstwahrscheinlich auf Versuche an um eine brauchbare > Lösung zu finden. Denke ich auch, deswegen hatte ich die anderen Komponenten auf einzelne Layouts gesetzt, um Module aufbauen zu können. > Das verstehe ich. Um welche STM32 IC Type handelte es sich bei Dir > übrigens? Nicht STM, sondern NxP -> Die LPC11xx-Reihe bzw. LPC13xx-Reihe. > USART DMA Betrieb könnte aber ganz nützlich sein. Das müsst ich mir dann noch angucken, wenn man damit das TXE-"Problem" umgehen kann. > Welche jahrelang oder überhaupt nie behoben werden... Ja, leider. Wobei ich jetzt noch nie einen Fall hatte, der ein echtes KO war, aber andersrum macht's halt irgendwie n schlechten Eindruck, weil man immer befürchtet dass ein potentieller KO-Bug auch nicht behoben würde. > Aber nur 3.6V Typen? Ja, SiLabs-MCUs sind (fast) ausnahmslos 3.3V-Typen, wenn man von einen LIN-MCUs absieht. Die IOs sind i.d.R. 5V-tolerant, und es gibt ein, zwei MCU-Serien welche einen LDO on-chip haben, um direkt mit 5V speisen zu können. > Meine alte Version von uV2 hat wahrscheinlich noch keinen Debugger > Support für die C8051 die mich interessieren. Ich dachte eigentlich, dass die DLL auch für µV2 funktioniert. Mit µV3 bist du eh noch etwas komfortabler, also kannst du auch die nehmen. > Ich nehme mir vor die Crossbar- und MCU-Konfiguration von Anfang manuell > zu handhaben. Da versteht man das ganze viel besser. Ich mag solche > Wizards überhaupt nicht gerne. Da bin ich mir nie sicher. So mach ich's auch, aber um ein Grundgerüst an Config-Code zu haben ist der CW spitze. Ausserdem sieht man beispielsweise bei der Portkonfiguration eben grafisch, was auf welchem Port liegt, und das ist hilfreich. > Spricht etwas dagegen dass ich mir den Toolstick+C582 Bord zukommen > lassen will? Da könnte ich mit Leichtigkeit meine ersten Schritte tun. > Den -582 Header File habe ich auch schon. Im Prinzip habe ich dann alles > um etwas Hardware zum Laufen zu bringen. Meinst du mit Board die entsprechende DaughterCard für den Toolstick oder ein großes DevBoard? Prinzipiell spricht nix gegen die kleine Variante, die große ist halt flexibler, was Erweiterungen für Versuche angeht. Je nach Erfahrungslevel braucht man das nicht mehr, dann reicht natürlich auch die kleine Toolstick-Variante. Ich würde aber dann empfehlen, auch die Debug-Adapter-DaughterCard zu kaufen, um den ToolStick in einen (nahezu kompatiblen) großen Debug-Adapter umwandeln zu können. Dann kannst du auch eigene Schaltungen damit bedienen. Ralf
Hi Ralf, Ralf schrieb: > Hi Gerhard, > >> Nach einer D Wikipedia ist die Plural von Theremin "Theremine". >> Meine Schreibweise war nur ein typo. > Macht ja nix, Hauptsache man weiss wovon wir reden :) > >> Hier kommt es höchstwahrscheinlich auf Versuche an um eine brauchbare >> Lösung zu finden. > Denke ich auch, deswegen hatte ich die anderen Komponenten auf einzelne > Layouts gesetzt, um Module aufbauen zu können. > >> Das verstehe ich. Um welche STM32 IC Type handelte es sich bei Dir >> übrigens? > Nicht STM, sondern NxP -> Die LPC11xx-Reihe bzw. LPC13xx-Reihe. Die neuen NXP Cortex Typen kenne ich noch nicht. > >> USART DMA Betrieb könnte aber ganz nützlich sein. > Das müsst ich mir dann noch angucken, wenn man damit das TXE-"Problem" > umgehen kann. Ich bin immer noch der Ansicht dass man mit der TXE Flag alleine gut arbeiten kann. > >> Welche jahrelang oder überhaupt nie behoben werden... > Ja, leider. Wobei ich jetzt noch nie einen Fall hatte, der ein echtes KO > war, aber andersrum macht's halt irgendwie n schlechten Eindruck, weil > man immer befürchtet dass ein potentieller KO-Bug auch nicht behoben > würde. der STM32F103VE6 hat in der Hinsicht allerhand auf dem Kerbholz;-) Aber es geht noch. Die ERRATA ist ein richtiges Büchlein mit vielen, vielen Seiten... > >> Aber nur 3.6V Typen? > Ja, SiLabs-MCUs sind (fast) ausnahmslos 3.3V-Typen, wenn man von einen > LIN-MCUs absieht. Die IOs sind i.d.R. 5V-tolerant, und es gibt ein, zwei > MCU-Serien welche einen LDO on-chip haben, um direkt mit 5V speisen zu > können. Das dürften die Automotive Version wie die F58X Typen sein. ZILOG hat auch ein paar interessante 8051 Typen. Ich arbeitete vor ein paar Jahren mit den ZILOG Encore+ MCUs. Die funktionierten wirklich gut. ZILOG hat ein freies IDE mit C-Compiler und Debugger. Die Doku sind auch recht gut. Irgendwie finde ich es schade dass so wenige sie scheinbar beachten. Das SW-Debug Interface dazu kann man sich sogar selber bauen. > >> Meine alte Version von uV2 hat wahrscheinlich noch keinen Debugger >> Support für die C8051 die mich interessieren. > Ich dachte eigentlich, dass die DLL auch für µV2 funktioniert. Mit µV3 > bist du eh noch etwas komfortabler, also kannst du auch die nehmen. Sollte funktionieren. Alle Typen die mich potenziell interessieren sind in der Liste von uV2 vorhanden. Header Files für neuere Typen gibt es auch oder macht man sich selber. Das uV3 habe ich nicht zur Verfügung. Da wir uV2 in der Fa nicht kommerziell benutzen, wurde es nie auf den neuesten Stand gebracht. Macht nichts. Es ist gut so wie es ist. > >> Ich nehme mir vor die Crossbar- und MCU-Konfiguration von Anfang manuell >> zu handhaben. Da versteht man das ganze viel besser. Ich mag solche >> Wizards überhaupt nicht gerne. Da bin ich mir nie sicher. > So mach ich's auch, aber um ein Grundgerüst an Config-Code zu haben ist > der CW spitze. Außerdem sieht man beispielsweise bei der > Portkonfiguration eben grafisch, was auf welchem Port liegt, und das ist > hilfreich. Mit der Crossbar Konfigurierung habe ich mich befasst und ist ziemlich einfach obwohl es m.E. etwas "quirky" ist. Der CW ist eigentlich sehr praktisch weil man sofort einen Überblick bekommt. Es hat also schon Sinn damit zu arbeiten. > >> Spricht etwas dagegen dass ich mir den Toolstick+C582 Bord zukommen >> lassen will? Da könnte ich mit Leichtigkeit meine ersten Schritte tun. >> Den -582 Header File habe ich auch schon. Im Prinzip habe ich dann alles >> um etwas Hardware zum Laufen zu bringen. > Meinst du mit Board die entsprechende DaughterCard für den Toolstick > oder ein großes DevBoard? Prinzipiell spricht nix gegen die kleine > Variante, die große ist halt flexibler, was Erweiterungen für Versuche > angeht. Je nach Erfahrungslevel braucht man das nicht mehr, dann reicht > natürlich auch die kleine Toolstick-Variante. Ich würde aber dann > empfehlen, auch die Debug-Adapter-DaughterCard zu kaufen, um den > ToolStick in einen (nahezu kompatiblen) großen Debug-Adapter umwandeln > zu können. Dann kannst du auch eigene Schaltungen damit bedienen. Ich habe mir mittlerweile die verschiedenen Bords angeschaut und für mich passt die C5081F58XSDK am besten weil ich Verwendung fuer CAN und LIN bus habe. Ich habe vor mir eines zu bestellen. Was mich an den 8051ern als Anfänger ohne bisjetzige 8051 Erfahrung etwas stört ist die etwas magere RAM Ausstattung welche architektonisch bedingt ist und man mit XRAM oder externen RAM arbeiten muss um mehr RAM zur Verfügung zu haben. Da auf die halbe RAM und XRAM nur mittels von MOVx Befehlen zugegriffen werden kann ist da wahrscheinlich ein Zugriffszeit Premium zu ertragen. Ich nehme zwar an dass es praktisch bei 99% aller Anwendungen nicht viel ausmacht. Durch die verbesserte Leistung der neuen 8051er ist es wahrscheinlich kein Problem. Ich habe gestern ein existierendes Test/Monitor AVR/PIC Programm von mir auf den 8051er um-portiert und war dann gleich ohne RAM bis ich dann auf XRAM umgestiegen bin. Danach verbrauchte ich nur 36 Bytes SRAM, 161 Bytes XRAM und 2680 Bytes für das Programm. (Beim PIC F877 mit 368 Bytes RAM lief dasselbe Programm tadellos.) Die meiste XRAM geht z.Zt. für UART RX/TX Puffer Betrieb drauf weil ich das UART mittels Interrupts verwende. Allerdings muss da noch einiges rein um ein externes I2C EEPROM einzubinden. Bin gespannt wie alles laufen wird wenn ich Hardware zur Verfügung habe. uV2 baute einen HEX File ohne Fehler und Warnungen. Ist ermutigend;-) Ob es natürlich läuft ist natürlich eine andere Frage. Mir macht es immer Spass was Neues zum laufen zu bekommen. Dieses Test/Monitorprogramm verwende ich immer beim experimentieren weil ich dann sofort leichten Zugriff auf ADC, Register, I2C-EEPROM, RTC, gewisse Timer Funktionen habe. PORT-IO mittels UART Command Interface ist sofort vorhanden. Naja, "Time will tell". Jetzt gehe ich drei Wochen auf Urlaub an der Westküste und werde an andere Sachen denken und saubere Bergluft atmen;-) Gerhard > > Ralf
Hi Gerhard, > Ich bin immer noch der Ansicht dass man mit der TXE Flag alleine gut > arbeiten kann. Wie gesagt, muss mir den Ablauf nochmal ansehen. Vielleicht hatte ich damals einfach nur ein Verständnisproblem. > ZILOG hat auch ein paar interessante 8051 Typen. Naja, sind nicht viele, und wohl z.T. spezialisiert auf LCD-Anwendungen. Oder hab ich was übersehen? > Ich arbeitete vor ein paar Jahren mit den ZILOG Encore+ MCUs. Die > funktionierten wirklich gut. ZILOG hat ein freies IDE mit C-Compiler und > Debugger. Die Doku sind auch recht gut. Irgendwie finde ich es schade > dass so wenige sie scheinbar beachten. Das SW-Debug Interface dazu kann > man sich sogar selber bauen. Die Encores bzw. generell Zilog kenne ich nicht. Aber freie IDE etc. ist immer gut :) > Mit der Crossbar Konfigurierung habe ich mich befasst und ist ziemlich > einfach obwohl es m.E. etwas "quirky" ist. Der CW ist eigentlich sehr > praktisch weil man sofort einen Überblick bekommt. Es hat also schon > Sinn damit zu arbeiten. Wieso quirky? > Was mich an den 8051ern als Anfänger ohne bisjetzige 8051 Erfahrung > etwas stört ist die etwas magere RAM Ausstattung welche architektonisch > bedingt ist und man mit XRAM oder externen RAM arbeiten muss um mehr RAM > zur Verfügung zu haben. Da auf die halbe RAM und XRAM nur mittels von > MOVx Befehlen zugegriffen werden kann ist da wahrscheinlich ein > Zugriffszeit Premium zu ertragen. Ich nehme zwar an dass es praktisch > bei 99% aller Anwendungen nicht viel ausmacht. Durch die verbesserte > Leistung der neuen 8051er ist es wahrscheinlich kein Problem. Ja, wenn die Anwendung größere Buffer benötigt müssen die ins XRAM, das stimmt. Als der 8051-Kern rauskam war on-chip-RAM halt noch relativ teuer, daher ist relativ wenig RAM da. Neue Architekturen wie Cortex o.ä. bekommen halt von Haus aus gleich mehr RAM. > Ob es natürlich läuft ist natürlich eine andere Frage. > Mir macht es immer Spass was Neues zum laufen zu bekommen. Das ist die Hauptsache. > Dieses Test/Monitorprogramm verwende ich immer beim experimentieren weil > ich dann sofort leichten Zugriff auf ADC, Register, I2C-EEPROM, RTC, > gewisse Timer Funktionen habe. PORT-IO mittels UART Command Interface > ist sofort vorhanden. Hört sich interessant an. > Jetzt gehe ich drei Wochen auf Urlaub an der Westküste und werde an > andere Sachen denken und saubere Bergluft atmen;-) Dann wünsch ich mal schönen Urlaub. Ralf
Hi Ralf, Ralf schrieb: > Hi Gerhard, > >> Ich bin immer noch der Ansicht dass man mit der TXE Flag alleine gut >> arbeiten kann. > Wie gesagt, muss mir den Ablauf nochmal ansehen. Vielleicht hatte ich > damals einfach nur ein Verständnisproblem. Vielleicht beschreibst Du mir irgendwann die Ablauflogik die Du damals im Auge hattest. > >> ZILOG hat auch ein paar interessante 8051 Typen. > Naja, sind nicht viele, und wohl z.T. spezialisiert auf LCD-Anwendungen. > Oder hab ich was übersehen? Viel haben sie nicht. Das stimmt. > >> Ich arbeitete vor ein paar Jahren mit den ZILOG Encore+ MCUs. Die >> funktionierten wirklich gut. ZILOG hat ein freies IDE mit C-Compiler und >> Debugger. Die Doku sind auch recht gut. Irgendwie finde ich es schade >> dass so wenige sie scheinbar beachten. Das SW-Debug Interface dazu kann >> man sich sogar selber bauen. > Die Encores bzw. generell Zilog kenne ich nicht. Aber freie IDE etc. ist > immer gut :) Jedenfalls war es recht angenehm damit zu arbeiten. Es agb absolut keine Probleme. Der C-Compiler hat mir überhaupt keinen Mucken gemacht. > >> Mit der Crossbar Konfigurierung habe ich mich befasst und ist ziemlich >> einfach obwohl es m.E. etwas "quirky" ist. Der CW ist eigentlich sehr >> praktisch weil man sofort einen Überblick bekommt. Es hat also schon >> Sinn damit zu arbeiten. > Wieso quirky? Ich dachte am Anfang dass ich damit die meisten PINS frei wählen kann. Das ist aber nur bedingt der Fall. Man kann die Alternate Function Pins nur verschieben oder Pins reservieren. Das ist OK - Nur anders als ich es mir ursprünglich vorgestellt. Es gab einen groesseren PIC der hatte auch die Crossbar Einrichtung. Dort konnte man allerdings die PINS ohne System frei wählen. > >> Was mich an den 8051ern als Anfänger ohne bisjetzige 8051 Erfahrung >> etwas stört ist die etwas magere RAM Ausstattung welche architektonisch >> bedingt ist und man mit XRAM oder externen RAM arbeiten muss um mehr RAM >> zur Verfügung zu haben. Da auf die halbe RAM und XRAM nur mittels von >> MOVx Befehlen zugegriffen werden kann ist da wahrscheinlich ein >> Zugriffszeit Premium zu ertragen. Ich nehme zwar an dass es praktisch >> bei 99% aller Anwendungen nicht viel ausmacht. Durch die verbesserte >> Leistung der neuen 8051er ist es wahrscheinlich kein Problem. > Ja, wenn die Anwendung größere Buffer benötigt müssen die ins XRAM, das > stimmt. Als der 8051-Kern rauskam war on-chip-RAM halt noch relativ > teuer, daher ist relativ wenig RAM da. Neue Architekturen wie Cortex > o.ä. bekommen halt von Haus aus gleich mehr RAM. Da sist schon sehr angenehm. Andrerseits erzieht wenig RAM zum Design Disziplin wo im Prinzip genug RAM für die App. vorhanden ist. > >> Ob es natürlich läuft ist natürlich eine andere Frage. >> Mir macht es immer Spass was Neues zum laufen zu bekommen. > Das ist die Hauptsache. Bestimmt. MCUs = "Zauberteppich";-) > >> Dieses Test/Monitorprogramm verwende ich immer beim experimentieren weil >> ich dann sofort leichten Zugriff auf ADC, Register, I2C-EEPROM, RTC, >> gewisse Timer Funktionen habe. PORT-IO mittels UART Command Interface >> ist sofort vorhanden. > Hört sich interessant an. Am Anfang nehme ich es immer bei den etwas groesseren MCUs her weil ich damit sofort mit der Hardware mittels Terminal Steuerung arbeiten kann. Meistens konzipiere ich wo es möglich ist die MCU externe Beschaltung so, dass ich immer (externe/interne) Peripherie mit den folgenden Funktionen habe: RTC, EEPROM, Temperature Sense, 1-4 Monitor LEDs, RS232 Schnittstelle, LCD I2C Parallel Expander Interface. Das verbraucht mit I2C nur ein paar I/O. Diese Monitorprogramm ist darauf zugeschnitten. Mit diesen Resourcen kann man dann sehr zügig arbeiten. Weil das Monitorprogramm nur aktiv ist wenn man es benützt, hat es auf den Rest der App. keinen Einfluss auf den Ablauf des eigentlichen Application Programms. > >> Jetzt gehe ich drei Wochen auf Urlaub an der Westküste und werde an >> andere Sachen denken und saubere Bergluft atmen;-) > Dann wünsch ich mal schönen Urlaub. Danke - Morgen geht es los. Gerhard > > Ralf
Ralf schrieb: > Als der 8051-Kern rauskam war on-chip-RAM halt noch relativ > teuer, daher ist relativ wenig RAM da. Hauptsächlich ging es darum, den Programmspeicher effektiv auszunutzen, d.h. kleinen Code zu erzeugen. Und daher ist der Adreßbereich im Befehlswort auf 8Bit beschränkt, wobei 128Byte SRAM und 128Byte IO-Bereich sind. Im Unterschied zum PIC hat man aber für mehr SRAM nicht das unsägliche Banking benutzt, sondern weitere 64kB über spezielle Befehle linear adressierbar gemacht. Peter
@Gerhard: > Vielleicht beschreibst Du mir irgendwann die Ablauflogik die Du damals > im Auge hattest. Das waren eigentlich nur Notizen, wie man mit dieser UART-Implementierung in Verbindung mit dem Buffer und sonstiger "Features" eine funktionierende Kommunikation aufbaut. Muss mal schauen, ob ich damals schon im Zustand "Notizen schriftlich festhalten" war :) > Ich dachte am Anfang dass ich damit die meisten PINS frei wählen kann. > Das ist aber nur bedingt der Fall. Man kann die Alternate Function Pins > nur verschieben oder Pins reservieren. Das ist OK - Nur anders als ich > es mir ursprünglich vorgestellt. Es gab einen groesseren PIC der hatte > auch die Crossbar Einrichtung. Dort konnte man allerdings die PINS ohne > System frei wählen. Das war das, was ich oben erwähnte und mir ein SiLabs-Mitarbeiter mal gesagt hatte: Es hätte 80% des Dies alleine gebraucht, um die Crossbar voll konfigurierbar zu gestalten. Vielleicht hatte Microchip da einen anderen Ansatz oder ein PIC braucht generell weniger Gatter als ein 8051 :) > Da sist schon sehr angenehm. Andrerseits erzieht wenig RAM zum Design > Disziplin wo im Prinzip genug RAM für die App. vorhanden ist. Was ja kein Nachteil ist, im Gegenteil :) > Am Anfang nehme ich es immer bei den etwas groesseren MCUs her weil ich > damit sofort mit der Hardware mittels Terminal Steuerung arbeiten kann. Zumal man die DevKits i.d.R. eh immer nur mit den dicksten MCUs der jeweiligen Serie bekommt. > Meistens konzipiere ich wo es möglich ist die MCU externe Beschaltung > so, dass ich immer (externe/interne) Peripherie mit den folgenden > Funktionen habe: RTC, EEPROM, Temperature Sense, 1-4 Monitor LEDs, RS232 > Schnittstelle, LCD I2C Parallel Expander Interface. Das verbraucht mit > I2C nur ein paar I/O. Diese Monitorprogramm ist darauf zugeschnitten. > Mit diesen Resourcen kann man dann sehr zügig arbeiten. Weil das > Monitorprogramm nur aktiv ist wenn man es benützt, hat es auf den Rest > der App. keinen Einfluss auf den Ablauf des eigentlichen Application > Programms. Interessanter Ansatz. Mit Monitorprogrammen etc. hab ich nie gearbeitet. Ich verwende immer eine UART-Schnittstelle, wenn möglich, oder direkt die internen Debugmöglichkeiten. Und wenn beides nicht geht, dann muss ein dicker Papierblock her und es heisst: "Was passiert, wenn Variable den Wert X und wenn Variable B den Wert Y..." :) @Peter: > Im Unterschied zum PIC hat man aber für mehr SRAM nicht das unsägliche > Banking benutzt, sondern weitere 64kB über spezielle Befehle linear > adressierbar gemacht. Wofür glaube ich viele Leute dankbar waren :) Diese Art von Banking war es, weswegen ich mir die PICs damals nie angeschaut hab. Ralf
Hi Ralph, nur ganz kurz von mir. Hier ist eine Link zum "Peripheral Pin Select" bei den 24er PICs: ww1.microchip.com/downloads/en/DeviceDoc/39711b.pdf Gruß, Gerhard Ralf schrieb: > @Gerhard: >> Vielleicht beschreibst Du mir irgendwann die Ablauflogik die Du damals >> im Auge hattest. > Das waren eigentlich nur Notizen, wie man mit dieser > UART-Implementierung in Verbindung mit dem Buffer und sonstiger > "Features" eine funktionierende Kommunikation aufbaut. > Muss mal schauen, ob ich damals schon im Zustand "Notizen schriftlich > festhalten" war :) > >> Ich dachte am Anfang dass ich damit die meisten PINS frei wählen kann. >> Das ist aber nur bedingt der Fall. Man kann die Alternate Function Pins >> nur verschieben oder Pins reservieren. Das ist OK - Nur anders als ich >> es mir ursprünglich vorgestellt. Es gab einen groesseren PIC der hatte >> auch die Crossbar Einrichtung. Dort konnte man allerdings die PINS ohne >> System frei wählen. > Das war das, was ich oben erwähnte und mir ein SiLabs-Mitarbeiter mal > gesagt hatte: Es hätte 80% des Dies alleine gebraucht, um die Crossbar > voll konfigurierbar zu gestalten. Vielleicht hatte Microchip da einen > anderen Ansatz oder ein PIC braucht generell weniger Gatter als ein 8051 > :) > >> Da sist schon sehr angenehm. Andrerseits erzieht wenig RAM zum Design >> Disziplin wo im Prinzip genug RAM für die App. vorhanden ist. > Was ja kein Nachteil ist, im Gegenteil :) > >> Am Anfang nehme ich es immer bei den etwas groesseren MCUs her weil ich >> damit sofort mit der Hardware mittels Terminal Steuerung arbeiten kann. > Zumal man die DevKits i.d.R. eh immer nur mit den dicksten MCUs der > jeweiligen Serie bekommt. > >> Meistens konzipiere ich wo es möglich ist die MCU externe Beschaltung >> so, dass ich immer (externe/interne) Peripherie mit den folgenden >> Funktionen habe: RTC, EEPROM, Temperature Sense, 1-4 Monitor LEDs, RS232 >> Schnittstelle, LCD I2C Parallel Expander Interface. Das verbraucht mit >> I2C nur ein paar I/O. Diese Monitorprogramm ist darauf zugeschnitten. >> Mit diesen Resourcen kann man dann sehr zügig arbeiten. Weil das >> Monitorprogramm nur aktiv ist wenn man es benützt, hat es auf den Rest >> der App. keinen Einfluss auf den Ablauf des eigentlichen Application >> Programms. > Interessanter Ansatz. Mit Monitorprogrammen etc. hab ich nie gearbeitet. > Ich verwende immer eine UART-Schnittstelle, wenn möglich, oder direkt > die internen Debugmöglichkeiten. > Und wenn beides nicht geht, dann muss ein dicker Papierblock her und es > heisst: "Was passiert, wenn Variable den Wert X und wenn Variable B den > Wert Y..." :) > > @Peter: >> Im Unterschied zum PIC hat man aber für mehr SRAM nicht das unsägliche >> Banking benutzt, sondern weitere 64kB über spezielle Befehle linear >> adressierbar gemacht. > Wofür glaube ich viele Leute dankbar waren :) > Diese Art von Banking war es, weswegen ich mir die PICs damals nie > angeschaut hab. > > Ralf
Hi Gerhard, > Hier ist eine Link zum "Peripheral Pin Select" bei den 24er PICs: Danke für den Link. Scheint recht flexibel zu sein, aber auch nicht ganz ohne Einschränkungen. Ich würde sagen nahezu gleichwertig zu SiLabs, mit leichtem Vorsprung für den PIC. Ralf
Hi Ralf, ich habe mit diesem PIC Typ noch nicht gearbeitet und habe deshalb noch keine praktische Erfahrung mit den Eigenheiten des PPS da ich noch keinen Grund hatte mit den 24er PICS zu arbeiten. Wenn ich von meinem Urlaub zurück komme dann werde ich mal was mit dem C8051 anstellen. Ich nehme nicht an das es irgendwelche wesentliche Schwierigkeiten mit dem Crossbar geben sollte. Mit dem CW sollten die Peripherien auf die gewählten PINs korrekt initialisiert werden. Ich werde mir wahrscheinlich wie von Dir vorgeschlagen die größere Development Board zukommen lassen und werde dann berichten;-) Habe heute noch allerhand zu tun um von hier weg zukommen;-) Gruß, Gerhard Ralf schrieb: > Hi Gerhard, > >> Hier ist eine Link zum "Peripheral Pin Select" bei den 24er PICs: > Danke für den Link. Scheint recht flexibel zu sein, aber auch nicht ganz > ohne Einschränkungen. Ich würde sagen nahezu gleichwertig zu SiLabs, mit > leichtem Vorsprung für den PIC. > > Ralf
Hi Gerhard, > Wenn ich von meinem Urlaub zurück komme dann werde ich mal was mit dem > C8051 anstellen. Alles klar. Und wenn du Hilfe brauchst, sag Bescheid. > Habe heute noch allerhand zu tun um von hier weg zukommen;-) Genau, jetzt genieß erstmal deinen Urlaub :) Ralf
Hi Ralf, danke für Deine guten Wünsche. Also bis bald - Morgen geht's endlich los. Gerhard Ralf schrieb: > Hi Gerhard, > >> Wenn ich von meinem Urlaub zurück komme dann werde ich mal was mit dem >> C8051 anstellen. > Alles klar. Und wenn du Hilfe brauchst, sag Bescheid. > >> Habe heute noch allerhand zu tun um von hier weg zukommen;-) > Genau, jetzt genieß erstmal deinen Urlaub :) > > Ralf
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.