MicroBlaze Development Kit

I have a new toy - MicroBlaze Development Kit from Xilinx! :)



The main feature for me here is the USB download feature as my laptop doesn't have a serial port as most of XESS boards require. Hopefully I can do all my hardware emulation research tests with this board now :)

The Key Features are:
* Device Supported: XC3S1600E FG320-4CS1
* Clocks: 50 MHz Oscillator (soldered) , 66.67MHz Oscillator (socketed)
* Memory: 512Mb (32Mx16) DDR SDRAM, 128Mb (32Mx8) Parallel Flash, 16Mb SPI Flash, & Xilinx Platform Flash
* Connectors and Interfaces: Two RS-232 Serial Ports, 1 10/100 RJ45 Ethernet Port, DB 15 VGA Display, LCD Graphic Display, SPI Port, 1 PS2 Port, 4 channel DAC and 2 channel DAC, General Purpose I/O: Buttons, Switches, LEDs, Rotary Encoder, and 43 Bit User Expansion (16 Diff-Pairs) Connector, and three 4-bit I/O Connectors and 14 Input only I/O, 50MHz and socketed 66.67 OSC, and 1 SMA input.
* Display: 16 x2 Character LCD, RGB VGA

Compiling uClinux OpenRISC port

While compiling uClinux today I succeeded with some source modifications.

ERROR:
/home/ant/project/or1k/uclinux/uClinux-2.0.x/include/asm/board.h:63: Error: junk at end of line, first unrecognized character is `/'
SOLUTION:
include/asm/board.h: only /* */ comments are allowed. // comments should be removed

ERROR:
head.S:231: Error: junk at end of line, first unrecognized character is `,'
SOLUTION:
arch/or32/kernel/head.S: remove last coma from the line 231: .section .romvec, "ax",

ERROR:
/home/ant/project/or1k/uclinux/uClinux-2.0.x/include/linux/skbuff.h:424: error: label at end of compound statement
SOLUTION:
in include/linux/skbuff.h, at the lines 423 and 410, add ; after head

ERROR:
sched.c:440: error: label at end of compound statement:
SOLUTION:
in kernel/sched.c, at line 439 add ; after case TASK_RUNNING:

ERROR:
tcp_input.c:2349: error: label at end of compound statement
SOLUTION
in net/ipv4/tcp_input.c, at line 2347 add ; after default:

ERROR:
udp.c:202: error: label at end of compound statement
SOLUTION:
in net/ipv4/udp.c, at line 201 add ; after next:

ERROR:
filemap.c:775: error: label at end of compound statement
SOLUTION:
in mmnommu/filemap.c, at line 773 add ; after case 0:

ERROR:
or32-uclinux-ld -T arch/or32/board/rom.ld arch/or32/kernel/head.o init/main.o init/version.o \
arch/or32/kernel/kernel.o arch/or32/mm/mm.o arch/or32/board/board.o kernel/kernel.o fs/fs.o ipc/ipc.o net/network.a mmnommu/mm.o \
fs/filesystems.a \
drivers/block/block.a drivers/char/char.a drivers/net/net.a \
/home/ant/project/or1k/uclinux/uClinux-2.0.x/lib/lib.a arch/or32
/lib/lib.a /opt/or32-uclinux/lib/gcc/or32-uclinux/3.4.4/libgcc.a -o linuxor32-uclinux-ld: error: no memory region specified for loadable section `.rodata.str1.1'
make: *** [linux] Error 1
SOLUTION:

in arch/or32/board/rom.ld add entry for .rodata.str1.1 and .rodata.cst4 similar to that for .rodata. as follows:

        .rodata.str1.1 :
        {
        *(.rodata.str1.1)
        __etext = . ;
        } > flash

        .rodata.cst4 :
        {
        *(.rodata.cst4)
        __etext = . ;
        } > flash

With these modifications the application compiled and linked successfully.

Building with GNU toolchain

I was trying to build OpenRISC architectural simulator today. Configure task passed fine, but on the make stage I've got the following error:

configure.in:11: version mismatch.  This is Automake 1.9.6,
configure.in:11: but the definition used by this AM_INIT_AUTOMAKE
configure.in:11: comes from Automake 1.9.5.  You should recreate
configure.in:11: aclocal.m4 with aclocal and run automake again.
WARNING: `automake-1.9' is needed, and you do not seem to have it handy on your
         system.  You might have modified some files without having the
         proper tools for further handling them.  Check the `README' file,
         it often tells you about the needed prerequirements for installing
         this package.  You may also peek at any GNU archive site, in case
         some other package would contain this missing `automake-1.9' program.
