TKJ Electronics

I finally got the display I bought on eBay to work. It took me a lot of hours as the man I’d bought the display from told me that the display controller was an ILI9320, so I started making code for the display like it was using an ILI9320 controller.

But as it didn’t work, I started debugging using my Raisonance RLink, and just when I looked at the Device variable – a variable which holds the controller number, and is loaded at the initialization process of the display, it showed me that it was an SSD2119 controller.

So I found the SSD2119 datasheet and started recoding using the new Command calls found in the datasheet… Finally it worked and showed some life 🙂

So right now I have a working SSD2119 code with SetPixel, Text, Circle, Rectangle, Fill and some working Touch Screen commands for the onboard ADS7843 touch screen controller.

Please take a look at this image to see the display in action:

SSD2119 from top

SSD2119 Pringles example

The current GUI commands I’ve made is:
void Lcd_Text(u16 x, u16 y, u8 *str, u16 len,u16 Color, u16 bkColor);
void Lcd_Line(u16 x0, u16 y0, u16 x1, u16 y1,u16 color);
void Lcd_Circle(u16 cx,u16 cy,u16 r,u16 color,u8 fill);
void Lcd_Rectangle(u16 x0, u16 y0, u16 x1, u16 y1,u16 color,u8 fill); // Slower than Lcd_ColorBox
void Lcd_Square(u16 x0, u16 y0, u16 width, u16 color,u8 fill);
void Lcd_ClearCharBox(u16 x,u16 y,u16 color);
void Get320240PictureCode(u8* pBuffer,u32 BufferCounter,u32 BaseAddr);

void Lcd_FastRectangle(u16 x0, u16 y0, u16 x1, u16 y1,u16 color,u8 fill); // Faster than Lcd_Rectangle
void Lcd_FastSquare(u16 x0, u16 y0, u16 width, u16 color,u8 fill); // Faster than Lcd_Rectangle
void Lcd_FastClearCharBox(u16 x,u16 y,u16 color);

void DispPic320_240(const unsigned char *str);
void DispPic(u16 x0, u16 y0, const unsigned char *str);

DispPic320_240 and DispPic uses a byte array to show a image – the byte array is converted from a 24-bit .BMP (bitmap) file using a program I’ve made in Visual Basic .NET!

You can download the STM32 code for a Paint Demo application I’ve made here: SSD2119_PaintDemo
OBS.: The project files in there is for Ride7, but the code can be used together with ARM-GCC

Messy Table

This is the table where I’m working with electronics when it’s messy!
But still I keep a little bit order, as the PIC is in the left, the STM32 in the middle, and the Arduino (+ ultrasonic) at the right.

Today I recieved a Ultrasonic Range Sensor bought on eBay.

It’s much like the Parallax Ping))), except that it has got a Trig and a Echo pin, instead of the Ping)))’s multipin (Trig and Echo on the same pin)

I quickly made some code in the Arduino IDE and got it running quick…

Just a sidenode from the physics class; as the sound is travelling thru air with a speed of 340 m/s, this can be recalculated to 0.034 cm/microsecond, which is the same as 29.411 microsecond/cm

Arduino with Ultrasonic Sensor

For those who may be interested the code is here:

/* Ultrasonic Sensor

This sketch reads a ultrasonic rangefinder and returns the
distance to the closest object in range. To do this, it sends a pulse
to the sensor to initiate a reading, then listens for a pulse
to return.�  The length of the returning pulse is proportional to
the distance of the object from the sensor.

The circuit:
* +V connection of the Ultrasonic Sensor attached to +5V
* GND connection of the Ultrasonic Sensor attached to ground
* Trig connection of the Ultrasonic Sensor attached to digital pin 2
* Echo connection of the Ultrasonic Sensor attached to digital pin 3

created 25. Januar 2010
by Thomas Jespersen

*/


// this constant won't change.�  It's the pin number
// of the sensor's output:
const int TrigPin = 2;
const int EchoPin = 3;

void setup() {
// initialize serial communication:
Serial.begin(9600);
pinMode(TrigPin, OUTPUT);
pinMode(EchoPin, INPUT);
}

void loop()
{
// establish variables for duration of the ping,
// and the distance result in inches and centimeters:
long duration, inches, cm, mm;

// The Ultrasonic Sensor is triggered by a HIGH pulse of 2 or more microseconds.
// Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
digitalWrite(TrigPin, LOW);
delayMicroseconds(2);
digitalWrite(TrigPin, HIGH);
delayMicroseconds(5);
digitalWrite(TrigPin, LOW);

// Read the signal from the Ultrasonic Sensor a HIGH
// pulse whose duration is the time (in microseconds) from the sending
// of the Trig to the reception of its echo off of an object.
duration = pulseIn(EchoPin, HIGH);

// convert the time into a distance
inches = microsecondsToInches(duration);
cm = microsecondsToCentimeters(duration);
mm = microsecondsToMillimeters(duration);

Serial.print(inches);
Serial.print("in, ");
Serial.print(cm);
Serial.print("cm, ");
Serial.print(mm);
Serial.print("mm");
Serial.println();

delay(100);
}

long microsecondsToInches(long microseconds)
{
// According to Parallax's datasheet for the PING)))
// (another ultrasonic range sensor),
// there are 73.746 microseconds per inch (i.e. sound travels at 1130 feet per
// second).�  This gives the distance travelled by the ping, outbound
// and return, so we divide by 2 to get the distance of the obstacle.
// See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf
return microseconds / 74 / 2;
}

long microsecondsToCentimeters(long microseconds)
{
// The speed of sound is 340 m/s or 29 microseconds per centimeter.
// The ping travels out and back, so to find the distance of the
// object we take half of the distance travelled.

// 340 m/s
// 34000 cm/s
// 34 cm/ms
// 0.034 cm/micros

// 1/0.034 cm/micros = 29.411 micros/cm

return microseconds / 29.411 / 2;
}

