osx - set routing after establishing vpn connection

nice and easy trick to set up routing after VPN connection has been established.

just create ip-up file in /etc/ppp

for example:

sudo nano cat /etc/ppp/ip-up

#!/bin/sh
/sbin/route  -v add -net 10.0.0 -interface ppp0

be sure to set chmod 755.

osal_snv_read and osal_snv_write on BLE112 (CC2540 - 128kb version)

osal_svn_read and osal_snv_write provides a way for applications to store information into device's memory persistently.

Please refer to OSAL API pdf. There is a range of ID's which can be used for your applications to store data in. Others are reserved or used by the stack or ble platform.

Usable ID's are in range:

0x80 - 0xFE

When you run this code on BLE112 (or other cc2540 128kb version):

uint8 array[]={0,1,2,3,4,5,6,7,8,9};

uint8 read_array[10];

uint8_t result = osal_snv_write(0x80,6,array);

You will receive NV_OPER_FAILED in result. Same result when trying to read using osal_snv_read.

After some digging around net I found explanation. Code provided in sample applications (ie. SimpleBLEPeripheral) and HAL subsystem was designed to run on 256kb chip.

One file need to be fixed to use osal_snv read/write functions properly.

Search for hal_board_cfg.h file, look for code shown below:

// NV page definitions must coincide with segment declaration in project *.xcl file.

#if defined NON_BANKED

#define HAL_NV_PAGE_END                30

#elif defined HAL_BOARD_CC2541S

#define HAL_NV_PAGE_END                125

#else

#define HAL_NV_PAGE_END                126

#endif

change it to :

// NV page definitions must coincide with segment declaration in project *.xcl file.

#if defined NON_BANKED

#define HAL_NV_PAGE_END                30

#elif defined HAL_BOARD_CC2541S

#define HAL_NV_PAGE_END                125

#elif defined HAL_BOARD_128K

#define HAL_NV_PAGE_END                62

#else

#define HAL_NV_PAGE_END                126

#endif

and add HAL_BOARD_128K to your preprocessor settings:

connecting CC2540 (BLE112) to MCP23009 using I2C

CC2540 does not have hardware i2c interface. Implementing i2c protocol in software is quite easy task. A lot of samples could be found around the net.

Ive used i2c implementation found on: https://github.com/RedBearLab/Biscuit

Remember to change #defines to reflect your wiring. Also check .c file for hardcoded ports. You need to change this before running code.

My wiring of MCP23009 to BLE112:

wiring MCP23009 i2c extender to CC2540 (BLE112)

Next use the code below to turn on LED diode.

First you need to establish connection to MCP23009 (i2c address: 0x40) and set few registers:

    i2c_init();
    i2c_start(0x40);
      
    // io mode
    i2c_write(0x00);  // IODIR
    i2c_write(0x00);  // 00 - all pins as output
    i2c_stop();
    // polarity
    i2c_restart(0x40);
    i2c_write(0x01);
    i2c_write(0x00);
    i2c_stop();    
    // config
    i2c_restart(0x40);    
    i2c_write(0x05);
    i2c_write(0x00);
    i2c_stop();    
    // pullup
    i2c_restart(0x40);    
    i2c_write(0x06);
    i2c_write(0x00); // 00 - disable pullups
    i2c_stop();    
 
Registers can be found in datasheet, quick look to understand what registers was set in code:

Then you can turn on LED:

    i2c_restart(0x40);
    i2c_write(0x09);
    i2c_write(0xFE);
    i2c_stop();    

Useful links:

MCP23009 datasheet

MySQL - changing table engine in very big table dump

Changing table type from MyISAM to InnoDB or some other engine could be very painful if your table has a lot of rows.

If you have a lot of time you can do it using standard ALTER TABLE syntax.

However If you have more than one drive in you box, a lot faster would be dumping and restoring dump from command line.

After dump use sed to change table type:

sed -e "s/Engine=MyISAM/Engine=InnoDB/gi" input.sql > output.sql

Then import your output.sql.

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.

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.

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.

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.