In einer vorhandenen Hardware befinden sich mehrere uralte LPC767 (8051 Derivat), die durch ein neueres passendes Teil ersetzt werden sollen. Außerdem sollen ein paar Modifikationen am Code vorgenommen werden. Ich bin schrittweise vorgegangen: Ich habe mir Keil uVision (Eval Version, begrenzt auf 2KB Code, reicht mir) installiert und konnte inzwischen den vorhandenen 8051 Assembler Code im virtuellen Simulator / Logic Analyser testen. Funktioniert, das Ding scheint tatsächlich das zu tun, was es soll. Den vorhandenen 8051 Assembler Code habe ich daraufhin in C umgeschrieben und auch das funktioniert super. Der Code ist jetzt leicht wartbar und verständlich. Der nächste Schritt ist jetzt die Auswahl eines passenden Ersatzes, der von uVision unterstützt wird. Ich bin bei der Recherche auf die EFM8 Busy Bee Serie von Silicon Image gestoßen, die passt von den Features bestens, ist bei Farnell auch in Kleinmengen verfügbar und spottbillig. Meine Fragen: Hat jemand Erfahrung mit EFM8, ist die Serie wirklich brauchbar? Welches Gerät sollte ich am besten zum Flashen verwenden? Ich suche ein kleines, günstiges Device, das das notwendige C2 Protokoll beherrscht. Ideal wäre, wenn es auch noch in uVision als HW Simulator einbindbar wäre. Für Tipps wäre ich sehr dankbar.
Da schaust Du erstmal beim Hersteller selber: https://www.silabs.com/development-tools/wireless/simplicity-link-debugger?tab=overview https://www.digikey.de/de/products/detail/silicon-labs/SI-DBG1015A/20412634 Ob der mit Keil/IAR läuft, weiß ich jetzt nicht. Aber Silabs hat da auch was eigenes: https://www.silabs.com/developers/simplicity-studio Die Vollversion kostet Dich nur eine Registrierung und deckt alles ab, was Silabs an MCUs so macht. fchk
:
Bearbeitet durch User
Keil C2 ist kein Problem. Der Silabs Debug Adapter wird unterstützt. Ich verwende diesen hier: https://www.silabs.com/development-tools/mcu/8-bit/8-bit-usb-debug-adapter?tab=overview
https://www.silabs.com/developers/keil-pk51 Du kannst bei Silabs / Keil auch eine vollwertige Keil Lizenz bekommen.
> ist bei Farnell auch in Kleinmengen verfügbar und spottbillig. Also Bastler oder 1Personen Bude? > Hat jemand Erfahrung mit EFM8, ist die Serie wirklich brauchbar? Hast du das hier gesehen: https://community.silabs.com/s/question/0D5Vm00000GrJ9rKAF/discontinuation-of-qsop-pacakge-for-various-efm8-processors?language=ru Also ich kann QFN fuer Prototypen oder schonmal gelegentlich fuer ein Projekt loeten, aber willst du dir das wirklich antun? Bei >1000 im Jahr kein Problem, bei 3Stueck auch nicht. Bei 50Stk aber schon... Vanye
Danke für das schnelle Feedback, ist ja ein tolles Forum! Der Reihe nach: Es geht um Kleinstückzahlen, vielleicht 200-300 pro Jahr. Die 8051er befinden sich auf einem recht betagten Gerät, das jetzt wieder neu aufgelegt werden soll. Die 8051er dienen darin nur als digitale Controller (Stby, Tastatur, Display, Schutz/Alarm bei zu hohen Spannungen/Strömen), die eigentliche Funktion des Geräts ist im extrem Analog, das (Kosten-)Verhältnis Digital:Analog ist grob gesagt 1:1000. Den Entwickler des Codes gibt es nicht mehr. Ich springe als Notnagel ein - meine letzten richtigen Programmiererfahrungen liegen noch in den 80ern, ASM und C. Für Keil habe ich mich entschieden, weil mein Vorgänger das auch benutzt hatte, in einer wesentlich älteren Variante. Ich kannte bis vor zwei Wochen den Namen Keil gar nicht. Also habe ich mir die Software installiert - gibt's als Eval Version umsonst. Die Einarbeitung ging erstaunlich problemlos, die virtuellen Simulationsmöglichkeiten haben es mir sehr leicht gemacht. Mein C-Code verhält sich in der Simulation genau wie der Original ASM Code. Der derzeit verwendete µC ist ein LPC767 von NXP im SO16, der schon lange abgekündigt ist. Er sitzt auch einem Piggyback, weil das nämlich auch schon ein Ersatz für einen noch älteren 8051 im DIL16 ist. Mein Auftraggeber hat zwar noch reichlich LPC767 auf Lager, aber die Dinger sind OTPs. Das möchte ich mir nicht antun und moderne Flash Devices verwenden. Wäre seitens des Auftraggebers kein Problem, schnell ein Piggyback mit einem anderen µC zu designen - HW-technisch sind die gut drauf, nur von SW keine Ahnung ;-) Bei der Suche bin ich auf die EFM8BB Serie von Silicon Labs gestoßen. Ich benötige max. 16 I/Os, davon vier AD Eingänge. Passt also. Die Features des EFM8 liegen WEIT über dem 767, purer Luxus. Ich komme eigentlich mit 2KB ROM und 128Byte RAM aus. Aber schaden kann es nicht. Reichen würde ein 20 Pinner , ich plane aber 28 zu nehmen, dann habe ich I/O in Reserve und kann 2 Pins exklusiv und ungeshared für das C2 Interface von Silicon Labs verwenden. Soweit zur Planung. Mit der "echten" Ziel-HW bin ich noch nicht in Berührung gekommen, ist alles noch Vorarbeit. Aber Gedanken über das Flashen der realen Devices mache ich mir schon und deshalb die Fragen nach dem Programmer. Den von Silicon Labs hatte ich schon entdeckt und wurde hier eben empfohlen (Danke, Bernd). Bei Keil in der Device List ist die 8BB2 und 88B3 Serie drin, die 8BB5 leider nicht. Bei Farnell habe ich mir daraufhin den EFMBB22F16G-C-QFN28 ausgesucht. Ich werde jetzt in Keil weiter abtauchen, den (Startup-)Code an den EFM anpassen und schaun, ob es fluppt. Und danach mal das Silicon Labs Software Paket samt Keil Lizenz ausprobieren.
>> Und danach mal das Silicon Labs Software Paket samt Keil Lizenz >> ausprobieren. Wenn du durch die Registrierung gehst, dann wirst du feststellen, dass du die Lizenz auch für die Keil IDE nutzen kannst. Es gibt 2 Möglichkeiten. 1.) Keil wird lizensiert und kann verwendet werden. Also uVision installieren. 2.) Silabs Umgebung auf den Keil Compiler konfigurieren. Damit steht dir eigentlich alles zur Verfügung. Freier Compiler wäre der SDCC, auch der läßt sich in die Silabs Umgebung einbinden. https://www.silabs.com/documents/public/application-notes/an198.pdf https://www.silabs.com/documents/public/application-notes/an104.pdf Oder Silabs Simplicity Studio mit Keil C Compiler: https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-overview/ Ansonsten Mide mit SDCC bei so einem kleinen Programm. https://www.opcube.com/home.html Packed File verwenden.
Bernd N. schrieb: > https://www.silabs.com/developers/keil-pk51 > Du kannst bei Silabs / Keil auch eine vollwertige Keil Lizenz bekommen. richtig aber die Lizenz ist nicht ganz vollständig. 1. Es werden nur Silabs Chips unterstützt 2. Kein Debugger Support siehe AN104 Der erste Punkt ist einfach zu beheben, da man die Header Files der Eval Version verwenden kann. Nur das Anlegen eines Projekts ist etwas komplizierter. Der 2. Punkt ist kritischer da der TO ja auch debuggen will. Dazu braucht er dann auch die Silabs IDE mit weniger Möglichkeiten.
Leider bin ich eben auf das hier gestoßen: https://www.keil.com/dd/chip/7986.htm The following on-chip peripherals are not simulated. Crossbar External & On-Chip memory Interrupts (Including External) Port 0 Port 1 Port 2 Port 3 Power Saving Modes (Idle and Power Down) Serial UART 0 (Enhanced Interface) Timer 0 Timer 1 Timer 2 Oje, das ist übel, denn Interrupt, Port 0 -2, Saving Modes und ein Timer verwende ich in der Simulation. Ohne Simulation ist das Ganze ohne Wert für mich. Muss mir jetzt überlegen, wie ich weitermache :-( Kann man mit den SiLabs Tools auch simulieren? Sprich, Port Eingänge beliebig setzen, Stimuli-Signale erzeugen (zB Tastendruck mit Prellen), Breakpoints setzen, Memory Watch usw? In Software, nicht mithilfe eines Hardware-Debug-Devices.
es wird halt ein normaler 80x52 emuliert, das bedeutet alle zusätzlichen Funktionen gehen nicht. Das liegt im wesentlichen an der Crossbar. den ext Irq kannst du jederzeit simmulieren indem du das IRQ Bit in der Kommandozeile von uVision setzt. Pwr Optionen hat der EFM halt viele mehr. Was benutzt du den Idle? Die Ports könnten in der Tat ein Problem sein da die Zuordnung nicht fix ist
Kalle W. schrieb: > Ohne Simulation ist das Ganze ohne Wert > für mich. Muss mir jetzt überlegen, wie ich weitermache :-( Sehr viele Leute entwickeln ihre Software direkt auf der Hardware oder auf einem Eval-Board. Ein-und Ausgänge mit LEDs, Buttons, Potis bestücken, Oszilloskop dran und man kann schon viel sehen. Mit dem Debugger kann man den Code Step-by-Step durchgehen und genau schauen ob er das richtige macht.
Das Simplicity Studio habe ich mir installiert, aber komme damit gar nicht klar. Und die Kommentare, die ich zu Simplicity im Netz gesehen habe, sind vorsichtig formuliert "nicht druckreif". Da die SW Simulation sowieso nicht möglich ist, werde ich auch nicht versuchen, da durchzusteigen. Habe mir jetzt den Atmel AT89LP51RB2 ausgesucht, ist bei Mouser verfügbar. Der wird ordentlich von Keil supportet und kann weit mehr, als ich benötige. Zumindest konnte ich schon erste Simulationen erfolgreich durchlaufen. Die Portierung war einfach: ich musste das von Keil bereitgestellte H-File für den Chip patchen, da das SFR IEN1 im Original fehlte. Zusätzlich musste ich die Keyboard Inputs von Port 0 auf Port 1 verlegen. Ist egal, da sowieso ein neues Piggyback geroutet werden muss. Nur bei der Port Initialisierung muss ich noch etwas graben, die stehen nach Reset alle auf Quasi-Bidirectional und das mag der Simulator bei reinen Eingängen nicht. Sobald ich die echten Eingänge (Tasten) auf reine Inputs umgestellt habe, sollte es gehen. War jedenfalls beim 767 so. Welchen Programmer (Debugger) empfehlt ihr für den ATMEL Chip? Hatte ich mich schon bedankt für euer Feedback? Ich finde es toll, wie ihr mich unterstützt!
Kalle W. schrieb: > Welchen Programmer (Debugger) empfehlt ihr für den ATMEL Chip? Das Teil kann man wie die kalsischen AVRs nur programmieren, nicht aber debuggen. Das Programmierinterface ist quasi SPI, d.h. von der Hardware her sollte ein Programmer für einen klassisschen AVR das können. Firmware und Applikationssoftware müssen das allerdings können, und da beginnt das Problem. Die originalen Atmel-Tools gibts nicht mehr zu kaufen, und die Microchip-Tools können keine 8051-Controller. Brauchst Du aber auch nicht. Das Teil hat einen ROM-UART-Bootloader, der gestartet wird, wenn ein bestimmter Pin während des Resets low oder high ist. Damit reduziert sich der Aufwand auf ein USB-UART Interface mit 5V-Pegeln. Z.B. FTDI TTL232R-5V. (https://ftdichip.com/products/ttl-232r-5v/). Als Software nimmst Du Atmel Flip. (https://www.microchip.com/en-us/development-tool/flip) fchk
Kalle W. schrieb: > Welchen Programmer (Debugger) empfehlt ihr für den ATMEL Chip? zum Flashen kannst du Flip benutzen. Da ist ein Bootloader drauf der mit der seriellen Schnittstelle funktioniert. Zusätzlich geht wohl auch SPI Programmierung. Einen Debugger kenn ich nicht. Vieleicht existiert eine IAD Implementierung in Keil, dann kannst du in uVision direkt über die ser. Schnittstelle debuggen. Das ist aber ziemlich wackelig und geht vermutlich nur in der Vollversion. Die IAD files liegen im Source code vor, die kann man anpassen.
So ganz verstehe ich dein Problem nicht. Du hast ja die Software schon soweit auf dem Silabs laufen und das mit der Keil Demo. Debuggen kann man in der Kombination Silabs IDE und SDCC ohne Probleme aber man braucht den Debugadapter dazu. Ich kann gerne später mal testen. Ich verwende das nun auch sehr selten aber ich würde fast sagen das geht auch mit dem Keil. Ich melde mich später hierzu. Was das Debuggen im Allgemeinen angeht ist das auch zu Fuß machbar zumal du ein sehr kleines Programm hast. Ich schreibe den Code immer kompatibel zu Keil & SDCC, auch keine große Kunst aber wenn es für dich neu ist dann kann ich es verstehen. Silabs ist jedenfalls was feines verglichen mit den anderen Herstellern für 8051 Derivate.
Letztens wurde im Markt ein Bizeps 51 von Brendes angeboten. Mit diesem Debugger habe ich mal vor 20 Jahren gearbeitet. Der bietet auch Debuggen über uVision an. Ob der mit aktuellen Chips klarkommt weis ich allerdings nicht. Beitrag "Brendes 8051 Emulator" Mir waren die richtigen Debugger aber immer zu teuer, weshalb ich in der Regel spezielle HW designed habe (Von Neumann Ram) und dann mit dem Keil Monitor durchgesteppt habe. Das hat gut funktioniert, braucht aber halt spezielle Debug Konfigurationen des Programms.
:
Bearbeitet durch User
>> So ganz verstehe ich dein Problem nicht. Du hast ja die Software schon
soweit auf dem Silabs laufen und das mit der Keil Demo.<<
Nein, da hast du mich missverstanden. Ich hatte das zwar vor, weil ich
gesehen hatte, dass der Chip in der Device List steht, aber als ich
losgelegt habe mit der Portierung, bin ich drauf gestoßen, dass die von
mir benötigte Simulation überhaupt nicht unterstützt wird, habe das
Experiment abgebrochen und das Thema SiLabs war für mich durch.
Eigentlich stimmt das Thema dieses Threads nicht mehr.
Der Atmel Chip scheint gut geeignet zu sein. Ich kämpfe zwar noch mit
den externen Interrupts, die wollen im Simulator nicht auslösen, aber
das finde (hoffentlich) noch. Timer Interrupt und Port I/O läuft
jedenfalls schon.
Was das HW-Debuggen angeht: das ist für mich (vorerst) unwichtig, weil
ich bisher gut per SW simulieren kann. Bei der Frage nach
Programmer/Debugger ging es mir primär um Programmer - ich hätte das
Wort Debugger weglassen sollen. Wenn der Atmel HW_Debug nicht
unterstützt, ist das nicht schlimm.
Kalle W. schrieb: > das ist für mich (vorerst) unwichtig, weil ich bisher gut per SW > simulieren kann. In Hardware Debugging kann extrem hilfreich sein, gerade auch wenn externe Komponenten nicht das tun was sie sollen. Das wäre mir viel wichtiger als Simulieren.
Niklas G. schrieb: > Kalle W. schrieb: >> das ist für mich (vorerst) unwichtig, weil ich bisher gut per SW >> simulieren kann. > > In Hardware Debugging kann extrem hilfreich sein, gerade auch wenn > externe Komponenten nicht das tun was sie sollen. Das wäre mir viel > wichtiger als Simulieren. genau! Die meisten Simulatoren bilden die Realität eh nur teilweise ab. Es geht nichts über echte Hardware und einen guten Debugger. Und genau gefür sind die ganzen Evalboards auch da. fchk
Kalle W. schrieb: > Ich kämpfe zwar noch mit > den externen Interrupts, die wollen im Simulator nicht auslösen EX0 bzw EX1 und EA auf 1 gesetzt?
Thomas Z. schrieb: > Letztens wurde im Markt ein Bizeps 51 von Brendes angeboten. Mit diesem > Debugger habe ich mal vor 20 Jahren gearbeitet. Ich habe noch den Vorgänger davon :-) lange her. Ich war an dem Emulator interessiert habe aber dann doch Abstand genommen, eigentlich mach ich eh nur 32 BIT derzeit. Kalle W. schrieb: > Nein, da hast du mich missverstanden. Ich hatte das zwar vor, weil ich > gesehen hatte, dass der Chip in der Device List steht, aber als ich > losgelegt habe mit der Portierung, bin ich drauf gestoßen, dass die von > mir benötigte Simulation überhaupt nicht unterstützt wird, habe das > Experiment abgebrochen und das Thema SiLabs war für mich durch. Ok, dann habe ich dich wirklich falsch verstanden. Vielleicht beschreibst du besser was du machen willst wenn es kein großes Geheimnis sein sollte. Dann kann man vielleicht besser helfen!?!?
>>EX0 bzw EX1 und EA auf 1 gesetzt? Na sicher, hat ja vorher auch mit dem 767 funktioniert. Heute mache ich aber nichts mehr, morgen wieder. >>Vielleicht beschreibst du besser was du machen willst wenn es kein großes Geheimnis sein sollte. Dann kann man vielleicht besser helfen!?!?<< Ich habe weiter oben (12:31) versucht, das Setup zu beschreiben. Mehr ins Detail kann ich nicht gehen, ist schließlich nicht mein Gerät. Nochmal kurz gesagt: eine sehr aufwendige Analogschaltung in mehreren Versionen mit bis zu vier 767 Chips, jeweils mit unterschiedlichem Code. Alles in Assembler. Wunsch des Auftraggebers ist Verbesserung des Codes, ist buggy. Den Assembler-Wust will ich mir nicht auf Dauer antun, also schreibe ich erst um in C. Und Simulieren in SW ist mir wichtig, weil ich nur zeitlich begrenzt an die wenigen zur Verfügung stehenden Geräte komme, die derzeit auch noch überarbeitet werden. Mit den OTP 767 könnte im Prinzip weitermachen, aber irgendwie möchte schon auf Flash Devices wechseln. War schon damals bei den PALs so, war ich froh, als die GALs rauskamen. Außerdem habe ich Zeit - bin Rentner und mal wieder selbst programmieren nach fast 30 Jahren Management macht richtig Spaß :-)
Das "kleine Problem" mit den Porteingängen, an dem ich gestern hängen blieb, stellte sich leider als Killer heraus. Es hat nichts mit den Ports zu tun, ich konnte es auf eine simple Routine eingrenzen. Das hat aber nichts mehr mit dem Thema dieses Threads zu tun. Ich habe ein neuen Thread eröffnet. Beitrag "AT89LP51: keine Powerdown Simulation in uVision möglich"
Kalle W. schrieb: > stellte sich leider als Killer heraus. Ganz im Ernst, häng dich nicht so an der Simulation auf. Ich kenn die Lage bei 8051 nicht, aber für die ARM Cortex-M kriegt man mittlerweile für <20€ vollständige Eval-Boards inklusive(!) Debugger - da kannst du blitzschnell alles auf der echten Hardware testen ohne irgendwelche Software-Limitierungen; die IDEs/Compiler sind sowieso gratis. Da kann man einfach mal "auf Verdacht" bestellen und ausprobieren, anstatt erst mit dem Simulator zu kämpfen. Wenn du ein 8051-Äquivalent dazu findest, nutze das, ansonsten wäre das ein guter Grund auf ARM Cortex-M zu wechseln.
Die gibts ja für kleine Geld. https://de.rs-online.com/web/p/entwicklungstools-microcontroller/1935481 Ich hatte das Debuggen gestern noch getestet und es geht mit der Silabs und der Keil Umgebung wenn der Debug Adapter vorhanden ist. Für mich fehlt da nix. Zusätzlich habe ich mir das Simplicity Studio angesehen und auch hier ein kleines Projekt aufgesetzt. Mag ja nicht perfekt sein aber auch die IDE funktioniert soweit und Debuggen ist kein Problem.
Es gibt Gründe, warum ich einen Simulator benutzen möchte, um den erzeugten Code für meinen uC zu testen: Der uC arbeitet im Verbund mit anderen Schaltungsteilen, die noch in Entwicklung sind. Deren geplantes zeitliches Verhalten ist aber bekannt und vorgegeben: also wie sie auf Signale vom uC reagieren und welche Signale sie an den uC schicken und welche exakten Timings einzuhalten sind. Mithilfe der Virtuellen Signalgenerierung kann ich das Verhalten der angeschlossenen Schaltungsteile und der Bediener simulieren. Ich kann absichtlich Fehler einbauen (Tastenprellen als simples! Beispiel) und sehen, ob mein uC darauf korrekt reagiert. Im Virtuellen Logikanalysator kann ich mir anschauen, ob und wann Signale erzeugt werden, ich kann ausmessen, ob die Zeitfenster stimmen. Ich kann diese Auswertungen sogar durch Simulationscode erledigen lassen, um bei Codeänderungen sichergehen, dass ich mir keine Nebeneffekte eingehandelt habe. Mir fehlt die Phantasie, wie ich das mit einem Evalboard, ein paar Tastern und LEDs hinbekommen soll. Jedenfalls nicht ohne einen Berg an zusätzlicher Zusatz-HW (LA, Digiscope, Signalgeneratoren, ...), den ich nicht besitze. Mir reicht ein Notebook und ein großer Bildschirm zuhause. Erst wenn es soweit ist, dass der uC im Gerät (das eine Stunde Fahrzeit entfernt steht) zur Realität wird, kommen Scope, LA und ggfs. In-Circuit-Debugger ins Spiel. Bis dahin will ich so gut wie möglich vorbereitet sein.
:
Bearbeitet durch User
>>Ich hatte das Debuggen gestern noch getestet und es geht mit der Silabs
und der Keil Umgebung wenn der Debug Adapter vorhanden ist.<<
Bernd, was meinst du damit genau? Funktioniert dann der HW Debugger in
der Keil uVision Umgebung? In uVision kann man ja zwischen SW Debugger
und HW Debugger switchen.
:
Bearbeitet durch User
>> Funktioniert dann der HW Debugger in der Keil uVision Umgebung?
Yep, genau so. Ebenso in der Silabsumgebung und in beiden Silabs IDEs.
Ich habe mit einem F410 und F326 getestet da ich keinen EFM hier habe. Da es aber auch im Simplicity Studio geht sehe ich da kein Problem. Auch hierfür war die Keil Lizenz schnell generiert. War eh schon auf meiner Liste zum testen.
Bernd: wenn ich den EFM8BB1LCK hätte, könnte ich dann ein Eingangssignal im zeitlichen Verhalten simulieren und den Verlauf von Eingangs- und Ausgangssignalen im uVision LA anzeigen lassen?
Kalle W. schrieb: > Bernd: wenn ich den EFM8BB1LCK hätte, könnte ich dann ein Eingangssignal > im zeitlichen Verhalten simulieren und den Verlauf von Eingangs- und > Ausgangssignalen im uVision LA anzeigen lassen? Das kann ich dir nicht sagen da ich keinen EFM hier habe.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.