AVR-Programmer-Software für standalone FT232R

So,
habe noch etwas programmiert.

Er ist sogar noch etwas schnelle als ich geschätzt hatte

*** Programmiere FLASH ***
11392Byte in 00:00:10.54 geschrieben und geprüft

Anbei noch ein Screenshot

LG Christof

Noch drei Bilder:
FT232R - Mapping
Fuses (Userfendlyfusing fehlt noch !)
Testaufbau (Das Blaue ist nur eine Breakoutplatine für den FT232R)

LG Christof

Christof

SUPER!

dann braucht man ja nicht mehr das gepatchte avrdude Zeugl benutzen. 
Echt super.

Eins verstehe ich noch nicht ganz:
"Plugt sich sebstständig in AVR-Studio5"
Das Bild im 2ten Post sieht für mich so aus als ob man darüber alles 
handhaben kann, also z.B. ne hex in dein Program einlesen und in den AVR 
flashen, etc. pp.. Man kann das also auch "standalone" benutzen, 
unabhängig von AVR-Studio5?

Wenn AvrStudio, lässt sich das auch aus älteren Versionen benutzen? 
(habe 4.16 und habe nicht vor auf 5 zu wechseln)

Thx,
Olli

Hallo Olli,
wenn ich fertig bin, geht beides.
Die Buttons aus Datei lesen und in Datei schreiben sind mit Stand heute 
noch ohne Funktion.
Der Umstieg auf AVR-Studio5 ist zwar etwas gewöhnungsbedürftig würde ihn 
aber schon über kurz oder lang empfehlen.
Wenn ich mich recht erinnere benötigt AVR-Studio5 Framework 4.0
Mein Programmer benötigt das ebenfalls.
Falls das ein Grund ist nicht auf AVR-Studio5 zu wechseln, dann bekommst 
du das Problem spätestens mit meinem Programmer.

Mein Antrieb für das Programm lag darin, dass ich mir einen neuen 
Rechner zugelegt habe, und der hat nun Win7 und keinen Parallel-Port 
mehr. Habe dann eben auch gleich AVR-Studio5 installiert.

Der FT232R hat mich gereitzt weil ich nun die Möglichkeit habe, 
SMD-Controller mit USB zu kombinieren und keinen ISP-Stecker mehr 
benötige.

Bei geschikter Verkabelung, dass Prrojekt ohne Bootloader einfach an den 
USB-Port hängen und Firmware einspielen.

Wenn ich das aus Datei lesen und schreiben über Standalone fertig habe 
können wir ja mal probieren ob wir die Software auch bei dir zum laufen 
kriegen. Hast du einen FT232R den du mit einem AVR Verbinden kannst ?

LG Christof

Hallo Christof

"Hast du einen FT232R den du mit einem AVR Verbinden kannst ?"
jo, massig... ich habe das wie gesagt mal mit der gepatchten avrdude 
Methode ausprobiert um eine Lösung für Nachbauer einiger meiner Projekte 
(www.olliw.eu) zu haben die sich nicht zwei Items, USB-Adapter und 
ISP-Programmer kaufen wollen... aber das mit dem gepatchten avrdude ist 
schon recht wackelig und tedious.

Deswegen bin ich auf deine Lösung gespannt.

"Framework 4.0"
wenn es das kostenlos gibt und auf XP auch läuft dann ist das nicht mein 
Problem, ich weiss nur nicht warum ich auf das fette AvrStudio 5 
umsteigen soll, bin zufrieden mit 4.16.

Cheers, Olli

Mit Framework 4.0 meint Christof wohl das .Net Framework 4.0 von MS und 
ja das ist kostenlos.... Echt nettes Projekt. Christof, machst du das 
ganze über die D2XX .net Api?
Wirst du den Source Code frei zugänglich machen?
Für die die kein AvrStudio 5 möchten, könntest du ja auch eine StanAlone 
Version zur Verfügung stellen.

MfG

@ Matthias K
Ja das Läuft über die D2XX.net

Den Quellcode werde ich nicht ganz öffentlich machen, aber dem ein oder 
anderen, den ich für Vertrauenswürdig halte kann ich ihn schon mal 
weitergeben.

Wie schon erwähnt wird die Version beides können. Stand-Alone und 
AVR-Studio5.

Ich denke, dass ich ab mitte nächster Woche Tester brauchen kann. Aber 
denkt dran, das ist ein Alpha-Release. Ich kann noch nicht ausschließen, 
dass eventuell Bauteile ihr Leben lassen müssen. Ein Tiny13 habe ich 
schon zerfused.
Dadurch, dass die Konfiguration FT232R auf AVR-ISP vollkomen frei 
eingestellt werden kann, hat man auch mal schnell Output auf Output 
konfiguriert.

