Mostly Technical

Thursday, November 24, 2016

A few years ago, I've written a small Arduino module to drive displays based on the TM1637 chip. The module has gained some popularity and I got a lot of requests to add some means to control the decimal point segments (which actually connects to a colon in most display modules). So, here it is. Version 1.1.0 of the library is available on GitHub, and includes some minor fixes (mostly spelling) as well.

Thursday, April 21, 2016

Recently, I've been playing around with RedBearLab's Wifi Micro board. Essentiallu, it's a TI CC3200MOD with some bare minimum components required to make it work, all mounted on a small PCB with conveniently .100" spaced pins.

RedBearLab recommends Energia as a coding environment for that board. Energia is TI's spin-off of the Arduino IDE. Arduino lovers will feel at home, with one-click-to-run and the huge Arduino ecosystem. On the other hand, the IDE is quite limiting for power users - with inefficient multi-file support, lack of modern IDE features like code completion and lack of control of the compilation process. One additional problem is that the chip is pre-configured in a certain manner that may not suit all applications. For example, the pin mapping is fixed and cannot be changed.

Luckily, TI also provides Code Composer Studio - a full-blown, Eclipse based IDE that can be used to develop software for the CC3200, as well as other TI processors. Here's a step-by-step tutorial on how to set things up to get started with the development quickly and easily.

Step 1: Installation

In order to develop for the CC3200, several tools and packages have to be downloaded and installed:

Code Composer Studio - When installing, make sure that all CC3200 stuff is marked for installation, including TI ARM compiler

All the above tools are available both for Windows and Linux. One small exception is the CC3200 SDK, where only a Windows package is available. The solution is to install the package on a Windows machine and copy the whole directory tree to the Linux machine (see also here).

Two more recommendations - install everything in the default location (c:\ti), it will save a lot of time configuring search paths; on Linux - install the software locally, not as root.

Step 2: Importing the base project

I have created a boilerplate project that includes some very basic facilities that are required to get started with CC3200 programming. The project can be found on GitHub. In order to use it, the first step is to import it into CCS. This can be easily accomplished using the built-in git support. First, select "Import ..." from the file menu. Then, select "Projects from Git" and "Clone URI" at the next screen. At the URI input box in the next screen, type the repository's URI: https://github.com/avishorp/RBL_CC3200_CCS.git, select the (only) master branch, the local working directory, and finally check the project name.

Step 3: Building the project

If all the tools were set up correctly, building the project is a matter of clicking the "build" button. The relevant result of the project is the bin file <Proj. Name>.bin (in our case - RBL_CC3200_BASE.bin).

The project can be built either in Debug or Release configurations. Unless your'e using a JTAG adapter for debugging, the Debug configuration is useless, and should not be used. To change the active configuration, right click on the project name, select "Build Configurations", "Set Active" and then select the appropriate one.

Step 4: Programming

The CC3200 module contains a bootloader that enables programming using only a serial port (logic level USB to serial adapter), similar to the way Arduinos are programmed. The hardware I'm using is a small board that comes with RedBearLab's WiFi Micro Kit, but I think (not verified) that a regular USB-to-Serial will be sufficient.
There are two possible ways to program the device:

cc3200prog - This little program can be found in the Energia distribution (in hardware/tools/lm4f/bin). It is invoked from command line in the following way:

cc3200prog <PORT> <BIN> h

Note the "h" at the end of command line - without it the process fails! PORT is the COM port number in windows or the complete path to the tty device on Linux (for example /dev/ttyUSB0). BIN is the binary filename, generated in the previous step. This program is easy to use and works great, but from my experience it has a log of bugs. For example, it crashes when the binary filename includes underscores or spaces, and sometimes it just crashes in the middle of the process with no apparent reason. This instability plagues both the Windows and the Linux versions.

Uniflash - Uniflash is a tool provided by TI. It has both a GUI and a CLI. It is much more flexible than cc3200prog - it can access and program not only the program image, but also auxiliary files that can be accessed later from the CC3200 firmware and are very handy for board-specific configuration. The downside of Uniflash is that it does not reset the board after it finishes its task - it has to be manually reset using the physical button. It's also not completely free of bugs as well - sometimes the programming task becomes very slow and goes on for a few minutes (instead of a few seconds) - but it's relatively rare.

After experiencing both methods above I would recommend using Uniflash for its stability and flexibility.

Understanding and Extending the base project

The base project is very minimal. It includes a console facility which can print messages to the serial port. The console is buffered and interrupt based, so it can be used freely without causing large unexpected delays in the program execution.

The pinmux is identical to the one provided in the WiFi Micro product documentation, but it can be change easily using TI's online pinmux utility, or its local version. The base project includes a CC3200.pinmux file which can be used as a base file and modified according to one's requirements.

The base project does not include any WiFi capability - TI provides a large collection of examples that are relatively easy to understand, copy and modify

Thursday, January 1, 2015

