Announcement: there is an English version of this forum on Revenue ist Gewinn, nicht Umsatz
Sebastian schrieb: > Revenue ist Gewinn, nicht Umsatz https://en.wikipedia.org/wiki/Revenue Ich denke da hast Du nicht recht...
:
Bearbeitet durch User
Angehängte Dateien:
-
display_rear.jpg
130 KB -
display_front.jpg
76 KB
Noch ein kleines Projekt mit dem PFS154: https://cpldcpu.wordpress.com/2020/04/05/addressable-7-segment-display/ Ein anreihbares intelligentes 7-Segment Display. Jedes Segment enthält einen PFS154, der für die Displaykontrolle und Kommunikation zuständig ist.
:
Bearbeitet durch User
Tim . schrieb: > Noch ein kleines Projekt mit dem PFS154 Hmm, ja, wenn man unbedingt etwas mit dem 3ct uC tun will. Aber so richtig taugt der nicht dafür, wie man am 1 Widerstand,-Multiplexing sieht, 10mA Nennstrom des Display sind damit nicht erreichbar. Ein DM13A STP16CP05 TLC5928 wäre nicht weniger intelligent (im Gegenteil, erlaubt Erkennung defekter LEDs) ebenso daisy-chainbar und auch nur 1 chip, und liefert nicht nur ordentlich Strom sondern sogar pinkompstible Verwendung bis 7-Segment Grossanzeigen mit 2 oder 3 LED pro Segment in Reihe. Gibts aber zugegeben nicht für 3ct sondern eher 30ct.
MaWin schrieb: > Tim . schrieb: >> Noch ein kleines Projekt mit dem PFS154 > > Hmm, ja, wenn man unbedingt etwas mit dem 3ct uC tun will. > > Aber so richtig taugt der nicht dafür, wie man am 1 > Widerstand,-Multiplexing sieht, 10mA Nennstrom des Display sind damit > nicht erreichbar. Beim ausgewählten Display werden pro Segment zwei LEDs in Reihenschaltung verwendet. Daher ist der Spannungsabfall >3V und es war nicht mehr genug Headroom für die Stromquelle übrig. Leider ging das aus dem Datenblatt des Displays nicht eindeutig hervor. (Ja, chinazeugs usw.). Leuchten tut es trotzdem. Die GPIOS begrenzen sowieso auf 10-15mA. Den Widerstand hätte man auch weglassen können. > Ein DM13A STP16CP05 TLC5928 wäre nicht weniger intelligent (im > Gegenteil, erlaubt Erkennung defekter LEDs) ebenso daisy-chainbar und > auch nur 1 chip, und liefert nicht nur ordentlich Strom sondern sogar > pinkompstible Verwendung bis 7-Segment Grossanzeigen mit 2 oder 3 LED > pro Segment in Reihe. > > Gibts aber zugegeben nicht für 3ct sondern eher 30ct. Ist aber auch langweiliger...
:
Bearbeitet durch User
@ Tim Wo hast du die Platinen zu deinem "kleinen" Projekt (PFS154) machen lassen? Kann dort jeder eventuell nachbestellen?
Jochen schrieb: > @ Tim > > Wo hast du die Platinen zu deinem "kleinen" Projekt (PFS154) machen > lassen? Kann dort jeder eventuell nachbestellen? Habe das PCB in EasyEDA designed. Ich werde das Projekt dort später teilen. Von dort aus kann man auch direkt bei JLPCB und LCSC bestellen. Alternativ habe ich das Projekt zum Importieren angehängt.
:
Bearbeitet durch User
Zufaellig darüber gestolpert. Auf eevlog wird ein Programmer vorgestellt. https://www.eevblog.com/forum/blog/eevblog-1306-(1-of-5)-3-cent-padauk-micro-open-source-programmer/
Tim . schrieb: > Noch ein kleines Projekt mit dem PFS154: Ja, ist alles schön recht und gut. Ich hab auch mal bei eevblog geschaut, da bist du ja wohl auch recht aktiv. Ich hänge hier mal was dran. Ds sind noch keine Projekte, sondern erstmal nur Fingerübungen meinerseits. Die D-Variante ist für ein LCD Tian-Ma-A2C00096100 (1 Zeile Alpha und ein paar Sonderzeichen), was es derzeit für zum Padauk preislich passende 55 Ct gibt. Aber mir fehlt noch was, nämlich Dokumentation. Daß ihr das mit der Programmierung der Chips bei eevblog hingekriegt habt ist gut, aber es braucht noch die Beschreibung der Programmieralgorithmen und (ganz wichtig) des tatsächlich verwendeten Takt-Kalibrier-Algorithmus. Das, was da an Laborbericht vorliegt, ist sicherlich bei intensivem Durcharbeiten recht informativ, aber keine wirkliche Dokumentation. Eine Beschreibung des Kommunikations-Interfaces zwischen PC und Brenner hab ich auch nicht gefunden. Ein Padauk-Assembler scheint bei SDCC wohl mit dabei zu sein, aber es piept mich mal wieder an, daß sowas lediglich als Gesamtpaket und als .EXE (!!!) vorliegt. Wer mit SDCC arbeiten will, ist ja wohl keine ahnungslose Büro-Maus. Und wenn da nix ist, sondern lediglich ein Nachbrenner für den Compiler, dann schreibe ich mir meinen Assembler selber. So, ich hab inzwischen zwar mal angefangen, eine Art Dokumentations-Rumpf zu schreiben, aber weit bin ich damit bislang nicht gekommen, es fehlen immer wieder Kleinigkeiten, die in dem mittlerweile riesigen Thread bei eevblog vermutlich irgendwo versteckt sind. Frage: Kannst du dich durchringen, wenigstens die Kernbelange des vorliegenden Brenners (Algorithmen und Interface PC--Brenner) zu dokumentieren? W.S.
W.S. schrieb: > Tim . schrieb: >> Noch ein kleines Projekt mit dem PFS154: > > Ja, ist alles schön recht und gut. Ich hab auch mal bei eevblog > geschaut, da bist du ja wohl auch recht aktiv. > > Ich hänge hier mal was dran. Ds sind noch keine Projekte, sondern > erstmal nur Fingerübungen meinerseits. Die D-Variante ist für ein LCD > Tian-Ma-A2C00096100 (1 Zeile Alpha und ein paar Sonderzeichen), was es > derzeit für zum Padauk preislich passende 55 Ct gibt. Sehr schön! Das sind wohl genau die richtigen Anwendungsfelder. > Aber mir fehlt noch was, nämlich Dokumentation. Daß ihr das mit der > Programmierung der Chips bei eevblog hingekriegt habt ist gut, aber es Ja, das ist bei Open-Source Projekten leider häufig ein Pferdefuss. Über Unterstützung in dem Bereich würden sich viele freuen. Ein Vorteil ist aber, dass die Datenblätter von Padauk auf Englisch und verhältnismässig ausführlich sind. > braucht noch die Beschreibung der Programmieralgorithmen und (ganz > wichtig) des tatsächlich verwendeten Takt-Kalibrier-Algorithmus. Das, > was da an Laborbericht vorliegt, ist sicherlich bei intensivem > Durcharbeiten recht informativ, aber keine wirkliche Dokumentation. Eine > Beschreibung des Kommunikations-Interfaces zwischen PC und Brenner hab > ich auch nicht gefunden. Die Programmieralgorithmen sind teilweise hier dokumentiert. https://github.com/free-pdk/fppa-pdk-documentation/tree/master/programming_sequence Den Programmer hat "JS" aus dem EEVblogforum entwickelt. Kommunikationsinterface ist leider nur über den Sourcecode dokumentiert: https://github.com/free-pdk/easy-pdk-programmer-software > Ein Padauk-Assembler scheint bei SDCC wohl mit dabei zu sein, aber es > piept mich mal wieder an, daß sowas lediglich als Gesamtpaket und als > .EXE (!!!) vorliegt. Wer mit SDCC arbeiten will, ist ja wohl keine > ahnungslose Büro-Maus. Und wenn da nix ist, sondern lediglich ein > Nachbrenner für den Compiler, dann schreibe ich mir meinen Assembler > selber. Ich finde einen C-Wrapper deutlich angenehmer. Der Compiler erzeugt recht brauchbaren Code und die kritischen Bereiche kann man ohne viel Overhead als inline-Assembler einbinden, wie z.B. hier: https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c Das ist natürlich Geschmackssache. Den aktuellen SDCC-Source gibt es im Repository oder als Archiv: https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/ Philipp kann dazu sicherlich mehr sagen.
Tim . schrieb: > Die Programmieralgorithmen sind teilweise hier dokumentiert. Nö. Da hast du mich falsch verstanden. Das ist der Laborbericht, den ich erwähnte - aber es ist keine Dokumentation. Ich hab dieses Papier bereits durchgesehen, es ist ein schwieriges Papier, insbesondere aufgrund der Diagramme. Tim . schrieb: > Kommunikationsinterface ist leider nur über den Sourcecode dokumentiert Das hab ich auch schon durchgesehen. Die Quelle ist durchaus mit ziemlicher Konsequentheit geschrieben, aber recht unkommentiert und nicht dafür ausgelegt, gut verstanden zu werden. Als Autor steht man normalerweise mittendrin und versteht die eigene Struktur, aber für Dritte ist das erstmal nur ein Dickicht. Abgesehen davon sind mir beim Durchsehen der diversen Papiere einige Gedanken gekommen, zunächst zum Problem der beim Programmieren wild herumgefahrenen Spannungen Vdd und Vpp: Mir scheint, daß es zwischen Vdd und Vpp im Chip etwas Z-Diodenartiges gibt, das dafür sorgt, daß beim Hochfahren von Vpp vor Vdd eben Vdd mit einem Abstand von knapp 7 Volt nachgezogen wird. Wenn nun Vdd aus einer Quelle wie einem OpV kommt, dann gibt es einen Crash, wenn diese Spannungsdifferenz überschritten wird. Deshalb das Hochfahren von Vpp auf einen ersten Zwischenwert, dann das Nachziehen von Vdd, dann das weitere Hochfahren von Vpp auf den benötigten Endwert und dann das weitere Hochfahren von Vdd auf einen Wert, bei dem das Einschießen von Ladungen in die isolated Gates zwar möglichst schnell geht, dabei der Chip aber grad noch nicht abraucht. Vielleicht ist es möglich, Vdd einfach floaten zu lassen (evtl. mit einem dezenten Runterzieher von 47k gegen Masse), dabei Vpp gleich auf Sollspannung zu fahren und dann Vdd nur per Einquadrantenquelle (also Spannungsquelle quasi wie ein Emitterfolger ohne Lastwiderstand) zu applizieren. So, wie es derzeit ist, scheint es eher ein Problem zu sein, das der Padaukschen Programmierhardware geschuldet ist als daß es vom Chip her eine Notwendigkeit wäre. W.S.
Tim . schrieb: > >> Ein Padauk-Assembler scheint bei SDCC wohl mit dabei zu sein, aber es >> piept mich mal wieder an, daß sowas lediglich als Gesamtpaket und als >> .EXE (!!!) vorliegt. Wer mit SDCC arbeiten will, ist ja wohl keine >> ahnungslose Büro-Maus. Und wenn da nix ist, sondern lediglich ein >> Nachbrenner für den Compiler, dann schreibe ich mir meinen Assembler >> selber. > > Ich finde einen C-Wrapper deutlich angenehmer. Der Compiler erzeugt > recht brauchbaren Code und die kritischen Bereiche kann man ohne viel > Overhead als inline-Assembler einbinden, wie z.B. hier: > > https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c > > Das ist natürlich Geschmackssache. > > Den aktuellen SDCC-Source gibt es im Repository oder als Archiv: > https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/ > > Philipp kann dazu sicherlich mehr sagen. Ja. SDCC wird im svn entwickelt (siehe oben). daneben gibt es auch noch Snapshots und Releases. Beide jeweils als Tarball mit Quellcode, als Kompilate für macOS, Windows, GNU/Linux. Eigentlich sollte sich nirgendwo nur eine EXE finden; an allen Stellen an denen es Kompilate git sollte sich auch ein Quellcode-Tarball finden. Woher kommt dieser "SDCC […] lediglich als […] .EXE"? Der sdas-Assembler in SDCC ist ein Fork des asxxxx-Assemblers (die haben sich nun leider etwas auseinanderentwicklet, sie wieder zusammenzuführen wäre wünschenswert, aber Aufwand).
W.S. schrieb: > Tim . schrieb: >> Die Programmieralgorithmen sind teilweise hier dokumentiert. > > Nö. > Da hast du mich falsch verstanden. Das ist der Laborbericht, den ich > erwähnte - aber es ist keine Dokumentation. Ich hab dieses Papier > bereits durchgesehen, es ist ein schwieriges Papier, insbesondere > aufgrund der Diagramme. Ja, es ist schon verständlich, dass Du Dir hier mehr Struktur wünschnst. Leider ist das alles, was vorhanden ist. > Abgesehen davon sind mir beim Durchsehen der diversen Papiere einige > Gedanken gekommen, zunächst zum Problem der beim Programmieren wild > herumgefahrenen Spannungen Vdd und Vpp: Mir scheint, daß es zwischen Vdd > und Vpp im Chip etwas Z-Diodenartiges gibt, das dafür sorgt, daß beim > Hochfahren von Vpp vor Vdd eben Vdd mit einem Abstand von knapp 7 Volt > nachgezogen wird. Wenn nun Vdd aus einer Quelle wie einem OpV kommt, Woraus schlussfolgerst Du das? Generell kann wohl davon ausgehen, dass es eine ESD Struktur gibt, die in irgendeiner Weise VPP, VDD und GND verbindet. Da VPP höher als VDD sein kann, wird es wohl keine einfache Clampdiode sein, sondern eine Struktur, die erst bei höherer Spannungsdifferent schaltet. > dann gibt es einen Crash, wenn diese Spannungsdifferenz überschritten > wird. Deshalb das Hochfahren von Vpp auf einen ersten Zwischenwert, dann > das Nachziehen von Vdd, dann das weitere Hochfahren von Vpp auf den > benötigten Endwert und dann das weitere Hochfahren von Vdd auf einen > Wert, bei dem das Einschießen von Ladungen in die isolated Gates zwar > möglichst schnell geht, dabei der Chip aber grad noch nicht abraucht. Ich hatte immer dein Eindruck, dass der Power-On-Reset genutzt wird, um die MCU zu resetten und in einen Zustand zu bringen, aus dem man danach in den Programmiermodus kommt. Dazu muss erst einmal VDD stabilisiert sein. Das DeltaV zu VPP initiiert dann den Programmiermodus. Wahrscheinlich werden viele Devices in einem Bereich mit starken hot carrier stress betrieben, so dass der Programmiermodus nicht all zu lange aktiv sein darf. > Vielleicht ist es möglich, Vdd einfach floaten zu lassen (evtl. mit > einem dezenten Runterzieher von 47k gegen Masse), dabei Vpp gleich auf > Sollspannung zu fahren und dann Vdd nur per Einquadrantenquelle (also > Spannungsquelle quasi wie ein Emitterfolger ohne Lastwiderstand) zu > applizieren. Dann kann man aber nicht genau kontrollieren, was der POR macht. Das würde ich als eher kritisch ansehen.
Ich habe jetzt eine vereinfachte Version das EasyPDKProg getestet, welche sich fast komplett beim JLCPCB Assembly-Service fertigen lässt. Siehe hier: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg3106318/#msg3106318 Es müssen ledliglich ein paar größere Bauteile manuell bestückt werden. Von der r0 sind keine PCBs mehr übrig, aber ich werde bald ein paar neue PCBs von einer finalen Version (r1) ordern. Wenn jemand interesse hat, bitte ich um eine PM.
:
Bearbeitet durch User
Angehängte Dateien:
-
Leiterplatte.jpg
150 KB
Tim . schrieb: > Von der r0 sind keine PCBs mehr übrig, aber ich werde bald ein paar neue > PCBs von einer finalen Version (r1) ordern. Wenn jemand interesse hat, > bitte ich um eine PM. Dann überarbeite bitte zuvor alle Footprints. Diejenigen für die gewöhnlichen R und C haben zu geringen Padabstand und sie sind für 0805 etwas zu klein und für 0603 zu riesig. Ich würde ja lieber bei allen R auf 0603 gehen. Und der Footprint für den STM32F072 hat viel zu lange Pads. Die gucken zu weit unter den Chip und das macht Probleme. Als nächstes sollte wenigstens die GND-Fläche auf der Bestückseite mehr isolate-Abstand haben. Abgesehen davon ist die ganze LP mit einer Unmenge von GND-Vias übersät - das ist unnötig und stört an manchen Stellen. Nochwas: dort wo der Fassungs-Footprint ist, lieber noch ein simples Hole mit so etwa 3 mm Dmr setzen, um die Drähte, die man dort für eine Programmier-Strippe anlöten muß, durchzuziehen und damit eine gewisse Zug- und Biege-Entlastung zu schaffen. Noch schöner wäre natürlich eine richtige Steckbuchse. Anbei ein Bild (nach Ablöten des µC aufgrund Kurzschluß unter dem Chip). Tja.. und: "Ja, es ist schon verständlich, dass Du Dir hier mehr Struktur wünschnst. Leider ist das alles, was vorhanden ist." Deswegen habe ich ja den Vorsatz gefaßt, mich schriftstellerisch zu betätigen. Ist aber ne Luftnummer, weil ich keinerlei OTP Typen habe und eigentlich auch nicht JFF ordern will und deshalb dann das meiste gar nicht selbst verifizieren kann. "Woraus schlussfolgerst Du das?" Nun, ich hab mir bei all den Diagrammen so meine Gedanken gemacht, offenbar floatet VDD ohnehin des öfteren beim Hochfahren und man nimmt ja erstmal an, daß es für ein beobachtbares Procedere irgend einen triftigen Grund gibt. "Ich hatte immer dein Eindruck, dass der Power-On-Reset genutzt wird, um die MCU zu resetten und in einen Zustand zu bringen, aus dem man danach in den Programmiermodus kommt." Ich kenne das alles von den PIC's her: dort gilt bei den meisten Typen, die einen internen RC-Oszi haben auch VPP vor VCC. Aber dort wird VPP sogleich auf etwa 13..14 Volt hochgerissen und später erst VCC auf 5V gesetzt. MicroChip gibt dafür auch einen Grund an: bei internem Oszillator kann es sein, daß dieser während des Ansteigens von /Reset schon anschwingt - offenbar reicht dann eine halbe Periode - und man kommt dann nicht mehr in den Programmiermodus. MicroChip scheint dabei die Innereien auf dem Silizium besser im Griff zu haben, so daß sie sogleich auf volle Kanne mit VPP gehen können. Bei meinem PIC-Brenner hab ich deshalb auch einen Gatetreiber eingesetzt, der schaltet zuverlässig binnen weniger als 20 ns VPP nach oben. Dann kann man auch VCC vor VPP bei besagten PIC's fahren. W.S.
Angehängte Dateien:
-
r1_current.JPG
230 KB
W.S. schrieb: > Dann überarbeite bitte zuvor alle Footprints. Diejenigen für die > gewöhnlichen R und C haben zu geringen Padabstand und sie sind für 0805 > etwas zu klein und für 0603 zu riesig. Ich würde ja lieber bei allen R > auf 0603 gehen. Und der Footprint für den STM32F072 hat viel zu lange > Pads. Die gucken zu weit unter den Chip und das macht Probleme. Als Ja, der STM32F072 lässt sich mit den aktuellen Pads in der Tat nicht gut löten. Die Footprints stammen allerdings alle von LCSC/JLCPCB. Daher gehe ich davon aus, dass sie für deren PCB-Assembly Prozess optimiert sind. Die Lite-Version ist explizit dafür vorgesehen, bei JLCPCB automatisch bestückt zu werden. Daher würde ich von deren Footprints nicht abweichen wollen, auch wenn es die Handbestückung erleichtern würde. Ich habe daher jetzt, wenn möglich, alle Passives auch auf 0402 geändert, da so etwas mehr Platz für tooling-holes ist und die Kosten niedriger sind. Der aktuelle Stand ist oben zu sehen. Ein 3mm Loch könnte ich im Prinzip noch einbauen. Die ganzen Durchkontaktierungen finde ich auch etwas obskur, zumal es sich ja nicht um ein HF-Design handelt. Ich habe die Anzahl jetzt grob auf die Häfte reduziert. Allerdings scheinen es gefühlt kaum weniger zu werden... W.S. schrieb: > "Ich hatte immer dein Eindruck, dass der Power-On-Reset genutzt wird, um > die MCU zu resetten und in einen Zustand zu bringen, aus dem man danach > in den Programmiermodus kommt." > > Ich kenne das alles von den PIC's her: dort gilt bei den meisten Typen, > die einen internen RC-Oszi haben auch VPP vor VCC. Aber dort wird VPP > sogleich auf etwa 13..14 Volt hochgerissen und später erst VCC auf 5V > gesetzt. MicroChip gibt dafür auch einen Grund an: bei internem > Oszillator kann es sein, daß dieser während des Ansteigens von /Reset > schon anschwingt - offenbar reicht dann eine halbe Periode - und man > kommt dann nicht mehr in den Programmiermodus. MicroChip scheint dabei > die Innereien auf dem Silizium besser im Griff zu haben, so daß sie > sogleich auf volle Kanne mit VPP gehen können. Evtl. nutzt Padauk auch einen leicht anderen Ansatz zur Aktivierung des Programmiermodus? Ich würde nicht erwarten, dass es hier zu große Anleihen an die PICs gibt. Man sollte auch bedenken, dass Padauk wahrscheinlich eine ganz anderen Speicher-IP nutzt und sich der Programmiervorgang daher als Ganzes unterscheiden kann. Das einfachste ist im Moment auf jeden Fall, dem Originalprogrammer zu folgen.
:
Bearbeitet durch User
Angehängte Dateien:
-
Boboards.JPG
290 KB
Passend zu dem Modifizierten "lite r1" Programmer habe ich ein paar Breakout-Boards designed, die direkt in den Programmer gesteckt werden können. Durch die minimale Größe können sie gut auf Breadboards verwendet werden. Die flash-typen von Padauk können mit zwei pin-out Varianten abgedeckt werden. Beim PFS172/PFC232-SO8 musste ich ein paar Pins vertauschen, damit die Programmierschnittstelle in an den richtigen Positionen liegt. Nicht ideal...
:
Bearbeitet durch User
> Die flash-typen von Padauk können mit zwei pin-out Varianten abgedeckt > werden. Soweit ich weiss, gibt es den PFC161 bisher nur im S08B-Pinout (auch wenn es laut Datenblatt auch S08A geben sollte), das zu keinem anderen Flash-Typ passt. Damit bräuchten man für die 8-Pin-Flash-Typen mindestens 3 Layouts (wie bei meinem f-eval-boards https://github.com/free-pdk/f-eval-boards).
:
Bearbeitet durch User
Philipp Klaus K. schrieb: >> Die flash-typen von Padauk können mit zwei pin-out Varianten > abgedeckt >> werden. > > Soweit ich weiss, gibt es den PFC161 bisher nur im S08B-Pinout (auch > wenn es laut Datenblatt auch S08A geben sollte), das zu keinem anderen > Flash-Typ passt. Damit bräuchten man für die 8-Pin-Flash-Typen > mindestens 3 Layouts (wie bei meinem f-eval-boards > https://github.com/free-pdk/f-eval-boards). Stimmt, die S08B type ist noch einmal deutlich anders. Da wird bestimmt die Kompatibilität zu einem Wettbewerber-IC eine Rolle spielen... Eine weitere Variante bekomme ich leider nicht aufs panel. Allerdings handelt es sich bei den PFC161 ja um touch controller - die wird man sowieso nicht auf einem breadboard nutzen wollen, da die parasitären Kapazitäten die Touch-Funktion beeinträchtigen.
:
Bearbeitet durch User
Tim . schrieb: > Evtl. nutzt Padauk auch einen leicht anderen Ansatz zur Aktivierung des > Programmiermodus? Ich würde nicht erwarten, dass es hier zu große > Anleihen an die PICs gibt. Das mag sein. Ich hab zwar so das Gefühl, daß Padauk durchaus recht deftige Anleihen an die PIC's genommen hat, aber zumindest bei den ausgewiesenen OTP Typen geht's wohl anders - ansonsten gäbe es ja keinen Grund, bei vorhandenen Flash-Zellen die Chips als OTP auszuweisen. Umso wichtiger ist eben genau das, was mir inzwischen im Magen liegt: eine möglichst genaue und kompakte und gründliche Zusammenfassung all dessen, was bislang herausgefunden wurde. W.S.
W.S. schrieb: > Das mag sein. Ich hab zwar so das Gefühl, daß Padauk durchaus recht > deftige Anleihen an die PIC's genommen hat, aber zumindest bei den Die Padauk MCUs kann man von der Architektur her als deutlich verbesserte PICs wahrnehmen. Von der Implementationsseite haben sie wenig gemein. Die neueren Padauks sind alle mit modernen Synthesetools in einem 0.18µm CMOS-Prozess designed, während die aus der Hochzeit der PICs bekannten Derivate auf Technologie der 80er Jahre beruhen - so, wie die Dies aussehen, auch mit full custom Layout. Dieses ist der Grund dafür, warum die PDK-Controller so günstig und klein sein können. Die 0.18 µm Technologie ist heute für wenig Geld auf 200mm Wafern verfügbar, während sie in den 90er Jahren noch nicht entwickelt war. Die Technologie des nichtflüchtigen Speichers wird bei beiden eine grundsätzlich andere sein. Kurz - außer auf Architekturseite nach Ähnlichkeiten zu suchen liefert eher zufällig Ergebnisse. > ausgewiesenen OTP Typen geht's wohl anders - ansonsten gäbe es ja keinen > Grund, bei vorhandenen Flash-Zellen die Chips als OTP auszuweisen. Ich gehe davon aus, dass es sich bei den OTP-Typen auch um OTP-Speicher handelt. Zumindest die Peripherie für den Löschvorgang wird man nicht integriert haben.
Naja, es ist ja auch kein Wunder, daß sich in den verflossenen 30 Jahren die Technik weiter entwickelt hat. Meinen PIC-Assembler hatte ich so etwa 1992..93 geschrieben, weil mir der damalige 'PICALC' zu doof war. Ist alles ne Weile her. Ich hab erstmal einen neuen STM auf die Brenner-LP gelötet und meinen JLink-edu herausgekramt. Geht so, aber /Reset hätte ruhig auch herausgeführt sein können. Man muß diese STM's ja zuerst entsperren, dann bulkerase und dann geht erst das eigentliche Programmieren. Mit der Schreiberei ist noch nichts weiter gediehen. Aber wie schaut's bei dir mit den Padauk's aus? Pläne, wie es weitergehen soll? W.S.
Angehängte Dateien:
-
picvspadauk.JPG
250 KB
Der Größenvergleich einer Padauk MCU mit einem PIC12C509 im Bild spricht Bände. Ich kenne zwar die genauen Dimensionen des PIC-die nicht, allerdings kann man annehmen, dass die Bondpads eine ähnliche Größe haben und daher zur Skalierung hinzugezogen werden können. Der PMS150C ist mehr als 10x kleiner als der PIC - trotz erweiterter Funktionalität.
W.S. schrieb: > Aber wie schaut's bei dir mit den Padauk's aus? Pläne, wie es > weitergehen soll? Im Moment ist im EEV-Forum viel Aktivität uns es gab Fortschritte bei der Toolchain und der Dokumentation. Es gibt jetzt dank Christian aus dem Forum hier ein Update der Website: https://free-pdk.github.io/ Die neue Website basiert auf Jekyll, so dass es relativ leicht ist, Beiträge im Markdown-Format zu verfassen. Ich kümmere mich gerade um den lite r1 Programmer. Die ersten Boards werden gerade aufgebaut und sollten in 1-2 Wochen bei mir sein.
:
Bearbeitet durch User
Tim . schrieb: > Im Moment ist im EEV-Forum viel Aktivität uns es gab Fortschritte bei > der Toolchain und der Dokumentation. Nun ja, die Fortschritte bei der Dokumentation sind allerdings recht überschaubar. Eine echte Dokumentation zum Programmieren dieser Chips existiert noch immer nicht. Ein gleiches gilt für deren Oszillator-Kalibration. Und der Größenvergleich der Dies zwischen einem PIC und einem Padauk ist zwar nett, aber für die Dokumentation unnötig. Es soll ja kein Plausch zum Tee-Kränzchen sein, sondern eine Dokumentation der Programmierung dieser Chips. Mit der Toolchain dürfte der SDCC gemeint sein, mit dem hab ich mich bislang noch gar nicht befaßt, ich neige bei solchen Chips eher zu Assembler. Naja und der Thread bei eevblog ist tatsächlich weiter angeschwollen, aber es ist extrem mühsam, dort noch irgend eine nützliche Information herauszulesen, es ist zuviel und auch thematisch zu sehr durcheinander. Es geht zumeist gar nicht mehr um den Programmer und die Algorithmen, sondern da wird über C++ diskutiert und darüber, daß printf zu groß ist. Wer hätte das je gedacht? Und als eine sehr seltsame Sache sehe ich es an, daß dort jemand so ein BluePill-Board hernimmt, dort den µC und andere BE herunterlötet, dann einen STM32F072 drauflötet, und dann eine Zusatzplatine entwirft, wo die brennerspezifischen Dinge drauf sind. Auch hier wäre mMn eine Konsolidierung nötig: den eigentlichen Brenner auf eine LP, die diversen Fassungen auf je eine andere LP und dazwischen ein Kabel. Also eine 'Standard'-Schnittstelle erzeugen. Kurzum, aus meiner Sicht hat sich in der Sache eigentlich sehr wenig bewegt. Du scheinst derzeit voll beschäftigt zu sein mit der kommerziellen Seite der verbesserten Programmierer-Version. Und ich? Nun, irgendwann werde ich mich entscheiden müssen, ob ich mich (notfalls auf eigene Faust) mit diesen Chips (PFS1xx) weiter befasse, oder ob ich das Ganze in die Tonne befördere. W.S.
W.S. schrieb: >... Nun ja, jedem seine Plaisierchen. Ich finde es auf jeden Fall nicht angemessen, sich ständig negativ über die Arbeit anderer auszulassen. Draussen scheint übrigens die Sonne!
W.S. schrieb: > oder ob ich das Ganze in die Tonne > befördere. Lieber in die Tonne, dein Gift braucht keiner in diesem Projekt!
Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain, vllt. gibt es dann in Zukunft Konkurrenz zum SDCC :D https://www.104.com.tw/job/54bzn
:
Bearbeitet durch User
Max M. schrieb: > Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain, > vllt. gibt > es dann in Zukunft Konkurrenz zum SDCC :D > > https://www.104.com.tw/job/54bzn Interessant! Die Open Source Toolchain droht ja besser als deren eigene Tools zu werden. Jetzt müssen sie nachlegen :) Anscheinend geht es aber nicht spezifisch um GCC, das war wahrscheinlich nur als Beispiel genannt. (sofern man Google-Translate hier trauen kann)
:
Bearbeitet durch User
Max M. schrieb: > Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain, vllt. gibt > es dann in Zukunft Konkurrenz zum SDCC :D > > https://www.104.com.tw/job/54bzn "8/32 Bit MCU compilation and development tools." Will Padauk in den 32-Bit-Markt einsteigen? Was käme da als Architektur in Frage? Dienststelle Hsinchu. Gehalt 40000 oder mehr. Google translate sagt Yuan (Währung der Volksrep. China, das wären dann 5000 € - ein überdurchscnittliches Monatsgehalt für Softwareentwickler dort). Aber Dienstort ist Hsinchu in der Republik China, mit der dortigen Wöhrung TWD. 40000 TWD wären aber nur 1200 €, etwa die Hälfte eines durchschnittlichen Monatsgehalt für Softwareentwickler dort.
Philipp Klaus K. schrieb: > Max M. schrieb: >> Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain, vllt. gibt >> es dann in Zukunft Konkurrenz zum SDCC :D >> >> https://www.104.com.tw/job/54bzn > > "8/32 Bit MCU compilation and development tools." > > Will Padauk in den 32-Bit-Markt einsteigen? Was käme da als Architektur > in Frage? RISC-V? Eine 32 bit-Version der FPPA-Architektur kann man sich natürlich auch vorstellen. Allerdings wäre das schon ein etwas merkwürdiger Ansatz.
:
Bearbeitet durch User
Philipp Klaus K. schrieb: > Aber Dienstort ist Hsinchu in der Republik China, mit der dortigen > Wöhrung TWD. Hsinchu ist weiterhin in Taiwan. Taiwan nennt man auch "Republic of China (Taiwan)" während China auch "People's Republic of China" heißt. Philipp Klaus K. schrieb: > 40000 TWD wären aber nur 1200 €, etwa die Hälfte eines > durchschnittlichen Monatsgehalt für Softwareentwickler dort. Nach kurzer Google-Recherche sind 40k wohl ein durchschnittliches Monatsgehalt in Taiwan. Edit: Scheint sogar etwas unterdurchschnittlich zu sein: https://www.statista.com/statistics/319845/taiwan-average-monthly-wage/#:~:text=Average%20monthly%20wage%20in%20Taiwan%202008%2D2018&text=This%20statistic%20depicts%20the%20average,49%2C989%20from%20the%20previous%20year.
:
Bearbeitet durch User
Max M. schrieb: >> Aber Dienstort ist Hsinchu in der Republik China, >> mit der dortigen Wöhrung TWD. > > Hsinchu ist weiterhin in Taiwan. Taiwan nennt man > auch "Republic of China (Taiwan)" während China > auch "People's Republic of China" heißt. Das war schon korrekt so, der Unterschied ist zwischen "Republik China" (= Taiwan) und "Volksrepublik China" (= Festlandchina).
Ich würde es einfach neutral "Taiwan" nennen. Hinter der Bezeichnung RoC steckt einiges an konfliktbehafteter Konotation: https://en.wikipedia.org/wiki/Republic_of_China_(1912%E2%80%931949)
Philipp Klaus K. schrieb: >> https://www.104.com.tw/job/54bzn > > "8/32 Bit MCU compilation and development tools." > Gehalt 40000 oder mehr. > > Google translate sagt Yuan (Währung der Volksrep. China, das wären dann > 5000 € - ein überdurchscnittliches Monatsgehalt für Softwareentwickler > dort). > > Aber Dienstort ist Hsinchu in der Republik China, mit der dortigen > Wöhrung TWD. 40000 TWD wären aber nur 1200 €, etwa die Hälfte eines > durchschnittlichen Monatsgehalt für Softwareentwickler dort. Ich denke es handelt sich hier um ein Mindestgehalt. Vielleicht muss so etwas in Taiwan ja angegeben werden? Ist z.B. in österreich auch so.
Tim . schrieb: > Ich würde es einfach neutral "Taiwan" nennen. > > Hinter der Bezeichnung RoC steckt einiges an konfliktbehafteter > Konotation: > https://en.wikipedia.org/wiki/Republic_of_China_(1912%E2%80%931949) In den meisten Fällen ist das durchaus eine sinnvolle Lösung, die ich auch verwende. "Taiwan" ist wie "China" und "Deutschland" gleichzeitig eine geographische und kulturelle Bezeichnung (und damit auch meistens dass, was man sagen will). Wenn man aber von etwas spricht, bei dem es um die staatlichen Gebilde geht (wie hier die Währungen) ist es sinnvoll, deren Eigenbezeichnugen zu verwenden. Wenn es in einem Text um "Mark" geht, und ich mich Frage, welche deutsche Währung gemeint ist, ist es ja auch sinnvoll, die Bezeichnungen "Bundesrepublik Deutschland" und "Deutsche Demokratische Republik" zu verwenden, wenn man von den beiden Staaten mit unterschiedlichen Währungen spricht. Auch wenn "Deutsche Demokratische Republik" historisch eine umstrittene Bezeichnung war.
Philipp Klaus K. schrieb: > Tim . schrieb: >> Ich würde es einfach neutral "Taiwan" nennen. >> >> Hinter der Bezeichnung RoC steckt einiges an konfliktbehafteter >> Konotation: >> https://en.wikipedia.org/wiki/Republic_of_China_(1912%E2%80%931949) > > In den meisten Fällen ist das durchaus eine sinnvolle Lösung, die ich > auch verwende. > > "Taiwan" ist wie "China" und "Deutschland" gleichzeitig eine > geographische und kulturelle Bezeichnung (und damit auch meistens dass, > was man sagen will). > Wenn man aber von etwas spricht, bei dem es um die staatlichen Gebilde > geht (wie hier die Währungen) ist es sinnvoll, deren Eigenbezeichnugen > zu verwenden. Ja, das ist logisch richtig. Gehört vielleicht nicht ganz hier hin: Nach meinem Verständnis impliziert "RoC" aber auch den seit dem zweiten Weltkrieg bestehenden Beherrschungsanspruch auf Gesamtchina. Ich habe zumindet bisher noch nie einen Taiwaner von der RoC sprechen gehört, obwohl ich seit vielen Jahren unterschiedliche Kontakte dort hin habe. Für mich klingt die Bezeichnung im allgemeinem Umgang höchst ungewohnt. > Wenn es in einem Text um "Mark" geht, und ich mich Frage, welche > deutsche Währung gemeint ist, ist es ja auch sinnvoll, die Bezeichnungen Allerdings heisst die Währung auch "New Taiwan Dollar" (TWD).
:
Bearbeitet durch User
Hallo :) Ich dachte mir, dasa ich die Frage am besten hier mit rein stelle a statt einen neuen Thread aufzumachen. Ich verwende jetzt schon ein Weilchen die Padauk uC und mich würde interessieren, wie ich erkenne wie viel Speicher also sowohl ROM als auch RAM von meinem Code belegt werden. Ich habe schon hin und wieder gelesen, dass man hierfür das .map File heranziehen kann. Dort habe ich auch eine Zeile mit Code gefunden. Entspricht die dort angegebene Größe 1 zu dem belegten ROM im uC? Schon mal vielen Dank für eure Antworten :)
Beitrag #6477629 wurde vom Autor gelöscht.
Beitrag #6477640 wurde vom Autor gelöscht.
Wenn du unter Linux arbeitest und den SDCC verwendest: Ich habe für mich ein kleines C-Programm geschrieben, dass die generierte IHX Datei auswertet und somit den Speicherbedarf im Flash des Padauks bestimmt: Syntax: pfsreadhex device filename Beispiel: pfsreadhex pfs154 foo.ihx Anmerkung der Name für das Device ist NICHT case sensitive (es wird nicht zwischen Groß- und Kleinschreibung unterschieden. Der Dateiname filename ist sehr wohl case sensitive (weil Linux eben case sensitive im Umgang mit Dateinamen ist). ---------------------------------------- Der RAM Bedarf ist im Map-File abgelegt, hierbei ist jedoch logischerweise nicht berücksichtigt, wieviele Bytes der Stack benötigt. Es wird hier nur angezeigt, wieviel Speicherplatz die Variablen belegen. Du findest im Map-File einen Abschnitt wie diesen hier (einen Dank hier an Philipp Klaus K. , der mich aufgeklärt hat, dass die diesem Abschnitt folgende Liste NICHT anzeigt, wieviel Ram-Platz eine einzelne Variable belegt)
1 | Area Addr Size Decimal Bytes (Attributes) |
2 | -------------------------------- ---- ---- ------- ----- ------------ |
3 | DATA 00000002 00000061 = 97. bytes (REL,CON) |
Eventuell schreibe ich noch einen Parser, der das Map-File nach dieser Stelle durchsucht und dann werde ich diese in pfsreadhex evtl. integegrieren. Gruß, Ralph
Ich habe dem Progrämmchen die Auswertung des Map-Files mit hinzugefügt. Die Syntax lautet jetzt: pfsreadhex device projectname Für projectname darf keinerlei Dateiextension mit angegeben werden, dieses fügt pfsreadhex automatisch hinzu. Beispiel: pfsreadhex pfs154 foo analysiert foo.ihx und foo.map Gruß, Ralph
Danke für die Antwort. Linux habe ich leider nicht, aber ich werde die C Datein schon verstehen. Ich programmiere derzeit nämlich meine eigene GUI für den SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher ist. Da werde ich das dann mit einbauen
Tobias schrieb: > Ich programmiere derzeit nämlich meine eigene GUI für den > SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher > ist. Oha, da bin ich mal gespannt. Ich hoffe du stellst das ganze dann hier vor. Ich habe meine eigene IDE mittlerweile fertig, jedoch allerdings als TUI... (ich bin halt ein alter Mensch und immer noch ein Fan der uralten Borland Produkte)
fyi, ich habe die aktuellen Designunterlagen zum lite-programmer hier abgelegt: https://github.com/free-pdk/easy-pdk-programmer-lite-hardware Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar, so dass man ihn nicht automatisiert bestücken lassen kann.
Ralph S. schrieb: > Ich hoffe du stellst das ganze dann hier vor. Kann ich gerne machen :) Tim . schrieb: > Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar Weist du woran das liegt? Ich wollte nämlich noch ein paar normal Programmer aufbauen, jedoch bekommt man die fast niergends mehr. Und der Preis den LCSC angibt (obwohl er nicht auf Lager ist) war das letzte mal bereits bei 14€. Gibt es irgendwelche Alternativen? Ich kenne mich mit den STM32 nicht sonderlich aus, da 8bit für mich bisher vollkommen ausreichend waren.
@Ralph S. könntest du mir kurz deinen Code erklären bzw. wie die Größe ermittelt wird.
Tobias schrieb: > Weist du woran das liegt? Ich wollte nämlich noch ein paar normal > Programmer aufbauen, jedoch bekommt man die fast niergends mehr. Und der > Preis den LCSC angibt (obwohl er nicht auf Lager ist) war das letzte > mal bereits bei 14€. > Gibt es irgendwelche Alternativen? Ja, ich weiß, woran das liegt. Die Firmware ist eben nicht so strukturiert, daß man sie problemlos auf eine andere HW portieren kann. Hätte man sie so gemacht, daß man eine saubere Trennung zwischen Programmieralgorithmen, generellem Systemsetup, Kommunikationskanal und Lowleveltreibern durchgezogen hätte, dann wäre das Ausweichen auf irgendwelche andere Hardware überhaupt kein Problem gewesen. Aber so, wie sie ist, geht das eben nicht - zumal nicht einmal das Kommunikationsinterface PC<-->µC dokumentiert ist. Die einzige Alternative wäre, die Firmware eben so umzuschreiben, daß man sie leicht portieren kann, z.B. auf einen LPC11Uxx oder NUC120 oder so etwas ähnliches. Aus meiner Sicht wäre sogar ein tiefer greifendes Umstrukturieren sinnvoll: nämlich derart, daß die Algorithmen auf der PC-Seite verbleiben und der µC lediglich atomare Lowlevel-Operationen durchführt. Also Spannungen einstellen, Präambel applizieren, Programmierworte schreiben/lesen und dergleichen. All so etwas steht oder fällt jedoch mit einer sauberen Definition des Protokolls zwischen PC und µC. Ich hatte das damals bei meinem PIC-Programmer so gemacht und es ist wirklich gut praktikabel. Für die Padauks würde ich sowas ja ebenfalls beisteuern, aber dafür braucht es eine ordentliche Dokumentation. Einfach nur zu sagen "lies dich durch den Wust an Forenseiten durch" ist daneben. W.S.
Tobias schrieb: > Tim . schrieb: >> Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar > > Weist du woran das liegt? Ich wollte nämlich noch ein paar normal > Programmer aufbauen, jedoch bekommt man die fast niergends mehr. Und der Keine Ahnung, man könnte beim Support anfragen. Die MCU war schon häufiger nicht lieferbar und ist nach einiger Zeit wieder verfügbar gewesen.
Hallo Ralph, ich denke ich die ROM berechnung in deinem Programm jetzt mehr oder weniger verstanden. Bei dem Bsp müsste demnach der benötigte Speicher 528 Byte betragen oder? Den ausführlichen Weg dorthin hab ich in dem Textfile. :02002000253089 :10000000000001 13072F0428FE2C820173381230E0 :20002400022F800B1930002F80030012022F052800171530FF2F820BFF2F830BFF2F840 B05 :0600440005130613113044 :06020A000913A0307A0088 Falls das vorgehen so stimmt würde ich gerne noch wissen, wieso du (0x400e <= fadress <= 0x4012 oder 0x10010 <= fadress <= 0x10014)abprüfst.
:
Bearbeitet durch User
Tobias schrieb: >> Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar > > Weist du woran das liegt? Ich wollte nämlich noch ein paar normal > Programmer aufbauen, jedoch bekommt man die fast niergends mehr. Die sind momentan auf Allokation, die dürften so gut wie überall ausverkauft sein. Könnte mir gut vorstellen daß das Nachwehen vom Corona-Lockdown im Frühjahr sind.
Ralph S. schrieb: > Tobias schrieb: >> Ich programmiere derzeit nämlich meine eigene GUI für den >> SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher >> ist. > > Oha, da bin ich mal gespannt. Ich hoffe du stellst das ganze dann hier > vor. Ich habe meine eigene IDE mittlerweile fertig, jedoch allerdings > als TUI... (ich bin halt ein alter Mensch und immer noch ein Fan der > uralten Borland Produkte) Eine naheliegende Möglichkeit könnte sein, eine Art easy-pdk-programmer-Plugin für eine IDE zu schreiben, die bereits SDCC unterstützt (z.B. Code::Blocks).
Oder man konfiguriert sich einfach mit ein paar Zeilen einen VSCode-Workspace:
1 | {
|
2 | "settings": { |
3 | "C_Cpp.default.defines": [ |
4 | "PFS173"
|
5 | ],
|
6 | "C_Cpp.default.intelliSenseMode": "msvc-x64", |
7 | "C_Cpp.default.systemIncludePath": [ |
8 | "${workspaceFolder}/include/", |
9 | "${workspaceFolder}/include/pdk", |
10 | "${workspaceFolder}/include/pdk/device", |
11 | "C:/Program Files (x86)/SDCC/include/", |
12 | "."
|
13 | ],
|
14 | "C_Cpp.default.cStandard": "c99", |
15 | "cSpell.allowCompoundWords": true, |
16 | "cSpell.diagnosticLevel": "Hint", |
17 | "cSpell.enabled": false, |
18 | }
|
19 | }
|
Die Builds mache ich in der Konsole. Das ist Geschmackssache. Ich vermute aber, hier es eher der Weg das Ziel :) Ich kann es nachvollziehen.
Angehängte Dateien:
-
intel_hex_format.png
14 KB
Tobias K. schrieb: > Falls das vorgehen so stimmt würde ich gerne noch wissen, wieso du > (0x400e <= fadress <= 0x4012 oder 0x10010 <= fadress <= > 0x10014)abprüfst. Das ist, Asche über mein Haupt, ein Fehler von mir und ist ein Überbleibsel von einem Programm, das ich original für PIC-Mikrocontroller geschrieben hatte. Dort sind die Adressbereiche Konfigurationsworte und haben mit dem Flashspeicherbedarf nichts zu tun. Im obigen Programm führt das zu keinem Fehlverhalten, da Byteadressen größer als 0x1800 bei einem Padauk Controller nicht auftreten können: PFS154: 2k words, max. Wordadresse 0x07ff, max. Byteadresse 0x0fff PFS173: 2k words, max. Wordadresse 0x0bff, max. Byteadresse 0x17ff Die Zeilen
1 | // die Configuration Words fuer hoechste Programmadresse ignorieren |
2 | if (!( ((fadress >= 0x400e) && (fadress <= 0x4012)) || |
3 | ((fadress >= 0x10010) && (fadress <= 0x10014)) )) |
können also gelöscht werden. Grundsätzlich erfolgt nur eine Auswertung einer Intel-Hex-Datei, siehe auch: https://de.wikipedia.org/wiki/Intel_HEX Bei einer Zeichenposition wird von 0 an gezählt. Zeichenpositon 0 muss in einer Datei immer ":" sein, sonst ist es keine Intel-Hex Datei. Position 1.2 geben eine hexadezimale Zahl an, wieviele Datenbytes in einer Zeile vorhanden ist. Position 3..6 geben in hexadezimaler Form eine 16-Bit Speicheradresse an, ab der später im Flash Datenbytes abgelegt werden, wenn die hexadezimale Zahl in Position 7..8 gleich 0x00 ist. Position 9 und folgende sind die Datenbytes, die ins Flash geschrieben werden. Was ich also mache ist, ausgehend davon, dass die kleinste Flashspeicheradresse 0 ist, die Datenbytes in einer Zeile zu zählen und diese der Adresse der Zeile hinzuzuaddieren. Ist diese so ermittelte höchste Adresse einer Zeile größer als die bisher höchste festgestellte Adresse, wird diese der Variable mit der höchsten festgestellten Adresse zugeteilt. Am Ende wird die ermittelte Anzahl der Bytes durch 2 geteilt, damit in der späteren Anzeige die Ausgabe als "Anzahl Words" ausgegeben werden kann. --------------------------------------------------------- Deine Bytereihe
1 | :020020 00 253089 |
2 | :100000 00 00000113072F0428FE2C820173381230E0 |
3 | :200024 00 022F800B1930002F80030012022F052800171530FF2F820BFF2F830BFF2F840B05 |
4 | :060044 00 05130613113044 |
5 | :06020A 00 0913A0307A0088 |
ergibt tatsächlich eine Anzahl von 528 Datenbytes = 264 Words, wobei hier anzumerken ist, dass das noch keine zulässige Intel-Hex Datei ist, weil ihr der "End of file" Record (Typ 01) fehlt. Dieser Record beinhaltet bei 8 Bit Daten auch die Startadresse, die bei Systemen, deren Flashspeicheradresse nicht bei 0x0000 beginnt, ausgewertet werden muß (höchste Adresse minus dem Wert der Startadresse ergibt den Flash Speicherbedarf) ------------------------------------- Hm, das Erklären des Intel-Hex Formats gehört aber eigentlich nicht in diesen Thread, weil es hier ja um die Padauk Controller geht und eben nicht um das Intel-Hex Format welches vom SDCC als Ausgabeformat verwendet wird. Gruß, Ralph
Philipp Klaus K. schrieb: > Eine naheliegende Möglichkeit könnte sein, eine Art > easy-pdk-programmer-Plugin für eine IDE zu schreiben, die bereits SDCC > unterstützt (z.B. Code::Blocks). Das wäre zum einen eine Möglichkeit, oder man nimmt das ganze als ein "Makefile" Projekt, bindet die Hostsoftware zum Easy-PDK-Programmer in das Makefile mit ein und hat eine (sehr einfache) GUI mittels Geany (welches ein Makefile aufrufen kann)
Gerd E. schrieb: > Die sind momentan auf Allokation, die dürften so gut wie überall > ausverkauft sein. stimmt... Reichelt hat scheinbar noch welche, hat aber seinen Preis im vl. zu von vor 2 Wochen nahezu verdoppelt auf jetzt 7,22 € für einen F072CBT6 Abartig
Ralph S. schrieb: > Tobias schrieb: >> Ich programmiere derzeit nämlich meine eigene GUI für den >> SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher >> ist. > > Oha, da bin ich mal gespannt. Ich hoffe du stellst das ganze dann hier > vor. Ich habe meine eigene IDE mittlerweile fertig, jedoch allerdings > als TUI... (ich bin halt ein alter Mensch und immer noch ein Fan der > uralten Borland Produkte) Für die die es interessiert, habe ich meine kleine GUI in nem extra Thread kurz ein wenig vorgestellt. Beitrag "Padauk Graphical User Interface"
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.