FEZ Panda II with HD44780 controlled LCD

Panda II with HD44780 LCDSecond test: displaying text on a 20×4 LCD controlled by a HD44780 compatible driver chip. As you can see, it’s working ūüôā

After Eric VDB pointed me to Codeshare¬†in a comment on a previous post, I couldn’t resist searching for something that could help me get started.

And I found something useful here. Although the example that came with it was targeted for a¬†Gadgeteer Extender Module (which I don’t have), I had no problems getting it to work. I created an additional constructor that would accept pin numbers, like this:

SerialLCDDisplay lcd = new SerialLCDDisplay(
                     FEZ_Pin.Digital.Di21, // RS
                     FEZ_Pin.Digital.Di23, // ENABLE
                     FEZ_Pin.Digital.Di25, // DB4
                     FEZ_Pin.Digital.Di27, // DB5
                     FEZ_Pin.Digital.Di29, // DB6
                     FEZ_Pin.Digital.Di31); // DB7

It took me some time to figure that out, but within the hour I had the LCD running. I added an endless loop with an increasing counter and a delay of 1 second and let the sketch program run; at the time I took the picture it had been running for more than 4 hours.

One thing I noticed was that the LCD sometimes displayed garbage when the Panda was rebooted; after that everything worked OK, but startup looked a bit ugly. Maybe give the hardware connected to the Panda some more time to settle? I don’t know yet; we’ll see about that later. Another thing I need to have a look at is the fact that this SerialLCDDisplay class was apparently written for an LCD with 2 lines; cause line 0 (first line on the LCD) and 1 (second line on the LCD) were OK, but output destined for line 2 were shown on the first line of the LCD again – probably a minor issue.

And since I’ll have to change the class code for that anyway, I’ll also add 2 additional parameters with which I can set the number of rows and columns of the LCD – cause I have both 20×4 as well as 16×2 LCDs!

Oh, and I saw these automatically generated Debug messages appearing in the Debug output window in Visual Studio on my PC:

GC: 4msec 12132 bytes used, 52248 bytes available
Type 0F (STRING              ):     96 bytes
Type 11 (CLASS               ):   1596 bytes
Type 12 (VALUETYPE           ):     60 bytes
Type 13 (SZARRAY             ):    108 bytes
Type 15 (FREEBLOCK           ):  52248 bytes
Type 17 (ASSEMBLY            ):   7560 bytes
Type 18 (WEAKCLASS           ):     48 bytes
Type 19 (REFLECTION          ):     24 bytes
Type 1B (DELEGATE_HEAD       ):     72 bytes
Type 1D (OBJECT_TO_EVENT     ):    168 bytes
Type 1E (BINARY_BLOB_HEAD    ):    156 bytes
Type 1F (THREAD              ):    384 bytes
Type 20 (SUBTHREAD           ):     48 bytes
Type 21 (STACK_FRAME         ):    828 bytes
Type 27 (FINALIZER_HEAD      ):    168 bytes
Type 31 (IO_PORT             ):    252 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):    492 bytes

This must be some diagnostic information from the GC process kicking in.¬†12 KB used? Woow… that’s 20%. But what’s the baseline of used memory, e.g. what does a program with an ’empty’ main() use in terms of memory? Sounds like a good subject for another post..

First step: FEZ Panda II with LuxPlug

FEZ Panda II with LuxPlugLast evening I created my first program for the FEZ Panda II; I attached a JeeLabs LuxPlug to it and just started trying.

I found a tutorial¬†on how to do I2C with the .Net MF and used that one as a starting point. It didn’t take long before I found out that for me, in this case, it was easier to rely on the TSL2561 datasheet than to try to use someone else’s code to create my first C# class for this sensor.

Probably because this first try was an easy one; I guess in the future, when things become more complicated, I’ll have to take some peeks at how others do certain things. But for now, I’m pleased with how this first exercise worked out!

