A messenger program for the micro:bit

Use 2 or more microbits to send messages to one another. Use A and B keys to select letters, press both A and B keys to select a letter, and select '>' character and press both A and B keys to send the message to other microbits.

As you can see the code is pretty simple. You can find the code in javascript in this github repository: https://github.com/tkleisas/microbit_examples

Exploring Mandelbrot set with javascript and HTML5

Show me the code:

A groovebox using Arduino uno (part 2 of N). Choosing the appropriate libraries.

In the last installment I introduced the Arduino uno groovebox concept. In order to be able to realize the design we need to use some libraries in order to perform the required tasks. Let me say that choosing the libraries can sometimes be an iterative process. Maybe we have to change our initial choice later. But we have to start somewhere, that is perform our first iteration. So, let's see the components we will use and the libraries we can utilize to communicate with them.
1. Sound generation. This is maybe the most important component. Arduino uses a microcontroller as its processor. It is an ATMEL atmega 328p with 32Kb of flash memory, 2Kb of ram and 1Kb of EEPROM. It doesn't have a pcm codec like a PC or even raspberry pi have. So in order to produce sound we need either some additional component like an i2c dac, or we can use a PWM output and then filter it to produce a signal that can be fed to headphones, an amplifier or recording equipment. The approach I chose is to use PWM because I did not have a dac, and from the research I did, I found that PWM output does sound OK, if properly filtered. The first candidate for sound generation was Mozzi, a fantastic library with excellent documentation. You should definately check it out: http://sensorium.github.io/Mozzi/
2. Library for the 128x64 OLED display: I searched for a driver/library to drive my OLED display. The display uses an SSD1306 chip. The particular display in my case was wired as SPI. You can find i2c or SPI/i2c versions in various places and with various prices. I bought 5 of those displays for under 20 euros in order to use them in various projects. The good thing about this display is that you can show a lot of information, With an 8x8 character matrix you can show 8 lines of 16 characters. That is a lot of information. The display is pretty crisp too! The only problem is that it is smallish, so if you are a bit older you may have trouble reading it. You can see details for the wiring in this Adafruit tutorial: https://learn.adafruit.com/monochrome-oled-breakouts

 The library I initially used is this one: https://github.com/adafruit/Adafruit_SSD1306. This library supports both SPI and i2c and it uses the Adafruit GFX library (a separate download) for text and graphics rendering. Using the wiring documentation above and the library, I managed to connect the OLED display to arduino uno without any problems.
3. Library/code for rotary encoder support. Anyone interested in reading rotary encoders with arduino should definately check out this post by Oleg Mazurov: https://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino
At first it was not working, but the problem was not in the code but rather on my poor soldering skills. You see I made 2 small breakout boards in order to make the encoders breadboard friendly and I created some sort circuits. When I found the problem Oleg's code worked like a charm.
4. Library code for reading the buttons. No worries about this one! The support is built in arduino. Just configure the input pins with the INPUT_PULLUP parameter like this

pinMode(BUTTON_1,INPUT_PULLUP);

So in theory it seems like its all roses and we will be able to advance this in no time.

Well, not so fast my friends. Why? Well these parts work OK on their own but when you try to make them work together problems DO occur.

For example some libraries use particular pins that cannot be shared. Some others use a lot of precious ram starving the other libraries from it. So what seems a good start at first, may need some iterations before it works adequately as a system with the required functionality.
So in our next blog post, we will go through some of the iterations required to make those libraries work together and even replace them with others in order to achieve the necessary interoperability and performance.

A groovebox using Arduino uno (part 1 of N)

Hello,

it's been a while since I last wrote on this blog. The previous blog entry dates back to 2009. Wow, that was six years ago... In the meantime a lot of things happened. As a citizen of a crisis plagued Greece I witness a whole nation holding its breath hoping for some kind of salvation fearing that an economic apocalypse might happen. As I find breath holding a waste of time, I started a new project that marries two of my favorite interests: Electronics and music. I am an amateur electronic musician and over the years I managed to gather a few sound producing gadgets and software. However, as every synth freak knows, I feel the urge to add new weapons to my sonic arsenal. I already have 2 Virtual Analog Synths (M-Audio Venom, Novation Mininova), and a cheap analog synth (Korg Volca keys). I recently brought back from the attic a yamaha 4 track cassette recorder and the idea of creating songs only with physical hardware, without a DAW and a computer for some reason started to resonate. What I don't have is a drum machine/groovebox hardware that could be used as the rhythm section and the backbone of the songs I write. Of course you can find a lot of grooveboxes and hardware in the market right now. But instead of buying a groovebox or a drum machine, the idea of creating my own groovebox started to grow on me for many reasons. Reason number one is to create something unique sounding with an expressive and creative workflow. As I had one or two arduino unos lying around I thought that I could base my groovebox on arduino. So I started researching and trying to shape the groovebox design in my head. I had to balance the features I wanted with the physical limitations of the parts I had in my disposal for prototyping. After quite some thought I decided on a simple design with the following specifications.
1. Arduino uno based. That means that you can use a lot of existing libraries and resources and integrate rather than write code from scratch and there are a lot of documented ways to create a product out of your prototype.
2. OLED LCD display. I also considered 7 segment type displays or even a color coded led scheme for visual feedback regarding the groove machine. But since I wanted to be able to edit a lot of parameters, some sort of LCD display became mandatory.
3. Rotary encoders. I really like rotary encoders. I think that by using them, instead of potentiometers, is easier and really expressive.
4. 4 sounds at once, in order to be able to create interesting grooves and mini songs. Also some other buttons with shift and/or mode functions.
5. Low fi sound.
6. Low part count and cheap to make.

