I am playing around with a PIC16F1455, using the USB port based on this article: https://www.codeproject.com/Tips/530836/Csharp-USB-HID-Interface
I send data to the port, and I set the packet size (Configuration descriptor) to 8 bytes.
However, the PC sees the Capabilities.InputReportByteLength as 9 bytes
And when I receive I get 9 bytes, the first one always being 00, followed by the 8 bytes I send from my device.
Can anyone tell me why this happens?
And this first 00, what is this used for?
Can I put something real there?
Related
I am using the STM32F479 microcontroller along with a AFE440 Analog Front End. When data is ready to be read on the AFE I get a trigger via the ADC_RDY pin on the Microcontroller. At this point I need to read 4 different registers on the AFE all with 3 bytes of data and store them in a buffer. (3 * 4 = 12 bytes total). Then I want my processor to sleep until I get another event on the ADC_RDY pin at which point I read another 12 bytes. I want to store the 12 bytes read each time in a FIFO buffer of size 120 bytes.
I would like to read and store the bytes into the Buffer all using DMA. My processor will be a sleep during this transaction. It will wake up once the FIFO buffer is full with 120 bytes and process the data.
How would I go about setting this up with ST ?
I am working on a project with a master computer connected via a CANOpen network to 4 slaves.
At each time step, the computer receives a measurement message from each slave, and sends them a control message. In total, 4 messages are received and 4 messages are sent at each time sample.
The message sent is a PDO with 6 data bytes (8 bytes including COB-ID)
The message received is a PDO with 8 data bytes (10 bytes including COB-ID)
My CAN network is configured at 1Mbit/s, and I run my program at 1000 Hz (1 ms sampling time). As the total load resulting from the messages described is 576 bits/cycle, the total load expected in the network is 576kbit/s, or 57%.
What I see, however, is that:
The controlling computer measures a load of ~86% (with minima of 68% and peaks of 100%).
A USB CAN bus analyser I connect to the network registers a traffic
of messages (count-wise) that is around half of what I nominally
expect (i.e., 4 sent, 4 received each cycle, for 50 seconds should result in 50k messages, while I only see 18-25k). Moreover, I receive
1-2 error messages per cycle from the slave devices that the
network is overloaded. Before it is pointed out, even counting the
size of these messages as part of traffic wouldn't get close to
explain the anomaly in load.
What I'd like to know is whether my way of calculating the CANOpen network load is correct. For instance, are there any protocol-specific handshakes, CRCs, or any sort of extra bytes sent to make the network simply work? It's nothing I could see in the wiki page of CANOpen, but I do know there are such appendices to messages in the original CAN bus standard.
In a CAN message, there is more than the data to be transmitted.
There is also the arbitration ID (11- or 29bits, depending on whether you use CAN 2.0A or 2.0B), there is a 15 bit CRC, an 7 bit EOF marker, the control field and also some other reserved bits.
Depending on the data, there may also be stuff bits.
Using CAN2.0B and assuming 48 bits (6 bytes) of data, you will get a message size of roughly 132 bits and roughly 151 bits for your 64 bits messages.
Summing this up, you will get roughly 1132 bits per cycle which is too much for a 1Mbit/s bus and 1000 Hz.
Hope that helps.
hw : lpc1549 eval board with usb hid test firmware ...
endpoint size 64 bytes
endpoint intr reads out-report buf and displays len and data in hex ...
copies out_report into in_report buf and echoes back with write funct and len
host :
using qt5 , libusb-1.0.19 wingw32 dll and hidapi code
hid test code issues all your api calls (except write and read) sucessfully in linux, win7 and win8.1
test code issues hid_write followed by hid_read and get's data back properly in linux
i am not using the, by hidapi hid_write mandatory flagged Report ID, since the nxp firmware and keil software do not use it (as far as i could figure out) ...
my linux sw sends and receives a defined 64 byte pattern or smaller len) correctly and byte [0] is part of this pattern ... out and in byte [0] data is intentionally different and correct received
running the keil hid client under windows succeeds to properly communicate with the lpc1549 firmware, even they only transfer and echo one byte ...
my firmware has the endpoint size changed to 64 bytes (i hope my changes are correct) and the keil hid client works with it in windows so my assumption is that my descriptors are correct ... hopefully
host sw kububtu 14.04
hid_write len = 17, device 17 bytes received, 17 bytes indicated as received ... all seems to work properly
host sw with hidapi in win 8.1
hid_write len = 17 bytes shows up on device with 16 bytes correct and the rest is 0, but the read indicates a received len of 64 ... i issued a write of 17, received 16 correctly, but was indicated as 64 received
also win 8.1 throws a blank system32/cmd prompt window up ... why ???
the same hangs on win7 and only a hid_write len = 0 succeeds ... popping the same cmd prompt ... received len = 64, but no data transferred (as it would make sense with len = 0)
i can not single step or breakpoints since qt debugger get's segment fault upon app loading
also i link in my qt app to the hidapi "windows/hid.c" code and it is now part my code
sorry for my rather complicated description
why is a Report ID mandatory if it's not being used ... it would be a waste of one byte and if uint32_t alignment is required it would be a waste of about 7 % of the 64 bytes data
why does the keil hid client written in c++ msvs work correctly with my fw and hidapi not
would the functioning of the keil hid client indicate that my fw and my descriptors and report len are correct
What would cause an empty cmd prompt popping up?
What could i be doing wrong (a whole hidapi based app is correctly communicating with a complete usb based firmware pgm, not just the described test code)?
after a couple of days a few things got clear
the ReportID seems to be something in windows and on the host side only ... the firmware is not effected on my setup
also what was not to clear initially is that the ReportID is in addition to the max of 64 report bytes
so i create a buffer with 1 + 64 bytes = 65 ... the 1st one is zero since i do not use the ReportID mechanism and the remaining 64 are normally used
the write call data size needs to be therefore 1 + whatever the reportsize is in the usb hid descriptor endpoint side
in linux there is no ReportID on hid what i could see
next : make sure the data length specified in the write call on the host as well on the device match exactly the endpoint size definitions, otherwise no data gets across either direction and your software might hang (wait forever) on the read on the other end
i hope this might help others to get a better pict of the windows end of the hidapi hid_write calls
Alan Ott wrote me the following
http://www.signal11.us/oss/hidapi/hidapi/doxygen/html/group__API.html#gad14ea48e440cf5066df87cc6488493af
There is always a report ID. You must always send a report ID in HIDAPI, but it will not be sent to the device if the report ID is 0.
I encounter some problem when I develop a network card driver in Linux. As we all know the MTU refers to the MAX size of IP packet without fragment. And the skb sent to xmit function will be added 14bytes including dst mac addr,src mac addr and lengh. but it's very odd that when I use different values for MTU, the added size to it is different, sometime it's 10bytes, sometime it's 14bytes. It's depending the size of MTU. For example, I use 7828 as the size of UDP payload, when MTU is 7700, the size of skb in xmit function is 7714, while when MTU is 7800, the size of skb is 7810. Can anyone explain this? I guess maybe there are some align limitation for IP packets, but I didn't find that.
I searched the answer from the internet, and I found that there is an align limitation for payload field of IP frame. The payload field must be align to 8 bytes. So if the MTU is 7700, the true size of IP frame should be 7680+20 = 7700 because 7680 can be divisible by 8. While if the MTU is 7800, the true size of IP frame should be 7776+20 = 7796 because 7780 can't be divisible by 8, the last 4 bytes will be assigned to next IP fragment.
Im using UDP packets and I want to be cleared about some points :
1 - what exactly does "recvfrom" Returns ? I mean if i send a packet with size of 450 byte + 20 byte of IP header + 8 byte UDP header does recvfrom returns 478 bytes as a whole or there could be something like :
it received 10 bytes,300 bytes,100 bytes,68 bytes ?
2 - does the return value of "recvfrom" related to packet fragmentation ?
note :
* Im talking with the assumption that "recvfrom" was successful
* I chose 450 byte to be sure that Im less than the min MTU
For an UDP socket, recvfrom() reads the UDP data. So it returns 450 , provided you supply a buffer that is at least 450 bytes big.
If you supply a buffer that is smaller than the received data, the data will be truncated, and recvfrom() will read as much data as can fit in the buffer you give it.
The IP layer will be the part that fragments an UDP packet, on the receiving host it will reassemble it. This is transparent to the sending/receiving application.