Svenska ElektronikForumet

Jag upptäckte att det finns en massa Python-drivers/libraries för FTDI-kretsarna. T.ex FT232R.

Några exempel:

PyUSB:
http://sourceforge.net/apps/trac/pyusb/
http://bleyer.org/pyusb/

Tyvärr stöds det än så länge bara av Windows,
men här har någon lyckats använda det till Linux också.

Sedan finns iofs även libUSB och OpenUSB.
Och PyFTDI - https://github.com/eblot/pyftdi



Det gjorde mig en smula fundersam.
Jag har använt dessa kretsar i tidigare projekt och med FTDI's drivrutiner för själva OS'et
så har man fått upp en vanlig COM/tty-port som man har kunnat använda som en sådan.

Så nu när jag använder Python och ser alla dessa API'n/libraries så undrar jag förstås varför de behövs.
Tillför de något extra?


Här hittade jag detta:

"FTDI has both their Virtual COM Port drivers, which create a serial COM port on your system representing the serial connection attached to their chip, and their D2XX direct communication libraries. You're going to want to work with the latter, which can be downloaded from their site for various platforms."

Vadå "You're going to want" ?
Varför kommer man vilja det? Det hade varit kul att få reda på...


Men jag antar att valet alltså handlar om "virtual COM port" eller "direct comunication".

Troligen stämmer det, så då hade jag egentligen inte behövt fråga,
men jag postar inlägget ändå. Det kanske finns någon annan som undrar samma sak någon gång.

Ft232R är ett väldigt kompetent chip, man kan i princip bitbanga ut vad som helst med det.. Men det kräver att du kör det i direct comunication mode, vill du bara ha en serieport är det bara att köra på med Virtual comport som vanligt. Och jag skulle tro/gissa att vcom mode är det de flesta använder...

Aha!


Hur är det med interruptstöd och FT232R?
Fungerar det i Windows XP om man kör med "virtuell com-port" i Python?
T.ex med TIOCMIWAIT och ioctl(), eller gärna något som fungerar i Windows också.

Annars får jag nog gå över till Linux för att programmera och testa resten av projektet.
Det är ändå där som det ska köras när det är klart, men det vore kul om det fungerade i båda världarna
utan några direkta modifieringar.



(Upptäckte just att om man använder pyserial så importeras det med "import serial". Inget "py" i början alltså.)


edit: Lägger till några av de sajter jag där jag letat idéer och svar:
http://pyserial.sourceforge.net/
Stackoverflow - Hardware interrupt for synchronous data acquisition
Stackoverflow - Python monitor serial port RS232 handshake signals
Stackoverflow - Full examples of using PySerial package
Varesano.net - Serial RS232 connections in Python


Det är inte nödvändigtvis så att interrupt är den enda lösningen.
Det jag främst är ute efter är en lösning som inte tar onödigt mycket tid av CPU'n.
(Det vore lite onödigt med tanke på att jag förväntar mig data in på serieporten max ett par gånger per dag
och då rör det rör sig om absolut max 50 alfanumeriska tecken som ska överföras per gång.
Det vore en sak om CPU'n aldrig behövde göra något annat, men i detta fall är det en server i ett lokalt nätverk.



En till edit:

Windows kör ju med COM1, COM2, osv och Linux med /dev/ttyS1, osv.

Kan man istället använda FTDI-kretsens String Descriptors (dvs t.ex namnet) istället?
Jag letar efter en lösning på det, men om någon vet på rak arm så..


En bit på vägen: Jag kan scanna portarna och se:
[('COM1', 'Kommunikationsport (COM1)', 'ACPI\\PNP0501\\1'), ('COM7', 'USB Serial
Port (COM7)', 'FTDIBUS\\VID_0403+PID_6001+AMX0US9GA\\0000')]

0403 och 6001 är Vendor ID respektive Produkt ID, så de ger inte så enormt mycket.
Däremot: "AMX0US9GA" är serienumret och det är unikt för just den här kretsen.
(Jag har själv stått för datan som ligger till grund för det.)

Så det går helt klart att använda för att hitta rätt namn på själva serieporten oavsett
vilka andra portar som finns och oavsett om man kör Windows eller Linux.


..
Och en stund senare ser det istället ut såhär:
Men det här med interrupt-stödet har jag fortfarande inget svar på.
Ingen annan heller tydligen. Lite synd.