Little by little I started connecting the various components. Here is the prototype spaghetti of wires that I made.

You can see six buttons. The first 4 switches act as trigger pads and the other two as shift and mode buttons. The screen used is an OLED 0.96" monochrome display that is quite small but really crisp and can be had with only 4.30 euros. The two rotary encoders and the sound output are on the upper breadboard. In the next installments of these series we will take a look on how we could decide on the sound producing library for Arduino. Until then, take care and take a look on the project code on github !

Can N900 and Maemo save nokia?

I absolutely love android, don't get me wrong but strong competition is a good thing. And android's only solid competition seems to be the one coming from Apple. Even though Nokia practically owns over one third of the mobile phone market, it is way behind technologically in the prestigious smartphone sector. Symbian series 60, is considered old and boooooring... Maemo is still wearing diapers (it is in my opinion, more immature than android was when it launched one year ago). So what steps can be taken by Nokia to improve the situation? Here's my short list:

1. Abandon Symbian series 60 models in favor of Maemo.
2. Keep its series 40 line for dirt cheap mobile phones.
3. Develop a series 60 emulator that can run series 60 apps on Maemo phones.
4. Radically improve Maemo development tools. Let me elaborate on this. Compared to android and iPhone developer tools, Symbian series 60 tools have been really difficult to use. An entirely different sdk should be downloaded in order to support specific features found in specific models. And the SDK's were practically running only on Windows (and very specific versions of windows that is). Now, the new Maemo SDK is linux only, and it requires a lot of setup steps compared to android. So Nokia developers should make a move from windows to linux and from symbian to maemo. Whoa, that seems like a lot of work!
On the other hand the android SDK runs on windows, linux and MacosX, is simple to setup (at least compared to symbian and Maemo) and the emulator and the IDE are really simple to use and quite fast. In only one year android has 10,000+ apps and a lot of them are very good. Of course Nokia is starting to make some moves on the right direction. One of those moves is QT Creator, a very good cross - platform IDE, that can create QT apps that can be compiled for mobile platforms like Maemo, in good, old, speedy C++. But until Nokia bundles a simple to use QT Creator and Maemo SDK combo, I don't see developers fleeing their way.
However, N900, the first Maemo smartphone device, looks cool and packs a lot of power. But as we all know, the apps count, so Nokia should help developers write some cooool apps or it may be heading palm's way.

Robotic Space Rock 1.0.10 for android 1.5 (cupcake)

Since the release of the android 1.5 SDK, I wanted to update the code of RSR to use the 1.5 SDK. It seems that as far as openGL/ES is concerned, programming is greatly simplified by the introduction of the class GLSurfaceView and the Renderer interface. It only took me a couple of hours to change the code to use the new programming interface. However I spent several days trying to find out why my application misbehaved when it was paused and then brought back to life. However I was able to track the problem down using the setDebugFlags(DEBUG_CHECK_GL_ERROR);

It had to do with incorrect rendering of a square (used for the moon/earth) surface. I also replaced the mediaPlayer class I was using to play back an mp3 with the JetPlayer class, which can be used to play back midi files that are a lot smaller compared to mp3's and they can use little cpu power. Now a midi file is used for playback, and the application size has reduced considerably to well under 1 Megabyte. However I did not find the time to write a proper midi song, so all you gonna hear is a repetitive ditty that is probably gonna drive you crazy...

Overall I think that the game is now a lot more responsive and fast but I only tested it on the emulator, so your feedback is welcome. Go to http://code.google.com/p/monolithandroid/downloads/list , download roboticspacerock1.0.10beta.apk and keep those bug reports coming...

The 1.0.9 version did not work, probably due to the getHolder().setType(android.view.SurfaceHolder.SURFACE_TYPE_GPU);

bug. In order for the game to work in real phones it seems that you still have to use the previous line.

New! Improved! The 1.5 android SDK is here.

The android 1.5 SDK (based on the notorious cupcake code branch) is here and it is what the first release of the SDK should have been. Support for sound recording and playback through buffer manipulation (using the AudioTrack class) is something that game developers want. And easier OpenGL programming is now easier, too. However there are still spotty places. It seems that the new SDK broke a lot of programs, especially games. And the apk size limitation of 16 MB still holds. My application RSR kinda works but when you try to exit it, it freezes. So I will have to adapt it to the new SDK release. I will rewrite the openGL parts using the new classes and see what happens. Maybe I will try to use AudioTrack class, too...