mikrocontroller.net

Forum: Projekte & Code "Universalprogrammer" für Linux


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: Joerg W. (joergwolfram)
Datum:

Bewertung
18 lesenswert
nicht lesenswert
Nachdem es entsprechende Nachfrage gab, habe ich mein 
Universalprogrammer-Projekt etwas aufgeräumt und dokumentiert.

http://www.jcwolfram.de/projekte/uprog2/main.php

Hauptgrund für die Entwicklung war damals, dass es für die 
Programmierung von HCS12XE-Controllern nichts Brauchbares unter Linux 
gab, nach und nach sind dann weitere Controllerfamilien dazugekommen.

Als Controller kommte ein ATMega644 zum Einsatz, derzeit sind noch etwa 
20K Flash frei. Von der Hardware her ist derzeit nur die USB-Variante 
ausführlich dokumentiert, es gibt auch noch eine Bluetooth-Variante mit 
eingebautem Akku (derzeit nur als Lochraster ohne Dokumentation und mit 
etwas anderer Pinbelegung), die ich bei Bedarf noch dokumentieren kann.

Die Liste der programmierbaren Devices umfasst derzeit etwa 400 Typen, 
wobei teilweise auch generische dabei sind (z.B. STM32F0xx-32K), die 
meherere Typen abdecken.
Programmiert werden können:

- Atmel AVR (SPI)
- Atmel ATxmega (PDI)
- Cypress PSOC4 (SWD)
- Microchip PIC10xx/PIC12xx/PIC16xx
- Microchip PIC18xx
- Microchip dsPIC33xx
- NXP/Freescale MPC56xx (BAM)
- NXP/Freescale HCS08
- NXP/Freescale HCS12(X)
- Renesas R8C
- Renesas 78K0R
- Renesas RL78
- ST Micro SPC56xx (BAM)
- ST Micro ST7FLITE
- ST Micro STM8 (SWIM)
- ST Micro STM32 (SWD)
- TI MSP430 (SBW)
- TI CC2540/1
- XILINX XC9500/XL
- Atmel Dataflash (AT45DBxx)
- SPI-Flash (25xx)
- I2C-EEPROM (24xx)

Die Liste ist fest im Programm integriert (über Header-Files), ich habe 
mir sie bis jetzt einfach erweitert und neu compiliert, wenn es nötig 
war. Eine Auslagerung in eine externe Datei ist derzeit nicht 
vorgesehen, das Projekt war eigentlich auch nie zur Veröffentlichung 
geplant...

Jörg

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

Wahnsinn wieviel Arbeit Du in den Programmer gesteckt hast.
Vielen Dank dass Du das Projekt veröffentlichst.

Einen kleinen Schaltungsfehler habe ich gefunden: der 10k Widerstand um 
den AVR ist in der Zeichnung kurzgeschlossen.

Gruß Sven

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis, ich habe das korrigiert und gleich noch ein 
Changelog mit auf die Seite gemacht. Der andere Anschluss des 
Widerstands muss natürlich an PA3. Damit wird die Device-Spannung 
gemessen, wenn sie einen gewissen Wert übersteigt, wird VDD auf Pin2 der 
Leiste nicht angesteuert. Über die Schottky-Diode werden dann ggf. die 
Pegel auf die der externen Spannungsquelle angehoben.

Was momentan noch fehlt, sind die dsPIC30. Der Code dafür ist auch schon 
drin, lediglich die Device-Definitionen fehlen. Werde ich aber demnächst 
noch ergänzen.

Jörg

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nett. Und sehr vorbildlich alles mit Quellcode. Werde ich mir bei 
Gelegenheit mal näher ansehen.