The code is not finished yet, but it’s in a stage where it works and produces the raw data coming from the data registers. Good enough for a post ūüôā

Here’s a small piece (the constructor part) of the class code:

public TSL2561(byte I2CAddress, int ClockinKHz)
{
  I2CConfig = new I2CDevice.Configuration(I2CAddress, ClockinKHz);
  I2C = new I2CDevice(I2CConfig);

  // read the ID register.
  var Actions = new I2CDevice.I2CTransaction[2];
  byte[] rx = new byte[1];
  Actions[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0x0a });
  Actions[1] = I2CDevice.CreateReadTransaction(rx);
  if (I2C.Execute(Actions, 1000) == 0)
  {
    Debug.Print("Read ID Register failed");
    // exit or something
  }
  else
  {
    Debug.Print("ID value: " + rx[0].ToString());
  }
  // 4 msb must be 0001 for a TSL2561
  if ((rx[0] & 0xf0) != 0xa0)
  {
    // exit or something
  }

  setGain(0x10);
  Thread.Sleep(5);   // Mandatory after each Write transaction !!!
}

Not that bad if I may say so…

The sensor is being read every 5 seconds and this produces the following output, where it shows the decimal values of low and high bytes of both ADC channels:

--------------
Result: 156 1
Result: 69 5
--------------
Result: 160 1
Result: 80 5
--------------
Result: 174 1
Result: 114 5
--------------
Result: 177 1
Result: 119 5
--------------

Nice! Calculations with these numbers is something that’s on the¬†to-do¬†list for now, but that should not give any big problems anymore; no, but what I think will be the biggest obstacle to overcome is my knowledge of C#.

For example, I’m used to displaying numbers in hexadecimal format. So I added a x.ToString(“X2”) (where x is a byte) in a Debug.Print(), knowing I’ve used this before myself in VB.Net and have seen this being used in C# too – I got no build errors, but I did get an exception… apparently the .Net Micro Framework doesn’t support this? I have to press F1 for help too much for my taste.. ūüėČ A¬†matter of learning on the job I guess..

Now let’s see if I can find that 20×4 LCD for my next ‘project’; and maybe a spare LCD Plug, to keep the number of wires acceptable.

Arduino on steroids and .Net Micro Framework

FEZ Panda II compared to Duemilanove

Another gadget to tinker with arrived yesterday; a  FEZ Panda II from GHI Electronics. Arduino pin compatible, compatible with most Arduino shields, 72 MHz 32-bit CPU, 512 KB flash, 62 KB RAM for application, Micro SD socket, RTC and more, much more.

It’s a bit bigger though; the length is about ¬†10 mm more than the Duemilanove.

The FEZ Panda II runs on the .NET Micro Framework and you can¬†program (and even debug) the Panda with Microsoft Visual C# Express (free). Deployment to the Panda is done from within the Visual Studio IDE, and setting breakpoints, stepping and adding watches all (seem to) work. I got a ‘blinking LED’ example up and running in no-time – downloading and installing the .NET Micro Framework 4.1 and the GHI NETMF 4.1 cost me more time than getting the LED to blink; so far this looks OK.

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.Hardware;
using GHIElectronics.NETMF.FEZ;

namespace MFConsoleApplication1
{
  public class Program
  {
    public static void Main()
    {
      OutputPort LED;
      LED = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.LED, true);
      while (true)
      {
          LED.Write(true);
          Thread.Sleep(20);
          LED.Write(false);
          Thread.Sleep(2000);
      }
    }
  }
}

Why did I buy this FEZ Panda II? Well, for the fun of it ofcourse! And second, I wanna know more about these kind of devices and check some of the statements made.

For instance, the statement that the Panda is compatible with most Arduino shields intrigues me; to what extent is this true? “The shield fits in the headers” is not enough ofcourse; most shields come with a library to support the hardware that’s on the shield, but those libraries are for the Arduino platform, so how easy is it to plug in a Arduino shield and get it ¬†really working? Can, and if so, how hard is it to port Arduino code to this C# environment?

