PC ile seri port uzerinden haberlesen bir kartim var.
Kartin seri portunun hemen onune FT232 koyarak artik karti PC ile USB uzerinden haberlestiriyorum.
Kart uzerindeki islemci ve PC yazilimim, hantal sayilabilecek bir protokol kullanarak seri data iletisimi yapmakta, bu sayede gurultulu ortamlardan kaynaklanabilecek veri bozulmalarinin onune gecilmekte.
Projeyi win98 uzerinde gelistirirken USB kullanmiyor ve haberlesmeyi dogrudan PC uzerindeki UART cipinin registerleri uzerinden yurutuyordum.
Bu haliyle iletisim hantal protokola ragmen son derece hizli idi. Asla ve asla iletisimde yavaslik kesinti yasamiyordum.
Gel gelelim XP isletim sistemininde, sinirlamalardan dolayi artik PC ciplerinin registerlerine dogrudan ulasilamadigi icin seri portu
CreateComport, SetupComm, BuidCommState, SetCommState gibi dusuk seviyeli komutlar uzerinden halletmek zorunda kaldim.
Bu ise hatiri sayilir bir yazilim gecikmelerine neden oldu.
FT232 uzerinden 115200 baud ile haberlesiyorum. Ancak verilerin pespese gonderilmesi esnasinda anormal yavaslik var.
(Benzetmek gerekirse, eskiden idrar sarrrr diye bosalirdi simdi prostatli birisinin isemesi gibi)
Iletisimi nasil hizlandiririm?
Sorunumun XP seri port kullanimi asamasindaki yogun isletim sistemi denetimlerinin neden oldugu gecikmeden kaynaklandigini bu nedenle PC tarafinda FT232 cipi ile haberlesmek icin seri port kullanmam gerekmemeli diye dusunuyorum.
FT232 nin RX, TX, LSR, MSR gibi registerlerine ulasmami saglayacak bir driver sanki sorunumu kokten cozuverecek gibi.
bu register larla hiç işin olmaz. sorunsuz haberleşiyor. zaten. yalnız formalitesine uymak gerekir.
Firma diyor ki :
FT çipten veriokumak için 2 yöngtem vardır.
1- Ya çipteki buffer dolacak
2- ya zaman aşımı oluşacak
çipteki buffer 60 bayt civarı. zaman aşımını ise sen 500 ms ayarlamışsan ( veya varsayılan hali ne ise artık)çipten "şebelek" stringi gönderdin diyelim. istediğinkadar hızlı gönder. bu string çok kısa olduğu için buffer dolmayacak ve zaman aşımı oluşana kadar bekleyecektir. ( 500ms ise okadar bekler)
Yukarıda anlattıklarımdirekkullanım için. ancak bu sanal com port da öncelikle direk sürücüden geçerek sanal comporta dönüştüğünden dolayı hantallık oluşmuştur.
Cihazdan sürekli veri göndermeyi deneyin. sorunsuz gelir.
Hakli olabilirsiniz. FT232 ye gecis tamamen USB ve XP zorunlulugundan dolayi oldu ve belki eski protokolu terketmem gerekecek.
Ancak soyle bir durum var.
PC - USB kalblosu - FT232 baglantisinda USB protokolu PC - FT232 arasinda hatasiz veri iletimini %100 garanti ediyor olsun. (Muhtemelen boyledir)
Fakat FT232 ile kendi islemcim arasindaki veri iletiminin %100 dogru oldugunu kimse garanti edemez.
Ilemcim bir onceki veriyi okumakta gecikebilir yenisi bir oncekinin ustune yazilabillir, ortam gurultusunden dolayi islemciye gelen yada islemciden giden bazi bitler konum degistirebilir vs.
RS232 ile dogrudan haberlesirken veri kontrolunu iki uc tarafinda yani PC ve islemci tarafinda yapip tamam aldigin veri dogru bunu kullan yada yanlis olmuş aman kullanma sana 32bit veriyi tekrar yollayacagim seklinde protokol kullaniyordum.
FT232 ye geciste her seyi dll lere birakirsam aldigim verinin dogrumu yanlismi oldugunu nasil kontrol edecegim?
cehecksum gibi bazı bilgiler gerekecek.
Donduk dolastik gene ayni yere geldik. Yani protokol olusturmak gerekecek.
Cipi monte edip veri alip verdigimi gorunce FT232 ye hic kafa yormadim dokumanlarini okumadim. Ancak geldigim noktada FT232 uzerine kafa yormam gerekecek.
Peki sunu sorayim;
En azindan FT232 icindeki buffer verilerle tamamen doldugunda, buffer bosalirken gonder bekle gonder bekle gibi bir fren mekanizmasi olusturabilirmiyiz. Yoksa buffer doldugunda veriler hurra tx pinine hucum mu ediyor?
(Su anki mevcut uygulamam da PC tarafindaki seri port bufferini sadece 1 byte uzunluga set ettim)
edemezsin olmaz öyle şey. buffer çipin içinde . ama yazılımdan ayarladıysan gerçekten ayarlanmış olmaz. buffer den sonra buffer ayarlamış olursun. örnek 5 saniye timeout ve 500kb buffer yada dediğin gibi 1 bayt buffer ayarlanabilir. bunlar DLLden gelen verileri okumak içindir. gerçekte ise çipten 64 baytmı ne geliyor. bunlardan 2 si start stop gibi bitlermiş.
1 bayt ayarladıysan senin çipten gelen bu bir baytı okuyabilmek için en az timeout kadar beklemen gerekir. o da galiba en düşük 1ms
çipin içinde ne işin oluyor onu anlamadım. okuyacaksan okuyorsun. yazacaksan yazıyorsun. bu işlemlerde bir sıkıntı yok.
Bufferin dolması ve boşalması bizi ilgilendirmiyor. (çift buffer yapmıştır. biri dolarken diğeri boşalıyordur. ne olduğunu anlamamız gerekmiyor.)7
gönder diyorsun gidiyor. oku diyorsun okuyor. hatta okuma yazma durumunu algılamak için rs485 işlemleri için ek bir uç vermiş. aynı anda okuma yazma olmaması için
Galiba bir de çip içinde veri gelip birikmişse başka bir uç 1 oluyor. ozaman okumaya başlıyorsun. (en falza çipin hafızası kadar okursun 62 bayt olsa gerek) bunlar bitince program veri pompalamaya devam etmesi gerekir.
Varmis varmis.
Xon/Xoff yada donanimsal el sikisma ozelligi varmis. Is basa dustu. Dokumanina bakiyorum artik.
evet elsıkışma kullanabilirsin ayrıca checksum tarzı bir yöntemde işini görecektir. tabi her halukarda yeniden bir protokol hazırlamak gerekir.
benim başka sorularım olacak.
1.ft232 tampon belleği dolduğunda veya 1bayt aldığında pc tarafında nasıl interrupt yaptırabilirim?
2.ft232 nin usb den çıkarıldığını bir timer nesnesi kullanmadan veya sürekli kontrol etmeden nasıl algılayabilirim?
Sorularinin cevabini bilmiyorum fakat;
Seri portu kullanan komponentlerden kullandigin takdirde komponent sana bu tur hizmetleri (int vs) saglayacak fonksiyonlari barindiracaktir.
Gelelim benim yeni sorunuma.
FT232 dokumaninda MPROG diye bir utlity programdan sozediliyor ve bu programin sitelerinde yeraldigini yazmislar.
Bir zamanlar hatirliyorum bu programi calistirdigimizda E2 icindeki bazi verileri degistirebiliyorduk.
Simdi adamlarin sitelerinin altini ustune getirdim bir turlu bu programi bulamiyorum.
Sozkonusu programin linkini yada kendisini gonderebilirmisiniz?
Gozumden kacmis.
MPROG linki http://www.ftdichip.com/Resources/Utilities.htm
şu günlerde bende ft232 nin ocağına düştüğümden, dün akşam al gülüm ver gülüm şeklinde yaklaşık 16K lık ufak bir data transferini usb üzerinden bir mikroya aktardım. her byte içinde mikrodan bunu aldım diğerine geç şeklinde bir yol izledim. sonuç hüsran. 16K yı mikroya 4.3 dakikada yollayabildim malesef.
iletişim hızı 4800bit/s idi. bunu 230400 yaparak tekrar denedim. hızın 48 katına çıkmasına karşın 16K lık veriyi yollama süresi pekde tatminkar şekilde azalmadı.
bunun sebebinin ft232 yi 1 byte al 1 byte ok bekle şeklinde kullanılmasından kaynaklandığını düşünüyorum. yani ft232 programda ayarlanan hızda veriyi aktarıyor fakat alma ve verme arasında geçiş yaparken gecikiyor. bunu da bu akşam deneyip sonucu yarın yazarım.
tüm bunları neden anlattım?
sanıyorumki z arkadaşında protokolden kaynaklanan bir sorunun var...
ft232 , işini gayet iyi yapıyor. suç sizde :)
Mikro, ft232 'den gelen verileri usulunce alıp değerlendirememiş, eli ayağı dolaşmış...
başka bir yerde tekrar gelen datanın tümünü kontrol ediyorum. eli ayağı dolaşsa anında anlarım :)
hız 230400 bit/ saniye ise bunu 10a bölelim (startbit, stop bit, ve data 8bit)
FT232 saniyede 23040 bayt göndermiş oluyor. denetleyici bu veriyi aynı hızda alıp bakabiliyor mu?
Önce hiç bir kontrol yapamadan gelen verileri alıp depolayalım. sonra kontrol edelim.
Ancak pcden gönderirken de hata yapmış olabilirsiniz. nereden nasıl gönderiyoruz?
Eski protokolde;
115200 baud ile haberlesen islemci her aldigi veriyi gerisin geriye PC ye yolluyor PC de bu veriyi kullanip kullanmamasini soyluyordu. Islemci de bir yandan kendine gelen verinin hatali olup olmadigini mevcut protokol dahilinde anlamaya calisiyordu.
Simdi dedigine benzer bir yapi kurdum.
Blok data transferi ardindan kontrollar yapiliyor.
Yeni protokol daha cok eksik ve hatali veri kacma ihtimali var. Uzerinde calismam gerekecek.
https://www.picproje.org/main/modules.php?name=Forums&file=viewtopic&p=157068#157068
wsxwsx
max 6Mbit/s hızında sağlam bir uart modülü var aletin üzerinde fakat ben bu denemeleri yaparken işim garanti olsun diye hızı dahada düşürüp 4800 kullandım.
z
denemelerimi yaptım. sonuç tahmin ettiğim gibi. ft232 alma ve verme arasındaki geçişlerden dolayı gecikiyor. 16K veri aktarımı için 64byte lık blok transferler yaptığımda 4.3 dakikalık aktarım süresini, iletişim hızı 4800baud olmasına rağmen yaklaşık 40 saniyeye indirdim. tabi bende kullandığım protokolü biraz geliştirmeliyim. haliyle daha çok eksiği var.
ama şunu öğrendim, ft232 ile yeni haşırneşir olan arkadaşlar için belirtmemde fayda var, bu alet ile blok data transferi yaptırdığınızda sisteminiz yukarıda anlattığım gibi ciddi bir biçimde hızlanıyor aksi halde alma ve verme arasındaki anahtarmadan kaynaklanan zaman kaybından dolayı sistem hantal kalıyor.
Evet aynen dediginiz gibi. Blok data transferi yapilirsa sorun kalmiyor. Haliyle eskiden yazilmis protokollerin bu durumda degismesi gerekiyor.
Sorun time out suresi dolmadan yada buffer verilerle dolmadan transferin gerceklesmemesi.
Time out suresi 1ms nin altina inmedigi surece baud rate in 9600 yada 115200 olmasinin hic bir onemi olmuyor.
Ben sorunumu simdilik cozdum. Yukarida verdigim linkin linkindeki videoda mekanizma hizli ardisil hareketler yapiyor. Eskiden bu hareketler kesik kesikti. Yani Ft232 ile al ver mantigiyla olusturulmus protokolde elektronik, mekanikten cok daha yavas kaliyordu.
z
linkteki video yu izlerken aklıma takıldı. makine işlemini yaparken daha doğrusu sürekli pc ile haberleşirken, pc tarafında yazdığınız arayüz üzerinde herhangi bir işlem yapabiliyormusunuz veya şöyle sorayım eğer arayüzde bir menu çubuğu varsa bu menu içerisinde gezebiliyormusunuz? onu merak ediyorum. çünki benim yazdığım arayüz programında 64byte lık blok tranferler tamamlanana kadar programı simge durumunda bile küçültemiyorum. bu sorunla başa çıkmanın bir yolu var mıdır ve bu durum sizdede aynı mıdır?
Alıntı yapılan: "z"Time out suresi 1ms nin altina inmedigi surece baud rate in 9600 yada 115200 olmasinin hic bir onemi olmuyor.
1ns olsa işinizi görecek mi? USB teknolojisinden daha hızlı bir işlem mi yapmak istiyorsunuz?
çözüm:
timeout bittiğinde gitmesi gereken veri, hazırlanacak ve süre bitmeden pompalanacak. o gönderilirken diğer paket veri hazır olacak..
timeout 50ms olsa bile bunu yapabilirsiniz. yeter ki mikrodenetleyici bu kadar süre içinde gönderilecek veriyi işleyebilsin. böylece kesintisiz ileyişim sağlanacak.
Alıntı yapılan: "z"
yazdığım arayüz programında 64byte lık blok tranferler tamamlanana kadar programı simge durumunda bile küçültemiyorum. bu sorunla başa çıkmanın bir yolu var mıdır ve bu durum sizdede aynı mıdır?
transfer için ayrı bir thread gerekir . Arka planda CPU kullanımınız thread sayesinde %90 bile olabilir. ama sizin programınız donmaz hiç
http://www.diyezon.com/?p=58
wsxwsx
thread olayını öğrettiğiniz iyi oldu bakayım C de nasıl kullanılıyor.
c# içinde backgroundworker isminde komponent var işe yarayabilir ( v.studio 2008)
CreateThread ile başım belada şuan...
Alıntı yapılan: "OptimusPrime"z
linkteki video yu izlerken aklıma takıldı. makine işlemini yaparken daha doğrusu sürekli pc ile haberleşirken, pc tarafında yazdığınız arayüz üzerinde herhangi bir işlem yapabiliyormusunuz veya şöyle sorayım eğer arayüzde bir menu çubuğu varsa bu menu içerisinde gezebiliyormusunuz? onu merak ediyorum. çünki benim yazdığım arayüz programında 64byte lık blok tranferler tamamlanana kadar programı simge durumunda bile küçültemiyorum. bu sorunla başa çıkmanın bir yolu var mıdır ve bu durum sizdede aynı mıdır?
Benim uygulamamda mekanizma tarafinda mekanik hareket bitmeden islemcinin yeni veriyle beslenme zorunlulugu var. Bunu islemcide FIFO tarzi bir buffer ile astim.
Dolayisi le PC tarafindaki gonderme islemi kesintiye ugrasa bile FIFO bufferdaki veriler bu kesintileri mekanige yansitmiyor.
Bahsettiginiz gibi sistem transfer halindeyken bir menu uzerine gelirsem ve FIFO verileri biterse mekanizma beklemeye geciyor.
Bunu sistemin isleyisi acisindan bir aksaklik olarak gormuyorum.
Alıntı yapılan: "wsxwsx"Alıntı yapılan: "z"Time out suresi 1ms nin altina inmedigi surece baud rate in 9600 yada 115200 olmasinin hic bir onemi olmuyor.
1ns olsa işinizi görecek mi? USB teknolojisinden daha hızlı bir işlem mi yapmak istiyorsunuz?
Gereksiz bir soru olmuş.
Her gonderilen 1 byte veriye karsilik 1 byte veri beklenen protokollerde iletisim, 1 byte verinin alinmasi ardindan devam edecekse ve bu projede FT232 kullanilmissa, FT232nin time out suresi de T ise;
Gonderilen tek bir verinin karsiya ulasma suresi yaklasik T olacaktir.
Bir byte verinin B baud hizinda gonderilmesi durumunda verinin portu terketme suresi (1St,8D,1Stp,) 10/B olacagindan
T>10/B oldugu serece B nin buyuk onemi kalmiyor.
Cunku B yeterince buyukse 10/B degeri, T nin yaninda kucuk kaliyor ve T+10/B yaklasik T oluyor.
Demek istedigim bundan ibaret. Buradaki engel B değil T, yani 1ms.
Bu da verilerin al gulum ver gulum mantiginda değil de blok gonder blok al mantiginda iletilmesini zorunlu kiliyor.
FT232 normal calismasini surdururken usb kabloyu sokmek, usb interface'e bagli islemcinin elektrigini kesmek gibi siradisi durumlar olusturuyorum.
Bu durumlar olustuktan sonra pogrami yeni bastan calistirsam bile bazen initialize asamasinda FT232 ye ulasilmak istendiginde D2XX.dll deki fonksiyonlar invalid handle uyarisi le geri donuyor.
Boyle bir durumdan ancak USB kablosunu sokup tekrar takmak suretiyle kurtuluyorum.
Kabloyu sokup takmadan bu isi komut bazinda yapamazmiyim?
usb aygıt resetlendiğinde enumeration işleminin bitmesini beklemek gerekiyor. aksi halde geçersiz handle numasıyla geri dönüyor.
tabi usb aygıtın başına bişey gelmesi durumunda pc niz tıkanıyor değil mi. benim başımda böyle bir sorun varda o yüzden soruyorum. :)
PC tikanmiyor ama ne kadar ugrasirsam ugrasiyim kabloyu sokup takmadan sorunu duzeltemiyorum.
Bu soruna cozum bulan varmi?
Sorunumu tekrar yazayim.
USB kablosunu taktik ve FT232 windows tarafindan bulunmus olsun.
PC deki programimizi calistiralim. (FT232 kullanan kullanici program)
FT232 nin arkasindaki islemcimizin elektrigini keselim bir sure bekleyelim ve tekrar verelim.
PC deki programdan cikalim ve tekrar calistiralim.
Program FT232 ye erisemiyor.
Ilkel cozumum:
USB kabloyu sok
Bekle (windows sesli uyari vererek durumu algiliyor)
USB kabloyu geri tak.
Bekle (windows sesli uyari vererek durumu algiliyor)
Programimizi calistiralim.
Artik FT232 ile sorunsuz haberlesilebiliyor.
Buradaki kablo sok tak olayina gerek kalmayacak cozum ariyorum.
Not: Normalde FT232 USB uzerinden besleniyor. Arkadaki islemci ise kendi guc kaynagindan besleniyor.
Islemci gerilimini kesince FT232 cikislarindaki lojik sinyaller islemciyi beslemeye calisiyor. Bu da FT232 tarafinda soruna neden oluyor.
Muhtemelen PC USB besleme unitesi artan besleme akimindan dolayi iceride bir seyler yapiyor. (USB 5v hattindaki LED isiginda elektrik kesintisi gibi bir durum gozlemiyorum)
Hos bir durum olmasa da simdilik FT232 yi islemcinin beslemesinden beslemeyi dusunmuyorum.
Bu besleme isini duzeltsem bile yukaridaki senaryo geregi bloke olan usb iletisimi kabloyu sokup takmadan yeniden baslatacak yontemi ariyorum.
ft232 reset ucu var. ordan resetliyorsun
benin cihazım usb üzerinden beslendiğinden hiç denemedim ama çok ilginç bir sorun. acaba ilk başlangıçta mikronun beslemesini vermeseniz yinede aynı sorunu çıkartırmı?
akım yeterliyse izolasyon gerekmiyorsa hepsi usbden beslenir.
Ilk basta mikronun beslemesini vermezsem gene sorun cikiyor.
Reset butonu tarzinda cozum cok da isime gelmiyor.
Tahmin edeceginiz gibi burda sorun besleme orjinli. Ancak bir baska sebeple benzer sekilde iletisim kesilirse durumu yazilimdan kurtarabilmek istiyorum.
Cozum PC tarafinda USB donanimlari kapat ve tekrar ac tarzinda bir sey olmali.
X gibi DLL den bir fonksiyonu cagirmak kadar basit cozum olmali.
reset butonla değil mikrodenetleyici ile yapılabilir
aşağıdaki uygulama ile komut satırından ft232 li çeviriciyi eject edebildim, ancak mount etmek hakkında herhangi bir bilgi yok. sitede uygulamanın c++ kaynak koduda var. oradan incelenip birşeyler yapılabilir.
http://www.withopf.com/tools/deveject/ (http://www.withopf.com/tools/deveject/)
ekleme: birde aşağıdaki site var, komut satırı aygıt yöneticisi...
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272)
ikinci ekleme: microsoft un sitesindeki "devcon" ile usb aygıtlarını aktif pasif yapabiliyorum, usb fare ve ft232 li çevirici bağlı. farenin ışığı sönüyor, aktif yapınca tekrar yanıyor. ft232 nin üzerindeki led sönmüyor ancak aygıt yöneticisinden aktif/pasif olduğunu görebiliyorum.
"devcon" delphi de "ShellExecute" ile kullanılabilir.
Alıntı yapılan: "z"
Cozum PC tarafinda USB donanimlari kapat ve tekrar ac tarzinda bir sey olmali.
tam hakim değilim ama anakartın ACPI driverları ile donanıma ya da irqlara tam erişim elde edilebilirmi?
Prototip kartimda ilk kez FT232RL kullanmis ve acemilikten kaynaklanan sorunlar yuzunden cipi calistirmak icin bayagi bir ugrasmistim.
Bu asamada cip calismayinca cipi konfigure eden bir programi da calistirmis ama bu programla cipe bir seyler yazdimmi hatirlayamiyorum.
Neyse sorunun cipin bir bacagini gnd yapmamamdan kaynaklandigini gordum ve ardindan programlarimi yazmis ve cipi sorunsuz kullanmistim.
Simdi pcb kartlarim basildi ve FT232RL yi monte ettim isletim sistemi cipi gordu tanidi.
Cipe USB tarafindan veri yolladigimda RS232 TX pininde herhangi bir aktivite goremiyorum. (Scopla izliyorum)
Fakat DTR ve RTS pinlerini PC tarafindan harekete gecirebiliyorum.
PCB de hata da yapmamisim.
Sorun hakkinda fikriniz varmi?
Sorun gene acemilikten kaynaklaniyormus. Cipin bir bacagi pcbye lehimlenmis gibi duruyormus ama gostermelikmis.
Lehimler yenilenince sistem calisti.
Bu çipin bazı bacakların yerleini değiştirebiliyoruz. Genel amaçlı IO pini de oluyor. Bağlayacağımız mikro denetleyici için clock üretebiliyoruz. çipten dışarıya 6,12,24,48 Mhz Clock çıkabiliyor .
Saygıda kusur etmeyin
ft232 d2xx dll de deadmantimeout fonksiyonu ne ise yariyor? RX,TX timeout dan ne farki var?
Bazen nedenini anlamadigim sekilde FT232RL yada D2xx dll rutinleri bir anda donup kaliyor?
Yazilimimdaki FT232 rutinlerim loop icinde veri bekliyor.
Buralarda dongude kaldigi dusuncesiyle breakpointler koydum. Ancak gordum ki takinti D2XX dll icinde olusuyor.
USB kablosunu soktugum anda dlle cagri yapilan noktada dll den geri donuyor. Bu da gosteriyorki dll icinde bir seyler dongue kaliyor.
dll icine mudahale edemeyecegime gore sorunun ne oldugunu anlamam mumkun değil.
Benzer sorun yasadinizmi cozum bulabildinizmi?
Elektriksel parazit nedeniyle oluşabilecek kilitlenme durumu varsa PWREN ucundan algılayıp mikro denetleyici ile çip resetlenir. Kilitlenme varsa bu pin 1 oluyor. O zaman resetten başka çare yok. Bu tip kilitlenme , şebekeye bir cihaz bağlandığında ortaya çıkıyordu. Normalde olmuyordu.
Hatta bazen cihaz aygıt yöneticisinde görünmesine rağmen aslında iletişim kesilmiş oluyordu. Bu durumu PWREN pininden anlayabiliyoruz. (pin ismini yanlış hatırlamadıysam)
Aslında kilitlenme varken USB kabloyu çıkarmakla çipi resetlemiş oluyorsunuz. sorun bu yüzden çözülmüş oluyor.
Bunun haricinde çıkan kilitlenme sorunu varsa DLL ilgili değildir diye düşünüyorum. Cihazdan sürekli bilgi geliyorsa ve bunu sürekli denetliyorsak yeterlidir. Arada sırada cihazın gerçekten bağlı olduğunu anlayabileceğimiz bir fonksiyon çağırılması gerek. DLL içindeki Devicecount gibi bir fonksiyon kullanılabilir.
Alıntı yapılan: "z"Bazen nedenini anlamadigim sekilde FT232RL yada D2xx dll rutinleri bir anda donup kaliyor?
Yazilimimdaki FT232 rutinlerim loop icinde veri bekliyor.
Buralarda dongude kaldigi dusuncesiyle breakpointler koydum. Ancak gordum ki takinti D2XX dll icinde olusuyor.
USB kablosunu soktugum anda dlle cagri yapilan noktada dll den geri donuyor. Bu da gosteriyorki dll icinde bir seyler dongue kaliyor.
dll icine mudahale edemeyecegime gore sorunun ne oldugunu anlamam mumkun değil.
Benzer sorun yasadinizmi cozum bulabildinizmi?
Farklı bir çözüm,
http://www.bisque.com/sc/forums/p/446/430.aspx#430