make[3]: *** [Makefile.in] Error 1
make[3]: Leaving directory `/home/ant/project/or1k/or1ksim/cpu/or32'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ant/project/or1k/or1ksim/cpu'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ant/project/or1k/or1ksim'

After issuing aclocal command the build succeeded. WTF?
I'm not very familiar with these tools, so I googled for 'aclocal'. Here's what I found:

The aclocal program creates the file `aclocal.m4' by combining stock installed macros, user defined macros and the contents of `acinclude.m4' to define all of the macros required by `configure.in' in a single file. aclocal was created as a fix for some missing functionality in Autoconf.

It seems to me that autoconf should include aclocal functionality. I might be missing something here but shouldn't the tool be more intelligent?

getters and setters

Recently I had to cleanup some very old Java code. Just simple batch applications that take some data from one database and transfer it to another database. I noticed a funny "pattern" in the legacy code: one static method iterates the ResultSet and collects the results into a Vector using String[], like:

  List list = new ArrayList();
  while (rs.next()){
     String [] row = String[3];
     row[0] = rs.getString(1);
     row[1] = rs.getString(2);
     row[2] = rs.getString(3);
     list.add(row);
  }

The second method then iterates the results, performs some calculations, and inserts new values to database:

  for(int i = 0; i < list.size(); i++){
    String[] row = (String[])list.get(i); // yaaggghhhhhh!?!
    ....
  }

Smells like C... Personally I have nothing against C, but not inside Java code. I'd better introduce a bean class to encapsulate the values.

OK. let it be:

// as all the logic fits into one class i'd better make this class private
private class MyBean {
  String a;
  String b;
  String c;
  MyBean(String _a, String _b, String _c){
    a = _a; b = _b; c = _c;
  }
}

What I realized now - no point of having getters and setters for the inner class' members. Why?
1) This is used only inside the host class, thus no encapsulation needed.
2) Getters and setters will just flood the source code without bringing any value and making the code less readable.
Instead, I set default access to the bean class members.

The moral is that getters and setters aren't absolutely necessary for simple code. I believe this is trivial, but some people wouldn't agree I guess.

Take care :)

What if... C#?

Programming covers many different business areas and therefor it seems narrowminded to me to be sticked 100% to Java and JVM. Today I thought, what if I will have to develop something in C#? I have no expirience with .NET yet. But I'm so used to the programming practices/tools that I gained with Java - like Ant, JUnit, cruisecontrol, O/R mapping, and Spring Framework of course.
While googling for a while I found that all the tools or some similar exist for .NET:

NHibernate
NUnit
NMock
NCover
log4net
Spring.NET

With such set of tools it seems that there's almost no difference in Java vs C# programming - just a matter of syntax - moreover it is similar for both.

Groovy from SQL and templates

Groovy is a real fun! Get some data from database and put it to XML - must be quick-n-dirty :)
Let the table be:

-- Apache Derby ij script
connect 'jdbc:derby:../../myderby;create=true;user=test;password=test';
create table test(
name varchar(20),
age integer,
gender char(1)
);
insert into test values ('John Doe', 55, 'M');
insert into test values ('Diana Smith', 34, 'F');
insert into test values ('Foo Bar', 21, 'M');
disconnect;
exit;

... and the template.txt:

<person>
<name>${name}</name>   
<age>${age}</age>    
<gender>${gender}</gender>  
</person>

.. and now, Groovy rocks! :)

import groovy.sql.Sql
import groovy.text.Template
import groovy.text.SimpleTemplateEngine
import java.io.File

class SQL2XML{
 static void main(args) {
  def file = new File("template.txt")
  def engine = new SimpleTemplateEngine()
  def template = engine.createTemplate(file)
  def sql = Sql.newInstance("jdbc:derby:myderby",
      "test", "test",
      "org.apache.derby.jdbc.EmbeddedDriver")                                          
  sql.eachRow("SELECT * FROM TEST") {
      def binding = ["name":"${it.name}",
                      "age":"${it.age}",
                   "gender":"${it.gender}"]
      def result = template.make(binding)
      println result
  }   
 }
}

It seems to me that the dynamic features might be useful for adding customizations to the end-user application.

Apache Derby with Eclipse

I sticked with Apache Derby for simple desktop application development. Derby (or JavaDB) is becoming part of the JDK, so it might be a good long term bet. The Eclipse plug-in appeared quite useful in this case.

The functionality of the plug-in makes the core jar files available in the project. One could run the ij queries just inside Eclipse console and execute custom scripts using a context menu item available via riht-button-click on the target file.