I'm trying to RTFM the HID Usage Tables
FOR
Universal Serial Bus (USB) v1.22 and the second paragraph of section 14 (Telephony Device Page) has this to say:
Indicators on a phone are handled by wrapping them in LED: Usage In Use Indicator and LED: Usage Selected
Indicator usages. For example, a message-indicator LED would be identified by a Telephony: Message usage declared as
a Feature or Output in a LED: Usage In Use Indicator collection.
I think this means that there is some way to get the the Telephony state in an output report (the "message-indicator" in their example), but I have no idea from this description how to implement this in a HID report descriptor. Can someone provide an example section of a HID report descriptor that make use of the usage in use indicator as described?
Found example of the Usage in Use Indicator in Example A.10 (p. 144) of an older version (v1.12) of the same document (I would recapitulate the example here, but copying content from the original document is disallowed)
Furthermore, Table 11.6 (General Device Indicators, p.21) of the v1.12 document clarifies the definition of the Usage In Use Indicator and section 3.4.4 (Alternate Types, p. 66) describe the effect of the Usage In Use Indicator.
Related
In the Native Widgets and Custom Widgets section of Accessibility Insights for Web, the assisted test highlights widgets on the webpage being tested.
In the "How to test" section of the "Cues" section for Native Widgets and Custom Widgets , the tester is guided to interact with the highlighted widgets to determine whether it adopts any of these states: Disabled, Read-only, Required.
However, even though WCAG 2.1 SC 3.3.2 Labels or Instructions explicitly states that inputs have labels, including clear indication of required fields, the "How to test" section does not include verification that those Required fields have a visible indicator. It only directs the tester to "inspect its HTML to verify that the states are appropriately coded.
Thus, a required field could be one that exposes its required state to a screen reader but doesn't have a visible indicator that it's required.
Shouldn't AI for Web include a test for a visible indicator for fields that are required?
Thank you for the suggestion! I work on Accessibility Insights, and I've created a feature request in our github repo for this. Our team will take a look and decide what should be done, and will update this question once we address it.
UPDATE: We believe that failure to visibly indicate required fields is not a violation of this (or any) SC. Neither the 3.3.2 SC itself nor the Intent section of the Understanding document explicitly mentions it, nor is there a documented Failure example for it. (It does appear in the Examples and Sufficient Techniques, but those don't constitute requirements.) I believe the need to communicate required fields is addressed by Errors > Error identification.
I am trying to flash the very first u-boot binary file (uboot.bin) into blank NOR flash of a brand new blank board which has marvel 370 soc(ARM) using Teraterm(xmodem/ymodem/zmodem)
When I compile the uboot, I get two binaries like uboot-uart.bin and uboot.bin.
What is the difference between two binaries?
I have been instructed to make some dip switch changes and then load uboot-uart.bin first into the prototype board.
From manual I understand that the dip switch setting is to set "Boot from Uart" to Boot source list.
I am new to embedded and want to learn more about this from u-boot perspective. Where can I learn about this?
Would also like to know what these xmodem,ymodem,zmodem things are?
And would also like to learn how to customize u-boot for a custom board using marvel 370 soc(ARM)?
I would be happy if someone can point to good resources.
XModem itself is a quite simple protocol which is meant to send files over a serial link it is explained in detail here.
Most Marvell ARM-Chips in the last couple of years have the possibility to upload a binary via UART using the XModem protocol. There are two ways to do that.
By sending a special sequence to the chip during bootup (which can be done without any changes to the bootstrap options).
By setting up the bootstrap options accordingly (via DIP-Switches in your case)
In both cases the chip will then initiate an Xmodem-download. TeraTerm should have an option to upload files via the xmodem protocol. IIRC it is available under File/Transfer/XModem/Send.
If you know just send your "uboot-uart.bin" file to the Armada 370 (which will take some time). The SoC will now boot the file just like if it was loaded from NAND or any other source.
The only difference between your uboot-uart.bin and uboot.bin is most probably the special header which has to be put in front of the actual uboot-binary, it contains the bootdevice type the image was meant for, the address in memory where the image should be loaded to and a lot of board specific settings. The exact structure and content is usually explained in the very excellent datasheets from Marvell.
For customizing uboot I can only suggest to dig into the code provided by Marvell and change it according to your own board. You'll find the board specific files under boards/Marvell.
This question already has an answer here:
Something turns on GPS but what? How do I find which Object uses GPS?
(1 answer)
Closed 9 years ago.
If I used
[self.locationManager startUpdatingHeading];
An arrow shows up on status bar.
Does
[self.locationManager startUpdatingHeading];
uses GPS?
If it doesn't, why arrows does show up on statusbar?
Note: I've read the documentation. True heading is available only if location is enabled. What I am thinking is
Enable location
Get heading once.
Compute difference between true heading and magnetic heading.
Store that number in a static variable.
Disable location.
Every time heading is updated, get the magnetic heading, and then add the difference between true heading and magnetic heading.
Another thing I think might work is to set location accuracy to be so wide that it doesn't require GPS at all.
I wonder if it's possible. For example, can we disable location update programatically? As far as I know calling stopUpdatingLocation does not turn off location update (didUpdateToLocation no longer called but an ugly arrow is on status bar).
self.locationManager.locationServicesEnabled=false doesn't work because the property is a class property that's read only. Looks like there is no way to turn off locationServices and yet update heading. I may be wrong. Am I?
Basically I want to help my visitor see direction without excessive GPS.
Of course, startUpdatingHeading uses GPS.
From CLLocationManager Class Reference:
In iOS, a device with the appropriate hardware may also report heading information. When the value in the headingAvailable property is YES, you can use a location manager object to retrieve heading information. To begin the delivery of heading-related events, assign a delegate to the location manager object and call the location manager’s startUpdatingHeading method. If location updates are also enabled, the location manager returns both the true heading and magnetic heading values. If location updates are not enabled, the location manager returns only the magnetic heading value. These features are not available in OS X.
The Location Services are designed to be as efficient as possible, to minimise power consumption and increase battery life. For example, the API allow you to declare to the service how much measurement accuracy is required, because more accuracy requires more hardware and power. If you only require low accuracy (eg ~10km) you can simply use the cell towers for location info, which is cheap as the radio is already active. If you need more accuracy than that (eg. a few km) the hardware might switch to triangulation using WiFi hotspot information, which requires a medium amount of power. But for the highest accuracy, the system will enable the GPS unit, which consumes much more power.
However, if you only request heading information, the magnetometer alone will be used (provided the hardware supports it; ie. iPhone 4+ IIRC). The GPS unit will not be enabled in this instance. As per the CLLocationManager Reference:
If location updates are not enabled, the location manager returns only the magnetic heading value.
As for the arrow indicator in the status bar, this is displayed whenever any app uses Location Services. If you open the built-in Compass app, you'll notice the arrow is displayed there also, even though it only manages heading data.
Using stopUpdatingLocation is separate to stopUpdatingHeading and will only stop calling your location callback, while also powering down the hardware resources as appropriate.
As for locationServicesEnabled, this is set to YES if the services are enabled on the device (by the user), which is why the field is read-only.
So, simply call startUpdatingHeading and provided you don't call startUpdatingLocation, you don't need to worry about the GPS. The steps you mention are not necessary as CL is already doing the hard work for you.
This information is all covered in the reference:
CLLocationManager Reference:
I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
I´ve been googling for a week and the following four links are the best I have found:
http://www.brackeen....vga/basics.html
http://www.osdever.n...VGA/vga/vga.htm
http://bos.asmhacker...sing%20bios.htm
Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!
--Vincenzo
my code at http://bos.asmhackers.net/docs/vga_without_bios/snippet_5/vga.php
works fine if you are in 32bit mode with full hardware access. Unfortunately I doubt that any Linux variant will let you directly access the VGA ports. I'm not sure how you develop this driver, but if you made sure that you have full access to the VGA ports it should work. In my example code I only switch between mode 0x03 and 0x13, but in the folders above you'll be able to find port values for most other common VGA modes, as well as C code to do the switch if you prefer that.
Christoffer code include files are found BOS operating system source code like text.inc and font8x16.inc
http://bos.asmhackers.net/downloads.php
This is coming many many years later but I think it's still very relevant and if somebody is struggling I hope they can find it useful.
First of all, it is completely possible to configure VGA only using registers without interrupts, as hard as it may be. A useful resource about registers and how to configure them can be found here, but unless you have a ton of time to spare to learn how to properly do all of it, move to the following section.
If you wish to really learn how to do it, I suggest going through with the documentation provided earlier. However, some of it is already done!
Chris Giese did a great job demonstrating exactly how to do this for MS-DOS system, and while you may think that doesn't help you, it really does.
Chris's code can be found here. If you want another useful codes check here as well.
Now, while it only works for MS-DOS it's actually easy to convert to other systems. The code already contains all data needed to configure the registers in many different modes. And that's the part that saves you a ton of time going through documentation.
The code uses functions outportb, inportb, which are MS-DOS functions, to write/read single byte to/from a port. Therefore, you have to redefine these functions to read/write for your own system. Redefinition complexity depends on the system you operate on.
In addition, you will also need to provide means to write to physical memory region between 0xA0000-0xBFFFF which corresponds to standard VGA memory area. Once you have that allocated, you need to also redefine the functions pokeb pokew peekb which will help you output things (text or pixel data) on the screen.
One last note: the code is already defined to work with many different modes including both text and display modes.
looking to bit-bang the I2C interface of a MCP23017 with an ATtiny13A, a lot of places mention HI2COUT as a method to send data on the I2C bus but i have no clue if this is part of a language or a Library or even a description of what happens when called. so the questions:
1) where can i get info on HI2COUT?
2) if any one has ever interfaces with an MCP23017 can you post the proper sequence to set 1 (or all) pins as output and set HIGH? (this includes start, write address, write register IOCON, ..., stop, etc...)
3) this may be to "Hardware" like for stackoverflow if anyone knows of a site better suited for this question (or may have the answer) please let me know.
Do you mean you're interested in programming the ATtiny13A (so that it can talk to a target device, which happens to be a MCP23017 but that's not an important detail)?
Just guessing, HI2COUT might be the name of a memory-mapped register to output data to the I2C peripheral of a microprocessor. However, looking at the ATtiny13A data sheet and the MCP23017 data sheet, I can't see such a register named. Perhaps that is the name of a register for an I2C peripheral of a different type of microprocessor?
The MCP23017 has I2C hardware built-in--see section 1.3.2 "I2C Interface" starting on page 5 of the MCP23017 data sheet. It will tell you how to do I2C on that device. But assuming it's the ATtiny13A you want to program, it looks as though it has no I2C hardware, so as you say, bit-banging is needed.
I suggest doing an Internet search for "ATtiny13A i2c" and you should be able to find several examples.