My first commit to github, yay!
It’s a rudimentary GUI system, optimized for touchscreen use. Very lightweight and totally OOP (except for properties, zomg!). Plus, about every second line of the source is a comment, because it was written to support an educational project. The basic Idea is this: GUI System -> GUI Pages -> GUI Elements. No other documentation so far, although there’s a built-in numerical keypad – which will also give you an idea of how to use the code.
Find it on https://github.com/niston/touchGUI
Here are some screenshots of an embedded project using touchGUI.py:
The other day, from the #raspberrypi@freenode IRC channel was looking for a way to calibrate a sensor he had on his raspi’s I2C bus. He stated that, the sensor gave a millivolt reading from an ADC, that the millivolt reading was linear to the measured parameter, and that his existing code was incomplete (no calibration) and thus produced a reading with considerable offset at the lower end of the scale, compared to a reference sensor. So he was wondering how to do High/Low Point calibration in software.
He had another requirement: He wanted to map the calibrated millivolt reading from the sensor to a zero based ppm scale in a linear fashion.
It took me a while to figure something out, but here it is:
The idea is to provide ratio-based mapping between the two scales -millivolts from sensor to value on the target scale- while referencing the zero point on the target scale to the Low Point Calibration millivolt value. The targetCalHigh variable is the target scale value at calibration high point (the high point calibration solution’s known ppm value). Because the targetCalLow value is zero as he calibrates the low point with 0ppm solution, we don’t need it for the calculation. The targetValue is the calibrated reading, mapped to whatever zero based scale targetCalHigh refers to.
did some verification of the formula with different calibration solutions (0ppm, 550ppm, 1000ppm and 2200ppm) and said that his raspi based probe provides accurate readings now when compared to the same reference meter, and that the problem appears to be solved.
Feel free to use my Math as you see fit.
As a little review on the making of Stream One, this is the PPT for a presentation I held at school today. Looking into aspects like: The idea behind it all, prototyping, cross platform development with mono, building and evolving the firmware, some of the software patterns used during design as well as some reflection about what has been done so far and where it’s all heading to.
You can view/download the PDF version: Building Stream One (PDF).
Debugging a C# app that:
- Uses native libraries
- Segfaults on Linux w/ mono
- Runs fine on Windows
Given that a native C app using the same calls to the native lib will not Segfault, you can:
- set MONO_LOG_LEVEL=debug
- set MONO_LOG_MASK=dll
- Create a .gdbinit file as per .
- Use the –args switch to tell gdb to run mono with your exe
- Once in gdb, use “r” to run mono with your exe.
- Use “bt” to get a backtrace
- Use “info sharedlibrary <libname>” on your native library
If you have debug symbols, you can:
- Use “info registers” and
- “info frame” to get stack frame information
You can also do:
mono –trace=all <executable>
An example is at http://pastebin.com/Kza9kemJ
I want to cross-platform develop c# on Windows with Visual Studio, for the Raspberry Pi running mono. I’m using SQLite for it’s embeddedness and portable database files. Now, while mono has support for SQLite, my version 3.2.3 happens to have a documented bug with Mono.Data.Sqlite. So it can’t work with .NET 4.0 on Windows.
Doom and despair: The mono project does not have a newer installer for Windows. The available one installs the 3.2.3 instead of current 3.8.0. Attempting to use the Mono.Data.Sqlclient.dll from the Raspberry Pi on the Windows machine was no help either and gave me a BadImageFormatException.
Thus, I compileth mono on my Win7 box…
I’ve been mostly following the official guidance  from the mono project here, with some extra steps and additional information from outside sources:
- mono 3.2.3 was already installed
- downloaded / installed cygwin
- obtained mono 3.8.0 source tarball and extracted to disk
- replaced cygwin make.exe with the make.exe from mono 3.8.0 
- Added the mono 3.2.3 bin folder to the PATH variable
- In cygwin, did export MONO_PATH=”/cygdrive/c/Program Files (x86)/Mono-3.2.3″ 
- Gave my account NTFS permissions to the <mono_3.8.0_src>\runtime folder
- Did a
- Followed by
make, make install
This took forever, yet worked like a charm.
Some caveats apply, because my Windows machine is 64bit:
I can’t build my application to AnyCPU target , and I have to use the 64bit version of the sqlite3.dll – least everything grinds to a halt with more BadImageFormatException.
But yes, I can now code and compile test.exe in VS on Windows, scp the test.exe to the raspberry, and run it there with mono test.exe. Not bad.