long microsecondsToMillimeters(long microseconds)
{
// The speed of sound is 340 m/s or 29 microseconds per centimeter,
// and then we multiply with 10 to get in in millimeters.
// The ping travels out and back, so to find the distance of the
// object we take half of the distance travelled.

// 340 m/s
// 34000 cm/s
// 340000 mm/s
// 340 mm/ms
// 0.34 mm/micros

// 1/0.34 mm/micros = 2.9411 micros/mm
return microseconds / 2.9411 / 2;
}

Finally I found how to use the Nokia LCD I’ve bought from Sparkfun a year ago.
Originally I bought the display for the Arduino, but as the LCD is 3.3V I tried to make a voltage convertion circuit, but it didn’t work 🙁
But now, I’ve got the STM32 which is running 3.3V – so I could just connect it directly… And then it worked!

Nokia LCD - Hello World

Nokia LCD - TKJ-Electronics Logo

The time is currently 21:42 and I’ve been sitting in front of my computer in 2 hours to get the DFU programming to work.

Now it is working, and I’m able to make one of my excisting projects into a DFU loadable project (compiled it’s a .dfu filed)

I’ve also changed the DFU bootloader code to use GPIOA_0 as DFU Enable pin, and GPIOA_1 as USB Disconnect – this makes me able to use the GPIOB and GPIOC for my display without any interferrance!

Here is how you make a Ride7 project DFU loadable:

The USB connection between the STM32 and the computer is finally working.
I’ve tried the different USB programs from the StdPeriph Library

Fx.

• Virtual COM Port
• DFU Programming

As I’m using Ride7 for programming, I can upload the project and sources if you want me too.

OBS: If you have projects which DOESN’T use the USB, you have to set the USB Disconnect jupmer to Ground (Pos. 1-2), as if not, the STM32 will stop in some kind of USB Interrupt trying to make a data communication with the computer, but it never comes as the STM32 doesn’t start one!

I discovered this Ã? when I tried DFU’ing my 320×240 LCD code – and when I went back to normal .hex, it didn’t work – that was because I had to set the USB Disconnect to Ground!

Got some sensors hooked up to my header board.
The code is ugly and needs work, but gets data from stuff.

UART1@115200 = ft232 USB adapter (todo change to internal usb) – for debugging
UART2@9600 = SFE 16×2 SerLCD (For Display)
I2C1@100KHz = TMP102 (temperature) and HMC6352 (compass)

TMP102:

Compatible with LM75
TIe ADD0 to GND for default address 0x90
I just grabbed the LM75 stuff from ST’s STM32103B EVAL Demo kit (tsensor.h/c) and ripped out the LCD stuff – TODO work on formatting, return types, etc

HMC6352:

Get Heading: Send 0x41 (‘A’) and read in two bytes of data / 10 for decimal degrees

I think I like I2C, this was all entirely too easy 🙂

TODO: Improvements so maybe I can post some code, and should do a driver for the ADXL345 accelerometer.

New Gyro, Cam, LCD on the way to figure out as well.

So I’m quite frustrated with trying to roll my own arm-elf- toolchain. Building it was easy enough, but getting the options right is proving to be challenging. I managed to work through all the hard/soft FPU stuff with newlib, and got things to compile, but still some linker warnings/errors that result in the app crashing on the hardware. One day I’ll learn to debug and look into this more.

In the meantime, even though the download link for it is quite well hidden, I have discovered that I am quite happy with Codesourcery’s G++ Lite edition. It includes the GNU ARM buildchain, along with some of their proprietary tools (so no, I can’t mirror it 🙁 ) as an unsupported command line only free version with a license that looks very reasonable to me, so I’m pretty comfortable working with it. Thanks to those responsible for make the Lite version exist, now if only we could get an arm buildchain in the repos…

To save you the trouble of accidentally downloading their full suite trial edition like I did (feel free to purchase it if you want an IDE and other tools), here is a link to the downloads:
http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite
You will want to select the EABI (first) link (unless you need a different target OS, which for an STM you probably don’t)
The first links for the Installer are the easiest to use, everything is packaged in a Java installer to extract and setup your path, make links, etc)

I’ve been using Randomskk’s STM32 Skeleton project Randomskk’s GitHub, he has a rather nice blinking LED example in there (I had to change the LED pin for my board and fixup the Makefile to have tabs, but that was all painless).

Now to see if I can get FreeRTOS to build under arm-none-eabi – what fun, doesn’t look like it will be trivial based on the errors I’m getting so far, but I can’t imagine it should be too bad.

So we all know that GSM phones can induce various sounds in unshielded amplified speakers, but ever have one take over control of your machine?

I recently got a new Blackberry 8320 and switched it from T-Mobile to AT&T (work phone). Whats fun is that when I set it down to the right of my keyboard (by the mouse and my Polycom) my cursor starts doing strange and interesting things when its radio is active – cursor movement, right clicks/half-clicks, etc – just weirdness. Now if this were an RF mouse or something, sure, but this is a wired, USB, optical mouse, which makes it seem odd. Any theories? Anyone know if optical mice have an ADC anywhere in the input chain?

Below is the openocd config I am currently using with my STM32 (Olimex STM32 header board from SFE) to program through the JTAG header on the board. Randomskk had better scripts, but they didn’t want to behave for me. Its rather minimal, but it does the job. TODO: integrate changes back into the skeleton project.

Tested on FC10/FC11 with openocd 0.3.1

GIves some weird warning know – run with sudo openocd -f thisfile.cfg 2>&1 | grep -v khz for readable output (filters the repetitious warning)