Again
that time of the year has come. Christmas is here, New Year 2015 is
around the corner. And one more reason to be happy, this is the time
Numato hosts the largest give away of the year. That is right! We hosted
our 2014 Christmas/New Year give away
during December 2013/ January 2014 time and we saw overwhelming
response from our readers. We gave away random gifts to every single
person participated in the event, 250+ electronics enthusiasts. We hope
that everyone who received the gifts put it to good use and learned
something from it.

Tuesday, September 23, 2014

No, it's probably not.
Ever since the Edison broke into our lives, people keep comparing it to boards from the makers world - like Raspberry Pi and even to Arduino. I think it's a total miscomprehension of what this module is and what is its purpose.
Edison is not primarily targeted at makers. It is targeted at IoT manufacturers with medium-high manufacturing volume, that need some real computation power, which even high end microcontrollers can't offer, along with some serious connectivity.

Intel chose to introduce the module through the makers community, partnering with major names in this area such as Sparkfun. This is a tactical marketing move, and an obvious question arises - why? I can think of two reasons. The first one is that Intel truly believe that this is where innovation comes from. The second is that Intel does not want to lose another market segment to ARM, as it did with mobile platforms (cellular, tablets etc.), understanding that future engineers may prefer familiar technologies from their making days. On the way, it's trying to fix its absence from this small, but very loud market.
The true competition to the Edison will not come from Pi nor from Arduino - it will come, once again, from ARM with ultra-cheap, connectivity-centric modules such as HE and HLK-RM04. While not providing half as much computation power offered by Edison, they do allow both makers and manufacturers to enable product connectivity easily and on-the-cheap.

Saturday, July 26, 2014

ASTROGUN is an Asteroid shooting game I developed along with Maayan Dreamer for the Jerusalem Mini Maker Faire (the link is in Hebrew), held in June 2014.
The game is pretty simple - the player stands and has to shoot Asteroids that are coming towards him from any direction, before they hit him. A RADAR-like view helps the player locate the Asteroids around him.
The most interesting thing is the display system. We build a HUD - heads up display - which is a display that shows an image overlaid on the background.

Check out how it looks like in the video below:

How it Works

