mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Suche Simulator für 8051


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Kein Name (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du schon probiert, den alten Simulator in dem Freeware Programm 
'DOSBox' zu starten? (Simuliert prähistorische PCs für alte DOS Spiele).

Autor: Wildes Ferkel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: troll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fachkraft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenns gar nicht geht (nicht lachen ;-)), versuchs mal hier

http://www.computerbild.de/download/DOSBox-930358.html?dl=1

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fachkraft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm hast du eigentlich mal hier geschaut?

http://mcu8051ide.sourceforge.net/

(oder meintest du den?)

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für diesen Zweck am besten geeignet:

http://www.edsim51.com/

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Gerhard. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Ebay-Artikel Nr. 261050682608

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;-)

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: khmweb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
btw, einen 8050 Emu gäbe es auf meiner Homepage, falls ihn jemand 
braucht:

http://sharpmz.org/za8050emu.htm

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verdammter Mist.

Mit Dosbox geht gerade mal gar nichts.

Mir fehlt da sowas wie ein Template anscheinend.

Hat noch jemand eine Idee?

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der DOS-Box geht nicht alles wie im echten DOS. Vielleicht liegts 
daran.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor anschreiben, Foren gucken. Dann erst Müll. Bezahlsoftware ist oft 
noch schlechter.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? ;-)

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Proxxon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pieter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans-Georg L. (h-g-l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

>>Das hat Pieter reingestellt, nicht ich :)

waas,
so schlecht, dass Du nichts damit zu tun haben möchtest?

Mit Gruß
Pieter

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Gert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm, ich dachte du meintest das DOS-Fenster ab Win2000, nicht das 
Programm DOSBox. So kann man sich irren.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ralf (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Grad gesehen, dass die Bilder nicht hochgekommen sind - neuer Versuch!

Ralf

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.