|
|
By Oleg Mazurov Today Kristian added support for STM32F4-based NUCLEO-F446RE board. The board is available from the manufacturer for little more than ten bucks which is pretty good for this type of MCU. The commit can be examined here.
Even though NUCLEO claims Arduino compatibility the 2×3 SPI connector is absent. It means that many modern Arduino shields, including full-size USB Host Shield, won’t work on this board. For his setup, Kristian used USB Host Mini wired as described in Teensy 3 wiring article. More information is available in the example repository on Github.
Thank you, Kristian!
By Oleg Mazurov The alpha of the third revision of USB Host library has been posted on GitHub. The code has been extensively re-organized to make it modular and generic; as a result, it is now possible to run it on more Arduino compatibles and also use native USB Host hardware on some of them. At the time of this writing, USB Hub and Mass Storage classes are supported, the work on migrating the rest of device drivers is in progress.
The code is to be used with Arduino IDE 1.6.1 or newer, please upgrade before attempting to compile it. Also, please read the README file for more details. If you encounter any issues, post them in the issue tracker on GitHub.
The credit for this commit goes to Andrew Kroll – thank you!
By Oleg Mazurov  XKeys backlight control contacted me a while back with a project involving XKeys – a series of HID keyboards with extended functionality. Tom also offered to lend me XK-16 Stick; after receiving it I made a small addition to the USB Host Shield library and soon after Tom e-mailed me back asking to test his code. The picture on the left shows one of the example sketches, a “blinky” of sorts, where all backlights are sequentially turned on and off.
Xkeys can be controlled by sending proprietary (but well documented) output report which doesn’t follow standard HID report format. By sending this report it is possible to turn LED integrated into each key on or off, change light intensity, as well as switch the keyboard on the fly between mouse, joystick, and keyboard emulation modes. Larger keyboards have some additional features. In addition to that, products are very maker-friendly; for example, a manual for XK-16 Stick contains this:
Customization
The electronic design of the X-keys Stick is such that the stick may be cut off to any length after the second key. P.I. Engineering will perform this service in our lab for a fee including testing to maintain the warranty, or you may contact us for specific instructions if you wish to do it yourself.
The big disadvantage of Xkeys is price. However, if you want you project to look professional but don’t have much time to refine it, a good looking user interface can be produced very quickly with Xkeys.
Tom’s library implements programmer’s interface to extended keyboard features (sans cutting). Easy to use functions are provided enabling direct access to programmable features of each key or LED. Thank you very much, Tom!
By Oleg Mazurov  ChipKIT Uno32 with USB Host Shield and I were talking a lot about running USB Host Shield at higher SPI speeds. We were discussing one peculiar case of seemingly defective SPI master module and were needed full sized shield-compatible host board with fast SPI to check our theories when I realized that I have two Digilent ChipKIT Uno32 boards sitting in my ever expanding “to-do” pile of projects. I sent one to Andrew and soon he made a port which compiles under Digilent’s IDE and runs on chipKIT boards, although we only tested on Uno32 (rev.B).
It should be noted that another good candidate for the host board capable of high-speed SPI would be Arduino DUE. It is supported by the library and presumably runs at up to 24 MHz SPI speed with full-size shield. Incidentally, none of us have a DUE so we can’t test. Donations are gladly accepted.
The chipKIT support is currently in beta. At the moment, the only code example I have verified is Board QC routine – a program I’m using to test the shields before selling them to people. The port lives in xxxajk branch. Making other examples work should be a simple matter of (quoting Andrew) “including the right SPI.h”. Indeed, nothing in the library relies on SPI speed so increasing it would simply allow data to be sent faster.
In this article I will show how I modified a standard full size USB Host shield rev.2.0 to run on chipKIT Uno32 board at high SPI speed. I was able to run up to 20 MHz; unfortunately, the next available SPI rate on Uno32 is 40 MHz which is too high for the MAX3421E chip. The modded shield can be seen on a title picture (click on it to make it larger). Uno32 is 3.3V board; even though the inputs on PIC32 on-board MCU are 5V tolerant and it is likely possible to run the shield as-is I removed the level shifting ICs, which are unnecessary when interfacing the shield with 3.3V boards and could decrease error margin. Also, the RESET line on the ICSP connector on Uno32 has been replaced with CS by Uno32 designer, perhaps to make it look more like SPI, so I also needed to disconnect and reroute it. Here is the implementation, step-by-step.
Continue reading Running USB Host code on Digilent chipKIT board
By Oleg Mazurov
Real time microcontroller applications, such as digital power supplies, motor controllers, and others that utilize one or several real time digital control loops generally can’t be efficiently debugged using LEDs, single-stepping, setting breakpoints, and other traditional programming techniques. In the process of developing a real time system it is often necessary to change a variable on the fly while observing changes in some other variable, also in real time. Microchip MPLAB X and MPLAB IDE have a tool called DMCI (Data Monitor and Control Interface) allowing to do what the name suggests when used in combination with dsPIC and PIC24 micros. I am a big fan of new “enhanced mid range” PIC16 micros and I always wanted to have similar tool to use with these chips. Some time ago I started porting dsPIC RTDM (Real Time Data Monitor, used to communicate with DMCI) protocol implementation to PIC16 and this short article is the announcement of the first working implementation of the protocol.
The title video (expand it to full-screen and switch the resolution to 1080 to see numbers better) demonstrates PIC16F1509 MCU reading its internal fixed voltage reference (FVR). A plot on the right shows, in near real time, last 128 ADC conversions collected into a buffer. A slider on the left allows me to modify sampling delay of the ADC and you can see the difference in conversion when I change this delay from 50 to 20 microseconds. A FVR is high-impedance source and the effect of sampling too fast can be clearly seen. The output is free running, similar to free running oscilloscope timebase; with little extra effort, reads and writes can be synchronized, if desired – see Microchip code examples CE155, CE455 for details.
It should be noted that PIC16 is a very small micro and no amount of clever coding will change that. The RTDM overhead will likely constrain the use of RTDM to test cases rather than real projects. Still, ability to change and read MCU memory on the fly is very useful while testing implementation of digital filters or PID loops.
The C code used to produce the demo along with DMCI config file is available on GitHub. It will run on PIC16F1509 with external 16MHz crystal, other necessary connections being a decoupling capacitor on VCC and a serial connection to a PC running MPLAB X. All software versions are current at the time of writing.
The detailed documentation of RTDM implementation will be posted in several weeks (or so I hope). To increase speed and reduce code size I will be replacing chunks of C code with assembly so if you don’t like assembly, use github commits made earlier than the timestamp of this article. In the mean time, much can be learned from the code itself and developers already familiar with DMCI for dsPIC will have no difficulties using the code as-is.
Please try this code and let me know how it worked for you. Comments can be left in a my Google Plus community or in the “Issues” section of the GitHub repo. You can also use the comment section of the article or by contacting me using one of the e-mails from the “About” section of the site.
Enjoy!
Oleg.
By Oleg Mazurov  Bitmine A1 chip soldered in place Several weeks ago, a friend e-mailed me asking for help building a bitcoin miner based on Bitmine A1 ASIC – a mighty chip capable of 40GH/sec and also very DIY friendly. Last Sunday my friend showed up in the morning carrying a box of parts and in the evening we had semi-functioning board and zero casualties. In this article I’m writing my notes hoping that other builders following the same path may find them useful. As soon as we get working board I’ll build another one and post the real build log.
Note 1: The board we were building is a reference design by Bitmine.ch, a company that designed A1 ASIC. The reference board documentation is inconsistent; the rev.1.0.A schematic is different from rev.1.0.B Gerbers. Several part designators won’t match the PCB silkscreen, and the 500 ohm R12 resistor, likely added to improve stability of 2-phase buck converter, was not present on the schematic and/or BOM; we finally managed to figure out what it is by studying the board’s Pick-and-Place job file.
Note 2: Gerber file of a paste layer (the one used to cut a stencil) has openings for the thermal pads and power rails that are too large, using them as-is caused too much paste to be dispensed. Ohararp, the stencil shop, suggested shrinking some of the openings in half. This has helped, especially for pads with many thermal vias but the amount of solder on A1’s power bars was still excessive – take a look at the title picture, left side of the A1. On the subsequent builds about 3/4 of the paste from the power bars would have to be removed manually.
Continue reading Bitmine A1 reference board build notes.
By Kristian Lauszus 
The PS4 controller is now also supported via Bluetooth. It uses the same API as the other libraries I have written, so if you have used them before, then you should be quite familiar with it.
The example code is available at Github: https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/Bluetooth/PS4BT/PS4BT.ino.
For more information take a look at my blog post: http://blog.tkjelectronics.dk/2014/01/ps4-controller-now-supported-by-the-usb-host-library/. This explains how to pair with the controller and have some background information as well.
You should also check out the readme which will always have the newest information available.
That is all for now. Hopefully this will be useful to anybody out there that wants to use the PS4 controller with the library.
Update 18. January 2014
A USB version of the library is now also available.
By Kristian Lauszus  PS3 keyboard I am glad to announce that Bluetooth HID devices are now supported by the USB Host library. The library already supports PS3 and Wiimote controllers, but now you are also able to use Bluetooth mice and keyboards with the library.
An example is available at the following link: https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/Bluetooth/BTHID/BTHID.ino.
I have personally tested it with a PS3 keyboard (see image), an Apple Wireless Keyboard and an old Bluetooh mouse from Microsoft and all of them works fine.
For more specific instructions on how to use the library I recommend taking a look at the blog post at my own blog: http://blog.tkjelectronics.dk/2013/12/bluetooth-hid-devices-now-supported-by-the-usb-host-library/.
Feel free to post a comment below if you got questions or got problem with a specific device and I will answer as fast as possible.
By Kristian Lauszus  Layout of the Teensy 3.0 I am pleased to announce that the first ARM processor is now supported by the USB Host library. It is the Teensy 3.0 which features an 32 bit Cortex-M4 ARM processor running at up to 96MHz. This is a huge increase in speed if you are used to the Arduino Uno running at 16MHz.
The Teensy 3.0 is created by the Paul Stoffregen which is also a dedicated contributor to the Arduino IDE. If you are looking for a ARM based board for your next project, I recommend taking a look at the Teensy 3.0. A more detailed overview can be found at the official page.
To use the Teensy 3.0 with the library I recommend using the Mini variant of the USB Host Shield as it is much more compact and a bit cheaper too. Since the Teensy 3.0 is running at 3.3V no logic conversion is needed.
Note it is very important than you do not connect a 5V microcontroller to the Mini variant of the USB Host Shield, as this might damage the board. If you are planning to use a 5V microcontroller like the Arduino Uno I recommend getting the full sized version of the shield.
In order to use the Teensy 3.0 you will need to connect the Teensy 3.0 to the USB Host shield like so:
| USB Host Shield |
Teensy 3.0 |
| RESET |
3.3V |
| GND |
GND |
| INT |
9 |
| SS |
10 |
| MOSI |
11 |
| MISO |
12 |
| SCK |
13 |
| 3.3V |
3.3V |
| GND |
GND |
The images to the right shows both the pinout for the Teensy 3.0 as well as the Mini USB Host Shield.
 Layout of the USB Host Shield Mini variant Furthermore I recommend cutting the VBUS jumper and then soldering a wire from the provided pad on the USB Host shield. This wire can then be connected to the VIN on the Teensy 3.0. The USB Host shield will then get powered directly from the same USB port as the Teensy 3.0 and the VBUS will be 5V as required by most devices – note that you might need a separate 5V regulator depending on which device you are using with the shield, as it might draw too much current.