Autor: Thomas W. (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tolles Projekt, danke! 😅

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Es gibt ein kleines Update (V1.26). Es sind ein paar Bugfixes dabei, 
beim MSP430 kann man jetzt festlegen, ob das INFO-A Segment mit gelöscht 
werden soll. SPI-Flashes können jetzt auch im Quad-Mode angesprochen 
werden, das bringt etwas mehr Geschwindigkeit, insbesondere beim 
Lesen/Verify. Außerdem kann man jetzt 3D-Magnetfeldsensoren (MLX90363) 
direkt auslesen. das Ganze wieder unter:

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach längerer Zeit gibt es wieder mal ein Update. Hinzugekommen sind 
SPI-EEPROMs (AT25010...) und  Programmierung der SPC56xxx über JTAG. 
Daneben gibt es noch ein paar Bugfixes und Ergänzungen, z.B. Erase und 
Programm für die MSP430F5xxx wobei letzteres noch relativ langsam ist, 
da ich die Register noch direkt über SBW beschreibe.

Und es gibt einen Funktionsgenerator, einstellbar von 153Hz bis 2,5MHz. 
Dabei stehen neben der eingestellten Frequenz auch noch geteilte (1/2, 
1/4, 1/8, 1/16 und 1/32) zur Verfügung.
Mittelfristig geplant ist ein Web-Interface für die meisten Funktionen 
und ein kleiner Logik-Analysator mit max. 1 MHz Abtastrate. Über das 
Webinterface lässt sich zur Zeit nur der Frequenzgenerator steuern, dazu 
wird der Webserver mit

uprog2 WSERVER

gestartet (Programmer muss angeschlossen sein) und im Browser die Seite 
http://localhost:48512 aufgerufen. Im Moment ist das Ganze aber nur 
experimentell, da ich für mich selbst das Webinterface eigentlich (noch) 
nicht brauche.

Jörg

Autor: Zweifel (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Wenn es noch eine Windows Oberfläche dafür gäbe, wäre das der beste 
Programmer, den es gibt!

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tolles Teil, absolut!

Auf der Seite http://www.jcwolfram.de/projekte/uprog2/reference.php 
scheint mir bei 25.1 die Signalbelegung unvollständig zu sein.

Gibt es auch ein Layout für ein PCB?

Autor: Vancouver (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Cooles Projekt und sorgfältig dokumentiert, Respekt.

Wäre es prinzipiell möglich, das Teil basierend auf einen Arduino nano 
aufzubauen (AtMega328)? Oder ist ein AtMega644 zwingend erforderlich? 
Man könnte sonst ein kleines Shield mit den notwendigen diskreten 
Bauteilen draufstecken und würde sich den Aufbau des Prozessorsystems 
sparen, die Nanos gibts ja beim Chinesen fast umsonst. Anpassungen der 
Software wären natürlich zu machen.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Eine Windows-Version wird es von mir nicht geben. Dazu müsste ich mich 
damit beschäftigen, dafür ist mir aber meine Zeit zu schade und der 
Mehrwert wäre Null (Ich benutze kein Windows). Beim AX81 ließen sich die 
Programme via MinGW relativ einfach übersetzen, hier müsste man aber das 
Konzept zum großen Teil überarbeiten (forking, shared memory). Und 
selbst dann hat man "nur" ein Kommandozeilentool und keine grafische 
Oberfläche.

Eine Idee wäre, das Projekt auf einen Raspberry Pi zu portieren (mit 
direkter Kommunikation über UART) und dazu ein minimales, schnell 
bootendes Image zu erstellen. Mit entsprechend ausgebautem Webinterface 
könnte man dann per Ethernet oder WLAN programmieren und wäre vom OS 
unabhängig.

Das Problem mit der Pinbelegung habe ich korrigiert. Es lag an meinem 
Latex->HTML Konverter, da hat der Tabellenumbruch gefehlt. In der 
PDF-Doku war es richtig drin.

Layout für ein PCB gibt es schon (gEDA PCB), das kann ich auch 
hochladen. Allerdings habe ich teilweise Bauteile genommen, die halt 
sich halt gerade in der Bastelkiste befunden haben. So sind zum Beispiel 
die FETs total überdimensioniert, aber ich hatte halt zu dem Zeitpunkt 
nix passenderes da. Und auch beim Doppel-OPV musste ich auf einen 
anderen Typ gehen, da der original vorgesehene defekt war und ich keinen 
neuen kaufen wollte. Daher auch die Drahtbrücken in dem Bereich.


Das ursprüngliche Projekt lief sogar auf einem Mega168/Mega328P, war 
aber sehr eingeschränkt. Die aktuelle Version belegt aber bei mir 
inzwischen 52K Flash. Also müsste ein Teil der unterstützten Typen 
wegfallen. Außerdem müsste man generell die Blockgröße ändern, da sonst 
der RAM nicht ausreicht. Also müsste man noch eine zweite PC-Version 
pflegen oder eine Programmer-Erkennung nebst Blockgrößen-Umschaltung 
einbauen. Und da ich die Libftdi verwende, würden Arduinos mit anderem 
USB-Seriell Wandler auch nicht gehen.


Jörg

Autor: bingo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Es gibt den Arduino Mega mit 128k, der müsste doch auch gehen, hat einen 
FT232 an Bord. Oder gleich einen Arduino Mega 2560 (die haben aber meist 
einen CH340 drauf, der wird aber von Linux verstanden).

Autor: Andreas R. (daybyter)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wenns billig sein soll einen stm32f103 ? Braucht mal aber wohl 
Levelshifter.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sicher könnte man zumindest Teilfunktionen auf einen Arduino portieren. 
Aber da geht es schon los beim Quarz. Der UPROG2 hat 20MHz, Arduino 
16MHz. Einfach anpassen ist nicht, da z.B bei allen seriellen 
Protokollen das Timing über die Anzahl der Takte geht. Und auch die 
Spannungsversorgung müsste angepasst oder auf die 3,3V/5V Umschaltung 
verzichtet werden.

Auch wenn der CH430 unter Linux als serieller Port ansteuerbar ist, über 
die libftdi lässt er sich meines Wissens nach nicht ansteuern. Die habe 
ich aber gebraucht, weil ich über den seriellen Port die 1,25MBps nicht 
gescheit hinbekommen habe. Da hat sich der Rechner hin und wieder 
verschluckt, trotz RTS-Auswertung im Controller. Mit der libftdi kann 
ich über chunk_size und latency_timer das Verhalten an meine 2K-Pakete 
viel besser anpassen. Auch bei Bluetooth gehe ich direkt über ein Socket 
und nicht über /dev/rfcommxx.

Und, da bin ich mir ziemlich sicher, sobald das Projekt auf einem 
Arduino läuft kommen früher oder später Forderungen, dass der Quellcode 
auch mit der Arduino-IDE übersetzbar und flashbar ist...


STM32: Bevor ich über 20000 Zeilen Assemblercode von AVR nach Thumb2 
übersetze, fallen mir sicher sinnvollere Projekte ein :-)

Jörg

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Erläuterungen, ist verständlich.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurz vor Weihnachten gibt es noch ein kleines Update auf Version 1.29. 
Neben ein paar Fehlerbereinigungen (Data-Flash bei den S12XE lag an der 
falschen Adresse) habe ich u.a. die Trimm-Funktion für die HCS08 
verbessert. Das Trimmen des internen Oszillators dauert jetzt zwar etwas 
länger, dafür ist es genauer und die Frequenz lässt sich auf 8, 9 oder 
10MHz einstellen.

Außerdem werden jetzt einige V850 / RH850 von Renesas unterstützt.


Bei den Sensoren ist der Rotary-Magnetsensor MLX90316 sowie der 
Drucksensor LPS25H dazugekommen, hier lassen sich Druck und Temperatur 
auslesen. Die Sensoren habe ich mit dazugenommen, auch wenn sie sich 
meist nicht programmieren lassen. Aber es hat mir schon das Debugging 
bei anderen Projekten erleichtert.


http://www.jcwolfram.de/projekte/uprog2/main.php


Jörg

: Bearbeitet durch User
Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit stm8flash-Unterstützung?
Dann könnten STM8-Anwender den UPROG2 mit ihnen vertrauter Software 
nutzen.

Philipp

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Direkt über stm8flash wird es wohl nicht gehen, da die Kommunikation 
zwischen Programmer und Steuerprogramm nicht direkt sondern über einen 
Daemon erfolgt.
 Man könnte aber das Steuerprogramm (uprog2) dahingehend erweitern, dass 
es sich wie ein stm8flash verhält, wenn es als stm8flash aufgerufen wird 
(über Softlink). Wenn dazu dann noch parallel das "richtige" stm8flash 
installiert ist/wird, kann es aber zu Problemen und Missverständnissen 
führen, gegen die die abweichende Syntax von uprog2 wahrscheinlich das 
kleinere Übel ist.


Jörg

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die PIC18xxxx (ohne J und K) z.B. 18F2455 18F2550 etc. werden wohl nicht 
unterstützt?

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich fehlen sie nur in der Liste. Ich habe halt erstmal nur 
das eingetragen, was zu meinem "Mustern" irgendwie ähnlich war. Aber bei 
den PICs scheint es ja wohl hunderte von Typen zu geben.
Wenn man einen Typ mit gleicher Speicherausstattung nimmt und ii (ignore 
ID) als Parameter mit angibt, sollte es auch so gehen. Ich mache fast 
nichts mit PICs, wenn Du mir eine Liste mit gängigen Typen auflisten 
würdest, kann ich sie beim nächsten Release mit aufnehmen.

Jörg

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MS hat ja in Win10 eine Funktion eingebaut das Linux Programme direkt 
laufen können. Hat das Jemand schon mit der Soft hier versucht ?

Autor: MaWin (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Zweifel schrieb:
> Wenn es noch eine Windows Oberfläche dafür gäbe, wäre das der
> beste Programmer, den es gibt!

Schreib sie doch, ist doch alles dolumentiert.

Autor: Peter S. (petersieg)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Eine schöne Weihnachtsüberraschung wäre es, wenn jemand eine Platine 
dazu erstellt (für mich gerne auch als Through hole - muss aber nicht) 
und das Layout zum Bestellen bei den günstigen CN Lieferanten hier 
einstellt.
Gerne auch mit Sammelbestellung hier über das Forum ;-)

(Man darf sich ja aktuell gerade auch mal etwas wünschen ;-)

Peter

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> wenn Du mir eine Liste mit gängigen Typen auflisten
> würdest, kann ich sie beim nächsten Release mit aufnehmen.

Von den PICs gibt es generell sehr viele Typen, m.W. mehrere Hundert.

In der 18er Serie gibt es die J und K-Typen, da hast Du ja schon einige, 
die laufen aber nur bis 3.6 Volt. Die Typen 18Fxxx und 18Fxxxx (ohne J 
oder K) sind 5-Volt-Typen und werden von Bastlern oft benutzt, wobei die 
Serie mit 3 Zahlen schon etwas antik sind, da wird geleg. noch der 
18F242 verbaut, aber auch dafür gibt es neuere Typen in der Serie mit 4 
Zahlen, auch da sehr viele Varianten.

Sehr oft verbaut werden 18F1320, 18F2455, 18F2550, 18F2620 sowie ihre 
Pendants die statt der führenden 2 eine 4 haben und statt 18 Pins dann 
40 bzw. 44 Pins haben.

Eine gute Übersicht findest Du unter 
http://www.sprut.de/electronic/pic/18f.htm und 
http://www.sprut.de/electronic/soft/usburn/usburn.htm#typen

Autor: Peter S. (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Ich weiß, ein wenig off topic für uprog2 - trotzdem evtl. für den einen 
oder anderen hilfreich.. und für uprog2 hoffentlich nicht störend.. 
sonst bitte verschieben.)

Ich bin auch auf der Suche nach Programmierwerkzeugen unter Linux. 
USBasp mit avrdude klappt einwandfrei.

Für meinen K150 Kitrus PIC Programmer aus CN für 7€ läuft die Win$ 
Software aber nicht unter Wine. Hier gibt es es ein Python Script was 
funktioniert:

https://eliasandrade.wordpress.com/2015/01/20/como-usar-o-gravador-pic-k150-no-linux/

Und hier wird ein Parallel EEprommer mit Arduino Mega2560 und Adapter 
vorgestellt (auch dafür wird unten in den Kommentaren ein Python Script 
vorgestellt):
http://danceswithferrets.org/geekblog/?p=496
Link zu Python Script:
http://kildall.apana.org.au/~cjb/Arduino/megaprogrammer.py

Peter

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schönes Projeket.

Wenn du schon den Renesas R8C unterstützt kannst du den Code auch auf 
die M16C erweitern, ist ja jast das Gleiche. Der Speicherbereich 
(Adressen) ist ein anderer. Ich weiß nicht aus dem Kopf ob es noch 
andere Unterschiede gibt.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Problem ist halt, dass ich keinen M16C hab, um das ausprobierem zu 
können. An sich geht das ja über einen Bootloader, dessen 
Kommando-Interface bei R8C/M16C/M32C weitestgehend gleich ist. Also 
müsste man wohl nur ein paar neue Typen mit entsprechenden 
Adressbereichen in die Tabelle einfügen.

Für das nächste Release sind erstmal ein paar weitere PIC-Typen geplant, 
dazu ein paar Bugfixes und, wenn es klappt, der CC2640 von TI. So 
langsam wird auch das Flash vom Controller voll, so dass demnächst auch 
ein bisschen "Aufräumarbeit" ansteht.

Jörg

Autor: Uschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es denn dafür schon eine Platine bzw. Gerber-Files, ich mag die 
Ätzerei nicht selbst machen.

Autor: Joerg W. (joergwolfram)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Von mir nicht, ich ätze meine PCBs noch selbst. Ich kann die .pcb (gEDA 
PCB) zur Verfügung stellen und ggf. ein PNG mit als Belichtungsvorlage. 
Die Bluetooth-Variante habe ich auf Lochraster aufgebaut. Und mehr 
Programmer brauche ich momentan nicht.

Da sie SW nicht unter Windwows läuft, ist der Kreis der Interessenten 
halt eher klein. Aber vielleicht findet sich ja jemand, der Zeit und 
Lust dazu hat, ein entsprechendes Layout zu erstellen.

JUörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Es gibt wieder einmal ein Update (V1.30). Neben ein paar Bugfixes können 
jetzt auch die STM32L4xx und der CC2640 programmiert werden. Außerdem 
habe ich die PIX18F2xxx/PIC18F4xxx mit aufgenommen.

Außerdem gibt es ein neues Feature (wofür man leider das gesamte Image 
mit einem anderen Programmer flashen muß):
 Es lassen sich, per Software umschaltbar, 2 Devices ohne Umstecken 
programmieren. Dazu wird an den Programmierspannungsausgang (Pin 9) 
einfach ein 12V Relais angeschlossen. In den Programmierbefehl für das 
zweite Device muss dann einfach ein "d2" eingefügt werden. Bei den PICs 
geht das leider nicht, da hier die Programmierspannung benötigt wird.


Das Ganze wie üblich unter:

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

Nachtrag: Die Seite ist jetzt (experimentell) auch unter

http://tcrkkpvqapdku6vi.onion/index.html

erreichbar

: Bearbeitet durch User
Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:

> Problem ist halt, dass ich keinen M16C hab, um das ausprobierem zu
> können. An sich geht das ja über einen Bootloader, dessen
> Kommando-Interface bei R8C/M16C/M32C weitestgehend gleich ist.

Der M16C verwendet ein paar Leitungen mehr als der R8C. Letzterer wird 
eigentlich nur über MODE und RESET programmiert.


Eine Platine mit MC3062CF8TGP drauf kannst Du haben falls Dir das 
irgendwie weiterhilft.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darauf würde ich später gerne zurückkommen, momentan habe ich aber noch 
2-3 größere "Projektbrocken" herumliegen, die auch mal fertig und 
dokumentiert werden wollen ...

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt wieder mal ein neues Update, V1.31.

Neu hinzugekommen sind die S32K von NXP (früher Freescale). Das sind 
automotive Mikrocontroller mit einem Cortex M0+ bzw. M4F Kern.

Des Weiteren gab es bei den SPI-Flashes Fehler beim Quad-Mode, das 
scheint jetzt weitestgehend behoben zu sein. Es gibt aber immer noch 
gelegentlich das Problem, dass hin und wieder bei großen Flashes die 
Verbindung zum Programmer abbricht. Das tritt aber nur bei der 
USB-Variante auf. Eventuell "verschlucken" sich der FTDI oder der 
Treiber, mit 1,25MBps läuft das Ganze ja ganz flott und ich habe kein 
Handshake eingebaut. Das muss ich ggf. noch ergänzen. Ich habe jetzt als 
Workaround ein kleines Delay eingebaut, damit tritt der Fehler 
wesentlich seltener auf.

Die Webserver-Funktion habe ich wieder entfernt, da ich sie nicht mehr 
benötige und demzufolge auch nicht mehr weiterentwickle. Eigentlich 
sollte das Teil einer IDE sein, die komplett im Browser läuft, das 
Projekt habe ich aber inzwischen komplett aufgegeben. Das Projekt liegt 
(immer noch) unter:


http://www.jcwolfram.de/projekte/uprog2/main.php


Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Es gibt wieder mal ein neues Update, V1.32

Neu hinzugekommen sind die S9KEA64 von NXP (Freescale), kleinere 
RH850-Typen und PIC16(L)F153xx. Um Platz zu gewinnen, habe ich die 
Bootloader-Sektion verkleinert, dadurch müssen das System neu 
aufgespielt und die Fuses neu programmiert werden.

Ansonsten ist noch ein Bugfix für ältere AVRs ohne Ready/Busy Bit dabei, 
diese wurden sonst u.U. nicht richtig programmiert.

Link wie gehabt...

Jörg

Autor: Ralf E. (r_e)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

was ist den eigentlich aktueller, das weiter oben gepostete Layout 
(.pcb) oder die Schaltung auf deine Website? Wobei sich diese Layout ja 
auch noch vom Bild des Programmers unterscheidet.

Ich wollte mir gerade das Layout neu erstellen, dabei sind mir 3 
Unterschiede aufgefallen:

* im Layout hast du zusätzlich noch einen Kondensator zwischen VPP und 
GND
* im Layout fehlt der 100nF am FT232_3V3OUT (17) (Im Bild ist der Pfeil 
2Pins zu weit unten)
* der Schaltungsteil zur Programmierspannungs-Erzeugung hängt im Layout 
vor der Sicherung direkt an +5V USB

LG
Ralf

: Bearbeitet durch User
Autor: peg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Um Platz zu gewinnen, habe ich die Bootloader-Sektion verkleinert,

Ist denn der 644(pa) zwingend, das System müsste doch auch auf einem 
1284(P) laufen ?

Autor: Karl I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde die Tatsache, dass endlich ein vernünftiges PCB-Design 
existiert sehr interessant. Ich habe das mal auf einer 
Experimentier-Platine realisiert, aber das ist ja nicht befriedigend. 
Gibt es das neue PCB auch als Gerber o.ä., dann könnte man eine 
Sammelbestellung organisieren.

Autor: AVR-Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den hatte ich noch gar nicht gesehen.
Schick.
Wenn er jetzt noch updi für die neuen Attiny könnte...

Autor: Karl I. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
AVR-Bastler schrieb im Beitrag #5711473:
> Wenn er jetzt noch updi für die neuen Attiny könnte...

Wenn es speichermassig beim 644 schon gng wird, ist ein Attiny doch 
mindestens 1 Hausnummer unterhalb der Anforderungen: die Attiny hören 
z.Zt. bei 16/2 kB auf, der 644 ist mit 64/4 kB schon kanpp dran ...

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Schaltung sollte eigentlich das Aktuellste sein. Auf dem Bild ist 
mein "Prototyp", da sind auch noch ein paar Drahtbrücken drauf (beim 
OPV). Von diesem Prototypen habe ich dann die Schaltung abgezeichnet.

Der Kondensator an 3V3OUT ist nicht zwingend notwendig, aber sinnvoll, 
den an VPP hatte ich nur vorsichtshalber vorgesehen.
Für die VPP-Erzeugung hatte ich eigentlich eine zweite Polyfuse 
vorgesehen, letztendlich ist ein 0-Ohm Widerstand drauf gekommen, weil 
gerade zur Hand. Und dann ist es halt so geblieben...

Sicher wäre auch eine Variante mit dem Mega1284P möglich, die müsste 
aber gesondert gepflegt werden, da der Bootloader- und Sytembereich dann 
an anderen Adressen liegt. Es ist aber für mich einfacher, die Software 
zu ändern, als einen neuen Controller zu kaufen und aufzulöten UND die 
Software zu ändern.

Wenn mir ein ATTiny mit UPDI unterkommt, werde ich die sicher mit 
einpflegen.

Jörg

Autor: Uschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl I. schrieb:
> Gibt es das neue PCB auch als Gerber o.ä., dann könnte man eine
> Sammelbestellung organisieren.

Gerber wäre toll.

@Ralf

Auf Deinem Board sind einige einzelne Lötaugen, wozu sind die gut?
Welchen Quarz (Bauform) verwendest Du?
Pin17 des FT232 sollte laut FTDI-Datenblatt bestückt werden.

@Karl

Organisierst Du eine Sammelbestellung (sofern Joerg und Ralf 
einverstanden sind)?

Danke an alle!

Autor: Ralf E. (r_e)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erst mal zur Klarstellung, das ist nicht mein Board.
Der Entwurf von Hardware und Software ist von Jörg. Das Bild zeigt das 
Layout aus der Datei uprog2_08.pcb von Jörg.

Ich bin gerade dabei, das neu zu layoten, um mir Platinen machen zu 
lassen, selber ätzen tu ich mir nicht mehr an.

Wenn fertig, dann werde ich das natürlich auch hier zur Verfügung 
stellen, evtl. fallen auch gleich noch ein paar Platinen ab, die 
Chinesen liefern ja sowieso nicht einzeln.


Jetzt zur Schaltung.

Jörg schreibt auf seiner Website,  er hat an Bauteilen genommen, was 
gerade da war :-), z.B: die Mosfets im TO252 Format, die riesige Spule 
oder die ausgefallenen LEDs.
Mach ich auch meist so, allerdings möchte ich im Layout doch Teile 
verwenden, die auch leicht zu bekommen sind (Reichelt,...).

Schaltplan hab ich mal angehängt, ich hoffe ich hab bei der schnellen 
Übernahme nicht noch was vergessen oder verwechselt.

Aktuell ist da noch nichts fix, ihr könnt noch Wünsche äußern.

* SMD soweit möglich komplett in 0805.
* USB-Teil hab ich hier jetzt von einem vorhanden Layout übernommen, 
spart Arbeit, muss ja nicht kompl. bestückt werden (LEDs,..).
* Mini-USB bleibt, ist einfach haltbare als die Micro-Teile
* Mosfets: Da hätte ich IRF7410 da, halte ich allerdings auch für 
übertrieben. Was denkt Ihr über z.B. den IRLML2246, geeignet?
* Induktivität, sollte was kleineres reichen, Typ ??
 (* Schotky-Dioden dito, muss ich noch nach nem Typ schauen 
(BAT54/MBR520/BAT46 ?), oder hab ihr da welche, die ihr sowieso immer 
verwendet und deshalb vorrätig habt /verwenden möchtet.
* Stecker, evtl zusätlich zur 9pol. Stiftleiste noch ein 5x2 
Wannenstecker, damit lassen sich leicht verpolungssichere Adapterkabel 
machen.

LG

Autor: Stephan S. (uxdx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wannenstecker für ISP hielte ich für übertrieben, braucht viel Platz, 
wird damit ja nur 1x programmiert, Updates dann über USB

Für den Programmierstecker wäre Micromatch chic, gibt es auch bei R..., 
Flachkabel haben bei den PICs aber den Nachteil, dass die CLK-Leitung 
sehr empfindlich gegen Störungen ist (siehe 
http://sprut.de/electronic/pic/icsp/icsp.htm, auch eigene Erfahrung), da 
müssen GND daneben

USB wäre mir egal, mini oder micro

IRF7410 wäre für 16A gut, lieber was kleineres

Schottky-Diode dürfte unkritisch sein, ich verbaue gerne BAT43/46/48, 
obwohl die oft im Mini-Melf sind, gibt es aber auch in anderen 
SMD-Bauformen. Bitte keine 3-poligen ...

Quarz als 5x7mm oder 3x5mm (2x2.5mm wäre schon echt winzig), alle bei 
R... erhältlich

Induktivität z.B. L-1616FPS 150µ oder L-1210F 150µ von R...

Autor: Ralf E. (r_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wannenstecker nicht für den ISP des Programmers, sondern zusätzlich zur 
einreihigen 9pol. So kann man sich ein paar Adapterkabel für die 
verschiedenen Anwendungen machen.

Micromatch verwende ich normalerweise auch für den ISP, ist allerdings 
nicht so weit verbreitet.

Autor: Stephan S. (uxdx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch ein P.S.

Der TLV272 als Präzisions-OPV für die Programmierspannung der PICs wäre 
mir vom Spannungsbereich zu klein, VPP kann immerhin bis 14V betragen 
plus Sicherheits-Marge wären dann 18-20V besser, z.B. LM6132, allerdings 
deutlich teurer

Autor: Ralf E. (r_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der alternative OPV ist ja pinkompatibel, da kann jeder verwenden, was 
er will.

Und wer PICs programmiert, muss ja kein Flachbandkabel verwenden (oder 
kann auftrennen).

Wenn du auch Micromatch für ISP verwendest, welch Belegung hat sich denn 
bei dir durchgesetzt? Pin 1 bei der verlängerten Nase (so hab ich das 
bis jetzt gehandhabt) oder Pin 1 auf der anderen Seite (wie in einigen 
Micromatch-Datenblättern).

Autor: Stephan S. (uxdx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pin 1 ist bei mir an der Nase, weiblich ist auf Platine, männlich am 
Kabel. Leider ist es im Datenblatt bei Reichelt genau umgekehrt.

Ich nehme auch oft Pogo-Pins (auf einer kl. Hilfsplatine) zum 
programmieren, das spart den Stecker auf der Platine.

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan S. schrieb:
> Der TLV272 als Präzisions-OPV für die Programmierspannung der PICs wäre
> mir vom Spannungsbereich zu klein, VPP kann immerhin bis 14V betragen
> plus Sicherheits-Marge wären dann 18-20V besser, z.B. LM6132, allerdings
> deutlich teurer

Den TLV272 scheint es von verschiedenen Herstellern zu geben. Bei TI 
sind es 16V, das dürfte reichen; ich habe aber auch schon 5.5V gesehen.

Autor: Renate (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich finde das Projekt SEHR interessant, zumal Sprut seine eigenen 
Brenner aufgegeben hat, er zeigt nur noch die Microchip-Brenner 
http://www.sprut.de/electronic/pic/brenner/, die alten Seiten sind 
völlig weg, sehr schade.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 9-polige Buchsenleiste ist nicht unbedingt optimal, besonders was 
Verschleißfestigkeit angeht. Nach ca. 4 Jahren habe ich sie tauschen 
müssen, da zumindest die 4-poligen Adapterkabel nicht mehr ordentlich 
gehalten haben. Meine BT-Variante (aus der später die USB-Variante 
entstanden ist) hat übrigens eine 9-pol. D-Sub, daher kommen die 9 Pins.

Für PICs nutze ich einen kurzen Zwischenadapter, ebenfalls für die 
Xilinx CPLDs (damit ich zum Parallel-Kabel kompatibel bin). Bei fast 
allen anderen Projekten nutze ich die Signalfolge vom Programmer und 
komme dadurch mit ein paar 1:1 Kabeln (4,5,6 Pole) aus.

Für Controller und Schnittstellen, die das zulassen, ließen sich auch 
Debug-Funktionen realisieren. Letztendlich habe ich das aber nicht 
weiter verfolgt, da ich selbst mit "indirektem Debugging" besser 
klarkomme. Kleinere Schaltungen lassen sich auch probeweise direkt aus 
dem Programmer betreiben, hier sind die 4 parallelgeschalteten Portpins 
nicht die optimale Lösung, aber in den meisten Fällen reicht es bei mir 
aus. Ansonsten wird ja erkannt, wenn bereits Spannung an der Baugruppe 
anliegt.

Jörg

: Bearbeitet durch User
Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..... aaaalso wenn jemand eine Platine beim Chinamann fertigen läßt: 
Just for fun um die Arbeit von Jörg zu sehen würde ich eine nehmen.

Autor: Np R. (samweis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Wenn mir ein ATTiny mit UPDI unterkommt, werde ich die sicher mit
> einpflegen.

Das wäre wirklich sehr schön.

Ich würde Dir ja gerne einen in einen Briefumschlag stecken - aber 
leider wohne ich nicht in Deutschland, und mit den neuen Regelungen für 
den internationalen Postversand müsste ich den kleinen Käfer in ein 
Paket werfen.

Bei TME z.B. gibt's den Attiny212 oder Attiny412 ab ca. 60cent. Die 
größeren ab 75cent.

Falls es hilft - Code gibt's auf GIThub: jtag2updi, STK2UPDI (beide C++ 
auf Atmega328), pyupdi (Python), oder updiprog (C).

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Btw, in dem Schaltplan weiter oben (uprog2.png) ist der MOSFET Q2 falsch 
- sollte nen N-Channel sein. Und was soll des Gehampel dahinter mit dem 
OpAmp?

Autor: Ralf E. (r_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Fehler mit dem Mosfet hatte ich auch schon bemerkt, war einfach ne 
Unachtsamkeit von mir beim Abzeichne der Schaltung von Joerg.

Mit dem OP wird die durch den Aufwärtswandler erzeugte 
Programmierspannung (für PICs) gemessen und geschaltet.

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

Bewertung
0 lesenswert
nicht lesenswert
Ralf E. schrieb:
> Mit dem OP wird die durch den Aufwärtswandler erzeugte
> Programmierspannung (für PICs) gemessen und geschaltet.

Eigentlich wäre der gar nicht nötig, sprut hat das ganz ohne OPV 
einfacher gestaltet

Autor: Renate (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
über L1, D1, Q2 und C5 wird Vpp erzeugt und über R4 und R5 gemessen.

Q3/Q4 und Q5/Q6 sind nur dazu da, um Vpp je nach Pin-Layout an den 
Testsockel zu führen. Bräuchte man beim uprog2 nicht.

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Q3/Q4 und Q5/Q6 sind nur dazu da, um Vpp je nach Pin-Layout an den
> Testsockel zu führen. Bräuchte man beim uprog2 nicht.

Abschalten möchte man die Vpp evtl ja doch, ein Pärchen wäre also schon 
angebracht (gerne auch MOSFETs). Ebenso R9 für ein definiertes Low.

Insgesamt gefällt mir die Schaltung auch besser - statt zwei OpAmps zwei 
08/15-Transistoren ...

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> statt zwei OpAmps zwei 08/15-Transistoren ...

Naja, so viel Platz braucht ein SO8 Dual-OPV auch nicht...

Eher finde ich die Lösung mit den 4 parallelgeschalteten Pins für die 
Spannungsversorgung im Nachhinein als nicht optimal. Aber es 
funktioniert.

Jörg

Autor: Stephan S. (uxdx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Naja, so viel Platz braucht ein SO8 Dual-OPV auch nicht...

Viele Wege führen nach Rom ...

Autor: Ralf E. (r_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joerg W.

...Eigentlich wollte ich an deiner Schaltung nicht so viel ändern, 
sondern nur das Layout auf leicht verfügbare Bauteile anpassen und 
Platinen fertigen lassen....

Ein zusätzlicher Mosfet zum schalten der Spannungsversorgung hätte aber 
sicher noch Platz und würde auch ohne Softwareänderung funktionieren.
Welchen der 4 Ports verwendest du denn zur Spannungserkennung?

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Welchen der 4 Ports verwendest du denn zur Spannungserkennung?

Keinen. Die Spannung geht über einen 10K/1K Teiler an PA3. Falls doch 
Änderungen notwendig sind ist das i.A. auch kein größeres Problem, man 
könnte z.B. PB0 auf Masse legen damit die Firmware das erkennt.

Jörg

Autor: Ralf E. (r_e)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier mal mein aktueller Layout-Stand, Bestückungsdruck usw. muß 
natürlich noch überarbeitet werden.
9- und 10-pol. Stiftleiste Belegung wie bei Joerg, 6-pol. AVR-ISP 
Standard

: Bearbeitet durch User
Autor: Ralf E. (r_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:

> Änderungen notwendig sind ist das i.A. auch kein größeres Problem, man
> könnte z.B. PB0 auf Masse legen damit die Firmware das erkennt.

Wäre da wahrscheinlich doch nötig, da einer der 4 jetzt zur 
Spannungsversorgung verwendeten Ports dann Low-Aktiv verwendete werden 
sollte um die Spannung per Mosfet zu schalten.....

Autor: Stephan S. (uxdx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf E. schrieb:
> hier mal mein aktueller Layout-Stand,

hübsch, gefällt mir !  (ohne das Routing kontrolliert zu haben)

Autor:   (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin schon eine Weile auf der Suche nach einer Lösung zur 
Programmierung von HCS08 Controllern unter Linux. Das Projekt hier sieht 
nach einem sehr interessanten Programmer aus.

An welche Pins müssen denn die Programmierleitungen für die HCS08
angeschlossen werden? Das hat sich mir aus der vorliegenden 
Dokumentation und einer ersten Durchsicht des Quellcodes bisher nicht 
direkt erschlossen.

Das Kompilieren von uprog2 klappt sowohl auf dem PC als auch auf einen 
RaspberryPi (Version 3) nach einem "sudo apt-get install libftdi1-dev 
libusb-1.0.0-dev libbluetooth-dev" ohne Probleme.

@Joerg W.: Gäbe es Einwände den Code so wie er ist in ein GitHub Projekt 
zu importieren?

Für einen richtigen Test fehlt jetzt noch die Hardware.

@Ralf E.: Falls irgendwo Boardlayouts, Rohleiterplatten oder sogar 
bestückte Boards herausfallen würde ich ggf. Interesse haben.

Beitrag #5732475 wurde vom Autor gelöscht.
Autor: Ralf E. (r_e)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
@nbsp;: Die Signalbelegung hat Joerg doch übersichtlich in der 
Typenliste angegeben: 
http://www.jcwolfram.de/projekte/uprog2/reference.php

Das Layout von mir kann natürlich jeder verwenden, soweit Joerg da 
nichts dagegen hat, schließlich stammt der Entwurf ja von ihm.
Übrige LP können wir reden, wenn ich denn mal die erste getestet 
habe.... Falls da dann mehr Interesse besteht evtl. auch 
Sammelbestellung, da sollte dann IMHO aber auch ein paar ct. für Joerg 
abfallen, wird bei anderen Sammelbestellungen hier im Board auch so 
gehandhabt.

Layout ist so ziemlich durch.
Todo: noch zwei passende LogicLevel-Mosfets in SOT23-3 raussuchen...
Beschriftung Rückseite...
Noch mal auf Fehler prüfen...

Im Moment schwanke ich noch bei der Spannungsversorgung für 
angeschlossene Devices, so lassen wie von Joerg vorgesehen über den 644 
oder doch geschaltet direkt aus VDD..... gerade ist die Faulheit noch 
stärker....

: Bearbeitet durch User
Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> @Joerg W.: Gäbe es Einwände den Code so wie er ist in ein GitHub Projekt
> zu importieren?

Eigentlich nicht. Eventuell müsste man vom aktuellen Release einen Fork 
machen. Denn das Problem dabei ist, dass ich meinen eigenen Programmer 
auch auf Arbeit benutze und der noch ein paar Devices mehr kann, was ich 
aber nicht veröffentlichen darf (NDA). In den Quelltexten sind diese 
Familien dann entsprechend gekennzeichnet. Der Release-Erstell-Prozess 
entfernt diese und ersetzt z.B. in der interpreter.asm die 
entsprechenden Aufrufe (man sieht das an den "reserved" Kommentaren), 
bevor alles neu übersetzt und gepackt wird.

Aus der öffentlichen Version lässt sich meine eigene aber nicht mehr 
rekonstruieren, so dass ich zwei Versionen aktuell halten müsste. Da 
müsste ich mir etwas einfallen lassen...

Die Belegungen finden sich in der Doku und werden zusätzlich beim Aufruf 
des Programmers angezeigt. Das funktioniert im Moment aber nur, wenn der 
Programmer angeschlossen ist. Ich habe versucht, ein möglichst 
einheitliches Schema zu verwenden, 1=GND, 2=VCC, 3=RESET, 
4...=Daten/Clock, damit ich so wenig wie möglich "Adapterkabel" 
benötige.

Jörg

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre auch Unterstützung für Padauk µC möglich? Fehlt es dazu an 
Spannungen? Die Flash-Varianten sind da wohl etwas weniger anspruchsvoll 
als die OTP.

Philipp

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wäre auch Unterstützung für Padauk µC möglich? Fehlt es dazu an
> Spannungen? Die Flash-Varianten sind da wohl etwas weniger anspruchsvoll
> als die OTP.

Warum nicht? Es gibt wahlweise 3,3 und 5V sowie eine Spannung, die sich 
zwischen ca 5V und 14V einstellen lässt.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir noch eingefallen ist: Wenn man VCC über einen Transistor 
schaltet, sollte auch ein zweiter Transistor gegen Masse vorhanden sein. 
Hintergrund: Es gibt einige wenige Devices, die den Secure-Status nur 
beim Power-On Reset erfassen. Also muss man zwischen Unsecure und 
Programmieren einen Powerzyklus machen. Ohne Entladen von vorhandenen 
Blockkondensatoren klappt das aber nicht sicher. Und beim folgenden 
Programmaufruf kann es dann vorkommen, dass der Programmer beim 
Wiedereinschalten die Restspannung als externe Versorgung interpretiert.

Jörg

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich habe versucht mittels uprog2 einen MC9S08 DN 60 zu programmieren, 
das funktioniert aber nicht.

Dieser Controller ist derzeit nicht explizit in der Liste der 
unterstützten Controller aufgeführt. Vielleicht liegt es also daran, 
dass das Programmieren nicht geht?

Bisher wurde der Controller mittels Codewarrior über ein s19-File 
programmiert.

Für uprog habe ich das s19-File mittels srecord in ein Hex-File 
umgewandelt:
srec_cat file.s19 -o file.hex -intel

Anschließend habe ich dieses File mittels
uprog2 MC9S08AW60 -pm file.hex
 bzw.
uprog2 MC9S08AW60 -empm file.hex
 "erfolgreich" programmiert.

Allerdings läuft das Programm nicht.

Testweise habe ich auch den zuvor mittels Codewarrior und s19-File 
geflashten Speicher mittels
./uprog2 MC9S08AW60 -rm orig.hex
 ausgelesen und anschließend dieses Hex-File erneut programmiert um zu 
prüfen, ob eventuell bei der Konvertierung von s19 zu Hex etwas schief 
läuft.
Aber auch dann läuft das Programm nicht mehr.

Vergleiche ich die ausgelesenen Hex-Files nach der Programmierung 
mittels Codewarrior und nach der erneuten Programmierung des 
ausgelesenen Files so sind diese Files großteils gleich, aber nicht 
ganz.
1. Programmierung mittels Codewarrior
2. uprog2 MC9S08AW60 -rm orig.hex
3. uprog2 MC9S08AW60 -empm orig.hex
3. uprog2 MC9S08AW60 -rm test.hex
4. diff orig.hex test.hex

Liegt das Problem eher am unterschiedlichen, nicht unterstützten Typ, 
oder gibt es noch etwas anderes, das ich bisher übersehe?

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für uprog habe ich das s19-File mittels srecord in ein Hex-File
> umgewandelt:

Braucht man eigentlich nicht, denn die UPROG2 Software kann beides lesen 
und auch schreiben. Beim Lesen geht theoretisch sogar gemischt...

Läuft folgendes Kommando fehlerfrei?
uprog2 MC9S08AW60 -empmvm orig.s19

Wenn der Datensatz "secured" ist, kann man das auch mit der Option 'ns' 
abschalten. Dafür wird dann das Byte an 0xFFBF entsprechend modifiziert.

Jörg

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

danke für die schnelle Antwort.

Tatsache, das s19-File wir auch eingelesen. Gestern hatte ich damit 
irgendwie zuerst Probleme, weshalb ich ein Hex-File probiert habe.

Das Ergebnis ist aber auch direkt mit dem s19-File leider noch gleich.

Ich bekomme folgendes mit einem selbst kompilierten uprog auf einem 
RaspberryPi (bei … habe ich gekürzt):
$./uprog2 MC9S08AW60 -empmvm orig.s19

#################################################################################
#                                                                               #
#  UNI-Programmer UPROG2 V1.32         
…
#     0 types in database                                                       #
#                                                                               #
#################################################################################
>> USB programmer is active.

***  can be programmed with:  ***

Version =  1.5
Sysver  =  0011
V-Ext   =  2.9V
V-PROG  =  2.1V
## Action: main flash erase
## Action: main flash program using orig.s19
## Action: main flash verify using orig.s19
## Action: writing SEC to unsecured state

BDM FREQ = 9.0MHz     USED MODE = 9MHz     FCDIV = 0x2d
>> CHECK SECURITY
** DEVICE IS UNSECURED **
ERASE
PROG |**************************************************|
READ |**************************************************|
ERR -> ADDR= 10000  DATA= FF  READ= 84
ERR -> ADDR= 10001  DATA= FF  READ= 00
ERR -> ADDR= 10002  DATA= FF  READ= EA
...
ERR -> ADDR= 118FD  DATA= FF  READ= 00
ERR -> ADDR= 118FE  DATA= FF  READ= 00
ERR -> ADDR= 118FF  DATA= FF  READ= 00

(unexpected error)                                                              


Wieso sind die gelesenen Adressen fünfstellig?

---

Der zu programmierende MC9S08DN60 wird auf seinem Board mit 3.3 Volt 
versorgt. Die VDD Leitung vom Programmer ist nicht angeschlossen.

Beim Speicherlayout gibt es Unterschiede. Der MC9S08DN60 hat 60kB (62080 
Bytes) Flash, der MC9S08AW60 hat 63280 Bytes Flash.

Die Memory Map für den MC9S08DN60 findet sich hier auf Seite 38.
https://www.nxp.com/docs/en/data-sheet/MC9S08DN60.pdf
Die Memory Map für den MC9S08AW60 findet sich hier auf Seite 42.
https://www.nxp.com/docs/en/data-sheet/MC9S08AW60.pdf

Hier das Speicherlayout im direkten Vergleich:
MC9S08AW60 / MC9S08DN60 
Direct Page Registers 
Size  112 Bytes / 128 Bytes
Start 0x0000 / 0x0000
End   0x006F / 0x007F

RAM
Size  2048 Bytes / 2048 Bytes
Start 0x0070 / 0x0080
End   0x086F / 0x087F

Flash
Size  3984 Bytes / 2944 Bytes
Start 0x0870 / 0x0880
End   0x17FF / 0x13FF

EEPROM
Size  0 Bytes / 2048 Bytes 
Start ------ / 0x1400
End   ------ / 0x1700

High Page Resisters 
Size  95 Bytes / 256 Bytes
Start 0x1800 / 0x1800
End   0x185F / 0x18FF

Flash 
Size  59296 Bytes / 59136 Bytes
Start 0x1860 / 0x1900
End   0xFFFF / 0xFFFF

Die S19 Datei enthält Daten von 0x1900 bis 0xBD40, was also für den DN 
Typen passen würde. Ich habe zur besseren Lesbarkeit Leerzeichen 
zwischen den Feldern eingefügt.
S0 43 0000 …
S1 23 1900 A7FCC619714C95E701C619704CF7321972201F898BF687E6024C9EE706E603EE 52
…

S1 23 BD20 CD4C6C062805080D10151C1F06201A1E061D0620161E0620021F061D0620041E 45
S1 1B BD40 061C061B0620061E061C061A06A702810002010301FF0000 E2
S1 04 FFBD FF 40
S1 23 FFBF 7EFFFFFFFFFFFFFFFFFFFFFFFF90CDA967A968FFFFFFFFFFFFFFFFA96978C9A9 3A
S1 23 FFDF 6AA96BFFFFFFFFFFFFA1B8FFFFFFFFFFFFFFFFFFFFA096FFFFFFFFFFFFFFFF19 F0
S1 04 FFFF 67 96
S9 03 0000 FC

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal nachgeschaut, beim AW60 ist der Adressbereich bei mir falsch 
eingetragen, da steht als Startadresse noch 0x8000 wie beim AW32 (den 
ich getestet habe).

Du kannst in die devices_FSL_HCS08.h probeweise den DN60 mit eintragen, 
einfach den letzten Eintrag in der Datei kopieren und anpassen. In der 
dritten Zeile (mit Kommentar "//main flash") einfach Startadresse 
(0x1900) und Länge (0xE700) eintragen und neu kompilieren. Ich kann das 
später mit einpflegen. das nächste Release gibt es wahrscheinlich Anfang 
Mai.

Was mich noch ein wenig stutzig macht, sind die 0 Typen in der 
Datenbank, das scheint aber eine andere Ursache zu haben...

Jörg

: Bearbeitet durch User
Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt folgendes in devices_FSL_HCS08.h ergänzt.
        "MC9S08DN60",
        1,
        0x1900,0xE700, //main flash
        0x0000,0x0000,
        0x0000,0x0000,
        0x0000,0x0000,
        0x0080,0x0400, //RAM
        0x00000000, //ID
        0x004a,0x0000, //TRIM REG
        0x0000,0x0000,
        0x0000,0x0000,
        0x0000,0x0000,

Leider startet der Code immer noch nicht.
$uprog2 MC9S08DN60 -empmvm  orig.s19
… 
READ |**************************************************|
ERR -> ADDR= F900  DATA= FF  READ= 00
ERR -> ADDR= F901  DATA= FF  READ= 00
ERR -> ADDR= F902  DATA= FF  READ= 00
ERR -> ADDR= F903  DATA= FF  READ= 00
…
ERR -> ADDR= FFFE  DATA= 19  READ= 00
ERR -> ADDR= FFFF  DATA= 67  READ= 00

(unexpected error)



Nachdem ich mich gerade durch den Quellcode grabe noch zwei weitere 
Fragen.

src/modules/writehex.c dürfte für das Schreiben der HEX Dateien 
zuständig sein. Dort wird in den Funktionen write_s19,  write_s29 und 
write_s39 auch der Header "S00441424335" in das srec file geschrieben.

1. Warum heißen die Funktionen s29 und s39 statt s28 und s37.
2. Wenn ich in allen drei Funktionen den Header ändere ist in der beim 
erneuten Auslesen des Speichers in geschriebenen Datei trotzdem der 
unveränderte Header drin.
$uprog2 MC9S08DN60 -rm readout.s19
$cat readout.s19
S00441424335
S32500001900FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE1
… 
Auch nach einem definitiven Neustart des Dämons mittels uprog2 KILL und 
einem make clean. Kommt der Header noch woanders her? Den String habe 
ich sonst nur in proto_shadow.s28 prot_shadow.s37 und 
proto_shadow_orig.s37 unter inc/exec/ppc_shadow gefunden.

Der Inhalt der ausgelesenen s19-Datei ist
S00441424335
S32500001900FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE1
…
S3250000F8E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF22
S3250000F9000000000000000000000000000000000000000000000000000000000000000000E1
…
S3250000FFE00000000000000000000000000000000000000000000000000000000000000000FB

Dabei sind tatsächlich die ersten Bereiche alle FF und die letzten 
Bereiche alle 00. Interessanterweise beschwert sich das obige Verify nur 
über die Bereiche mit 00.

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Update:
Nach den Änderungen sind die Originaldatei und der Readout "gleicher".
S1 ist aus dem Original, S3 aus dem Readout.
S1 23     1900 A7FCC619714C95E701C619704CF7321972201F898BF687E6024C9EE706E603EE 52
S3 25 00001900 A7FCC619714C95E701C619704CF7321972201F898BF687E6024C9EE706E603EE 50
...
S1 23     BD20 CD4C6C062805080D10151C1F06201A1E061D0620161E0620021F061D0620041E45
S3 25 0000BD20 CD4C6C062805080D10151C1F06201A1E061D0620161E0620021F061D0620041E43
S1 1B     BD40 061C061B0620061E061C061A06A702810002010301FF0000E2
S3 25 0000BD40 061C061B0620061E061C061A06A702810002010301FF0000FFFFFFFFFFFFFFFFE0

Das sieht erstmal biss zur letzten Zeile gleich aus. Dann folgt im 
Readout FF bis
S3 25 0000F8E0 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 22
und dann 00
S3 25 0000F900 0000000000000000000000000000000000000000000000000000000000000000 E1
bis
S3 25 0000FFE0 0000000000000000000000000000000000000000000000000000000000000000 FB

Während nach Originaldatei am Ende noch folgendes stehen sollte.
S1 04 FFBD FF 40
S1 23 FFBF 7EFFFFFFFFFFFFFFFFFFFFFFFF90CDA967A968FFFFFFFFFFFFFFFFA96978C9A9 3A
S1 23 FFDF 6AA96BFFFFFFFFFFFFA1B8FFFFFFFFFFFFFFFFFFFFA096FFFFFFFFFFFFFFFF19F0
S1 04 FFFF 6796
S9 03 0000 FC

Der letzte Speicherteil müsste nach Datenblatt die Vektortabelle sein. 
Diese fehlt scheinbar.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ich denke, ich habe die Ursache gefunden. Die Programmierung erfolgt 
immer in 2K-Blöcken die auf 2K Boundaries liegen, und im Fall der 60K 
Varianten klappt das dann logischerweise nicht mehr. Und dann liegen ab 
0xF900 keine Daten mehr...

Du könntest mal versuchen, soweit es möglich ist, den Code für eine 32K 
Version zu übersetzen und als solche zu programmieren. Inzwischen schaue 
ich mal, wie ich die Programmierung/Auslesen von Teilblöcken realisieren 
kann.

Jörg

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was mich noch ein wenig stutzig macht, sind die 0 Typen in der
>Datenbank, das scheint aber eine andere Ursache zu haben...

Das kommt wohl fest kodiert hier her:
main.c:80 printf("#     0 types in database                #\n",jj);
Fix:
main.c:80 printf("#     %4i types in database                #\n",jj);

Ähnliches passiert hier:
***  can be programmed with:  ***
in
main.c:207 //printf("ALGO: 0 \n",algo_nr);
main.c:208 printf("***  can be programmed with:  ***\n\n",name,cables[algo_nr]);

Fix:
main.c:207 //printf("ALGO: %i \n",algo_nr);
main.c:208 printf("*** %s can be programmed with: %s ***\n\n",name,cables[algo_nr]);

Autor: Renate (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf E. schrieb:
> hier mal mein aktueller Layout-Stand

Gibt es Neuerungen zum PCB ?

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

Bewertung
0 lesenswert
nicht lesenswert
Da habe ich mit dem  meinen Post schreiben zu lange gebraucht.

Danke für den Hinweis mit den 2K-Blöcken. Soweit war ich im Code noch 
nicht.

Ich bin nochmal an den write_s19, write_s29 und write_s39 Funktionen.

Diese werden garnicht benutzt, oder?

Das sreg format wird von
writehex.c:301 int writeblock_open()
...
fprintf(datei,"S00441424335\n");
und
writehex.c:362 int writeblock_data(unsigned long start_addr, unsigned long block_len,unsigned long dest_addr)
geschrieben.

Im Anhang ein diff meiner bisherigen Änderungen falls es von Interesse 
ist.

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte auch ein Layout, muss aber noch ein paar Tests machen und dann 
klären, ob ich das veröffentlichen darf, oder vorher noch ändern muss.
Die erste der Platinen programmiert aber offensichtlich (fast) 
erfolgreich einen HCS08 bei 3.3V

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Arbeit und die Hinweise.

Bevor Du dich aber weiter auf Fehlersuche machst, ich habe bei mir einen 
Bug entdeckt. Nicht im Code selbst, aber in dem Script, welches alle 
Devices und Algorithmen für die öffentliche Version entfernt, die dort 
nicht hinein dürfen. Und dort werden die Zeilen an einer Stelle 
fälschlicherweise via printf statt print zurückgeschrieben, was die 
ganzen Formatstrings schon auflöst... Und beim automatischen Test des 
Releases wird nur das Resultat einer "Probeprogrammierung" ausgewertet.

Die write_xxx sind noch "Altrelikte" der Vorgängerversion. Die werde ich 
gleich mit raus werfen.

Ich werde schauen, dass ich die neue Version zum WE vorziehen kann.

Jörg

Autor: Ralf E. (r_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab vor einigen Tagen Mal ein paar Platinen bestellt, melde mich, wenn 
die ersten Tests erfolgreich verlaufen...

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

vielen Dank für deinen Support.

Meinst du es wäre möglich beim Schreiben eines Speicherdumps zwischen 
den verschiedenen srec Formaten (16, 24, 32 bit) zu unterscheiden? 
Entweder anhand des Dateinamens (wie das jetzt schon zwischen hex und 
"nicht hex" gemacht wird), oder mittels eines Parameters, oder auch nur 
als Define im Code. Das würde einen späteren textuellen Diff auf die 
Dateien vereinfachen.

Holger

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich machen. "s19/S19" wären dann 16 Bit Adresse, "s28/S28" 24 Bit 
Adresse und default 32 Bit Adresse. Was außerhalb der entsprechenden 
Adressbereiche liegt, wird einfach verworfen.

Bei den 60K HCS08 würde ich erst mal den zweiten Flashblock und den 
EEPROM weglassen und nur die "ungerade Startadresse" imlementieren, wäre 
das OK?

Jörg

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SREC Format: Top. Danke!

Der zweite Flash Block ist der an der niedrigeren Adresse?
Flash
Size  3984 Bytes / 2944 Bytes
Start 0x0870 / 0x0880
End   0x17FF / 0x13FF

Der Bereich von 1900 bis FFFF reicht mir erstmal. Das ist ja auch der 
Bereich aus dem S19 File.

Holger

Autor: Holger M. (nezaya)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
So, ich habe mal meinen Login wieder ausgegraben. Der hm (Gast) bisher 
war ich.

Mit Unterstützung meines Arbeitgebers, der Primes GmbH (www.primes.de), 
folgt hier ein erstes Layout (Schaltplan, BOM und Gerber) und ein 
einfaches Gehäuse (STEP) zum 3D Drucken für den uprog2. Das alles in der 
ZIP Datei im Anhang.

Die Spannungsversorgung hat einen FET zum Schalten spendiert bekommen.
Auch hier gilt wie bei Jörg: Die Bauteilauswahl ist dem Vorhandensein 
geschuldet. Es geht sicher besser.

Getestet wurde bisher die grundsätzliche Programmierfähigkeit mit 3.3V.
Der Hochspannungsteil und weitere Teils sind im Schaltplan als nicht 
bestückt gekennzeichnet noch nicht getestet, da ich dafür derzeit keine 
Verwendung habe.

@Jörg: Wenn du möchtest, kannst du das Layout gerne auch bei dir auf die 
Website stellen oder verlinken.

Wenn es Bugs oder Änderungswünsche gibt, werde ich versuchen das in 
Zukunft einzupflegen.

Holger

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich habe jetzt Version 1.33 online gestellt. Für die 60K S08 habe ich 
noch Kommandos für den "lower" Flash eingefügt, konnte sie aber mangels 
Devices nicht testen.
Ansonsten gibt es ein paar Bugfixes und Erweiterungen, insbesondere bei 
den RH850.

Jörg

Autor: Holger M. (nezaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die 1.33 heruntergeladen und erfolgreich kompiliert.

Aber irgendwie klappt das Programmieren jetzt nicht mehr.
#  UNI-Programmer UPROG2 V1.33                                                  
...
#   694 types in database                                                       ...
uprog2 daemon is not active, starting daemon and searching for programmer
...

>> USB programmer is active.

*** MC9S08DN60 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

ERROR CODE 9F

FATAL: CONNECTION TO PROGRAMMER LOST!
   <<< PLEASE RESET PROGRAMMER >>>

Kann es sein, das der Controller auf dem Programmer nicht automatisch 
aktualisiert wird?

Korrektur: Es war ein zweites FTDI Device angeschlossen und das scheint 
uprog2 zu verwirren.

Jetzt komme ich ein Stück weiter und die Programmer Firmware wird 
aktualisiert. Programmieren klappt aber noch nicht.

*** MC9S08DN60 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

Version =  1.5
Sysver  =  0011
V-Ext   =  2.8V
V-PROG  =  1.9V
PROGRAMMER SYSTEM VERSION: 0011
REQUIRED SYSTEM VERSION:   0012
STARTING UPDATE
Update |**************************************************|
UPDATE DONE
## Action: main flash erase
## Action: main flash program using test.s19
## Action: main flash verify using test.s19

Nach den drei "Action" Zeilen bleibt uprog2 für immer stehen.

Bei einem erneuten Starten bleibt es direkt nach "V-PROG = 1.9V" stehen.

Wenn ich wieder 1.32 verwende, wird die Firmware auch wieder 
"aktualisiert" und ich kann anschließend programmieren (abgesehen vom 
ursprünglichen Problem).

: Bearbeitet durch User
Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um das Ganze etwas einzugrenzen, würde ich morgen von meinem Programmer 
ein Image ziehen und hier reinstellen. Dann könntest Du mit einem AVR 
Programmer vergleichen, ob das Update erfolgreich war. Solche "Hänger" 
hatte ich eigentlich nur früher, als ich die RTS Leitung nicht 
ausgewertet hatte.

Das mit dem 2.FTDI ist mir auch schon passiert, bei der Entwicklung von 
meinem PDP11-Emulator war das zeitweilig arg nervig, weil ich zum Testen 
immer einen seriellen Port gebraucht habe.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt meinen Programmer ausgelesen, Datei im Anhang. Das Image 
weicht von der öffentlichen Version etwas ab, da es zusätzliche Module 
enthält. Ich habe auch mal probeweise das öffentliche Image auf meinen 
Programmer geflasht und damit einen MC9S08SG16 programmiert.
#################################################################################
#                                                                               #
#  UNI-Programmer UPROG2 V1.33                                                  #
#                                                                               #
#  (c) 2012-2019 Joerg Wolfram                                                  #
#                                                                               #
#  usage: uprog2 device -commands [file/data]                                   #
#         uprog2 KILL                            kill active daemon             #
#         uprog2 LIST                            for device list                #
#         uprog2 device -help                    for device specific commands   #
#                                                                               #
#   694 types in database                                                       #
#                                                                               #
#################################################################################
>> USB programmer is active.

*** MC9S08SG16 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

Version =  1.5
Sysver  =  0012
V-Ext   =  0.0V
V-PROG  =  4.7V
## Action: main flash erase
## Action: main flash program using main.s37
## Action: writing SEC to unsecured state

BDM FREQ = 8.0MHz     USED MODE = 8MHz     FCDIV = 0x28
>> CHECK SECURITY
** DEVICE IS UNSECURED **
ERASE
PROG |**************************************************|

OK                                                                                                 
./uprog2 MC9S08SG16 -st

#################################################################################
#                                                                               #
#  UNI-Programmer UPROG2 V1.33                                                  #
#                                                                               #
#  (c) 2012-2019 Joerg Wolfram                                                  #
#                                                                               #
#  usage: uprog2 device -commands [file/data]                                   #
#         uprog2 KILL                            kill active daemon             #
#         uprog2 LIST                            for device list                #
#         uprog2 device -help                    for device specific commands   #
#                                                                               #
#   694 types in database                                                       #
#                                                                               #
#################################################################################
>> USB programmer is active.

*** MC9S08SG16 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

Version =  1.5
Sysver  =  0012
V-Ext   =  0.0V
V-PROG  =  4.7V
## Action: start device


PRESS ENTER TO EXIT 

OK                                                                                                 

Eventuell bekommt der PI Timing-Probleme mit der libftdi, dann müsste 
man sich überlegen, die Bitrate von derzeit 1,25MBps für diesen Fall auf 
z.B. 500KBps zu senken. Um nicht noch mehr verschiedene Images zu haben, 
könnte man das z.B. über eine Lötbrücke zwischen PD3 und PD4 erkennen. 
Auf der Hostseite müsste dann in der demon.c der Wert für 
ftdi_set_baudrate entsprechend angepasst werden.

Jörg

Autor: Holger M. (nezaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das main-usb.hex File jetzt mittels avrdude auf den uprog 
geschrieben. Seitdem funktioniert es.
Der MC9S08DN60 wird korrekt programmiert und das Program startet.

Vielen Dank!

Holger

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könntest Du probieren, ob es bei Dir auch mit dem Hexfile aus dem Archiv 
geht (direkt in den AVR programmieren)?

Jörg

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Eventuell bekommt der PI Timing-Probleme mit der libftdi, dann müsste
> man sich überlegen, die Bitrate von derzeit 1,25MBps für diesen Fall auf
> z.B. 500KBps zu senken

ich habe meine Arduinos (AVR1284p muss ich noch) im Bootloder nach 
Optiboot mit 115k wieder auf 57k6 gesenkt. Damit hat der PI auch keine 
Probleme.

Autor: Holger M. (nezaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

> Könntest Du probieren, ob es bei Dir auch mit dem Hexfile aus dem Archiv
> geht (direkt in den AVR programmieren)?

Ich hatte direkt das main-usb.hex aus dem Archiv genommen um via avrdude 
yu programmieren und nicht das von dir nochmal extra hochgeladene 
uprog-usb.hex. Beantwortet das die Frage?

Noch eine Frage zum Bereitstellen der Programmierspannung via PA4 bis 
PA7. Im Assembler Code (label vcc_on) habe ich dazu die Teile gefunden, 
die das ein- und ausschalten. (Dort wird auch noch irgendwie PD3 
benutzt?) Aber kann ich das Ein- und Ausschalten vom PC aus 
kontrollieren? Bisher habe ich es nämlich nicht geschafft beim 
Programmieren des HCS08 die Spannung vom uprog zu beziehen.

Holger

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Entscheidung, ob das Device über den Programmer versorgt wird ist 
abhängig von der gemessenen Spannung an V-Ext. Liegt diese unter 0,5 
Volt, sollte der Programmer die Versorgung übernehmen. Die Schwelle 
ließe sich sicher auch auf 2..3 Volt erhöhen.
PD3 ist optional dazu gedacht, die Spannung über einen über einen 
P-Kanal FET zu schalten, wird aber in der Schaltung nicht benutzt.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Letztens ist bei mir auch das Update schiefgegangen, hier werde ich evtl 
noch Prüfsummen oder ein Verify einbauen.


Wenn jemand ein Layout macht, bitte PD4 offen lassen. In der nächsten 
Version will ich die beiden Varianten (USB und Bluetooth) codemäßig 
zusammenfassen und die Unterscheidung über PD4 machen.
Bei der Gelegenheit würde ich auch die Schwelle zur externen 
Spannungserhöhung anpassen, evtl auf 1,5V erhöhen.


Jörg

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.

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