Another thing is: how does the .NET runtime influence time critical I/O, where output pins have to be switched very fast? How does this Panda perform, knowing there’s an additional layer (the CLR, Common Language Runtime) between the C# code and the bare hardware?

And how about memory usage? 62 KB user memory may sound like a lot compared to the Arduinos 2 KB. OTOH, when I compare my VB.Net touchscreen application to my Delphi Domotica system, the memory usage of the first one is huge compared to the 1.3 MB my Domotica system uses. So what will using a .Net environment do in this particular case? Will adding a few hardware drivers to a C# program quickly make the available memory vanish, or what?

And I’m also interested in how I¬†will perform with C#; I hope that seeing/writing code in all kinds of programming languages from the early 80’s will help me to get started ūüėČ

Questions, questions… which I hope to be able to answer in the next weeks; I was getting bored with watching that blinking LED on the Panda II, so I decided my first “Panda project” will be an I2C¬†exercise¬†with a JeeLabs Lux Plug to see how hard (or easy) it is to talk I2C with this sensor. And if all goes well, next thing will be to write some text on a spare 20×4 LCD I have one laying around. Those sound like some good beginner projects, right?

And if both succeed, the 2.8″ TFT LCD Touchscreen I bought recently, will be next.

That’s it for now; new challenges are waiting!

 

Arduino with TFT Touch Shield

TFT Touch ShieldAfter the TFT Touch Shield I ordered had arrived and some playing around with the examples that were part of the library that can be found here, it was time to do some testing.

For starters I made a small sketch with just a string, 3 ‘touchable’ areas and an icon. The first challenge was making the drawLine() function from the library working; somehow it had problems with drawing the left side of the roof of the ‘home’ icon. No clue why, but it just didn’t work. Only after I changed the parameter types from unsigned int to int and replaced the algorithm with the simplified version of the Bresenham line algorithm¬†the home was correctly drawn.

Next thing I did was printing some touch related information to the Serial and this is what I saw:

X = 611, Y = 442, P = 575
X = 609, Y = 443, P = 536
X = 606, Y = 444, P = 507
X = 599, Y = 447, P = 457
X = 599, Y = 447, P = 449
X = 600, Y = 440, P = 486
X = 601, Y = 434, P = 522
X = 642, Y = 604, P = 470
X = 634, Y = 609, P = 468

Well, so far so good… on to the next phase!

IR trouble with the Pace DCR7111 (UPC mediabox)

This week we got a new UPC Mediabox; the old Thomson DCI52UPC02 was replaced by a Pace DCR7111(/03). The Thomson was constantly updating itself, went into reboot-loops where only disconnecting power sometimes helped to get it going again. After I finally managed to get in touch with UPC support, 2 days later the new box arrived.

My biggest concern was whether this new Pace box would still work my Pronto/IRTrans combo; would it accept the same Infrared (IR) codes as the Thomson? A quick test revealed that the old Thomson remote could be used to control the new Pace, so at that point I didn’t expect any problems.

Later that evening, when I used the Pronto to control the Pace mediabox, I discovered that the “CH+” and “CH-” buttons of the Pronto didn’t work anymore. To be precise: the first “CH+” did work, but the second time it didn’t…huh? The “CH-” had the same wierd behavior.. first push OK, the second was ignored; and the 3rd, 4th… So selecting a channel with a digit (0..9) did work as before, but zapping through all the channels didn’t? What the ….?

Hmm, time for some investigation. First thing I did was trying to find the Pronto CCF codes for this new model, but that didn’t help. Later I found out that this Pace uses the same IR codes as a Philips DCR-8111 but I couldn’t find any IR codes for that model either.

Well, back to the original symptom then Рwhy do the CH-buttons only work once? After some time I found the cause in a post on the L5 remote forum:

Parity & Toggle Bits
A somewhat common problem is when a device (such as a cable box) will accept a learned code once but not twice in a row. For instance, you can enter the channel “1 – 2”, but not “3 – 3”. This is not a fault with your new remote, but rather a very hard to work with design employed by your equipment.
What happens is your original remote tacks on a “parity bit” (sometimes called a “toggle bit”) to the end of each code. So, the first time it sends the code it follows up with a “0”. The next time it ends with “1”. The problem is that a learning remote can only learn or send the signal one way ‚Äď the way it learned it. Your equipment, unfortunately, will not accept the code again unless it ends with a new parity bit or you send a different code to clear the memory buffer.

The most common example of equipment that uses this system is anything that employs the Philips RC5 or RC6 code format – such as Philips or Marantz products, or even Microsoft Media Center Edition remote controls. As the RC5 and RC6 implementation guidelines make parity bit checking optional, not all RC5/RC6 devices will respond the same way to non-alternating learned codes. Some may require parity bits at all times, some may only require it for certain commands (such as “power”), some may use the parity bit only for closely repeated commands (meaning you could send “3-3-3” quickly with the original remote but only slower using a learned code), while some ignore parity bits completely and show no noticable operational difference with or without.

The Philips Pronto is the only remote that I am aware of that can learn codes with alternating parity bits in the method required for several (not all) brands of equipment. If you have one that is not yet covered you can try tacking on a “do-nothing” code after each real one. So, your button for “3” would send the “3” code followed by another code to clear the buffer. What can that code be? Anything that the equipment senses as a real code but doesn‚Äôt affect operation. It may be next to impossible to find such a code.

Great, this sounds exactly as what I’m experiencing. Parity (toggle) bits… and the new Pace doesn’t ignore them!

Now that I know what is causing my problem and how it works, I should be able to create a workaround; I can stop searching for the correct IR codes for the CH+/CH- buttons, because a single IR code for a CH button will never work. Instead, I will need to get hold of both IR code ‘versions’ for a single CH button and make sure my system will automatically alternate between those 2 versions.

How do I get those 2 codes for a single button? Well, ¬†PEP1 (Pronto Edit Professional v1) and a Pronto Remote (a TSU9600 in my case) enables you to learn a IR code. So that’s what I did; I learned ¬†a couple of CH+ IR codes, copied the resulting CCF codes to a text editor and searched for differences; and found the 2 different versions for CH+:

[up1][CCF]
0000 0072 0024 0000 000F 000A 0006 000A 0006 0016 0006 000A 0006 000A 0006
001C 0006 000A 0006 000A 0006 000A 0006 0016 0006 0016 0006 0010 0006 0016
0006 000A 0006 0016 0006 000A 0006 000A 0006 0CB7 000F 000A 0006 000A 0006
0016 0006 000A 0006 000A 0006 001C 0006 000A 0006 000A 0006 000A 0006 0016
0006 0016 0006 0010 0006 0016 0006 000A 0006 0016 0006 000A 0006 000A 0006
BEA1

[up2][CCF]
0000 0072 0024 0000 000F 000A 0006 000A 0006 0016 0006 000A 0006 000A 0006
001C 0006 000A 0006 000A 0006 000A 0006 000A 0006 0016 0006 0010 0006 0016
0006 000A 0006 0016 0006 000A 0006 000A 0006 0CB7 000F 000A 0006 000A 0006
0016 0006 000A 0006 000A 0006 001C 0006 000A 0006 000A 0006 000A 0006 000A
0006 0016 0006 0010 0006 0016 0006 000A 0006 0016 0006 000A 0006 000A 0006
BEA1

There’s¬†definitely¬†a difference between those 2 codes, marked in red; so far things are looking good. Now it’s time to test these 2 codes by sending a up1, up2, up1, up2 IR sequence to the Pace mediabox. Yep; the channel increased 4 times – it worked!