Device-Tabellen habe ich erst für den Tiny13 und den ATMega32 erstellt. 
Die kann man aber ganz einfach mit einem Editor selbsterstellen. Devices 
>128 werden aber noch nicht gehen. Da sag ich noch was zu wenn es soweit 
ist.

Eine Tücke gibt es noch bei der D2XX.net. Beim lesen gibt es Probleme 
wenn der RI (D7) High ist. Desshalb habe ich ihn wärend des 
programmierens als Output geschaltet und beschreibe ihn mit 0. Als RESET 
funktioniert der RI super, da ich dann im High-Zustand keine Daten lesen 
muss.

LG Christof

Dank Arc Net aus dem PC-Programmier-Forum konnte ich heute das RI (D7) 
Problem lösen.
Der angenehme Nebeneffekt - ein plus von 30% Geschwindigkeit.
Da sag nochmal einer mit einem FT232R geht ISP nur sehr langsam !!!

LG Christof

So,
jetzt könnt ihr mal spielen.

In den .dev Dateien sind die AVR-Typen definiert.
Ich habe Definitionen für den ATmega32 und ATtiny13 geschrieben.
Die sind als Muster schon so aussagefähig, dass eigendlich jeder neue 
.dev erstellen kann.
Der Name der Dev ist einfach die Hexadezimale Signatur des AVR mit .dev.
Die nötigen Informationen sind in den Datenblättern zu den AVR 
hinterlegt.

Steht bei einem AVR keien Page-Programmierung im ISP zur Verfügung so 
ist entsprechend bei FLASHblock bzw. EEPROMblock 0 einzutragen.

Habt ihr eien .dev erstellt, die funktioniert, so könnt ihr sie hier 
wieder hochladen. Feuses mit dem Namen SPIEN und RSTDISBL sperrt das 
Programm. Nach FExtBit7 = muss ein Zeilenumbruch stehen. Wenn ihr wollt 
könnt ich darunter euren Namen schreiben ect.

Denkt daran, es ist eine Alpha-Version. Es kann schnell gehen, dass 
Bauteile plötzlich unbrauchbar sind. Dafür übernehme ich keine Haftung.

Das Programm braucht zum Laufen:

http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=0a391abd-25c1-4fc0-919f-b21f31ab88b7
und
http://www.ftdichip.com/Drivers/D2XX.htm

Das Programm ist mit VB.Net geschrieben.

Bekannte Fehler.
-Bringt beim ersten Starten manchmal einen Laufzeitfehler (Einfach 
beenden und nochmal starten.
-Scheint aus einer IntelHex manchmal mehr Daten zu lesen als in ihr 
vorhanden sind. (Warum ist mir noch völlig unklar.)
-User-Frendly-Fusing fehlt noch komplett.

Dann dürft ihr nun schön Bugs reporten ;-)

LG Christof

>jetzt könnt ihr mal spielen.

Okay, aber sauber ist dein Code ja nicht wirklich und die 
Rechtschreibung der Variablen lässt auch zu Wünschen übrig - kein 
Wunder, dass du Niemanden deinen Code zeigen willst ...

z.B.:

1

Public Sub Warte(ByVal zentel As Byte)

2

    Dim i3 As Integer

3

4

    Fortschritt.Value = 0

5

    Fortschritt.Maximum = zentel

6

    Dim i2 As Integer = zentel

7

    Dim i1 As Integer = 0

8

    While i1 <= i3

9

        Fortschritt.Value = i1

10

        System.Threading.Thread.Sleep(100)

11

        i1 = i1 + 1

12

        i3 = i2

13

    End While

14

End Sub

Grüße,
Verfechter von OpenSource!

Hallo icke,
interesannt das du den Code aus der Exe so nachvolziehen kannst
geschrieben hatte ich aber:

    Public Sub Warte(ByVal zentel As Byte)
        Fortschritt.Value = 0
        Fortschritt.Maximum = zentel
        For i = 0 To zentel
            Fortschritt.Value = i
            Threading.Thread.Sleep(100)
        Next
    End Sub

Ich weiß das die Rechtschreibung mist ist, und auch alles furchtbar 
denglisch ist. Aber das war mir für den Alpha-Status egal. Auserdem ist 
Rechtschreibung nicht meine Stärke.

LG Christof

schön das du vorankommst, SUPER!

Könnte man nicht die conf Datei von avrdude anstatt der dev hernehmen? 
Da müsste doch auch alles Nötige drinnen stehen, und dann bräuchte man 
die devs nicht selber machen.

Hehe, you definitely chose the wrong language to make it a closed source 
project.

