- unit DelegateTalkerImpl;
-
- interface
-
- {$MODE OBJFPC}
-
- uses
-
- TalkerIntf;
-
- type
-
- TDelegateTalker = class(TInterfacedObject, ITalker)
- private
- fActualTalker : ITalker;
- public
- co
Yes, that makes sense.. probably best not to over complicate it.
James
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Thursday, August 29, 2019 2:18 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] USB Human Interface Devices
I see your point. But since libusbhi
I see your point. But since libusbhid is mostly a wrapper library, its
messages are going to be a higher level of debugging anyway - mostly
related to how you handle a particular device. So once you are confident
that things are working for your device, turning debug off completely seems
the way to
Yes, and besides the errors, everything else seems to work properly. I did
notice that the one machine uses an AMD processor and all the others are Intel,
not sure what that would have to do with anything, but it is a major system
configuration difference.
Thanks for the debug level infor
I would chalk this up to differences between OS versions, configurations,
devices, etc and move on. I see all memory is released. At least it does
not crash and burn badly.
The function call you want to play with is:
libusb_set_debug
http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b
At least I can shut off the messages with that.. but any idea what these
messages actually mean? It’s an init_device error but no one was tying to do
anything but get the list of devices from the system.
Is there a description of the verbosity level anywhere?
Is this a variable I can ch
Looks like email removed all my linefeeds...
Here is the output with errors on just the one sytem:
https://pastebin.com/axtH3hvn
Here is typical output on all other sytems:
https://pastebin.com/ZaJYU3ak
James
-Original Message-
From: fpc-pascal On Behalf Of James
Richters
Sent: Thurs
libusb has a debug verbosity level which currently is set to 3 (i.e., very
verbose) in the device open function.
There is a define in libusbx.pas that you can change to shut off debug
messages.
On Thu, Aug 29, 2019 at 12:03 PM James Richters <
ja...@productionautomation.net> wrote:
> Now I have
I use circular buffers for another project as well, but I made my own.. and the
program doesn't use threads... it's buffering data being sent to a serial port
in a really complicated way with a series of loops and timers to manage to
function in a single thread... I'm thinking of overhauling it
Now I have a new strange issue. I've been working with my sample program
here: https://github.com/Zaaphod/libusbxhid/blob/WHB04B-4/whb04b.pas
And it's been working just fine for me.. just some minor little tweaks and
adding new functionality.. etc.. I was just about to start to merge this in
Yes , and it works well on Linux.
I use it on a circular (ring) buffer where the main program reads data from
the circular buffer and increments the read index while a totally random
thread reads data from an incoming Ethernet UDP , serial port or a custom
hardware port , writes to the circular bu
Thanks for the Sybcobs suggestion, I didn't know there was such a thing but it
seems like a great way to prevent simultaneous data/hardware events.
James
-Original Message-
From: fpc-pascal On Behalf Of Brian
Sent: Thursday, August 29, 2019 10:50 AM
To: fpc-pascal@lists.freepascal.org
Su
A bit of clarification ..
Also rather than using critical sections , use syncobs to ensure that you
are not trying to /SIMULTANEOUSLY/ read and write to the same USB address or
your data memory.
Try using an Ethernet UDP connection to simulate the USB connection as it
may illuminate an issue in
A few general thoughts. Having been in similar situations when dealing with
hardware interfaces .. the hardware is what it is .. and annoying as it is
you have to work around it , as the hardware isn't going to change.
It seems you have two problems 1) the USB hardware and 2) your program , in
whi
14 matches
Mail list logo
