Re: [fpc-pascal] Documentation generation
On Sat, 17 Aug 2019, leledumbo via fpc-pascal wrote: How are the FPC RTL documentations generated? I wanted to see if I could generate .docsets files from them also. A starting point: https://wiki.freepascal.org/FPCDocs_Tutorial I believe that "write me" part is not far from calling make with certain options. You simply call make rtl.pdf for the PDF version or make rtl.chk for the HTML version. The README.DOCS file contains the following: --- If you only want to generate the RTL and FCL reference documentation in HTML format, starting from the fpdoc XML descriptions, then the following 2 commands should be enough: make rtl.chk make fcl.chk --- One wonders why these README files are created. No-one seems to read them anyway. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] String type with specified length and without codepage
Hi All, I try to rewrite some C/C++ code with FPC. I don't know which is the best string handling technique in this case. The original code for example: char b_l[b_list_len][bn_len+1]; char s_n[sn_len+1]; I do not want to fight with "char"s or "byte"s. Just want to use the easier way which have the best performance. (The original code use strncpy.) I can use "s_n:String[sn_len]", but "String" is ShortString and it's have CP_ACP codepage if I understand the wiki correctly. So I need a string type with explicit defined length and with CP_NONE codepage for a Linux/Windows multi platform application. Any idea? Gabor ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String type with specified length and without codepage
On 18/08/2019 11:57, Gabor Boros wrote: > I do not want to fight with "char"s or "byte"s. Just want to use the > easier way which have the best performance. (The original code use > strncpy.) I can use "s_n:String[sn_len]", but "String" is ShortString > and it's have CP_ACP codepage if I understand the wiki correctly. So I > need a string type with explicit defined length and with CP_NONE > codepage for a Linux/Windows multi platform application. Any idea? That does not exist/is not supported. All strings have an associated code page, because strings are data + interpretation of that data, rather than just data. If you only want data, you have to use an array instead (or a custom record with overloaded operators that uses an array of char internally). Jonas ___ 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 Samstag, den 17.08.2019, 18:00 -0400 schrieb James Richters: > I commented out all the try & except stuff and ran it.. I get this > output: Could you please "git push" the source code to Github so that the line numbers match the output? At least in line 1330 of libusboop.pas there is no Create. Please ensure that the version on Github is the very same version where you executed the program and got the line numbers. Thanks Hansi > Running "i:\programming\pas- > libusb_test_dll\src\examples\testopendevic_vidpid2.exe " > start > 1 > 2 > a05472131 > a10CEEB93 > b > c > FALSE 8086 10CE A36D EB93 > FALSE 8087 10CE 0AAA EB93 > FALSE 0424 10CE 2734 EB93 > FALSE 1D50 10CE 6015 EB93 > FALSE 1B1C 10CE 0C15 EB93 > TRUE 10CE 10CE EB93 EB93 > FALSE 05E3 10CE 0610 EB93 > FALSE 04E8 10CE 61F5 EB93 > FALSE 1B1C 10CE 0C10 EB93 > FALSE 0424 10CE 274C EB93 > FALSE 047D 10CE 1020 EB93 > FALSE 1B1C 10CE 1B4F EB93 > FALSE 1A40 10CE 0101 EB93 > FALSE 0C45 10CE 7403 EB93 > FALSE 10C4 10CE EA60 EB93 > d > e > N > P > L > H1 > I > I2 > Q > R > K > M > O1 > An unhandled exception occurred at $00010002D0BB: > EAccessViolation: Access violation > $00010002D0BB CREATE, line 1330 of libusboop.pas > $00010002B3AB > $00011942 main, line 75 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $00011AF6 main, line 96 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $000100010040 > $000117F0 > $7FFB66D07E94 > $7FFB675FA251 > > > > > > > Could you please remove the try-except block in > > > testopendevic_vidpid2.pas and compile with debug line info to get > > > the full exception backtrace incl. line numbers? > ___ > 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] String type with specified length and without codepage
RawByteString? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String type with specified length and without codepage
On 18/08/2019 15:47, Dmitry Boyarintsev wrote: > RawByteString? RawByteString still has a dynamic code page. Additionally, operations on RawByteString are not very well defined by Embarcadero. In general, it should only be used as a function result or parameter type, and never as a variable on which you perform operations. Again: strings are data + metadata, arrays are just data. Do not use strings for raw data. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation generation
Op 2019-08-18 om 11:43 schreef Michael Van Canneyt: On Sat, 17 Aug 2019, leledumbo via fpc-pascal wrote: How are the FPC RTL documentations generated? I wanted to see if I could generate .docsets files from them also. A starting point: https://wiki.freepascal.org/FPCDocs_Tutorial I believe that "write me" part is not far from calling make with certain options. You simply call make rtl.pdf for the PDF version or make rtl.chk and the fixdocs.sh shell script for the CHM version. ___ 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 just pushed it. >Could you please "git push" the source code to Github so that the line numbers >match the output? At least in line 1330 of libusboop.pas there is no Create. >Please ensure that the >version on Github is the very same version where you executed the program and >got the line numbers. Thanks Hansi > Running "i:\programming\pas- > libusb_test_dll\src\examples\testopendevic_vidpid2.exe " > start > 1 > 2 > a05472131 > a10CEEB93 > b > c > FALSE 8086 10CE A36D EB93 > FALSE 8087 10CE 0AAA EB93 > FALSE 0424 10CE 2734 EB93 > FALSE 1D50 10CE 6015 EB93 > FALSE 1B1C 10CE 0C15 EB93 > TRUE 10CE 10CE EB93 EB93 > FALSE 05E3 10CE 0610 EB93 > FALSE 04E8 10CE 61F5 EB93 > FALSE 1B1C 10CE 0C10 EB93 > FALSE 0424 10CE 274C EB93 > FALSE 047D 10CE 1020 EB93 > FALSE 1B1C 10CE 1B4F EB93 > FALSE 1A40 10CE 0101 EB93 > FALSE 0C45 10CE 7403 EB93 > FALSE 10C4 10CE EA60 EB93 > d > e > N > P > L > H1 > I > I2 > Q > R > K > M > O1 > An unhandled exception occurred at $00010002D0BB: > EAccessViolation: Access violation > $00010002D0BB CREATE, line 1330 of libusboop.pas > $00010002B3AB > $00011942 main, line 75 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $00011AF6 main, line 96 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $000100010040 > $000117F0 > $7FFB66D07E94 > $7FFB675FA251 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] TFPSList clear but not shrink
Is it possible to remove or clear items from TFPSList without actually shrinking the memory (i.e. setting capacity to 0)? Looking the source below I see every time I clear the list it the capacity is set to 0 also. This is fine most of the time unless you want to reuse the list without reallocating memory. If it’s not possible can I make a patch to include this option? procedure TFPSList.Clear; begin if Assigned(FList) then begin SetCount(0); SetCapacity(0); end; end; Regards, Ryan Joseph ___ 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 have a question about USB data transfer.. but it's going to take some
explanation...
I've been doing more testing with my device and Libusbxhid. Here's the device:
https://www.amazon.com/gp/product/B07M5ZY1P2
I have all the inputs working, still have to figure out how to output to the
LCD... I've implemented a test program that shows what button I have pressed,
and it also processes the switches and handwheel properly... The hand wheel
has 100 indents on it, and if I rotated it clockwise, it gives me a positive
count, and if I rotate it counter-clockwise, it gives me two's compliment
representation of a negative count, it only sends a single byte, and the number
it sends is the number of ticks since the last time it reported so it
would have to be read at least every 127 ticks.
ok.. so I got that all working but then I discovered an issue... I thought the
count on the hand wheel was the number of ticks since the last time I got the
report... because if I turn the when very slow, I only get 1 or -1... but if I
turn it faster, I get larger numbers... but once I got it reporting the total
count... I found that if I start with the wheel at the 0 mark, and turn it
really slow, it will count exactly 100 times when it returns to the zero
point.. but if I got at even a slow (but not ridiculous) speed, then the count
would come up short, and if I turned it fast, it would come up really short...
So I tried a test, and disabled the writeln to the console... and now it is
much more accurate.. at slow and medium speeds it is exact but at really fast
speeds it is still slightly short. So I thought this would be a great use for
a thread! So I looked into it.. and I guess in windows I don't even need a
unit to run a thread.. I just need to define a function and do a BeginThread()
to run the function in a thread... well I didn't think it would be THAT easy..
but yes it works! Now I'm going to have threads everywhere LOL. I have the
thread running the tightest possible loop to just read the data and store it in
the fastest way possible so it can get back to reading again... then outside
the thread I read the variables once every 5 seconds and just put where it
is... well this improved things greatly, and I will probably use the thread
method in the final program... but one thing is still bugging me... it's just
not 100% exact all the time, even with the thread method, I still miss count
here and there...
So back to the in-line code with writeln's of a minute... I tried another
test... this time I read the device as normal, then I put a huge delay in.. 5
seconds or so, then I started reading it again.. now if my previous theory was
correct, then I should be able to give up to 127 pulses during the delay and it
would show the total since the last report... but that's not what happened.. it
just forgets about whatever happened during the delayI was careful to only
do 1/2 rotation which would be about 50 pulses so I know I didn't make it
overflow so this behavior makes me think I am not reading it the correct
way it's like it sends the report out every so often whether I am reading
it or not.. and when I do read it I get whatever count it is since the last
OUTPUT, even if I missed the last output... also if I push a button and release
it during the delay, I have no indication it was ever pressed.
So my question is.. does this behavior suggest that the device is expecting
some other transfer method that would guarantee synchronization? I see in
pas-libusb there are test2controlsync and test test3controlasync I'm curious
if synchronous transfer would be the way to communicate with the device that
would guarantee no data loss. I don't really understand how either of these
work, but one is sync and the other is async, so I thought maybe sync was more
the method I should be using. My program in libusbxhid is using:
hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
length, varies by device}, {timeout=}3000);
Maybe it's not either of those.. but some other method where the device pushes
data into a buffer whenever it wants that I can then read.. or something like
that? Or maybe the interrupt read is the best I can do? Is there any way to
give my read thread to have a higher priority or something like that?
Any thoughts?
James
___
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
James, From the looks of it you made good progress reading the hardware and using a dedicated thread for it. Congrats! Seems you're in the thick of it now ready to get the minute details sorted out. Anyway, just a heads up that concurrent programming (threads, synchronization, etc) has many pitfalls. My armchair guess is that your program is just not reading fast enough to keep up with the rate of data that the hardware is generated. Having time sensitive code in a separate thread is a good idea but you should also store the report data in an adequately sized and thread safe data structure such as a thread-safe list/queue. FreePascal has something you could use (https://www.freepascal.org/docs-html/rtl/classes/tthreadlist.html) and although dynamically allocated, it may be fast enough for your purposes. Thread safety is crucial to avoid multiple threads overwriting the data structures they share. The way I see it, your timing sensitive hardware reading thread would fill up the queue and then, every so often, your main thread would consume the data from it. You have to also imagine mechanisms to check that one can keep up with the other and signal errors when that is not the case. Hope this helps, and good luck! On 8/18/19 12:05 PM, James Richters wrote: I have a question about USB data transfer.. but it's going to take some explanation... I've been doing more testing with my device and Libusbxhid. Here's the device: https://www.amazon.com/gp/product/B07M5ZY1P2 I have all the inputs working, still have to figure out how to output to the LCD... I've implemented a test program that shows what button I have pressed, and it also processes the switches and handwheel properly... The hand wheel has 100 indents on it, and if I rotated it clockwise, it gives me a positive count, and if I rotate it counter-clockwise, it gives me two's compliment representation of a negative count, it only sends a single byte, and the number it sends is the number of ticks since the last time it reported so it would have to be read at least every 127 ticks. ok.. so I got that all working but then I discovered an issue... I thought the count on the hand wheel was the number of ticks since the last time I got the report... because if I turn the when very slow, I only get 1 or -1... but if I turn it faster, I get larger numbers... but once I got it reporting the total count... I found that if I start with the wheel at the 0 mark, and turn it really slow, it will count exactly 100 times when it returns to the zero point.. but if I got at even a slow (but not ridiculous) speed, then the count would come up short, and if I turned it fast, it would come up really short... So I tried a test, and disabled the writeln to the console... and now it is much more accurate.. at slow and medium speeds it is exact but at really fast speeds it is still slightly short. So I thought this would be a great use for a thread! So I looked into it.. and I guess in windows I don't even need a unit to run a thread.. I just need to define a function and do a BeginThread() to run the function in a thread... well I didn't think it would be THAT easy.. but yes it works! Now I'm going to have threads everywhere LOL. I have the thread running the tightest possible loop to just read the data and store it in the fastest way possible so it can get back to reading again... then outside the thread I read the variables once every 5 seconds and just put where it is... well this improved things greatly, and I will probably use the thread method in the final program... but one thing is still bugging me... it's just not 100% exact all the time, even with the thread method, I still miss count here and there... So back to the in-line code with writeln's of a minute... I tried another test... this time I read the device as normal, then I put a huge delay in.. 5 seconds or so, then I started reading it again.. now if my previous theory was correct, then I should be able to give up to 127 pulses during the delay and it would show the total since the last report... but that's not what happened.. it just forgets about whatever happened during the delayI was careful to only do 1/2 rotation which would be about 50 pulses so I know I didn't make it overflow so this behavior makes me think I am not reading it the correct way it's like it sends the report out every so often whether I am reading it or not.. and when I do read it I get whatever count it is since the last OUTPUT, even if I missed the last output... also if I push a button and release it during the delay, I have no indication it was ever pressed. So my question is.. does this behavior suggest that the device is expecting some other transfer method that would guarantee synchronization? I see in pas-libusb there are test2controlsync and test test3controlasync I'm curious if synchronous transfer would be the way to commun
Re: [fpc-pascal] Documentation generation
On 18/08/2019 10:43 am, Michael Van Canneyt wrote: > One wonders why these README files are created. No-one seems to read them > anyway. Yeah, I've been wondering that same thing for years. Maybe we should create a README.1st file. :-P Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ 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
As far as reading it goes, things are going pretty well.. I still have yet to write to the display.. I can't get any of my attempts to send data to it to be successful at all.. I get "control transfer to usb device failed!" Thanks for the advice on a thread safe queue! For the moment I've been trying to do the math inside thread reading the usb device... it's pretty simple, and that allows me to read the totals at any time.. but I can see what you mean that if I just read the device and dump everything into maybe some kind of ring buffer without bothering to try to process it at all, and increment the buffer position then it could be ready to read again even faster. I could have my other slow process crunch the buffer. I have two of these devices, one is wireless, the other has a USB cable attached to it.. they both work a little differently.. the wireless one only responds to my interrupt read when some data has been generated... the wired version always responds to my request whether any data has been generated or not. For that one I would have to do a compare on the data to see if anything changed before adding to the buffer otherwise the buffer would always be overrun. Still I can't image my math is taking very long.. here is what I am doing: Read device If wheel moved then add wheel counts to appropriate variable then read device Else Update other variables if they changed then read device So when the wheel is moving I have very few instructions between reads.. I don't bother checking for buttons or anything else.. I just keep accumulating the total, and that's all I care about, and then I read again.. I only bother with the buttons if the wheel didn't move. One thing I'm really not sure how to handle with threads is this ok so I have my main fast read thread going in the tightest loop possible... but now I want to write something to the display (assuming I ever figure that out and don't just put a sticker over the display and look at the screen instead :D ) It seems I would have to stop reading to get a chance to write something.. I did a little test and I can do a suspend(Thread_ID) and resume(Thread_ID) but what if it's in the middle of a read.. but only got 6 of the 8 bytes when I do the suspend?? Now I am not really ready to write. so what method can I use to do a suspend_thread_just_before_the_next_read_happens() ? so that when the thread is suspended, the read is completed and the buffer updated.. etc.. and the USB system and libusb are all ready for me to send my write commands? Resuming would be no problem.. because it was suspended at the correct position.. I can just resume when I am done with the write and everything should be fine. I also still am hoping to find a method of making the device wait for me to read it... even with threads in my program, the operating system could go off and do something that takes all the processor time for a second and I would just not know about events that happened during that time. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Sunday, August 18, 2019 3:12 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices James, From the looks of it you made good progress reading the hardware and using a dedicated thread for it. Congrats! Seems you're in the thick of it now ready to get the minute details sorted out. Anyway, just a heads up that concurrent programming (threads, synchronization, etc) has many pitfalls. My armchair guess is that your program is just not reading fast enough to keep up with the rate of data that the hardware is generated. Having time sensitive code in a separate thread is a good idea but you should also store the report data in an adequately sized and thread safe data structure such as a thread-safe list/queue. FreePascal has something you could use (https://www.freepascal.org/docs-html/rtl/classes/tthreadlist.html) and although dynamically allocated, it may be fast enough for your purposes. Thread safety is crucial to avoid multiple threads overwriting the data structures they share. The way I see it, your timing sensitive hardware reading thread would fill up the queue and then, every so often, your main thread would consume the data from it. You have to also imagine mechanisms to check that one can keep up with the other and signal errors when that is not the case. Hope this helps, and good luck! ___ 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/18/19 3:58 PM, James Richters wrote: As far as reading it goes, things are going pretty well.. I still have yet to write to the display.. I can't get any of my attempts to send data to it to be successful at all.. I get "control transfer to usb device failed!" Assuming there are no other bugs in the libusbxhid library, for writing data you have to guess the reportType (in, out, feature) and reportNum parameter and set the report data buffer correctly (first byte is the report number) for your device. Have a look at similar devices. One thing I'm really not sure how to handle with threads is this ok so I have my main fast read thread going in the tightest loop possible... but now I want to write something to the display (assuming I ever figure that out and don't just put a sticker over the display and look at the screen instead :D ) It seems I would have to stop reading to get a chance to write something.. I did a little test and I can do a suspend(Thread_ID) and resume(Thread_ID) but what if it's in the middle of a read.. but only got 6 of the 8 bytes when I do the suspend?? Now I am not really ready to write. so what method can I use to do a suspend_thread_just_before_the_next_read_happens() ? so that when the thread is suspended, the read is completed and the buffer updated.. etc.. and the USB system and libusb are all ready for me to send my write commands? Resuming would be no problem.. because it was suspended at the correct position.. I can just resume when I am done with the write and everything should be fine. My guess is that it would be better to leave the time sensitive read thread to do the fast reads and immediate calculations and leave writing to the device screen in a separate thread (even main thread), with a lower update frequency! I also still am hoping to find a method of making the device wait for me to read it... even with threads in my program, the operating system could go off and do something that takes all the processor time for a second and I would just not know about events that happened during that time. If an operating system were realtime that should not happen. This is why LinuxCNC uses the realtime extensions (http://linuxcnc.org/) Some devices have multiple functional modes that can be selected by writing their appropriate settings/registers. For example, a graphic tablet I used before has a finger input mode (really becomes a trackpad) and a pen mode (uses the stylus, as usual). For more complex devices, guessing such things is less practical, you really need knowledge of the device or similar ones. ___ 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
>>Assuming there are no other bugs in the libusbxhid library, for writing data
>>you have to guess the reportType (in, out, feature) and reportNum parameter
>>and set the report data buffer correctly (first byte is the report number)
>>for your device. Have a look at similar devices.
I don't know if there is a bug or not... but I "Think" I have the information I
need. I found this device documented here:
https://github.com/rubienr/machinekit/tree/feature-xhc-whb04b-6/src/hal/user_comps/xhc-whb04b-6
it states: "Data transmitted is packed as 7 bytes plus a constant leading byte
0x06 which is the report ID. The data exclusive report ID reads as follows:"
this matches the python code I was trying to duplicate... so I send a $06 then
7 bytes of data at a time. It also describes the data structure as well.
The C code at
https://github.com/rubienr/machinekit/blob/feature-xhc-whb04b-6/src/hal/user_comps/xhc-whb04b-6/usb.cc
Uses libusb... here is the relevant section: It's in C but it's commented
pretty well.. and describes the exact parameters passed to
libusb_control_transfer
void Usb::sendDisplayData()
{
outputPackageBuffer.asBlocks.init(&outputPackageData);
if (mIsSimulationMode)
{
*verboseTxOut << "out 0x" << outputPackageBuffer.asBlocks << endl <<
std::dec << "out size " <<
sizeof(outputPackageBuffer.asBlockArray) << "B " << outputPackageData
<< endl;
}
for (size_t idx = 0; idx < (sizeof(outputPackageBuffer.asBlockArray) /
sizeof(UsbOutPackageBlockFields)); idx++)
{
UsbOutPackageBlock& block = outputPackageBuffer.asBlockArray[idx];
size_t blockSize = sizeof(UsbOutPackageBlock);
// see also
// http://www.beyondlogic.org/usbnutshell/usb6.shtml
// http://libusb.sourceforge.net/api-1.0/group__desc.html
// http://libusb.sourceforge.net/api-1.0/group__misc.html
intr = libusb_control_transfer(deviceHandle,
// send to hid descriptor: bmRequestType == LIBUSB_DT_HID == 0x21
== (interface | endpoint)
LIBUSB_DT_HID,
// bRequest == LIBUSB_REQUEST_SET_CONFIGURATION == 0x09 == set
configuration
LIBUSB_REQUEST_SET_CONFIGURATION,
// wValue: if bRequest == LIBUSB_REQUEST_SET_CONFIGURATION the
configuration value
0x0306,
// wIndex, device interface number
0x00,
// data to transmit
block.asBuffer.asBytes,
// wLength, data length
blockSize,
// transfer timeout[ms]
0);
if (r < 0)
{
std::cerr << "transmission failed, try to reconnect ..." << endl;
setDoReconnect(true);
return;
}
}
}
So I tried with libusbxhid:
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6 , 8 ,
WhB04_Packet )
and I get control transfer to usb device failed!
so inside function libusbhid_set_report, I put a bunch of writelns to show what
is being passed to libusb_control_transfer:
Writeln('device handle =');
Writeln('bmRequestType = $', inttohex(LIBUSB_CONTROL_REQUEST_TYPE_OUT,4));
Writeln('bRequest = $', inttohex(HID_SET_REPORT,4) );
Writeln('wValue= $', inttohex((reportType << 8) or reportNum,4) );
Writeln('wIndex= $', 0 );
Writeln('data = ', '$'+Inttohex(report_data[0],2),'
$'+Inttohex(report_data[1],2),' $'+Inttohex(report_data[2],2),'
$'+Inttohex(report_data[3],2),' $'+Inttohex(report_data[4],2),'
$'+Inttohex(report_data[5],2),
' $'+Inttohex(report_data[6],2),'
$'+Inttohex(report_data[7],2));
Writeln('wLength = $', Inttohex(reportLen,2) );
Writeln('timeout = $', 0 );
Result:=libusb_control_transfer(hid_device_context.usb_device_handle,LIBUSB_CONTROL_REQUEST_TYPE_OUT{},HID_SET_REPORT,(reportType
<< 8) or reportNum, 0{interface_num}, @report_data,
reportLen{sizeof(data)},0{no timeout});
Suspend
06 FD FE FF 01 02 03 04
device handle =
bmRequestType = $0021
bRequest = $0009
wValue= $0306
wIndex= $0
data = $06 $FD $FE $FF $01 $02 $03 $04
wLength = $08
timeout = $0
control transfer to usb device failed!
-1
It shows I'm getting the same values for everything but yet it's still
failing. I have this attempt on my fork at
https://github.com/Zaaphod/libusbxhid
I'm not sure it's libusbxhid though.. because I also can't get it to work with
pas-libusb I can run test3controlasync.pas with my device and it
Re: [fpc-pascal] USB Human Interface Devices
Hi James, are you really sure the WHB04B-6 is exactly the same as your WHB04B-4 viewn to the USB API? If those thingys come with a dll, maybe you can compare the header files? If there is no header file you could ask the manufacturer for it. If they made a programm using that dll, there must be a header file. HTH somehow... -- Marc Santhoff ___ 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
My guess is that it would be better to leave the time sensitive read thread to do the fast reads and immediate calculations and leave writing to the device screen in a separate thread (even main thread), with a lower update frequency! Yes, that was what I was attempting to describe.. but I can't write to the usb device if the read thread happens to be in the middle of a read... so how do I pause the read thread at the correct time so it's not partially in the middle of reading a packet, and I can't read again until I'm done writing. I figure I can just check for some period of time of idle handwheel input before I stop the read thread and do the write then start the read thread again, because only the handwheel produces such a large stream of data.. but still I’m not sure how to make sure I stop it at the correct time. I do not get why should you stop the read thread, when that is the actual advantage of having multiple threads. While the read thread is busily reading input in a buffer/queue/what have you, you are free within limits) to do whatever you need to do (e.g., output to LCD display, do calculations) in the other threads, including the main thread, after which, you can get back to consuming and processing the (hopefully only slightly larger now) data from the read thread buffer/queue. After you figured writing to the LCD screen you could try writing random data to it while reading and processing handwheel and button input *at the same time*. Hope this makes sense. ___ ___ 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
They come with a little CD, but not much really useful on them.. mostly instructions on how to get them to work with Mach3. But the manual does cover both models. The only difference is one has a selection switch for 4 axis and the other has one for 6 axis, but the 4 axis version shows 6 axis on the LCD so I think everything else is identical even the firmware. The manual does have a dll on it called ShuttlePro.dll I have no idea what to do with that... they don't include any program at all, just instructions for mach3. The documentation is very poor and there is no support at all on how to access it.. I'm just going on what everyone else has kind of figured out plus what I could figure out from just pushing the buttons on it. There's a readme in the same folder as ShuttlePro.dll: ShuttlePro.dll is the Driver of HB04BX for MACH3 cnc control system. You could externd the IO input with our wireless handle.To do reset,start,stop etc. The handle is just like ShuttlePRO,you coul do jog mpg and step with the handle. In all,you could control much things if you had our wireless HB04Bx. installation: first you must install mach3 and then insert HB04Bx handle usb controller.then install the batteries to HB04Bx handle's cell box. 1.You should copy the ShuttlePro.dll to Mach3\plugins\ directroy; 2.M930.m1s is the probez file.You should copy the it to Mach3\macros\Mach3Mill directroy; 3.M990.m1s is the ref all home file.You should copy the it to Mach3\macros\Mach3Mill directroy; 4.m933 is go to zero work macro,You should copy the it to Mach3\macros\Mach3Mill directroy; 5.you could change the macro file M930.m1s ,M990.m1s, m933 to satisfy your cnc system; It seems to indicate the designation after the B is not important to the operation.. W is for wireless and they are HB04Bx (either -4 or -6 as far as I know.. maybe there is a -3 as well) I have no idea what the DLL could possibly be for though James -Original Message- From: fpc-pascal On Behalf Of Marc Santhoff Sent: Sunday, August 18, 2019 9:12 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hi James, are you really sure the WHB04B-6 is exactly the same as your WHB04B-4 viewn to the USB API? If those thingys come with a dll, maybe you can compare the header files? If there is no header file you could ask the manufacturer for it. If they made a programm using that dll, there must be a header file. HTH somehow... -- Marc Santhoff ___ 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
My concern was that I could not read and write at the exact same time -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Sunday, August 18, 2019 9:32 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices >> My guess is that it would be better to leave the time sensitive read >> thread to do the fast reads and immediate calculations and leave >> writing to the device screen in a separate thread (even main thread), >> with a lower update frequency! > > Yes, that was what I was attempting to describe.. but I can't write to the > usb device if the read thread happens to be in the middle of a read... so how > do I pause the read thread at the correct time so it's not partially in the > middle of reading a packet, and I can't read again until I'm done writing. I > figure I can just check for some period of time of idle handwheel input > before I stop the read thread and do the write then start the read thread > again, because only the handwheel produces such a large stream of data.. but > still I’m not sure how to make sure I stop it at the correct time. I do not get why should you stop the read thread, when that is the actual advantage of having multiple threads. While the read thread is busily reading input in a buffer/queue/what have you, you are free within limits) to do whatever you need to do (e.g., output to LCD display, do calculations) in the other threads, including the main thread, after which, you can get back to consuming and processing the (hopefully only slightly larger now) data from the read thread buffer/queue. After you figured writing to the LCD screen you could try writing random data to it while reading and processing handwheel and button input *at the same time*. Hope this makes sense. ___ ___ 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 Mon, 2019-08-19 at 03:11 +0200, Marc Santhoff wrote: > Hi James, > > are you really sure the WHB04B-6 is exactly the same as your WHB04B-4 viewn to > the USB API? > > If those thingys come with a dll, maybe you can compare the header files? > If there is no header file you could ask the manufacturer for it. If they made > a programm using that dll, there must be a header file. Oh, it's chinese - forget about getting any information. Did you read there https://github.com/rubienr/machinekit/tree/feature-xhc-whb04b-6/src/hal/user_comps/xhc-whb04b-6#findings that the axis dial has to be switched on for the display to be updated? > HTH somehow... > > -- > Marc Santhoff > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- Marc Santhoff -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