@Olli
Die Daten möchte ich ungern Direkt verwenden, aber man könnte ein Tool 
erstellen, dass die .dev aus den conf erstellt. Ich brauche die .dev für 
verschiedene mechanismen in meinem Programm.

@cil ftw
If the programm runs proper, I think about translations.

@ Jay:
> man sollte nicht von der legasthenie eines menschen auf seine fähigkeit
> zum programmieren schließen!

das hast du nun falsch verstanden - ich meinte das eigentlich eher wegen 
der seltsam anmutenden schleife.

@ Christof:
Ich würde dir empfehlen das Projekt gleich Open Source zu machen - ich 
meine den kompletten Code zu extrahieren ist kein Problem, aber ich lade 
den hier nicht hoch, keine Sorge ;)
Zum einen mag ich Open Source und zum anderen besteht ja dann auch noch 
die Möglichkeit das Projekt auf andere Systeme zu portieren oder gleich 
woanders mit einzubauen.

Aber ansonsten schonmal super Arbeit von dir, hätte wirklich nicht 
gedacht, dass der FT232 so schnell ist.

@icke
Prinzipiel habe ich nichts gegen Open Source. Ich glaube aber, dass ein 
OpenSource-Ansatz gut nachvollziehbar und dokumentiert sein muss. Ich 
bezweifele stark, dass mein Code dies zur Zeit ist.
Ich glaube auch noch nicht daran, dass ich das Programm jemals so 
perfekt hinbekommen werde, dass ich jemals mit gutem gewissen Geld dafür 
verlangen könnte.
Wenn ich mal alle Grundelemente in dem Programm drinnen habe, und sich 
jemand findet, der bei der OpenSource-Aufbereitung hilft, kann ich dass 
gerne machen.
Es gibt nämlich noch eineiges zu tun, wo zu ich nicht wirklich Lust 
habe.
Da währen:
Sauber Spach-Übersetzungen
Saubere Dokumentation
DAU - Festigkeit
Saubere Modulisierung
und bestimmt noch einiges mehr.

Noch eine Anmerkung. Das Programm arbeitet mit dem Syncronen-BitBang des 
FT232R. In VB.net dauert die Übergabe eins Datenblocks (ca 60kB) mit der 
D2XX .net Schriebroutine sage und schreine 0,1 Sekunden zuzüglich der 
Ausführungsdauer der Datenübertragung. Der Trick liegt einfach darin, 
dass ich größt mögliche Kommandoblöcke generierer und später erst die 
rücklaufenden Daten auswerte. Dh. ich pushe blind Daten auf den AVR und 
werte z.B nach dem 10 Pages geschriben wurden, die Antworten aus.
Es ging noch etwas schneller, wenn dass Programm wärend der 0,1+ 
Sekunden nicht warten würde, söndern schon die nächsten Daten 
aufbereiten könnte.

LG Christof

@ Jay B.

O.K. ich dachte wegen dem Deutsch-Englisch kauderwelsch den ich 
geschriben hatte. Ich kam nicht auf die Idee, dass er die 
Programmiersprache meinte.

LG Christof

VORSICHT !!!!
Benutzt das Programm erstmal nicht !
Im Fusing ist noch irgendwo ein dicker Bock drin.
Ich habe schon 4 AVR zerfused.

Wer von euch hat denn ein High-Voltage Programmer ?

LG Christof

Joe G. schrieb:
> Christof Rieger schrieb:
>> Wer von euch hat denn ein High-Voltage Programmer ?

Ich auch.
STK500
Dragon

Gruß aus Heidelberg

Vielen Dank,
für eure Angebote.
Ich glaube ich den Fehler im Griff !
5 von 4 Tiny13 laufen wieder. Der Systemtakt war soweit runtergesetzt, 
dass mein Programmiertakt einfach zu schnell war.
Vieleicht kann ich morgen eine neue Testversion einstellen.

LG Christof

Hallo,
wie versprochen das Update.
User-Fendly-Fusing ist nun auch drin.
Fehlt nur noch die Programmierung der Devs Flash > 128 MB
z.Z nur die Definitionen für
Tiny13 und
Mega32 enthalten.

Viel spass beim Testen.

Bitte nicht Fluchen - ist immer noch Alpha-Stadium - Keine Haftung für 
zerschossene Devs ;-)

LG Christof

PS. Vieleicht schaffe ich die Woche noch die Dev's für den Mega8 und den 
Tiny2323

@ Christian R.

Mit der aktuellen H-Versionen des FT232 würde es nur schneller gehen, 
wenn dieser das ISP-Protokoll unterstützt.
Das Problem ist nicht die Hardwaregeschwindigkeit des FT232R !

Um ein Kommando im ISP zu übertragen muss ich mindestens 64 Bytes 
senden.
Für jedes Bit ein Byte und das mal 2 wegen SCK mal 0 und mal 1.

