Thursday, August 22, 2013

BLE112 IAR and moving bitmaps from RAM to FLASH (PROGMEM in IAR)

In previous article about converting st7565 library from AVR to IAR after compiling there was error about not enough memory

Error[e104]: Failed to fit all segments into specified ranges. Problem discovered in segment XDATA_N. Unable to place 2 block(s) (0xc02 byte(s) total) 
in 0x96c byte(s) of memory. The problem occurred while processing the segment placement command 
"-P(XDATA)XDATA_N=_XDATA_START-_XDATA_END", where at the moment of placement the available memory ranges were "XDATA:1594-1eff"


Quick fix about that to just run example was to minimize the heap size in IAR linker options.
Its ok if you want just to run the examples and see the results, but what if you need to store more images in flash - you need to move them to flash memory.

To see current memory consumption in IAR you need to tell the linker to save this information for you.
Go to Project Options > Linker > List (tab). Set is as follows:


Then after compiling source look for List folder in your build directory, there should be the file with .map extension. At the end of file you will found something like this:

 119 888 bytes of CODE  memory
      35 bytes of DATA  memory (+ 77 absolute )
   7 052 bytes of XDATA memory
     194 bytes of IDATA memory
       8 bits  of BIT   memory
   4 259 bytes of CONST memory


XDATA is your RAM. It is almost reaching 8KB what is RAM size in 8051. After moving images into flash its getting better:

 119 632 bytes of CODE  memory
      35 bytes of DATA  memory (+ 77 absolute )
   6 401 bytes of XDATA memory
     194 bytes of IDATA memory
       8 bits  of BIT   memory

   4 259 bytes of CONST memory

Its getting better. But how to move variables into flash ? In AVR like you can use PROGMEM, but syntax in IAR is different. Just add __code before variable name:

const unsigned char   __code stop_glcd_bmp[]={
0xFF, 0x00, 0x00, 0x00, 0x80, 0xc0, 0xe0, 0xf0,
 
You need to use const keyword as well.

After that your array will go to the flash memory freeing RAM. But then you will probably face another problem. After passing such variable to function you will notice that all you can read from that pointer are some random data or zeros.

You need to tell compiler that these variables are located in flash. In function definition you need to specify __code as well:

void drawbitmap(uint8_t *buff, int x, int y, 
uint8_t __code *bitmap, int w, int h,
int color);

That's all. Works like PROGMEM from AVR world.





Wednesday, July 31, 2013

BLE112 and redirecting debug info to console in IAR

Today I encountered strange behaviour on BLE112 and ST7565R display. The "drawbitmap" function wasn't working as expected, 

source image:


converted to hex with bmp2glcd

static unsigned char stop_glcd_bmp[]={

0x00, 0x00, 0x00, 0x00, 0x80, 0xc0, 0xe0, 0xf0,
0xf8, 0xfc, 0xfe, 0xff, 0xff, 0xff, 0xff, 0xff, 
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xfe, 0xfc, 0xf8, 
0xf0, 0xe0, 0xc0, 0x80, 0x00, 0x00, 0x00, 0x00, 
0xf8, 0xfc, 0xfe, 0x3f, 0x1f, 0x9f, 0x9f, 0x9f,
0x1f, 0x3f, 0xff, 0x9f, 0x9f, 0x9f, 0x1f, 0x1f, 
0x9f, 0x9f, 0x9f, 0xff, 0x7f, 0x3f, 0x1f, 0x1f,
0x1f, 0x3f, 0x7f, 0xff, 0xff, 0xff, 0x1f, 0x1f, 
0x9f, 0x9f, 0x9f, 0x1f, 0x3f, 0x7e, 0xfc, 0xf8, 
0xff, 0xff, 0xff, 0x7c, 0x78, 0xf3, 0xe3, 0xc7,
0x0f, 0x1f, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 
0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0xff, 0xff,
0xff, 0x00, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00, 
0xe7, 0xe7, 0xe7, 0xe3, 0xf0, 0xf8, 0xff, 0xff, 
0x1f, 0x3f, 0x7f, 0xfc, 0xf8, 0xf9, 0xf9, 0xf9,
0xf8, 0xfc, 0xff, 0xff, 0xff, 0xff, 0xf8, 0xf8, 
0xff, 0xff, 0xff, 0xff, 0xfc, 0xf8, 0xf1, 0xf1,
0xf1, 0xf8, 0xfc, 0xff, 0xff, 0xff, 0xf0, 0xf0, 
0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0x3f, 0x1f, 
0x00, 0x00, 0x00, 0x00, 0x01, 0x03, 0x07, 0x0f,
0x1f, 0x3f, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0x3f, 0x1f, 
0x0f, 0x07, 0x03, 0x01, 0x00, 0x00, 0x00, 0x00,
};

result on display:



debugging ble112 with IAR works very slow on VMWare Fusion, so i decided just to print some values to console and check if they are correct. Dumping logs to console from compiled code is easy.

Just use standard printf which is in stdio.h, then you need to tell IAR that you want to see these printf's in console. To do this go to the Project options -> Linker -> Output (tab) and in the "Format" section where you have selected "Debug information for C-SPY" you need to have "With I/O emulation modules" checked, then when debugging select View > Terminal I/O.
enable console ouptut

debugging with console printout on right


Long story short - Ive fixed the code to show images properly. The problem was in pmg_read_byte which is not available in IAR. When fixing code Ive found on some website to use macro:

#ifndef pgm_read_byte
#define pgm_read_byte(a) (a)
#endif

But it was not working as expected - returning wrong bytes. After removing this macro and using buffer as array, bitmap is displayed correctly.



Monday, July 29, 2013

connecting ST7565R LCD to BLE112

After playing around with BLE112, connecting it to my ATMEGA644P via UART I found a post about programming BLE112 with C.

http://blog.bluetooth-smart.com/2012/09/11/programming-the-ble112-with-c-code-using-iar/

After that Ive read CC2540 documentation and realized that this little module got everything what I need in my project - and even more.

First of all Bluegiga offers BGSCRIPT to program BLE112. Its very simple and got a lot of limitations, of course its sufficient to do simple programming, but nothing more. you even cant create functions.

I was very pleased that I can use C language to program this chip. You need IAR which is not free, however you can easily request 30 days trail or kickstart edition which is limited to 4kb of code (which is insufficient …)
Just use 30 day trial or find other way of getting IAR ;)
Trail version 8.20.2 runs just fine in VMWare fusion with all debugging capabilities as well.


