Usb pic programmer trager met FTDI chip

lage snelhied ftdi chip?

Op 3 april 2008 21:35:27 schreef Rikkepic:
Heeft iemand een idee waar het aan zou kunnen liggen?

1.11 is erg oud, upgrade naar de nieuwste firmware. Ik weet niet in welke versie, maar ergens heb ik iets ingebouwd dat wat rekening houd met USB latency.

Zelf heb ik weining (zeg < 20%) verschil tussen USB-serieel en direct serieel, maar dat kan aan allerlei dingen liggen
- PC software (ik gebruik natuurlijk xwisp)
- soort converter en de driver
- snelheid van je PC (USB is CPU intensiever dan direct)
- belasting van je USB bus

Wat wij bij het uitlezen van disks via USB merken is dat er maar 1000 "heen-en-weer" mogelijkheden per seconde zijn.

Dus als je met een HD per keer om 512 bytes vraagt haal je dus precies 500 kbytes per seconde. Doe je grotere blokken halen we wel 20 of 30 Mb per seconde.

Hier zou dat ook kunnen meespelen. Als het protocol zo is dat je iedere keer op een antwoord moet wachten...

Heb je je bautrate gecontroleerd?

hallo,

ik heb de driver en het programma van FDTI chip gedownload, en in het programma (Mprog) zie ik nergens dat ik de baudrate in kan stellen. Het is dezelde chip als in de converter. Ik denk dat het idd iets met de baudrate te maken heeft. Maar stel je deze niet in op de VCP driver? (virtual com port)
In bumblebee kun je m namelijk instellen, maar hij blijft er evenlang over doen. Staat die baudrate in de eeprom?

Gr. Rik

Op 3 april 2008 21:35:27 schreef Rikkepic:
hallo mensen,

Ik heb de wis628 programmer nagebouwd op een breadbord, en nu heb ik de feitelijke programmer ervan aan een FTDI232 en een digitus USB->serieel converter met MAX232 ertussen.

Dit begrijp ik niet. Als je van USB naar serieel gaat heb je daarna seriel met 5V logische niveau.

De max232 is om van 0 en 5V naar +-12 te converteren.

Dus wat die die max232 achter de USB-serieel converter?

Op 4 april 2008 23:54:33 schreef Rikkepic:
Maar stel je deze niet in op de VCP driver? (virtual com port)
In bumblebee kun je m namelijk instellen, maar hij blijft er evenlang over doen.

De bauderate wordt inderdaad door de applicatie insgeteld. Probeer het eens met xwisp?

De FTDI232 maakt een vistuel compoort aan in windows meestal COM5 ofzo. Deze compoort kan je netzo instellen als een normale compoort.(ik geloof dat hij zelfds sneller is)

@benleentje:

je hebt me verkeerd begrepen. achter de FT232 zit geen MAX232, maar achter de usb serieel converter. in deze converter zit een max232, en ik moet dus weer terug naar TTL. Met converter bedoel ik zo'n ding die je bij de PC-zaak haalt.

@wouter: ik zal het deze week eens met x-wisp proberen.

Iemand die ik ken dacht dat het aan het breadbord lag. Usb is niet goed op breadbord zei hij. Kan dat een mogelijke oorzaak zijn?

Gr. Rik

Op 6 april 2008 11:39:36 schreef Rikkepic:
Iemand die ik ken dacht dat het aan het breadbord lag. Usb is niet goed op breadbord zei hij. Kan dat een mogelijke oorzaak zijn?

Dat lijkt me sterk, met een beetje vorozichtigheid is USB (op de laagste snelheid) op een solderless breadboard nog wel te doen.

Maar als ik je goed begrijp heb je een usb-serieel converter, en daarna een MAX232 op je breadboard? Dan heb je toch geen USB op je breadboard?

hallo,

het is al een tijdje geleden, eindelijk weer tijd voor de programmer. Nog steeds zelfde probleem.

