Teensy 3.1: Adding mouse scrolling support for Linux

Logitech wireless keyboard + Teensy 3.1 + USB Host chip

Logitech wireless keyboard + Teensy 3.1 + USB Host chip

I recently started a project with a Teensy 3.1 and USB Host Shield, I dub it my Keyboard/Mouse Macroizer.  The objective was pretty simple: Record and Playback all of the actions one typically does with a keyboard and mouse.  This is fairly unique since it can record not only keyboard actions, but mouse actions too.  Currently I have two of them and they are my default keyboard and mouse both at home and at work.

LCD + 3d printed case

LCD + 3d printed case

Today I’ll just be talking about some modifications needed to the default Teensyduino 1.18 to add the necessary support for mice.  Apparently there is a bug in the linux driver for mice support, that causes the scrolling action on an absolute mouse, to not be processed by linux.  One day I may track it down, but for now, my work a round is to add a second mouse to the USB descriptors that the Teensy passes the OS when it begins the enumeration process.

Just so everyone knows, I’m using Eclipse as my IDE for this project since the Arduino IDE is designed for beginners.  I would have given up in frustration if I had to use the Arduino IDE to develop these project.

A quick summary of the changes I made:

  • Added support for 5 mouse buttons
  • Added an absolute mouse HID
  • Increased the power that the Teensy requests from the USB host (aka computer)
  • Removed support for the joystick (not necessary in my application)

I just went and updated Paul’s latest repo with my changes, which are reflected in the following git diff.  My recommended method of adding these features, if desired, is to use the application provided by Paul to get the base environment, then add the changes from there.

Continue reading

All controller functions functional! Now I need some remote projects!

This slideshow requires JavaScript.

So I have gotten to a point at which everything for the controller works. SD card, Xbee, BT serial, Shift LCD, PS2, and NunChuck. Pretty awesome. But if all of that code is enabled at once, I would have less than 1k bytes to write actual code to interface with things. In the code I have debugging via serial, debugging via LCD (for the controllers). I do like having debugging for LCD, but there is a problem: the PS2 library takes up 5k bytes. So when I actually build the controller, I don’t think I’ll include a PS2 connector, at least initially.

Breakdown of Sizes
with SD enabled
Everything Enabled: 29024 Bytes
Only LCD debug: 27252 Bytes
Only NUN LCD debug, PS2 disabled: 22550
Only PS2 LCD debug, NUN disabled: 25900
Only PS2 & Nun, no debug: 24690
Only PS2, no debug: 24484
No ps2 or Nun: 20972
With SD disabled
Nun and PS2 disabled:13488
BT disabled + SD + NUN PS2
Xbee: 11910
Everything Disabled:
11886 bytes

I think the optimal configuration would be to use the Nunchuck with LCD debugging information, with SD, XBEE and BT, coming at a total of 22550 bytes, giving me about 7.5k to write my code for all of my interfaced devices.

This has led me to the idea, that my interfaced devices should be giving the controller, the menus it should show. I’m thinking of an initial packet that is exchanged between the two, which has a good amount of strings, that are then saved into flash on the controller, and once data starts arriving, those ‘labels’ of the data will make the data make sense. Another idea is to use the SD card to carry firmware for remote projects, and remotely flash them using the controller on the go, so I can update code for my cars without having to take my laptop down there.

Well here it is: http://pastebin.com/JudSCJNN

Continue reading

Finding Parts is a Skill…

Let’s say you want to buy some 10 pin connectors to connect your boards together, it should be pretty easy to buy them, right? Sure! Just go to Sparkfun and spend $1.50 for a 40 pin female header and another $1.50 for a 40 pin male header. Wow, that’s expensive.

The trick to navigating Digikey or Mouser, is being able to select the right terms that get you to what you actually want, and sometimes that is trial and error. Let’s look at Mouser. Looking at the link itself, I had to go to Interconnects -> Rectangular Connectors -> Headers wire housings, then selecting male.  From there, I could then look for the actual specifications for the part I want (cheap, 2.54 mm pitch, 1 row).

Many times I get a little frustrated trying to navigate the menus, but it is usually always worth it, in $, to do so. In this case, I found the best prices at DipMicro.com, $0.33 for each (since I’m buying 100, the price is $0.15). They had the best prices for the female connectors as well. But they lacked quite a few parts, so I will still have to order at Mouser, but I think I’ll save money by ordering from both places, rather than getting it all from Mouser.

Learning how to navigate vendors like Digikey, Mouser, Newark, and ebay can help you save lots of money versus buying parts at specialty places like Sparkfun or Pololu. In this case, I can buy 5 headers from DipMicro versus 1 from SparkFun. Wowza!