Das Problem ist der Aufruf des Schreibefehls. Beim Geschwindigkeits 
messen muste ich feststellen, dass der Befehl einen Sockelwert von fast 
0,1 Sekunden benötigt um eine Datenblock an die USB-Schnitstelle zu 
übergeben. Dazu kommt, dass der Befehl die Programmausführung anhällt 
bis alle Daten "rausgebangt" wurden. Über den Daumen ergibt sich dann
0,1s + Bytes /(8*Baubrate)
Ich befürchte, dass das bei der H-Version nicht anders sein wird, da 
hirfür die Systemarchitektur und der D2XX-Treiber verantwortlich ist.
Das bedeutet, sendest du jedes Kommando einzeln, brauchst du für 10kB 
ca. 1000 Sekunden + 1000 Sekunden Veryfy. Durch das Bilden von langen 
Kommandofolgen komme ich auf 7 Sekunden incl. Verify.

LG Christof

@ Matthias K.

'Weiter könnte man das Projekt auch um PDI für die XMega erwitern.'

Ich habe mir die Protokolle für den PDI und den XMega noch nicht 
angesehen.
Das klappt nur Vernünftig wenn diese Protokolle wie beim AVR-8 kein 
Handshaking benötigen. Sobald mich das Protokoll zwingt z.B. ein 
Busy-Satus abzufragen, ist das Thema geplatzt.
Beim AVR-8 genügt es Mindestwartezeiten einzuhalten. Busy muss dann 
nicht geprüft werden.

LG Christof Rieger

Christof Rieger schrieb:
> Das klappt nur Vernünftig wenn diese Protokolle wie beim AVR-8 kein
> Handshaking benötigen. Sobald mich das Protokoll zwingt z.B. ein
> Busy-Satus abzufragen, ist das Thema geplatzt.

Warum ist das abfragen vom Busy-Status ein Problem?

Gruß aus Heidelberg

P.S.
es ist -8° warm.

@Umpa Lumpa
Weil mich jede Abfrage eines Busystatus mindestens 0,1 Sekunde kostet 
und damit alles wieder sehr langsam wird.

LG Christof Rieger

Aha, danke für die Antwort.

Gruß

Neues Update:

neue Devs:
ATTiny 2313
ATMega 8

Bug-Fixes:

- Vermutung, dass beim Öffnen einer Flash-Datei mehr Daten gelesen 
werden als vorhanden sind hat sich wiederlegt. Lesen erfolgt korrekt.
- Fehler bei der Änderung der FT232R-Beschreibung beseitgt.
- Nicht Finden der Projektdaten bei der 
Embended-One-Click-Programmierung beseitigt.
- Beim Fehlerstop in der Embended-One-Click-Programmierung dem Zustand 
entsprechende Buttons freigegeben.
- Das Rückschreiben der Fuses in der Embended-One-Click-Programmierung 
berichtigt.
- Fehler beim Erase-Commando beseitigt

!ACHTUNG! wer die Embended-One-Click-Programmierung schon mal benutzt 
hatte bitte unbedingt beim ersten mal mit force Settings aufrufen. Die 
.fuses -Datai hat sich in der Struktur geändert.

Dann habe ich noch einen seltsamen Effekt.
Habe ich die CKDIV8 - Fuse nicht gesetzt, so kann ich mit der maximalen 
Programiergeschwindigkeit fahren (entspricht einen eingestellten 
CPU-Takt von 6000kHz, schneller kann der FT232R nicht.) Klappt 
einwandfrei. Aktiviere ich nun die CKDIV8 - Fuse so sollte eine 
Programierung mit 700kHz möglich sein. Geht aber nicht ich muss auf 
200kHz runter.
Hat da jemand eine Idee woran das liegt ?

LG Christof Rieger

Hi,

die Taktrate des AVR muß mindestens 4* die Rate des ISP sein.

Gruß Wolfi

@ Wolfgang
Jo, weiß ich
Damit proportional zum Dev-Takt.
Einstellung 6000khz (>1,5Mhz ISP) bei 8Mhz Devtakt funzt. Beides durch 8
ergibt 750kHz bei 1MHz Devtakt.
Eingestellt habe ich 700kHz und es geht nicht.
Erst bei 250kHz läuft es wieder.

LG Christof

So,
ich habe mal auf www.r-tron.de unter Projekte -> USB-ISP begonnen eine 
Beschriebung zu dem Programmer zu erstellen.

LG Christof

PS.: Hat ihn schon jemand mal testen können ?

Neuer Beitrag zur Begleitung der Betaphase

Beitrag "AVR FTDI ISP-Prog (AVR-8 Programmersoftware für den FT232R)"

LG Christof