Archive for the ‘C’ Category

16C950 UART 9-bit and custom baud rates support for Linux

February 21, 2010

Last friday I found myself patching the Linux kernel sources to be able to add custom baud rates support for 16C950 UART cards. I needed to communicate, via a serial port, with one of the devices built by the hardware guys at work. Unfortunately, a non-standard baud rate and 9-bits were needed.

The Sealevel Ultra COMM+422 PCI card we are using is already provided with a patch that adds 9-bit support. However, I was not able to found how to change the baud rate to a non-standard one.

Following the 9-bit patch approach, I added extra requests to ioctl in order to modify the 16C950 registers needed to achieve custom baud rates. Here is the list of added extra ioctl requests (also the 9-bit ones) with the necessary parameters and updated/accessed 16C950 registers:

Request Parameters 16C950 registers Description
TIOC9BITGET out: integer NMR Get current 9-bit status
TIOC9BITSET NMR Enable 9-bit support
TIOC9BITCLR NMR Disable 9-bit support
TIOCPRESCALERGET out: integer EFR, MCR Get prescaler status
TIOCPRESCALERSET EFR, MCR Enable prescaler
TIOCPRESCALERCLR EFR, MCR Disable prescaler
TIOCDIVLATCHGET out: integer LCR, DLL/DLM Get divisor latch register
TIOCDIVLATCHSET in: integer LCR, DLL/DLM Set divisor latch register
TIOCSAMPLINGCLKGET out: integer TCR Get sampling clock
TIOCSAMPLINGCLKSET in: integer TCR Set sampling clock
TIOCPRESCALERCLKGET out: integer CPR Get prescaler clock
TIOCPRESCALERCLKSET in: integer CPR Set prescaler clock

I’m not sure if this is the best way to do it, but it works. So, if you need 9-bit and custom baud rates support, apply one the following patches to the kernel (I have aslo updated the Sealevel patch for older and newer kernels than the one provided):

9-bit 2.6.24 2.6.26 2.6.31 2.6.32
9-bit and baud rate 2.6.24 2.6.26 2.6.31 2.6.32

I am not responsible for any damage that these patches can cause to your hardware. No warranty is provided, so use them at your own risk.

Advertisements

SCEW 1.1.1 released

December 11, 2009

Finally, character escaping has been added to SCEW. This new release only features this and fixes output on Windows console for UTF-16 characters.

Stay tuned, major BitPacket updates come next!

Happy hacking!

SCEW 1.1.0 released

November 30, 2009

I’m pleased to announce SCEW 1.1.0. This is a minor release including two minor bug fixes and improvements for XML tree and element comparisons. Users can now provide their own XML tree and element comparison hooks.

Check out the release notes.

Happy hacking!

SCEW 1.0.0 released

October 30, 2009

I’m pleased to announce SCEW 1.0.0. It has been a long time since the last release in May 2004.

This new release includes a lot of improvements: unit tests, homogenized API, a lot of new functions, support for custom I/O sources, documentation updates, Windows support improved and many others.

Please, have a look at the changes for more details.

Savannah mirrors are being updated, so until then use the no-redirected download.

As usual, bugs, comments, criticisms, etc. are more than welcome.

Happy hacking!

Building applications for ERC32

October 2, 2007

A while ago, I answered a message, in the RTEMS users mailing list, about how to build raw applications for the ERC32 architecture. With raw applications I mean applications that are not dependent of RTEMS, which is the usual RTOS for this architecture. I am now writing about it just to make it easier for people to find it and to add some information to the explanation.

Before starting with the process, you need to get and build the RTEMS toolchain in order to compile your future applications (I used RTEMS 4.6.1). This is because the specific toolchain for ERC32 non-RTEMS applications is no longer maintained. Note, that you don’t need to install RTEMS itself, but you will need the source code. This video shows, step by step, how to download and build these tools for the i386 BSP, which should be almost identical for ERC32.

I’m not sure if what I’m going to explain is the best way to do it, but it has worked for me, and I have ran programs generated this way in a real board for a long time. I also think this may be useful for other architectures as well.

1. You need to get the following source files from the ERC32 BSP and copy them to your application’s directory:

    cpukit/score/cpu/sparc/asm.h
    cpukit/score/cpu/sparc/rtems/score/sparc.h
    cpukit/score/cpu/sparc/rtems/score/cpu.h
    c/src/lib/libbsp/sparc/shared/start.S
    c/src/lib/libcpu/sparc/reg_win/window.S
    c/src/lib/libcpu/sparc/syscall/syscall.S

2. Modify start.S so it does not call any RTEMS code, that is, commenting these lines:

/*
    call    __bsp_board_init
    nop

    set     (SYM(rdb_start)), %g6   ! End of work-space area
    st      %sp, [%g6]

    set     (SYM(Configuration)), %l1
    ld      [%l1+4], %l3            ! work_space_size
    sub     %sp, %l3, %sp           ! set %sp to area below work_space
    andn    %sp, 0x0f, %sp          ! align stack on 16-byte boundary
*/

3. Compile start.S, window.S and syscall.S. You can remove many things from the header files, but that’s up to you.

sparc-rtems4.6.1-gcc -DASM -c -o start.o start.S

4. Compile your C files (e.g. test.c).

sparc-rtems4.6.1-gcc -O4 -Wall -mcpu=cypress -c -o test.o test.c

5. Link your program. It will not work right now, as you need to generate two final files, my_bsp_specs and linkcmds.

sparc-rtems4.6.1-gcc -mcpu=cypress -Betc -specs my_bsp_specs -o test
window.o syscall.o test.o

Note the arguments -B and -specs. -specs is used to specify a file with options to override the default switches passed to cc1, cc1plus, as, ld… By default, RTEMS uses the file bsp_specs (found in c/src/lib/libbsp/sparc/erc32). You can edit it and see that it automaticaly links with the RTEMS libraries and adds its own start.S object file. The -B flag specifies where to find the executables, libraries, include files, and data files of the compiler itself. I have used an etc directory where I have stored my_bsp_specs. If any of the needed files is not found by the compiler it will automatically search its own paths.

So, what we need to do is to create our own file, my_bsp_specs, which will not use any RTEMS library and which will point to our compiled start.S object file.

Basically,

*endfile:
crtend.o%s crtn.o%s

*lib:
-T linkcmds

*startfile:
start.o crti.o%s crtbegin.o%s

*link:
-dc -dp -N -e start

The %s indicates to search the file in the compiler specific directories. I have removed the %s from start.o so it will search for it in the current directory.

Another important thing to note in this file is the -T linkcmds option. This indicates the linker script, which describes where the code and data for the application will reside in memory, to be used by the GNU linker. Fortunately, we can use the one that comes with RTEMS (found in c/src/lib/libbsp/sparc/erc32/startup), so copy it to the etc directory.

Finally, note that when linking, we have not specified the start.o file as it is already done in the my_bsp_specs file.

You might also find more information in the RTEMS BSP and Device Driver Development Guide.