Then you need sample BLE apps with BLE stack. Just search for it on TI site: BLE-CC254x-1_3_2.zip

After that you are ready to go.

ST7565R LCD is 3.3v - same as BLE112, so just connect it to the BLE. I used 4 pins - P0.2 P0.3 P0.4 P0.5
I still got no BLE breakboard so I had to solder cables right to BLE :) Its not very complicated task - an extra hand is recommended however.


Next find a ST7565R library - I used: https://github.com/adafruit/ST7565-LCD
C is not my "everyday" language so I spent two hours trying to compile it with IAR. After some modifications I was able to compile it using IAR.


Things to remember when converting code from AVRGCC or similar to IAR C to compile for CC2540:



  • There is no (or I cant find how to use it - even __delay_cycles) delay, sleep or what so ever function, so I used:

    #define F_CPU 32768000
    #define _delay_us(us) __delay_cycles(((us * F_CPU)/1e6) + 0.5)#define _delay_ms(ms) __delay_cycles(((ms * F_CPU)/1e3) + 0.5)
  • setting port direction you need to use PxDIR and not DDRx (where x is port number)
  • if you got compile errors with " Error[Pe020]: identifier "P0DIR" is undefined " just include ioCC2540.h
  • Ive got strange problems with "for" loops when using uint8_t - just convert them to int.
  • uint8_t declaration can be found in stdint.h "Error[Pe020]: identifier "uint8_t" is undefined"



Ive used wiring as follows:

ST7565R          BLE112
CS       ----     P0.2
RST      ----     +3.3v
A0       ----     P0.3
SCLK     ----     P0.4
SDATA    ----     P0.5


Of course that is not sufficient - you still need to supply 3.3v, GND and nine 10uF capicitors on other lines (just check datasheet).

After that you should be able to compile project and display ADAFRUIT logo which is included in stlcd.c.
drawrect, drawcircle should be working as well.



 The problem comes when you want to use drawstring function. When linking you will probably encounter similar error:

Error[e104]: Failed to fit all segments into specified ranges. Problem discovered in segment XDATA_N. Unable to place 2 block(s) (0xc02 byte(s) total)
in 0x96c byte(s) of memory. The problem occurred while processing the segment placement command
"-P(XDATA)XDATA_N=_XDATA_START-_XDATA_END", where at the moment of placement the available memory ranges were "XDATA:1594-1eff"

Solve to this is pretty simple, just go to project options, on the left select C/C++ compiler
and find Preprocessor tab. Then in defined symbols search for INT_HEAP_LEN=3072 and change it to 2048.



after that project should compile without errors.

Here is final version :)




 In next few days I will upload ST7565 IAR library to github.









Sunday, February 17, 2013

Windows XP 64bit for IA64


Windows XP 64-Bit Edition was designed to run on Intel Itanium family of microprocessors in their native IA-64 mode.


There are two versions of Windows XP for Itanium based systems:

1. Windows XP 64-Bit Edition for Itanium systems, Version 2002


Based on Windows XP codebase, was released simultaneously alongside the 32-Bit version of Windows XP on October 25, 2001.
You can find this one on emule.

WINDOWS.XP.PROFESSIONAL.64.BIT.EDITION-PLANKISO

Serial number is in archive and starts with: C4FPJ-...

file: windows.xp.pro.64.bit.edition-plankiso.bin
md5: faebc8b322702f9bb4872aeabb59c152
sha: 5febb1de77a9849e1ee3019975e23bad49e8fea8


Login screen:


System properties screen:


System is equipped with Internet Explorer 6. Very hard to use theses days :)


Windows Update isn't working anymore.
Furhtermore I wasnt able to find any service packs for this edition on MS site.


Thursday, September 27, 2012

bluegiga BLE112 smart module - got it

BLE112 is a Bluetooth smart module targeted for low power sensors and accessories. BLE112 _Bluetooth _smart module can be power directly from a standard 3V coin cell battery or pair of AAA batteries. In lowest power sleep mode it consumes only 400nA and will wake up in few hundred microseconds. 




I'll try to connect it to ATMEGA644p.