I'm learning about Eddystone beacons (URL at this moment) and I'm trying to understand the purpose of each field. I'm getting a bit hung up on one, mainly because it's not explained.
https://hackaday.io/project/10314-raspberry-pi-3-as-an-eddystone-url-beacon
has Flags Data as 0x06, while
https://github.com/google/eddystone/blob/master/eddystone-url/implementations/linux/advertise-url
uses 0x1A, but neither explains why the value is set there. The rest is more or less understandable, but I just don't get this bit. Can anyone elaborate?
Thanks,
Matt
The flags are described in supplement to Bluetooth Core Specification in section 1.3.
The difference in your case is:
0x06 - The device is BLE only. The full Bluetooth stack is not supported.
0x1A - The device can be used as BLE as well as full Bluetooth Controller/Host simultaneously.
Related
I have a project that needs to be compatible with STM32F1s and STM32F4s. I'm starting with a basic project that can use GPIOs and am now trying to get USB HID support. I have USB HID working on STM32F4s with another project using the standard peripheral drivers and USB OTG, but am having a difficult time with the HAL drivers. No matter what I've tried the USB device keeps showing up as an Unknown Device in windows. Where can I best start debugging this issue? Stepping through the code with an SWD makes it seem like the board seems to be working as it should. As far as I can tell the endpoints and descriptors for HID are correct.
Use STM32CubeMX to setup USB for you. Then you need to change the heap size, because the default one is not big enough. For some reason, you cannot change the heap size from STM32CubeMX. To change it, you need to edit the start up file (startup_stm32f4.....s) and find the line:
Heap_Size EQU 0x00000200
and change the value to a bigger one, for example:
Heap_Size EQU 0x00002000
I want to write a usb touchscreen kext for usb touch screen .
I have read the Kernel Extension Programming Topics and the I/O Kit Fundamentals etc,
My question is,
1 . how to get the input report messages from touch screen ?
2 . how to post the coordinate info to system ?
I have no idea, anybody help?
It depends on the hardware; moreover, this question is quite broad - you'll need to be more specific in your question to get more specific answers. I'll try to provide a broad overview:
A touchscreen has 2 parts:
Output: showing the image coming from the computer on the display
Input: the touch events to feed back into the computer
As you haven't asked about (1) at all, I assume your device just plugs into a display port on the Mac and is already displaying correctly. If not, you'll want to look into the IOFramebuffer API.
For (2) - Pretty much all USB input devices are HID devices of some form. If you're new to HID in general, you'll probably want to read and understand the USB HID specification and related documentation as you'll be using that information throughout.
OSX already comes with comprehensive support for the standard HID device classes such as keyboards, mice, touchpads, graphics tablets, etc. If your device claims to be any kind of HID device, OSX should already be detecting it and attaching its generic HID driver to it. You should see a IOUSBHIDDriver instance in the I/O Registry (eg. using Apple's IORegistryExplorer tool, or ioreg on the command line).
I'd also expect your device to conform to HID's absolute pointing device profile, so at least single touches should already be working properly. If it's a multitouch device, or you need other extra features, you'll probably want to implement a IOUSBHIDDriver subclass that generates or converts the necessary multitouch events.
If your device for some reason isn't already a HID USB device, you'll need to write a custom USB driver for it, and convert the events coming from it into HID events, as the HID events are passed directly into userspace and processed there. You can actually write USB drivers and generate HID events from userspace, so you might be able to avoid writing any kernel code at all if you prefer.
Apple provides some documentation on HID:
The HID Class Device Interface Guide covers some general concepts and the userspace interfaces.
The Kernel Framework Reference has API documentation for the various IOHID* classes in the kernel.
If you're going to be writing your own kernel HID device driver, your best bet is probably the IOHIDFamily source code. You can probably also find some open source examples around the web.
Apple's USB mailing lists is probably also worth checking, both for the archives and if you have questions. The darwin-kernel and darwin-drivers lists are also relevant.
I've been looking for a detailed description for how USB protocol and cabling works for a long time with no luck. I am looking for a detailed yet not overcomplicated explanation of how things work on the software and hardware side of USB. Links and explanations would be appreciated. I've really run out of ideas, so it would be great if you can help me out.
This is what I do know:
USB hardware carries 4 lines- 5V power, ground, and 2 full duplex lines.
When connecting, the device can ask for a specified amount of current.
The transfer speeds for USB are quite fast compared to traditional serial connections.
When connecting, a device will output descriptors to the host describing itself. These descriptors will also be used for data.
What I don't know:
How does a program in C/C++ write directly to a USB port? Does it write to an address in the port?
How do some devices describe themselves as HID?
How do drivers work?
Everything else...
Thank you!
Identification
Every device has a (unique) Vendor and Product ID. These are provided (sold) by usb.org to identify a device. You can use a library like libusbx to enumerate all connected devices and select the one with the Vendor and Product ID you are looking for.
HID Descriptors
The point of HID descriptors is actually to do away with drivers. HID descriptors are a universal way of describing your device so you don't need to waste time on a driver for every system/architecture/etc/. (Same concept as the JVM.)
Reports
You will use either the input, output, or feature reports to read or write to your device. You send a stream to your device on the input or feature report. This is typically 8 bytes I believe. Only one of which is a single character you wish to write. The HID descriptor contains all the information you need to put together a report. Although I'm struggling to find a related link to clarify this.
Potential Libraries
In an effort to be open-minded here are all the libraries I am familiar with and some info about them.
libusb-0.1
First off is libusb-0.1. This used to be the go to and was built in to many Linux kernels and Windows I believe. It is very easy to use and there is a lot of documentation. However, the owner never updated and it wasn't edited for many years. It supports only synchronous transfers. (If an error occurs, the program can wait infinitely while it expects a transfer.)
libusbx
Next is libusbx. This is what most people would suggest today and I agree. It was published by those frustrated by the owner of libusb-0.1. The code is much more lightweight, up-to-date, and importantly does not require root privileges like libusb-0.1 and libusb-1.0 (Discussed in a second). It supports synchronous or asynchronous transfers.
libusb-1.0
Then there is libusb-1.0. This was the first update to libusb-0.1 in some number of years. It is not compatible with libusb-0.1. This was published the same day as libusbx as a retaliation (I assume) and an attempt to rectify the lack of updated content and conserve a user-base. It supports synchronous or asynchronous transfers.
hid.h
Finally, there is the hid library. This was built on top of libusb as another layer of abstraction. But honestly, I think it's just really confusing and it just adds more overhead than necessary.
Some Good Resources
Understanding HID Descriptors
Control Message Transfer Documentation (Very Good Link IMO)
Rolling Your Own HID Descriptor
Good Visual of HID Reports for Transfers
Great List of bmRequestType constants (You will need this or similar)
A simple terminal app for speaking with DigiSpark using libusbx and libusb-0.1
I know this isn't exactly what you are looking for, but maybe it will get you started!
This website has a general overview of how USB devices work:
https://www.beyondlogic.org/usbnutshell/usb1.shtml
Particular sections give answers to things from the list of things you don't know yet about USB.
E.g. to find out how USB devices identify themselves, read about USB descriptors:
https://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors
To learn how a C/C++ program can talk to a USB device, see examples on using the libusb library:
https://github.com/libusb/libusb/tree/master/examples
To learn how USB drivers work, see a tutorial from Bootlin:
https://bootlin.com/blog/usb-slides/
I would like to create a scenario to directly access IOs via USB by using FT232R.
In more detail, scenario is the following: I would like to feed an LIN transceiver IC by a FT232R USB device. However, the FT232R as a USB-serial-converter outputs UART signals, which includes a start bit as well as a stop bit. For me, it is required to not have these start and stop bits, even though they are standardized in UART protocol.
My questions:
Is it possible to use the bang mode of this device to avoid start/stop bits and transfer raw data? Then, how to program the code for doing this?
If not, are there any USB transceiver, which have to possibility via COM/driver access to fulfil my requirement?
Thanks a lot in advance for your help!
Yes, the chip provides 4 pins that can be used for generic bit banging. Here is an application note describing how to use bit banging mode.
I have been tasked to write a device driver for an embedded device which will communicate with the micro controller via the SPI interface. Eventually, the USB interface will be used to download updated code externally and used during the verification phase.
My question is, does anyone know of a good reference design or documentation or online tutorial which covers the implementation/design of the USB protocol stack/device driver within an embedded system? I am just starting out and reading through the 650 page USB v2.0 spec is a little daunting at the moment.
Just as a FYI, the micro controller that I am using is a Freescale 9S12.
Mark
Based upon goldenmean's (-AD) comments I wanted to add the following info:
1) The embedded device uses a custom executive and makes no use of a COTS or RTOS.
2) The device will use interrupts to indicate data is ready to be retrieved from the device.
3) I have read through some of the docs regarding Linux, but since I am not at all familiar with Linux it isn't very helpful at the moment (though I am hoping it will be very quickly).
4) The design approach, for now at least, it to write a device driver for the USB device then a USB protocol layer (I/O) would reside on top of the device driver to interpret the data. I would assume this would be the best approach, though I could be wrong.
Edit - A year later
I just wanted to share a few items before they vanish from my mind in case I never work on a USB device again. I ran into a few obstacles when developing code and getting it up and running for the first.
The first problem I ran into was that when the USB device was connected to the Host (Windows in my case) was the host issues a Reset request. The USB device would reset and clear the interrupt enable flags. I didn't read the literature enough to know this was happening, thus I was never receiving the Set-Up Request Interrupt. It took me quite a while to figure this out.
The second problem I ran into was not handling the Set-Up Request for Set_Configuration properly. I was handling it, but I was not processing the request correctly in that the USB device was not sending an ACK when this Set-Up Request came in. I eventually found this out by using a hardware USB protocol analyzer.
There were other issues that I ran into, but these were the two biggest ones that took me quite a while to figure out. The other issue I had to worry about is big-endian and little-endian, Freescale 9S12 vs USB data format (Intel), respectively.
I ended up building the USB device driver similar to UART device drivers I had done in the past. I have posted the code to this at the following URL.
http://lordhog.wordpress.com/2010/12/13/usb-drive
I tend to use structures a lot, so people may not like them since they are not as portal as using #defines (e.g., MAX3420_SETUP_DATA_AVAIL_INT_REQR 0x20), but I like them since it makes the code more readable for me. If anyone has questions regarding it please feel free to e-mail and I can try to give some insight to it. The book "USB Complete: The Developer's Guide" was helpful, so long as you knew what areas to concentrate on. This was a simple application and only used low-speed USB.
While writing a device driver for any interface (USB, Parallel port, etc...) the code needed to be developed would depend upon whether there is any Operating System(OS), RTOS running on that Processor/Micro controller.
e.g. if thats going to run say WinCE - It will have its own Driver development Kit , and steps to be followed in the device driver development. Same for any other OS like Linux, symbian.
If its going to be a plain firmware code(No OS) which is going to control the processor/microcontroller, then it's a different situation altogether.
So based on either of the above situation u are in, one needs to read & understand:-
1.) The Hardware Specification of the processor/micro controller development board - Register files, ports, memory layout, etc.
2.) USB spec
3.) Couple of pointers i found quickly. Google shud be ur friend!
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/ - Linux USB device driver
http://www.microsoft.com/technet/archive/wce/support/usbce.mspx
-AD
I've used an earlier edition of USB Complete by Jan Axelson. Indeed very complete.
From the editorial review:
Now in its fourth edition, this developer's guide to the Universal Serial Bus (USB) interface covers all aspects of project development, such as hardware design, device firmware, and host application software.
I'm curious, why did you pick the 9S12? I used it at a previous job, and was not pleased.
It had lousy gcc support so we used Metrowerks
which may have been okay for C, but often generated buggy C++
had a lousy IDE with binary project files!
The 9s12 was also slow, a lot of instructions executed in 5 cycles.
Not very power efficient, either.
no barrel shifter, made operations that are common in embedded code slow
not that cheap.
About the only thing I dislike more is an 8051. I'm using an ARM CortexM3 at my current job, it's better than a 9S12 in every way (faster clock, more work done per clock, less power consumption, cheaper, good gcc support, 32-bit vs. 16-bit).
I don't know which hardware you're planning to use but assuming that's flexible, STMicro offers a line of microcontrollers with USB/SPI support and a library of C-code that can be used with their parts. -- I've used their ARM7 series micros for years with great success.
Here is an excellent site maintained by Jonathan Valvano, a professor at the University of Texas. He teaches four courses over there (three undergraduate, one graduate), all are about using a 9S12 microcontroller. His site contains all the lecture notes, lab manuals, and more importantly, starter files, that he uses for all his classes.
The website looks like it's from the 90's, but just dig around a bit and you should find everything you need.
users.ece.utexas.edu/~valvano/
Consider AVR for your next MCU project because of it's wonderful LUFA and V-USB libraries.
I'm working on a project using the Atmel V71. The processor is very powerful and among lot's of high end connectivity offered on chip is a USB engine that will do device or host modes for 480 Mhz or 48Mhz (not USB 3.0). The tools are free and come with a number of host and device USB example projects with all the USB stack code right there. It supports 10 end points and all the transfers are done via DMA so you have most of the processor horsepower available for other tasks. The Atmel USB stack works without needing an RTOS