Re: [fpc-pascal] USB Human Interface Devices
On 8/21/19 6:35 PM, James Richters wrote: I had them separated, but whenever it happened that I tried to write while it was waiting to read, I would get the error below. If it was reading all the time it seemed fine.. just if it was idle waiting to read and I did a write that it would fail with EAccessViolation: Access violation That should not happen - out of curiosity I modified a graphic tablet test program and included: - a separate read thread with a timeout of 1 second and - in the main thread, one set feature report call followed by a get feature report call (every 1 second). This was the behaviour: 1) if there is no input: - the main thread keeps calling set report +get report every 1 second - in the read thread, the interrupt read times out every second but generates report data every 5 seconds (tablet generates an interrupt read even if there is no input - a sort of heartbeat); 2) if there is input (pen approaches tablet or writes on tablet) there is a flurry of data from the read thread and of course, no more interrupt read timeouts; the main thread is business as usual, setting and getting feature reports every second; see the attached debug log Note that the interrupt read report size is specific to the device (10 bytes for the tablet); is the length for your device correct? DEBUG Found 15 devices attached [...] DEBUG Found device with vid:pid 1386:222 at idx:12! DEBUG Device instance found: 1 at idx:12! [...] DEBUG Device opened. Next I must claim the interface. [...] DEBUG Claiming interface.fingers crossed... DEBUG Interface claimed ... yay! DEBUG 22:13:42:711 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:42:713 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:43:711 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:43:715 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:43:812 libusbhid_get_report. received: 2 bytes from device DEBUG 22:13:44:718 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:44:812 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:44:913 libusbhid_get_report. received: 2 bytes from device DEBUG 22:13:45:720 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:45:914 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:46:014 libusbhid_get_report. received: 2 bytes from device DEBUG 22:13:46:722 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:46:852 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:858 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:866 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:874 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:882 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:888 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:895 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:904 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:912 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:918 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:926 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:934 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:942 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:948 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:956 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:964 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:972 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:978 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:986 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:994 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:002 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:008 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:015 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:47:015 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:024 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:032 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:038 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:046 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:054 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:062 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:068 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:076 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:084 libusbhid_interrupt_read. received: 10
Re: [fpc-pascal] USB Human Interface Devices
I had them separated, but whenever it happened that I tried to write while it was waiting to read, I would get the error below. If it was reading all the time it seemed fine.. just if it was idle waiting to read and I did a write that it would fail with EAccessViolation: Access violation I put them in the same thread but only allow writes when it's been idle for a few timeouts.. the only time I need to read the port like crazy if I spin the hand wheel really fast. I also use the slow main program to only tell the fast read thread that data is available to write at a pretty slow rate.I think this could be improved.. I just don't know how to us this locking system you mention. If I can lock it from reading when I try to write or to properly interrupt the read if it is just sitting there waiting for data that would be better. The device only answers the read request when it has something to send, so it will sit there for hours just waiting if no one gives it any input.. but I want to update the display all the time... all the time that it's turned on anyway... so that's the issue I'm facing. Whenever I try to write when the device is idle.. it blows up.. probably because I did not finish the read and lock reading. Anyway what I have now can't read and write at the same time.. I am using a timeout to stop trying to read.. and then if I get enough time outs in a row, I figure I'm not too busy reading, so I send out the write.. but if I blast it with data (turn the wheel super fast for a long time) then it never tries to write because I never time out.. so the display doesn't change.. but that's ok.. it corrects itself when I stop the crazy input. 99% of the time. The wheel will be turned slowly.. just once in a while the user might want to move a large distance with it and whirl it around really fast. I thought I saw something about sending a request to read.. then doing something else for a while and getting a call back when it's got something there.. maybe that's something like asynchronous? I think if I can figure that out it would solve the problem (maybe) of wanting to write something while I wait for input. I'm thinking if I don't use a timeout like I am now, I wouldn't get libusb: warning [handle_timeout] async cancel failed -5 errno=0 ... I wonder if that is a know issue and the reason why the timout was originally set to zero in the interrupt read function... Still all in all, I'm pretty happy with it! I do still miss like 2 pulses out of 800.. so not a super huge deal, but room for improvement... if I use the library the proper way, it will probably help. I'm wondering there is something in threads that I can set to make my fast read thread always run faster than the others.. some kind of priority or percentage?? Or do I just have to put enough delays with Sleep() commands to slow everything else down... James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Wednesday, August 21, 2019 5:31 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices From your example it looks like you placed the device reading (interrupt read) and writing (set report) into the same read thread. I thought keeping them separate was a good idea: tight loop reads and less frequent writes (LCD updates). Libusb is supposed to be thread-safe. Not really an issue for your app but if you need to make sure only one thread out of multiple threads is processing libusb events the library has asynchronous API that does offer locking functionality. On 8/21/19 3:48 PM, James Richters wrote: > Well.. It doesn’t always work just reading constantly and writing in a > different thread.. > > So I have my fast read loop always reading then my LCD write loop sending the > 3 packets every 0.3 Seconds.. and it functions ok, and I don’t miss too many > counts... but every so often I get this message: > libusb: warning [handle_timeout] async cancel failed -5 errno=0 > > I have a timeout on my read loop of 10ms. I tried setting that to 0 so it > would just wait for input in it's thread.. but when I do that I get this as > soon as I attempt to write to it: > An unhandled exception occurred at $7FFF189F03C6: > EAccessViolation: Access violation >$7FFF189F03C6 >$7FFF189EDA21 >$7FFF17AAA1A1 >$7FFF17AA9CB5 >$6B607FFB >$6B6081E7 >$6B60C695 >$6B605D6F >$6B607E40 >$00010001B1CA >$000121BF main, line 445 of whb04b-4_test.pas >$000122B6 >$0001EC20 >$00011880 >$7FFF17B47E94 >$7FFF18A4A251 > > Also if I put in a really long timeout like 1000ms I get that. Line > 445 is libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, > $6 , 8 , WhB04_Packet1 ); > > so I can't write while I'm reading or waiting for a read after all. > > So I came up
Re: [fpc-pascal] USB Human Interface Devices
From your example it looks like you placed the device reading (interrupt read) and writing (set report) into the same read thread. I thought keeping them separate was a good idea: tight loop reads and less frequent writes (LCD updates). Libusb is supposed to be thread-safe. Not really an issue for your app but if you need to make sure only one thread out of multiple threads is processing libusb events the library has asynchronous API that does offer locking functionality. On 8/21/19 3:48 PM, James Richters wrote: Well.. It doesn’t always work just reading constantly and writing in a different thread.. So I have my fast read loop always reading then my LCD write loop sending the 3 packets every 0.3 Seconds.. and it functions ok, and I don’t miss too many counts... but every so often I get this message: libusb: warning [handle_timeout] async cancel failed -5 errno=0 I have a timeout on my read loop of 10ms. I tried setting that to 0 so it would just wait for input in it's thread.. but when I do that I get this as soon as I attempt to write to it: An unhandled exception occurred at $7FFF189F03C6: EAccessViolation: Access violation $7FFF189F03C6 $7FFF189EDA21 $7FFF17AAA1A1 $7FFF17AA9CB5 $6B607FFB $6B6081E7 $6B60C695 $6B605D6F $6B607E40 $00010001B1CA $000121BF main, line 445 of whb04b-4_test.pas $000122B6 $0001EC20 $00011880 $7FFF17B47E94 $7FFF18A4A251 Also if I put in a really long timeout like 1000ms I get that. Line 445 is libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6 , 8 , WhB04_Packet1 ); so I can't write while I'm reading or waiting for a read after all. So I came up with a scheme to set all the variables in the slow loop then set a Boolean variable when it's done.. then the fast loop checks for the flag if it is idle for a time, meaning it's not trying to keep up with input.. and that does work.. and I don't miss many counts... but it does miss a few... but I STILL get this libusb: warning [handle_timeout] async cancel failed -5 errno=0 even though as far as I can tell, I can't possible be reading and writing at the same time. I've updated my test project here: https://github.com/Zaaphod/libusbxhid/blob/master/WHB04B-4_test.pas I don't really know what libusb: warning [handle_timeout] async cancel failed -5 errno=0 is trying to tell me... it is having an issue canceling waiting for data after the time out I guess.. but why is that a problem? Any Ideas? James -Original Message- From: fpc-pascal On Behalf Of James Richters Sent: Wednesday, August 21, 2019 8:30 AM To: 'FPC-Pascal users discussions' Subject: Re: [fpc-pascal] USB Human Interface Devices I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to libusb-win32... After I gave up on Python, I went back to FPC and just ran my existing sample program, and I noticed where it used have an error sending to device, it now said 8 bytes sent!! It's very strange I could read it just fine but not write to it without messing with the driver... but it's working now! I tried suspending the read thread to write to it.. and well it must have ended up suspending in the middle of a read because the whole thing locked up.. so I just tried as suggested and let it keep reading in a tight loop in it's own thread and then just throw in a write every few seconds on the main program.. and that actually worked fine.. I guess libusb takes care of worry about finishing a read before writing.. I think I did see libusb had something to do with threads. So now it's just a matter of small details. The display is a little odd... in that instead of sending it just a real number, you send it an integer for the numbers before the decimal and another integer for the numbers after the decimal.. but it's 2 bytes for each (4 bytes total) but they are in reverse order.. I need to send LowByte_Integer, High_Byte_Integer, LowByte_decimal, High_Byte_decimal so the bits from a 16 bit integer end up being 76543210,FEDCBA98 I think this is that edian byte order thing that was mentioned. I'm just curious if there is already a function available to reverse these like this.. or if I just need to write my own. It's just some rotates and then split it, so I can do that, but I'm just wondering if there is something already there to do this.. I seem to recall that this kind of thing needs to happen quite a bit. Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ; Ah.. but that doesn't work.. is there a way to do this with syntax or do I just need to make a
Re: [fpc-pascal] USB Human Interface Devices
Hmm I'll see what I can come up with. The language of all these units is completely foreign to me. I really don't understand how constructors and this inherited stuff or how even the functions and procedures manage to get anything done. I've been programming with Pascal since Turbo Pascal back in the 80's but I can't make any sense of this coding style at all. I'll have to do some research to see how this method of programing even works at all. I've done some stuff that uses units like this, so I can create and object and manage to use it, but the unit's themselves... well. I just don't get it. I keep going around in circles trying to follow the way things get done and it seems like I go round and round and never find any functions or procedures that really do anything at all.. they just keep calling each other. I was trying to just compile Snapi.pas with libusboop just to figure out the syntax.. then I can copy sections and modify it as needed. James >Hmm, no. You should make your own unit for your device, from scratch. >And then use snapi.pas as a guide how to do that. As I've written in my >previous EMail: ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Montag, den 19.08.2019, 18:22 -0400 schrieb James Richters: > Oh, for some reason I wasn't thinking I was replacing mydevice.pas > with snapi.pas... Ok.. so if > I understand this correctly, make the changes necessary in snapi.pas > to use libusboop.pas instead of the old usb.pas, and then use > TSNAPIDevice.Create to create a TLIBUSBPseudoHIDInterface to my > device? ... and that will allow me a more generic method to access > the device? Hmm, no. You should make your own unit for your device, from scratch. And then use snapi.pas as a guide how to do that. As I've written in my previous EMail: --- schnipp --- You really should create your own class descending from TLibUsbDevice (instead of TLibUsbDeviceWithFirmware). In your constructor, you have to get a reference to the HID interface of your device, e.g., by TLibUsbPseudoHIDInterface.Create(...) analogous to https://github.com/Zaaphod/pas-libusb/blob/Hack/src/examples/mydevice.pas#L141 . This internally also gets references to the necessary endpoints, therefore you most probably don't need manual FInterface.FindEndpoint() (like TMyDevice). --- schnapp --- But please pay attention to the new methods, parameters, ... Bye Hansi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Thanks for the suggestion! James >Move(LCD_Array[0..6],Device_Array[1],7) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Well.. It doesn’t always work just reading constantly and writing in a different thread.. So I have my fast read loop always reading then my LCD write loop sending the 3 packets every 0.3 Seconds.. and it functions ok, and I don’t miss too many counts... but every so often I get this message: libusb: warning [handle_timeout] async cancel failed -5 errno=0 I have a timeout on my read loop of 10ms. I tried setting that to 0 so it would just wait for input in it's thread.. but when I do that I get this as soon as I attempt to write to it: An unhandled exception occurred at $7FFF189F03C6: EAccessViolation: Access violation $7FFF189F03C6 $7FFF189EDA21 $7FFF17AAA1A1 $7FFF17AA9CB5 $6B607FFB $6B6081E7 $6B60C695 $6B605D6F $6B607E40 $00010001B1CA $000121BF main, line 445 of whb04b-4_test.pas $000122B6 $0001EC20 $00011880 $7FFF17B47E94 $7FFF18A4A251 Also if I put in a really long timeout like 1000ms I get that. Line 445 is libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6 , 8 , WhB04_Packet1 ); so I can't write while I'm reading or waiting for a read after all. So I came up with a scheme to set all the variables in the slow loop then set a Boolean variable when it's done.. then the fast loop checks for the flag if it is idle for a time, meaning it's not trying to keep up with input.. and that does work.. and I don't miss many counts... but it does miss a few... but I STILL get this libusb: warning [handle_timeout] async cancel failed -5 errno=0 even though as far as I can tell, I can't possible be reading and writing at the same time. I've updated my test project here: https://github.com/Zaaphod/libusbxhid/blob/master/WHB04B-4_test.pas I don't really know what libusb: warning [handle_timeout] async cancel failed -5 errno=0 is trying to tell me... it is having an issue canceling waiting for data after the time out I guess.. but why is that a problem? Any Ideas? James -Original Message- From: fpc-pascal On Behalf Of James Richters Sent: Wednesday, August 21, 2019 8:30 AM To: 'FPC-Pascal users discussions' Subject: Re: [fpc-pascal] USB Human Interface Devices I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to libusb-win32... After I gave up on Python, I went back to FPC and just ran my existing sample program, and I noticed where it used have an error sending to device, it now said 8 bytes sent!! It's very strange I could read it just fine but not write to it without messing with the driver... but it's working now! I tried suspending the read thread to write to it.. and well it must have ended up suspending in the middle of a read because the whole thing locked up.. so I just tried as suggested and let it keep reading in a tight loop in it's own thread and then just throw in a write every few seconds on the main program.. and that actually worked fine.. I guess libusb takes care of worry about finishing a read before writing.. I think I did see libusb had something to do with threads. So now it's just a matter of small details. The display is a little odd... in that instead of sending it just a real number, you send it an integer for the numbers before the decimal and another integer for the numbers after the decimal.. but it's 2 bytes for each (4 bytes total) but they are in reverse order.. I need to send LowByte_Integer, High_Byte_Integer, LowByte_decimal, High_Byte_decimal so the bits from a 16 bit integer end up being 76543210,FEDCBA98 I think this is that edian byte order thing that was mentioned. I'm just curious if there is already a function available to reverse these like this.. or if I just need to write my own. It's just some rotates and then split it, so I can do that, but I'm just wondering if there is something already there to do this.. I seem to recall that this kind of thing needs to happen quite a bit. Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ; Ah.. but that doesn't work.. is there a way to do this with syntax or do I just need to make a loop to copy the array elements the way they need to be? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
On 8/21/19 8:30 AM, James Richters wrote: I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to Persistence pays off. Congrats! Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ; Try Move (https://www.freepascal.org/docs-html/rtl/system/move.html) Move(LCD_Array[0..6],Device_Array[1],7) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] bug while generating androidR25.pas and Androidr25.inc
I know, that this task is heavy and should be only performed by The elites among Pascal programmers not by users of this programming language. But I Am sure, that if somebody experienced will answer. on my question, it would increase The number of volunteers, who would be ready to generate newer and newer Android header files, because Android APIS versions are newer and newer. I Am getting The bug related to swing. Here is whole part of window. C:\pasandr>java -jar javapp.jar -bootclasspath C:\Program Files (x86)\Android\android-sdk\platforms\android-25\android.jar -extdirs . -protected -x java.lang.System -x java.lang.Object -x java.io.Serializable -x java.io.IOException -x java.io.IIOException -x java.lang.Readable -x java.lang.Float -x java.lang.Double -x java.lang.Float -x java.lang.Double -x java.lang.Byte -x java.lang.Short -x java.lang.Integer -x java.lang.Long -x java.lang.Boolean -x java.lang.String -x java.lang.StringBuilder -x java.lang.StringBuffer -x java.lang.CharSequence -x java.lang.AbstractStringBuilder -x java.lang.Appendable -x java.lang.Number -x java.lang.IndexOutOfBoundsException -x java.lang.RuntimeException -x java.lang.IllegalArgumentException -x java.lang.IllegalStateException -x java.lang.UnsupportedOperationException -x java.lang.Exception -x java.lang.Throwable -x java.lang.LinkageError -x java.lang.Error -x java.lang.Comparable -x java.lang.Character -x java.text.Collator -x java.lang.Cloneable -x java.lang.Runtime -x java.lang.ThreadLocal -x java.math.BigInteger -x java.util.Comparator -x java.lang.reflect.Array -x java.lang.Class -x java.lang.reflect.GenericDeclaration -x java.lang.reflect.Type -x java.lang.reflect.Method -x java.lang.reflect.AccessibleObject -x java.lang.reflect.Member -x java.lang.reflect.AnnotatedElement -x java.lang.reflect.Field -x java.lang.reflect.InvocationTargetException -x java.util.Arrays -x java.util.Map -x java.util.HashMap -x java.util.Set -x java.util.Collection -x java.util.AbstractMap -x java.util.Calendar -x java.lang.Iterable -x java.lang.Enum -x java.lang.Math -x java.util.AbstractCollection -x java.util.AbstractSet -x java.util.EnumSet -x java.util.BitSet -x java.util.Iterator -x java.nio.Buffer -x java.nio.ByteBuffer -x java.nio.CharBuffer -x java.nio.charset. -a sun. -a com.sun. -a apple. -a java.awt. java. javax. org. android. junit. -o androidrNo default charset: windows-1250 Determining short Pascal class names... Indexing classes under (x86)\Android\android-sdk\platforms\android-25\android/jar... Indexing classes under Files... Indexing classes under android/... Indexing classes under java/... Indexing classes under javax/... Indexing classes under junit/... Indexing classes under org/... ERROR:Could not find javax/swing/JApplet C:\pasandr> I AM running jdk1.7.0_79 And The same version of JRE X86 with Windows 10 Home Edition 64 BIt. Sure! I know, that even when I generate .pas and .inc files, I will not get ready header files. There is plenty of work to make because of classes naming. If somebody will know The answer, it would be really useful. Thank you very very much. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to libusb-win32... After I gave up on Python, I went back to FPC and just ran my existing sample program, and I noticed where it used have an error sending to device, it now said 8 bytes sent!! It's very strange I could read it just fine but not write to it without messing with the driver... but it's working now! I tried suspending the read thread to write to it.. and well it must have ended up suspending in the middle of a read because the whole thing locked up.. so I just tried as suggested and let it keep reading in a tight loop in it's own thread and then just throw in a write every few seconds on the main program.. and that actually worked fine.. I guess libusb takes care of worry about finishing a read before writing.. I think I did see libusb had something to do with threads. So now it's just a matter of small details. The display is a little odd... in that instead of sending it just a real number, you send it an integer for the numbers before the decimal and another integer for the numbers after the decimal.. but it's 2 bytes for each (4 bytes total) but they are in reverse order.. I need to send LowByte_Integer, High_Byte_Integer, LowByte_decimal, High_Byte_decimal so the bits from a 16 bit integer end up being 76543210,FEDCBA98 I think this is that edian byte order thing that was mentioned. I'm just curious if there is already a function available to reverse these like this.. or if I just need to write my own. It's just some rotates and then split it, so I can do that, but I'm just wondering if there is something already there to do this.. I seem to recall that this kind of thing needs to happen quite a bit. Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ; Ah.. but that doesn't work.. is there a way to do this with syntax or do I just need to make a loop to copy the array elements the way they need to be? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