As a sidenote, I’m buying a non-latching shift register to see if I can reduce the pins needed to drive an LCD to two, using the Shift LCD library! I’m thinking of picking up a PS2 connector, as well as a NunChuck adapter, to make things nicer, even though they will probably cost more than an entire MCU + Wireless + Case combo…

Working on Wireless Comparison Boards – Need a better menu, ironically

This is the main board for my wireless testing experiment. It has 3 buttons, microSD card, 3.3V voltage regulator, and a 20×4 3.3V LCD. I setup the backlight to only illuminate if a button is pressed, since it apparently uses 180 mA to run (I really should have looked at the data sheet before buying these). The idea is that I will mount the wireless device under test (DUT) onto a non-conductive foam next to this, and perform the tests. My menu system will need to be redone, since it not only is hard to work on, but it has been a pain to upgrade to a 20×4 dimensions.

I designed the AdvMenu in hopes that it will help me to create menus quickly.  But in order to create a menu, I have to follow a 5-6 step guideline, which can be annoying if you have a lot to change.  Plus, since you have to modify the library, it can’t be called a true library then, since libraries typically don’t need to be modified.

So I’m going to completely change the AdvMenu.  I’ll be making it into a true library, where your menu system, and functions, will be in your main arduino INO file.  Imagine creating scrollable menus like the following:

AdvMenu.mainMenu(0,(__FlashStringHelper *)PSTR("Option 1"));
AdvMenu.mainMenu(1,(__FlashStringHelper *)PSTR("Option 2"));
AdvMenu.subMenu(0,0,(__FlashStringHelper *)PSTR("Under Option 1, sub 1"));
AdvMenu.subMenuFxn(0, &fxnPtrToAFunction);

All of the menu stuff would happen behind the scenes, which includes being able to call functions if you select an option. This init would need to be run everytime you startup (it will need to be in the setup), but you’ll be able to dynamically update menus just by making the corresponding call. Of course, the final product may be something totally different, but this is what it is looking like so far.

The first version helped me get something done and out the door, but I see now that it needs to be redesigned. Which is great news, since I should end up with something wonderful.

Source Code for VDay 2012 Released, and it is called AdvMenu!

I am really happy with how much progress I did tonight.  I finished all of the LED functions, so that you can vary brightness, speed, and pattern, from the settings menu.  Those settings are stored in eeprom just like everything else.

When you first run it, you’ll import it into your Arduino libraries directory.  Then you’ll restart Arduino, and check out the example.  You can modify which pins are for the LCD, and which Analog input’s you want to use.  The circuit is described in AdvMenu.cpp, and I plan on posting a schematic eventually.  When you look at the example, you’ll see that only a few initializations are in the main arduino sketch.  You’ll have to modify the actual AdvMenu.cpp, AdvMenu.h and MusicMenu.cpp to suit your tastes.

I have included 1 sample card and 1 hidden card, just to show you the capabilities of the library.  I have also included #defines in the top of AdvMenu.h that can do things like disable music (saves 11274 bytes), disable cards (saves 664 bytes), disable passwords.  It also does some pretty necessary stuff.  The first time you run it, you’ll need SETUPEEPROM and SETUPMENU uncommented, since it will setup the default menu and then save it to eeprom.  After you do that, then you’ll need to comment them out.

For the Shift Registers, you’ll need to manually define them in AdvMenu.h.  Since I wanted speed, you’ll define the pin numbers, their ports, and the pin number of the port.  You can look at this pin mapping to figure out what you need to put there.

I’ll continue to update this library as I add more functions to this VDay card.  My next thing to add is a little game called Dodge.  Please let me know if you have any suggestions, or if you like it 🙂  Progress!!!

LCD working on a ATMEGA168!

… But don’t I already have an LCD controller, you ask?  Why yes I do.  That was using an MC9S12C32 processor, a totally different kind of chip than an Atmel.

While I may be able to write my own, there are plenty of libraries out there that mostly work.  I picked this one since it’s the first one that worked for me.  Well, the Arduino environment worked right off the bat, but I’m not interested in running arduino yet. The have a nice tutorial that teaches you how to bit-bang the LCD.  I might redo this when I get the 75HC595’s in the mail later this week.

Ultimate goal of getting the LCD working on the Atmel platform: Remote 2.0!  My idea is to make a remote that can display the statistics of my car, when I am close enough to it.  Statistics like engine temp (in multiple regions), engine coolant level (I have a leak), and other things.  Hopefully I can capture the OBDI and integrate it with my logging, and displaying 😛   Imagine driving down the freeway with a little wireless display that shows all of those statistics…