Hallo Forengemeinde ! Nach langer Zeit melde ich mich mal wieder. Ich möchte schon mal meine Freude mit euch teilen. Ich habe meine ersten erfolgreichen Tests mit meinem AVR-Programmer als FT232R Standalone Programmer. Beschreibung: Benötigt nur eine FT232R mit der üblichen Randbeschaltung Benötigt keine Firmware Verwendbar für fast alle 8-Bit AVR Plugt sich sebstständig in AVR-Studio5 Schreibt ca. 8kByte in ca. 10 Sekunden mit Verify Freie Konfiguration der RS232-Leitungen(FT232R) auf den AVR-ISP Bei Projekten mit FT232R und AVR ist somit echtes ISP via USB ohne Bootloader möglich. Kann Tackt (6/12Mhz) und geschaltete Versorgungsspannung bereitstellen. Damit Out-Circuit-Programming möglich. Devicebeschreibung in einzelnen Datein (Neue Dev möglich ohne neue Software) Kann beim FT232R im EEPROM die Beschreibung und Seriennummer ändern. Doppel-Fusing am AVR möglich. (Fusing zur Programmierung und zum Normalbetrieb). Es können mehrere FT232R am PC angeschlossen sein. Die Beschreibung des FT muss wärend der Programmierung exclusiv sein. One Klick Programmierung nach erster Programmierung. Entwickelt auf Windows7 unter VB.NET Ich schau mal, dass ich ein Video mache und es bei YouTube einstelle. Ein paar Dinge muss ich noch Debugen bevor ich das Programm rausgeben kann. LG Christof
Angehängte Dateien:
-
AVR_FTDI_ISP.jpg
110 KB
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
Angehängte Dateien:
-
ISP-Conf.jpg
63 KB -
FuseMap.jpg
60 KB -
AVR_FTDI.jpg
270 KB
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
Christof Rieger schrieb: > Ich denke, dass ich ab mitte nächster Woche Tester brauchen kann. Schöner Ansatz! Biete mich als Versuchskaninchen (Alphatier) an ;-)
Angehängte Dateien:
-
speed.jpg
95 KB
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
Hey Christof, also würde mich auch mal als Testperson zur Verfügung stellen. Bei bedarf würde ich auch gerne an dem Projekt mitwirken, .net programmiere ich in C#. Hast du das Projekt in VB oder c# realisiert? Wie oben schon angedeutet würde ich das ganze evtl erstmal als StandAlone zum laufen bringen und anschließen in AVRStudio integrieren. Weiter könnte man das Projekt auch um PDI für die XMega erwitern. Greetz
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.
hi, icke schrieb: >>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 ... man sollte nicht von der legasthenie eines menschen auf seine fähigkeit zum programmieren schließen! Christof Rieger schrieb: > @cil ftw > If the programm runs proper, I think about translations. er meinte, daß man bei deiner programmiersprache aus deiner exe den sourcecode auslesen kann ;-) insofern kannst du es sowieso gleich opensource machen... jay
@ 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
Was für AVR's? Ich hab ein STK600, du kannst mich gerne ein PN senden bzw. die AVR's senden. Gruß Martin
Die ganze Geschichte müsste dann ja mit den aktuellen H-Versionen des FT232 noch schneller gehen, oder?
Hallo Christof, könntest du dich mal bitter per PN an mich wenden? Danke!
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
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
@ 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
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.