Upgrade of Radiation Monitoring System for
National Synchrotron Radiation LAB
Wang Ruopeng
Engineering Physics Dept., Tsinghua University
Email: WANGRP@thinker.ep.tsinghua.edu.cn

The prototype of this Radiation Monitoring System,
namely Digital Data Logger (DDL), has been on service
for nearly 10 years. It is used as local station of gamma-ray
radiation monitor for large accelerator or nuclear facilities
by National Synchrotron Radiation LAB in China. Now thenecessity comes up that the information sharing with othercomputer systems and a higher performance of hardware
and software must be achieved. For this aim, the main
control MCU is upgraded, system memory enlarged andpower system improved. However our chief revision is on
software. Here we applied a tiny real-time multitasking
kernel to improve the overall performance of the system.
Since the kernel is written in efficial assembler language, ititself takes up minimum system resources while
functioning basically like any commercial real-timesystem. We have done some modifications on the kerneland made it accustomed to our specific situation.
Considerate time and effort are saved by this way on
software development. The system can work moresmoothly, with shorter response latency, less chance of
fatal running errors and higher resistance to electric andmagnetic disturbance.

During nearly 10 years of operation, the monitor has
given us much about the additional dose rate attributed byrunning of the accelerator. What is more, it can often give
us suggestions when some bugs occur and we have to dosomething to diagnose the whole accelerator. This is
greatly invaluable especially at time when all othermeasures fail.
However, now we find several shortcomings in the oldversion of the monitor.
First, the storage capacity of the monitor is not large
enough since it can not store all the 16-channel data needed
continuously for a whole month, for the convenience ofoperation.
Second, the former monitor is devised with M6809
MCU, which is also out of date - it is actually discontinued
from production for some time and difficult for further
hardware or software development or maintenance.
Third, the human interface of the former monitor is far
from perfect. To set parameters, one has to pass several
trivial routines and the one-line display of the former
monitor gives a poor effect for instant data report.
Fourth, because the monitor has to do, maybe, several
jobs at the same time, i.e. when the monitor is refreshingthe display, it will be rather difficult to have our input
commands responded. In other words, it is not ″real-time″.

1 Objective

2 Measures of fulfillment

In 1987, an Environment Radiation Monitoring System,
namely Digital Data Logger (DDL), was set up for theNational Synchrotron Radiation LAB in China,Hefei. It ismainly used as local station of gamma ray and neutronradiation monitor for accelerators or nuclear facilities.
The first and most significant function of this device is tocollect current pulse specifying detection of gamma rays or
neutrons from ionization chamber (There can be 16channel counters working concurrently). The monitor
counts the pulse one by one and stores the result in memory
for further inquiry.
The second function is to calculate the dose rates of all
the channels every 6 seconds.
Thirdly, the monitor will check and report the runningstatus of the accelerator from a port of 32-channel inputs.
If the dose rate of every channel is above either of twodifferent thresholds, the monitor will display the warning
message to a 16-channel output port.
The Monitor can also keep and maintain a clock to workwithout break, which is necessary in order to collectradiation data continuously for a long period. It is able toreceive several kinds of commands from operator throughRS-232 port, to provide a measure for uploading data, ormodifying parameters.

Concerning the deficiencies mentioned above, we did agreat deal of hardware and software revision on the oldsystem. The hardware framework, the crate, is preservedand the CPU board, memory board are replaced. A more
popular and powerful MCU, M68HC11 is applied withmemory expanded to 128K byte (and still furtherexpandable), sufficient for a storage of one full monthwithout any data loss. On the control panel, the old oneline ASCII LCD gives way to a new 320X200 color
graphic LCD, which can lively show dose rate of every
channel, graphically tell us the switches status of the wholeaccelerator, and something else. Further, via RS-232, themonitor can be conveniently connect to a PC, on which aWindows program is running, when the operator wants toaccess the data already stored. Various configuration
parameters are also transferred to the monitor through RS232. A rechargeable cell is incorporated in the device toensure the continuous operation even in case of AC power
failure.
However our chief revision is on software. Here weapplied a tiny real-time multitasking kernel to improve theoverall performance of the system. The kernel, namely
MCX11, is written in efficient assembly language, it itself
takes up minimum system resources while functioning

Abstractbasically like any commercial real-time systems. It’s codetakes up only 1.3K byte when in full operation, theconsumption on RAM is barely 5K byte - mainly for stacksof application written in C language which normally eat up
large amount of memory. That is the reason why it is very
appropriate for 8-bit MCU application.
MCX11 is a real-time preemptive multitask kernel. Up to64 tasks can reside in memory simultaneously, which issufficient for complicated usage on M68HC11. Every task
has its own independent stack as well as its code. The tasks
are each given a priority, which is a reference of systemschedule and can not be changed by user after the kernel
starts up. Different status has to be given to tasks since at
any moment there can be only one task running. The
following is a diagram depicting a task transferring
between three different status.
PENDINGDONE

WAITINGl

Wait: wait on semaphore
We have made some modification on the kernel andmade it accustomed to our specific situation. Because
multitasking is supported by the kernel, functions can befulfilled one by one with independent modules, thus
minimizing the normal efforts to write codes for scheduling,timing and cooperation jobs between different modules.
Considerable time and effort are saved by this way on
software development.
Now it has become quite easy for one to define his/her
own tasks and start the kernel on a specific hardware
platform. Below is a list of jobs needed to run MCX11 forour purpose.
l
Devide your target system into several relatively lessinterdependent blocks.
lConvert these blocks into different tasks, and give
each task a priority according to their significance –requirement on processing latency.
lSelect appropriate programming language (Assemblyor C), and write module codes for the tasks.
l
Submit a form to kernel and specify everything about
number of tasks, entry code and stack size preservedfor each task, and so on.
The following is a brief frame of this kind of form.

A PENDING state indicates that the event associatedwith the semaphore has not yet occurred and is therefore
pending. The WAITING state shows that not only has theevent not yet occurred but a task is waiting for it to happen.
The DONE state tells that the event has occurred. MCX11
semaphores have a very strict state transition protocol
which is automatically managed by MCX11.
The communication and synchronization between thetasks are achieved with semaphores, messages, andmessage queues which are all maintained internally by thekernel. Dozens of system functions are provided to accessthese internal facilities, to operate on tasks, and so on. The
following is a list of some system functions incorporated in
MCX11:l
Delay: delay a task for a period of timelDequeue: get an entry from a FIFO queuelEnqueue: insert data into FIFO queuelExecute: execute a taskl
Pend: force a semaphore to a PENDING
l
Purge: purge a task's timerslReceive: receive a messagelResume: resume a taskl
Send: send a message to a tasklSendw: send a message and waitlSignal: signal a semaphorelSuspend: suspend a tasklTerminate: terminate a tasklTimer: start a timer

TSKNUM EQU 21
ORG TCBDATA

Set up total number of tasks* define task #1
TASK1 EQU STATLS+TCBLEN* Task #1 TCB address
STAK1 EQU STKBASE-20* Base address of task #1 stack
STK1SIZ EQU 18* Size of stack for task 2
FCB 0 * INITST is RUN
FDB Task1_entry, STAK1, TASK1* STRTADR, RSTSP, TCBADDR* define task #2
TASK2 EQU TASK1+TCBLEN* Task #2 TCB address
STAK2 EQU STAK2-STK2SIZ* Base address of task #2 stack
STK2SIZ EQU 21* Stack size for task #2
FCB 0* INITST is RUN
FDB Task2_entry, STAK2, TASK2* STRTADR, RSTSP, TCBADDRAs to the great conveniences the kernel provides to small
control system, MCX11 on M68HC11 has a quite
good prospective to be further applications.