even nogmaals de uitleg:
Ik probeer dus met een usb chip mijn converter van de PC na te bootsen. Het is het blauwe ding onderaan de afbeelding. De converter gebruikte ik eerst icm de gewone wisp 628, omdat ik geen seriele poort op mijn laptop heb. Nu probeer ik dus de PIC die op de wisp zit, rechtstreeks de signalen te geven van een usb chip, zodat het een USBwisp wordt, en dat ik de converter niet meer nodig heb.

Na een test met het erin laden blijkt dat de FT chip (veel) slomer is dan dat ik het op de normale manier doe.

Als ik de gewone PCconverter gebruik:
Na het varieren van de baudrate blijkt dat het ophogen van de baudrate na 38400 geen wezenlijk verschil in tijd is. bij een baud van 19200 en 9600 is de wisp slomer.

Als ik mijn converter gebruik, uiteraard zelfde programma:
van tevoren wordt de tijd geschat op 7:23 sec, wat gewoon echt niet meer leuk is als je wilt programmeren. Ik ga er niet op wachten, dat duurt me te lang

Ik heb nu echt geen idee waar het aan moet liggen.
iemand een oplossing?

Gr. rik

Op 23 mei 2008 14:05:20 schreef Rikkepic:
Ik heb nu echt geen idee waar het aan moet liggen.
iemand een oplossing?

Welke Wisp firmware versie en welke host software gebruik je? Ergens in de onwtikkeling van de spullen heb ik het protocol wat veranderd (blokken sturen ipv character echo) om het wat 'usb-vriendelijker' te maken. Het lijkt er op dat jij oude firmware en/of oude host software gebruikt.

hoi wouter,

wat jij noemt, kan kloppen. Maar:

waarom werkt de FT232 van mij niet goed, en de converter wel?
DAT is mijn probleem. in die converter zit exact hetzelfde chipje. dus het ligt aan het chipje, en niet aan de software. Al zal deze uiteraard wel de boel versneller natuurlijk. Toch zal ik dan weer een verschil blijven houden in programeertijd met de PC converter, als ik de software/firmware update. Bovendien heb ik op het moment geen 648 liggen, dus dat zou ook even duren. Ik doe dus denk ik iets fout met de instelling van de chip ofso...

Gr. Rik

De commercieel verkrijgbaare USB-seriele poorten zijn bijna allemaal PL2303, en niet FT232's... De FT232 is makkelijk voor hobbyisten te gebruiken, kennelijk is in de taiwan-wereld de PL2303 populairder (waarschijnlijk goedkoper).

Dus: Zit er echt een FT232 chip in je seriele USB converter?

Wat gebeurt er als je de baudrate instelt op je eigen setje? Staat ie niet gewoon belachelijk laag? Doet de software automatische baudrate detectie? Knap!

rew, volgens mij heb je het antwoord gevonden
als ik mijn convertor in de pc steek, komt er in windows device manager prolific te staan. dat is inderdaad de producent van de PL2303 (zegt google)
maar betekend dat dan dat de FT232R trager is dan de PL2303, of heb ik een instelling verkeerd.

waar zou ik de PL2303 kunnen kopen?

Gr. Rik

Ik zal vanavond ook eens mijn FT chip aan de Wisp hangen, eens kijken wat er gebeurt.
Dus vanavond heb je antwoord!

ok graag.
zou je dan eens Deze hexfile in een pic willen laden. als het even kan een PIC18F4620, of PIC18F4550

met de PL2303 duurt het bij mij 46 seconden. Met de FT232R maarliefst 7:23
graag wil ik weten hoelang het bij jou duurt.

bedankt alvast.

Gr. Rik