The rest is simple.¬†My system uses the IRTRans ASCII interface protocol for sending IR with the IRTrans LAN module. The IR commands that can be used are not predefined in my Domotica system however; they are retrieved from the IRTrans by using the Agetremotes and Agetcommands commands. So all I have to do is ‘tag’ the 2 ‘up’ commands in a way that my system can figure out that there are 2 commands for ‘up’. For example, I could name them [up#1] and [up#2] and let the system pick the right ‘up’ version and send the right ‘up’ command (up#1, up#2) to the IRTrans with the Asnd command whenever a UI sends a ‘up’ request..

No need to change anything at UI level and 10 lines of code should suffice. Problem solved!

Update Monday 06-08-2012:

I received an email from IRTrans (Marcus) with some additional information:

The Pace STB uses RCMM Codes with toggle bits. Newer IRTrans Firmware versions have got a flag you can activate.

Then the IRTrans device will recognize and reassemble the toggle bits automatically.

You can find the setting on the IR Codes page of the IRTrans Device settings.

So if you’re using a IRTrans product, it’s as simple as changing the Device settings. Another thing worth knowing is that if you have a firmware version that doesn’t support this setting (like me), you can request a firmware update via Email.

 

Extra user interfaces

I’ve been looking for an easy way to add some extra user interfaces to my Domotica system, particularly for upstairs. Now that we have a bunch of Radiator Thermostats and Roller shutters both up- and downstairs, the wish for some extra User Interfaces (bedrooms, office etcetera) increased the last couple of weeks. Yes, the Radiator Thermostats can also be operated manually, but that’s not always that convenient; I want something more flexible and versatile.

Should I buy a tablet and put it on the wall? Neh, too pricy and therefore not expandable enough – we would be bankrupt before I could finish this project ;-).

Or is it better to create a User Interface for the¬†smartphones? Useless for this particular ‘problem’, cause we all have the habit of leaving our smartphones downstairs – no one has the urge to Tweet or call while in bed (yet…). Besides that, guests in our house should also be able to lower a roller shutter without too much hassle.

What I’d like to have is something small & simple, touch-driven, communicating wirelessly, with an easily adjustable User Interface without having to change the code too often and, if possible, suitable to take in your hands.

For that I bought this Touch Shield to tinker with during the next weeks. There are some nice videos that demonstrate what you can do with these Touch shields and they look well enough to give it a try. This particular shield can be used with the Adafruit library, which takes care of the low level stuff and provides functions for stuff like drawing lines, circles, rectangles and text on the screen Рwith an SD card it should even be possible to draw 24-bit BMP files Рwell, let that be be step 2 for now.

While this Touch Shield is on its way, I started thinking of how to make this Touch Shield cooperate with my Domotica system. As I said, I don’t want to change the sketch when I want to add another menu option or button or anything else that comes to my mind; the ‘definition’ of the screens, menus, buttons should not be defined in the sketch, but somewhere else. Preferably somewhere on the network in a file; another good option could be stored on a SD card.

This file should contain everything that can be regarded as being subject to change when multiple Touch Shields are going to be used throughout the house: menu options, shapes, buttons, colors, text, actions; so the basic idea is: 1 sketch which can handle multiple User Interface definitions, designed for a specific location/room.¬†So I definitely need some sort of¬†User Interface Markup language for that, like XAML¬†is. ¬†But the markup language to be used should also be really ultra-light-weight, cause we’re still dealing with an Arduino here, where RAM is limited and every bit of overhead leads to problems, very quickly. I mean, you could define a button like this:

<Button Background="Red" Foreground="Green" Content="Light on" Action="C02 ON"/>

but that will consume more memory than

B;BRED;FGREEN;TLight On;AC02 ON

So maybe I’ll create my own Markup ‘language’; we’ll see.

The way in which an action will be communicated with my Domotica system will be something comparable to how our Ethernet Doorbell communicates with the system; for example, when the touch of a button should result in a light going on or off, I can just let the Arduino send a string (the Action property in the examples above) to my system and it will take care of the rest.

Big plans, which also bring a lot of new challenges – and I’m sure, a lot of fun!