In the heart of the Astrogun lies a Raspberry Pi computer. An IMU card connected to it (Sparkfun's MPU-9150 breakout board) providing it with the ability to sense the orientation the unit's orientation. Having this information, the Pi is able to draw the various elements (Asteroids, bullets, explosions), as seen from that specific angle. When the player moves, the graphics move ayour'ccordingly, giving the "object in the room" sense.

The display system comprises of two main elements: an LCD panel and a beamsplitter glass (also known as Teleprompter glass). This glass has a unique feature - it is both transmissive (like a window) and reflective (like a mirror). The player, looking through the glass sees both the image behind the glass and the image projected from the LCD.
Anyone who is familiar with basic optics will immediately notice that I'm a little bit cheating here. The system lacks one important component - a collimation lens. In real HUD systems, this lens projects the imager image to infinity, creating an illusion that the graphics is in fact "on" the object the user is looking at. In our case, the short development time hindered us from complex optical structures. Nevertheless, the experience of object-in-the-room is still there, to some degree.

As for the software, the game is not very computationally demanding (set aside the graphics rendering process, which is handled by the GPU). The development time, on the other hand, was definitely demanding. Therefore, Python was a natural choice. I used the excellent Pi3D library to create the graphics, while the rest of the game logic is written in pure Python. In order to determine the orientation, I used the RTIMULib library, which reads the sensors and fusions its data into orientation angles (I also contributed a Python binding module for that library, which was written for this project). Sound effects are played using the PyGame library.

Finally, the mechanics. Most of the electronics (RPi, IMU, power supplies and a few more) were fitted nicely within the body of a toy gun, which was sourced from a local toy store. The display system, which comprises the LCD, its controller and the beamsplitter glass are held in position by a glass epoxy structure which positions them in the location and angle required (the glass and the LCD must be positioned in a 45 degree angle, otherwise the image will be distorted). The Raspberry Pi is connected to the controller using an HDMI cable. The trigger of the gun had an electric contact for its original purpose (flashing LEDs and making noise), and it was re-routed to one of the GPIO pins.

Source Code

All the source code of the project is available through GitHub. Unfortunately, the mechanical structure is ad-hoc and not documented.

Thursday, March 6, 2014

Update:A new version has been released, includes control of the colon/decimal points.

I needed a small numerical display for a project I'm working on. I found this one on Dealextream. It looks great - a 4 digit module, with a driver and a serial interface - perfect match for my requirements. The product page mentioned that it is driven by a chip called TM1637. A quick search at Google lead me to an Arduino library, made by SeeedStudio that is capable of communicating with the module.

Three weeks later, I have the module at hand. I'm connecting it to an Arduino board, installing the library and uploading one of the example files. Nothing. Total blackness. On the hardware side, with only two digital pins, it's pretty hard to mess things up, so the suspicion falls on the software. The next step is trying to get the datasheet of the TM1637. The chip is made by a company called Titan Microelectronics, which holds a product page for it. Sadly, the link to the datasheet is broken. Searching again, filtering all the "datasheet.com" etc., I find this datasheet, in plain Chinese. With the help of Google Translate, and SeeedStudio's library, the communication protocol gets revealed. The chip uses the I2C protocol, and the sequence required to write display data is as follows (ST - start condition; SP - stop condition):

ST - COMM1 (0x40) - SP

ST - COMM2 (0xC0) + the first digit to be written

digit1 - digit2 - ... - digit4 - SP

ST - COMM3 (0x80) + the display brightness - SP

Having all that at hand, I wrote a new library, implementing this protocol. The library is available at GITHUB, including a sample sketch demonstrating its capabilities. The repository also includes a README file explaining how the library should be used and how the module should be connected to the Arduino.

Why did SeeedStudio's library fail?

Browsing through SeeedStudio's code, I found two problems that might cause it to malfunction.
The first one is this:

The digital output pins are bit-banged to create the I2C signal, but there's no delay. This gives a toggling rate much beyond the specified 400KHz. It's possible that Seeed were testing their module with an 8MHz Arduino, while my module was 16MHz, raising the toggle rate even further away from the specification.

The second problem also arises from the code snippet above. I2C is wired-and bus, meaning it should never be driven high.When a logic '1' is desirable, the output of the Arduino should be put in high-impedance state allowing the pull-up resistor to pull the line to its high level. This is unlikely to cause an immediate problem, but in the long term it may cause the reliability of the components to degrade.

Monday, January 6, 2014

I'm running a small OpenVPN setup at home, through which I can connect to my home network from various places securely and safely. I really like OpenVPN. It's robust, safe and fairly easy to set up. There is only one small caveat - it is not a standard VPN client in Windows. In order to use it, an OpenVPN client is required. Such client exists, of course, and it's can be downloaded and installed on any computer. There are occasions, though, that downloading and installing software is either impossible or inappropriate. For example, using a company provided notebook computer or a friend's computer.
One way to overcome this limitation is to use of an Android smartphone as a VPN gateway. The phone runs OpenVPN and has access to the private network. The client computer is tethered to the phone and set up in such way that access to the private network addresses from the PC is routed through the phone and forwarded over the secure tunnel. This is the ideal solution - the computer doesn't have to know anything about OpenVPN, no software has to be installed and no key has to be deployed. The only tweak required - sometimes - on the PC side is adding an entry to the routing table. In Windows 7 it seems that it can even be done without administrative privileges.
In order for this setup to work, some tweak are required on the phone side. The remaining of this post explains more about it.

Prerequisites

First of all - a rooted Android phone. Mine is a Samsung Galaxy S-II (also known as GT-I9100) with CyanogenMod ROM. I've never tested this procedure on any other phone, but I'm sure it will work on most of them.
The second requirement is a working OpenVPN setup. I won't get into the details of this setup, there are plenty of tutorials on the Internet. When OpenVPN works computer-to-computer, it's very easy to migrate it to the phone - just install the OpenVPN client from Google Play, put the configuration files on an SD card and let OpenVPN on the phone know where the files are.

Procedure

We will use the iptables utility to instruct the phone to forward IP traffic through the secure tunnel. For the sake of the discussion, let me assume that the private network is on the 192.168.2.0/24 subnet.

The first step is instructing the phone to forward packets to/from the secure tunnel (tun0) and Masquerade them:

These commands can be entered directly using a phone terminal software (such as the one installed by default when installing CyanogenMod on the phone), or better using an SSH server such as this one.

The second step is to enable packet forwarding from the interface tethered to the PC. There are multiple options here, and it may be necessary to detect which of the network interfaces is use for which purpose. This can easily be done with the netcfg command on the phone. Run it once, without the tethering and the once again with the tethering activated. The network interface that was used for this purpose should go from DOWN to UP state, and an address should appear. In my phone, the interfaces are wlan0, rndis0 and bt_pan for WLAN, USB and Bluetooth tethering respectively.
And now back to the iptables command:

Finally, we have to tweak the routing table on the PC to redirect the traffic of the private network to the right place. This step is not always required - if the PC's only network connection is the phone, this will happen naturally.
For all other cases, a new route is required. The routing table on Windows is managed using the route utility. First, open a command line window. In Windows 8, it must be run as an administrator. Now, we'll have to identify the network interface used for the tethering:

route print

This command prints the routing table, but in this stage we're only interested in the header of the result, the one listing the network interfaces on the computer:

In the case of Bluetooth tethering the first interface in the example is the one being used. In the case of WLAN tethering we'll select the wireless LAN adapter (not shown) and in the case of USB tethering it is shown as USB to Ethernet adapter. The first number in each line is the interface number.Now, the route is created as follows:

route add /p 192.168.2.0 mask 255.255.255.0 route 192.168.44.1 if 23

This address 192.168.2.0 is the address of the private network; the address 192.168.44.1 is the phone's address (on the tethering interface, obtained with ipconfig) and the number 23 is the network interface number as demonstrated above. The /p switch makes the route permanent, meaning that we won't have to touch the routing table every time the phone is connected.

That's it! Now, you should be able to access the private network from the PC.

Just one additional note: to make the changes permanent on the phone side (that is, they will be available after the phone is being reset), create a file called userinit.sh in /data/local and put all the iptable commands in it. For example: