Special Feature

T-Engine Latest Technical FAQ Collection


We have gathered here the questions most frequently sent to Personal Media's T-Engine Support Center and their answers [1].

Questions Concerning Development Tools

Q1. Can Red Hat Version 9 also be used for the development environment.

A1. Yes, it can be used. We have confirmed the operation of Red Hat Linux versions 7.1, 7.3, 8.0, and 9.0 for the development environment.

Q2. I can't get the gterm terminal software to work.

A2. The T-Engine device switch setting requires the '-3' option in the case of 38400 bps, or the '-B' option in the case of 115200 bps. Also, it is necessary to specify '-l/dev/ttyS0' or '-l/dev//ttyS1' based on the Linux serial port number. For example, if you use serial port #0 at at 38400 bps, please make it as '$BD/etc/gterm -3 -l/dev/ttyS0' [2].

Q3. I can't get the gdb debugger to work.

A3. Because gdb takes exclusive possession of the serial circuit, it cannot be simultaneously used with gterm. After temporarily shutting down gterm with the '.q' (dot-q) command, start up gdb (List A3).

List A3
[/SYS]% lodspg sample.trg . . . Program execution (T-Kernel base)
TM> .q                    . . . gterm terminates after control moves to T-Monitor
<< exit Gterm >> 
$ $BD/tool/Linux-i686/bin/sh-unknown-tmonitor-gdb sample.abs
                          . . . gdb startup (example with SH version of gdb)

Also, the gdb settings file, the '.gdbinit' file, is necessary. Please carefully look over the gdb development environment manual.

Q4. An error occurs with the recv command, and I cannot transfer a file to the actual machine.

A4. Because it is not possible to write onto the ROM disk from the T-Engine side, please transfer with the recv command after connecting to a CF card or USB storage and moving on top of one of those with the 'cd' command (List A4). In a case where a file of the same name already exists, please attach the '-d' option. Furthermore, please confirm whether or not the file you will transfer exists on Linux, including the path name also.

List A4
[/SYS]% df                                                 . . . disk confirmation
PATH  DEV   TOTAL   FREE  USED UNIT  MAXFILE  NAME
/SYS  rda     695      0  100% 1024     256   PM:TE-SH7277 . . . ROM disk (rda)
[/SYS]% att pca0 A                                         . . . PC card connection
pca0 -> A
[/SYS]% cd /A                                              . . . onto PC card
[/A]% recv -d test                                         . . . file transmission

Q5. When I load 'scrtst' with the 'lodspg' command, an error is generated, and I'm wondering whether this is right.

A5. Yes, it's right. Because it is not necessary for the sample program 'scrtst' to reside after screen drawing, we have intentionally made it so that the error terminates and the program does not reside (List A5).

List A5
[IMS]% lodspg scrtst
Can't start /SYS/scrtst [-327680]

With the lodspg command, when the main ( ) function returns a negative value, the program cannot load (reside).

Q6. I would like to rewrite the settings file of 'STARTUP.CMD', etc.

A6. The settings files 'STARTUP.CMD', 'STARTUP.CLI', 'DEVCONF', and 'SYSCONF' are EUC text files. To display their contents, we input in the form of 'tp -a STARTUP.CMD' on the CLI.

As for the contents of settings file on the startup disk on a CF card, etc., it is possible to rewrite them using the 'ed' command on the CLI. Also, as in List A6, there is also a method of transferring on top of T-Engine with the 'recv -d STARTUP.CMD' following editing on top of Linux after after copying the file to Linux using the gterm trace (log) function.

List A6
[/SYS]% .ton STARTUP.CMD           . . . log record begins
.. Trace  ON: STARTUP.CMD
% tp -a STARTUP.CMD                . . . file display
   (file contents are displayed)
[/SYS]% .toff                      . . . log record ends

Furthermore, in rewriting the settings file on a ROM disk, as in Q8, please copy the disk image to the ROM disk after first having rewritten on top of the CF card.

Q7. I would like to write into the Flash ROM data in Motorola S-Format form (for target side version upgrade, etc.).

A7. With T-Engine/SH7727 and SH7751R, we carry this out with the 'fl 0' (ef el zero) command after connecting the debugging board (J1 short, J2 open), and starting up the DownLoader. With µT-Engine/M32104, after unfastening JP1, we turn on the power supply with the POWER switch pressed down. With the other models, we use the FlashLoad (fllo) command of T-Monitor (List A7).

List A7
[/SYS]% #                                            . . . start up T-Monitor
TM> FlashLoad                                        . . . FlashLoad command
Copy Flash ROM Image to RAM Area
> Load S-Format Data of Flash ROM
(Here, please transfer the .mot file from the terminal software.)
Loaded: 80000000 -> 800BDDFF
Writing Flash ROM at 80000000 [12 blks] ... wait
Update Monitor Area, Restart System after Writing.   . . . after write-in ends, restart

As for files in S-Format format, please upload them from the Linux side in ASCII data transfer with XON (ASCII text files) by using terminal software with a file transfer function, such as minicom.

Furthermore, T-Monitor also is written onto the Flash ROM. Because you will completely destroy T-Monitor itself if you overwrite this region, please exercise sufficient caution.

Q8. I would like to store a user program on the ROM disk. Also, I would like to modify the file contents inside the ROM disk.

A8. This comes down to a method in which once you have created a startup disk on a CF Card and then added user programs and modified file contents, you store that CF Card disk image as a ROM disk using T-Monitor.

First, you create a partition on the CF Card with the 'hdpart' command. At this time, please make the partition size is less than the size from which you have deducted the area you use with T-Monitor, etc., from the Flash ROM size (Table 1).

Table 1 Maximum Size of ROM Disks

SH7727

SH7751R

VR5500

VR4131

ARM920-MX1

ARM720-S1C

7MB

7MB

12MB

12MB

15MB

7MB

(fractions omitted) 

Next, you create a startup disk by formatting and copying the system. After that, please store the user programs with the 'recv' command, etc., and modify contents in accordance with needs.

Finally, start up T-Monitor, and then using the 'WriteRda' command, you write in the CF Card disk image as a ROM disk (List A8).

List A8
[/SYS]% #                                            . . . start up T-Monitor
TM> WriteRda pca0                                    . . . WriteRda command
Write rda [4192 blks] OK (y/n)? y
Read from pca0 [4192 blks] ... wait
Write to rda [4192 blks (2096 KB)] ... wait

Or, by means of a 'WriteRda' command substitute, you can also use a primitive 'wrom' (List A8-2). Here, we show an example with T-Engine/SH7727. (On other models, the addresses are different.) As for the d'8288 in two spots, please specify the actual disk block numbers that are displayed.

List A8-2
TM> id pca0                                             . . . Confirmation of the number of blocks
pca0: Bytes/block: 512 Total blocks: 8288

TM> rd pca0, 0, d'8288, 8c010000                        . . . Disk image into memory
TM> wrom 80020000, 8c010000, d'8288 * d'512 / 10000 + 1 . . . ROM read-in
TM> mov 80010000, #10000, 8c010000                      . . . ROMInfo into memory
TM> mw 8c010018, 80020000, d'8288 * d'512 + 80020000    . . . ROM disk beginning and end address settings
TM> wrom 80010000, 8c010000, 1                          . . . ROMInfo read-in

Q9. Because I would like to use the PC Card slot for a different purpose, is it possible to start up from USB storage?

A9. Yes, it's possible. Please create a startup disk in USB Mass Storage Class-based USB storage, and then set to ON 'Start Up From USB' in the T-Engine DIP switch settings.

Furthermore, it is also possible to start up PMC T-Shell after loading it into USB storage. In this case, it is necessary to add settings for use with T-Shell to the settings files 'STARTUP.CMD', 'SYSCONF', and 'DEVCONF' inside the ROM disk with the method in Q8.

Questions about Programming

Q10. I would like to display a graphic on the LCD (liquid crystal screen).

A10. It is possible to display things on the LCD screen using the SCREEN driver. Please try the sample source '$BD/kappl/drawsamp' (simple drawing: Fig. 1) and '$BD/kappl/stpwtc' (stopwatch: Fig. 2). Also, for the differences between T-Kernel base and process base, please reference '$BD/kappl/scrtst' and '$BD/bappl/scrtst' (Fig. 3).

This method draws in units of pixels. For a more genuine utilization, we recommend Personal Media's PMC T-Shell middleware. PMC T-Shell supports drawing and clipping of various figure types, fonts (including multilingual and multi-kanji), a GUI with windows and so on, image format conversion, etc.

Q11. I would like to detect key input from the buttons on the LCD board and the USB keyboard.

A11. We receive key events using 'b_get_evt()' of the T-Kernel Extension Event Manager. First, please set the key table with 'b_set_ktb()', and then release the mask of the event type that does the receiving with 'b_chg_emk()' (List A11).

Furthermore, the T-Kernel Extension Event Manager can be used from either a process base or from a T-Kernel base.

List A11
/* key event program example (btron/event.h required) */
  INT e, i; EVENT evt; static KeyTab keytab;
/* Setting key table (for the time being, the character code is the same as the key top code */
  keytab.keymax = 256; keytab.kctmax = 1; keytab.kctsel[0] = 0;
  for(i = 0; i < keytab.kctmax; i++) keytab.kct[i] = i;
  b_set_ktb(&keytab);
/* key event mask release */
  b_chg_emk(EM_KEYDWN | EM_KEYUP);
/* key event reception */
  for(;;) {
    e = b_get_evt(EM_KEYDWN | EM_KEYUP, &evt, CLR);
    if (e == EV_KEYDWN)
      printf("key down [%d]\n", evt.data.key.keytop);
    else if (e == EV_KEYUP)
      printf("key up   [%d]\n", evt.data.key.keytop);
  }

Q12. I would like to use a serial port other than the standard serial port ('rsa').

A12. With T-Engine/SH7727, SH7751R, and VR5500, if you connect the RS-232C card to the PC Card slot, it is possible to use it with the device name 'rsb' using the RS driver (List A12).

List A12
/* serial port program example (T-Kernel base, device/rs.h required) */
  INT dd, asiz; RsMode rsmode; RsFlow rsflow;
/* device open */
  dd = tk_open_dev("rsb", TD_UPDATE);
/* communications mode: without parity. 8-bit length, 1 stop bit, 38400bps */
  rsmode.parity    = 0; rsmode.datalen = 3;
  rsmode.stopbits  = 0; rsmode.baud    = 38400;
  tk_swri_dev(dd,  DN_RSMODE, &rsmode, sizeof(rsmode), &asiz);
/* flow control: RTS/CTS control */
  rsflow.rcvxoff  = 0; rsflow.csflow = 1; rsflow.rsflow = 1;
  rsflow.xonany   = 0; rsflow.sxflow = 0; rsflow.rxflow = 0;
  tk_swri_dev(dd, DN_RSFLOW, &rsflow, sizeof(rsflow), &asiz);
/* character string transmission */
  tk_swri_dev(dd, 0, "Hello!\r\n", 8, &asiz);
/* device close */
  tk_cls_dev(dd, 0);

Also, with T-Engine/VR5500, the connector board serial terminal also can be used with the device name 'rsc'. However, control signals cannot be utilized.

Q13. I would like to read and write onto the disk in block (sector) units.

A13. Disk access in block units (512 bytes) is possible using using the system disk driver [3]. Please read and write native data after opening the device with the device name 'pca0' (block #1 of a PC card) or 'uda0' (block #1 of USB storage). For further details, please look at the disk dump sample source '$BD/util/tool/src/dd.C'.

Q14. I would like to read and write files.

A14. On a TRON format disk formatted with T-Engine, file access is possible using the T-Kernel Extension File Manager ('b_opn_fil()', etc.). This is a file system whose strong point is a multi-record/hyperlink structure.

In addition, it is also possible to use a traditional ANSI C-based file operation function group, such as 'fopen()', etc. Please look at the samples '$BD/bappl/fileio' and '$BD/kappl/fileio' regarding this.

Furthermore, the reading and writing of files using the ANSI C-based file function group has become possible even for MS-DOS/Windows FAT format disks. (We provide this function to existing users by means of an upgrade.)

Q15. I would like to access a USB-connected memory card or disk.

A15. Because we support the USB Mass Storage Class with a standard system device driver, it is possible to use various types of memory cards and various types of device drivers, etc., based on this. As for the device names, they become 'uda0' (block #1), 'uda1' (block #2), . . . File access (see Q14) and access in block units (see Q13) are both possible.

Q16. I would like to perform floating point operations.

A16. There is no problem on a process base. In the case of a T-Kernel base, please specify the TA_FPU attributes in the manner 'ctsk.tskatr = TA_HLNG | TA_RNG0 | TA_FPU;' at the time of task creation.

Whether it's a model that possess an FPU (Floating Point Unit) or a model that doesn't possess one, it has been decided in the T-Kernel specification that you should attach TA_FPU attributes to tasks that will carry out floating point operations. Even on models that do not possess an FPU, it is possible to program without being particularly being conscious of the presence or absence of an FPU, because a floating point library is linked.

Q17. How is the endian made up in the various current models.

A17. The µT-Engine/M32104 is big endian, and the other various current models are little endian.

By means of '#include <machine.h>', the symbol 'BIGENDIAN' is defined as 1 in the big endian models, and 0 in the little endian models. Utilizing this, it is also possible to write common programs among the models.

Q18. I would like to carry out control of hardware that I added on my own.

A18. You can directly carry out access, interrupt processing, etc., of the I/O port from a T-Kernel base or a T-Monitor base program. On the one hand, direct access of hardware is not possible with a process base program, but if you create a device driver that accesses hardware and make it into a form in which you call that device driver, then it is possible to access uniformly both from a process base and a T-Kernel base.

In a case where a physical address is required for input/output with hardware, please convert the logical address into a physical address with 'CnvPhysicalAddr()'.

Q19. I would like to create a device driver.

A19. Please utilize the general purpose device driver interface or the simple device driver interface we have provided as a library. We use the former for general devices where there is the possibility that a waiting time will occur in reading and writing, and the latter for simple devices where a waiting time will not occur.

Furthermore, in the case of a PC Card connection, because the card manager supplies the necessary functions to the device driver by means of the USB manager in the case of a USB connection, please use them together.

For for further details, please look at the device driver manual plus the sample source for each type of driver '$BD/driver/*'.

Q20. I would like to write a TRON Code character string in the source code.

A20. If you make the source file extension into an upper case '.C' and then write 'L"2 byte character string (EUC)"', it will automatically be converted into a 16-bit TRON Code string with '$BD/etc/wch2hex -t' at gmake time.

For example, 'TC dev[] = {L" SCREEN" };' will be converted into 'TC dev[] = {0x2353, 0x2343, 0x2352, 0x2345, 0x2345, 0x234e, 0x0000};'.

____________________

[1] Q4, Q6, Q8, and Q14 are not applicable to µT-Engine/M32104. Q5, Q9, Q10, Q11, and Q15 are not applicable to various µT-Engine models. Q12 is only applicable to T-Engine/SH7727, T-Engine/7751R, and T-Engine/VR5500.

[2] '$BD' shows the directory (normally, /usr/local/te) that installed the development environment. Also, as for '-l' ('minus l'), please do not insert a space between '-l' and '/dev/ttyS0'.

[3] For access in file units, please see Q14.


The above article on T-Engine programming appeared on pages 41-45 in Vol. 83 of TRONWARE . It was translated and loaded onto this Web page with the permission of Personal Media Corporation.

Copyright © 2003 Personal Media Corporation

Copyright © 2003 Sakamura Laboratory, University Museum, University of Tokyo