More information about how to modify the shield can be found at the hardware manual.
Also take a look at the guide for the other Teensy boards, as the wiring is almost the identical.
Hopefully this is just the first of many ARM based boards that is going to be supported by the USB Host shield library.
If you got any questions or comments, then feel free to write a comment below and I will answer as fast as possible.
Update
Both the Teensy 3.1 and Arduino Due is now also supported by the library.
By Oleg Mazurov  E strobe train
Traditionally, Toshiba HD44780-compatible alphanumeric LCD displays are driven by bit-banging bus signals combined with long delays between sending commands and data. In many cases this method is good enough. There are other cases as well where extra CPU cycles are not available and more economical method of driving a display is needed. I’m currently working on a design involving very fast USB exchanges combined with occasional LCD output and developed a solution which works very well for me. I’m posting it with hope that my fellow developers will find it useful.
HD44780 displays have been around for a long time. The internet provides plenty of posts about them, code samples and even a Wikipedia article. My favorite introductory text on the topic is Dincer Aydin’s LCD Info page.
PIC24 16-bit microcontrollers from Microchip have been around for some time as well. They are cheap and powerful and the Microchip C30 compiler (free version available) is quite good. They are not as popular as their 8-bit counterparts from Microchip and Atmel therefore good PIC24 resources are scarce. One nice introductory text on the topic can be found at Engscope.
Since I’m trying to minimize CPU time spent driving the LCD let’s first talk about timing in general. When developing for HD44780 we need to deal with 3 different times. First is the timing of the display part – the screen we see. LCD glass is very slow. When we attempt to update the screen faster than say twice a second the symbols become blurry and pale. The fastest display in my collection still looks OK when updated at 4Hz rate (250ms), while most others are twice as slow.
On the other hand, display data bus timing is many times faster. In order to write to the display we first need to set RS, RW and data lines, wait a little, then assert E line, wait some more and then de-assert it. If we are reading from the display we will also need to wait a little more after de-asserting E before we can read the data on the bus. Total bus cycle length is ~2.5us, which is 200 000 times less than the update rate of typical LCD glass. This time is pretty short but the MCU is still faster – a PIC24F clocked at 32MHz has an instruction cycle of 62.5ns and in 2.5us it will be able to execute 40 instructions. Therefore, no matter how simple it looks, it is preferable not to bit-bang the bus.
The third timing we need to deal with is command execution time. All but two LCD commands have stated execution time of 40us. Two slow commands – Clear and Home require 1.64ms to finish. Those are datasheet numbers, in reality the fast command on a modern display may finish in as low as 10us and slow commands on an old display can take as much as 3.5ms, depending on the age and the particular “HD44780-compatible” controller used. It is about 100 times faster than the glass.
Continue reading Driving a character LCD using PIC24 Enhanced Parallel Master Port
|
|