[Bericht gewijzigd door Rikkepic op vrijdag 23 mei 2008 17:25:11 (23%)

Weet je wel zeker dat je de goede driver gebruikt voor de FDTI ?
Je kan die driver nog wel tunen, maar dat heb ik alleen gedaan omdat ik op 500K aan het kletsen was.

Persoonlijk zou ik niet beginnen aan het gebruik van de PL2303. Het zal allicht iets zijn wat op te lossen is. Maar je weet nu in ieder geval EEN verschil.

In princiepe is de USB zoveel sneller dan een 38k4 seriele link dat alles wat ook 1mpbs aankan echt niet de hoofd-vertraging kan zijn.

Mogelijk is het zo dat je een slechte USB poort hebt. Of dat er bytes verkeerd overkomen naar je FTDI. Heb je die goed ontstoord? Voed je de boel uit de USB?

Als er een goede ecc check op het programmer protocol zit, werkt het wel, maar langzaam als 90% van de pakketjes verminkt worden....

Op 23 mei 2008 17:41:12 schreef rew:
In princiepe is de USB zoveel sneller dan een 38k4 seriele link dat alles wat ook 1mpbs aankan echt niet de hoofd-vertraging kan zijn.

Het probleem met USB is dat door de architectuur maar een beperkt aantal calls (pakketjes) per seconde kan versturen. Als je per byte een i/o transfer opzet dan haal de je 9k6 niet eens. Dit noem je zelf ook al.
Er is het een en ander te tunen in de driver maar ik gok erop dat er een verkeerde driver gebruikt wordt.

via ftdi bitbangen (wat een wisp doet denk ik) is verschrikkelijk traag. De baudrate veranderen heeft zal weinig veranderen. Telkens je een pin van de ftdi van toestand wil veranderen maakt de driver een nieuw usb pakket aan en dat heeft een latency van default 16ms geloof ik. Aangezien je bij het bitbangen per bit 3 wijzigingen hebt (klok hoog, klok laag, data bit setten of resetten) gaat dat dus niet echt snel.

Wat de boel iets sneller maakt is die latency op 2ms zetten (dat is het minimum).

Wat ook enorm helpt is een usb2 hub tussen de computer en de ftdi chip steken. Dan gaat het gemakkelijk 10x zo snel. (maar nog altijd trager dan een echte seriele poort gebruiken). Een goede uitleg heb ik hier niet voor, maar ik vermoed dat de computer de verschillende pakketjes in één keer doorstuurt naar de usb2 hub omdat deze op een hogere snelheid werkt.

Wil je zeer snel programmeren met de ftdi chips, dan zal je moeten programmeren. Ftdi heeft namelijk een synchrone mode waarbij je de chip niet als seriële poort gebruikt maar als 8bit digitale IO. Op die manier kan je de snelheid van een conventionele seriele programmer overtreffen. Ik heb op die manier een at89s4051 en een atmega168 programmer gemaakt die enorm snel is.

krabat heb je de ballen verstand niet van de materie zeg dan nix(ja sorry maar je verhaal gaat liniea directa de verkeerde kant op)

de wisp is een intelligente programmer en heeft dus alleen een seriepoort nodig voor communicatie op rs232 nivo en protocol

Zoals beloofd heb ik het even uitgeprobeerd.
Gebruikt: Wisp628 V1.23 met XWISP.EXE V1.20
voor USB een FTDI FT232RL chip

Lezen van een 18F4550
Serieel: 1 minuut en 16 seconden
USB: 2 minuten en 13 seconden

Schrijven van jouw hex bestand naar een 18F4550
Serieel: 17 seconden
USB: 55 seconden

Waneer ik Bumblebee gebruik is het via USB nog veel trager.

Op 23 mei 2008 22:49:37 schreef marcob:
Gebruikt: Wisp628 V1.23 met XWISP.EXE V1.20
Lezen van een 18F4550
Serieel: 1 minuut en 16 seconden

d:\wouter>x time get time
XWisp 2.01, command line mode
Fri May 23 23:47:18 2008
hardware: Wisp628 1.27 (fast) (wisp648 firmware)
target: 18f4550, device code 1200 revision bits 02
Fri May 23 23:47:46 2008 [28.037]
OK

(x is een alias voor python xwisp.py $$)

misschien toch maar de firmware en/of xwisp updaten?

Ik heb nog een usb-serieel converters op m'n nieuwe (Vista) PC geinstalleerd, dus geen tijd voor UBS. Op m'n vorige PC moest ik wel, daar werkte de seriele poort onbetrouwbaar.