David,

DavidK wrote:
> At this stage, we have not decided which CPU will be used, but I suspect
> it will be a single-board computer (such as a PC/104 form factor) with an
> Intel x86 or compatible processor.

Consider that this target does not use any SMM (System Management Mode)
services in the background. If it does so, your RT OS (whatever you will
select) *will* fail. The SMM always has the highest priority in your
system, and cannot controlled by your OS! So the OS cannot ensure any
latency.

> I am considering using embedded / RT Linux for this project, to help keep
> costs down by avoiding operating system per-copy royalty charges. How
> should I go about selecting a particular distro or Linux? I was reading
> about uCLinux, but it doesn't seem to have been ported to Intel x86 CPUs
> yet.

If you will use an x86 based system, there is no need for uCLinux. You *can*
use any regular distribution. But you better should select one for embedded
purposes. Its easier to handle in your case.

BTW: Linux + Realtime:
http://rt.wiki.kernel.org/index.php/Main_Page

Patches you will find here:
http://www.kernel.org/pub/linux/kernel/projects/rt/

There is also a RT-Preempt specific maillist
(linux-rt-users@vger.kernel.org). Maybe you could ask your question there
again. Especially about your use in a medical environment.

Juergen

> I am considering using embedded / RT Linux for this project, to help keep
> costs down by avoiding operating system per-copy royalty charges. How
> should I go about selecting a particular distro or Linux? I was reading
> about uCLinux, but it doesn't seem to have been ported to Intel x86 CPUs
> yet.

Ya. RTLinux supports wel for this type of applications. FYI, In
RTLinux, we have 2 major versions, one is Open source RTLinux and
commercial version RTLinuxPro. If you will prepare Open source
RTLinux, then you need to learn more in this RTLinux, before you enter
into Open source RTLInux. If you like to get some supports and extra
components in RTLInux, then you can preapre RTLinuxPro from Windriver
[Early FSM Labs]. Its affordable for your application.
And you just consider this eCos also, http://ecos.sourceware.org/ and
http://ecos.sourceware.org/hardware.html
I dont thing, uclinux will suitable for this application.

-Prakash.

> At this stage, we have not decided which CPU will be used, but I suspect it
> will be a single-board computer (such as a PC/104 form factor) with an Intel
> x86 or compatible processor.

IMHO a x86 CPU is much too high performance level and not enough "long
living chip-design" for this "deeply embedded" application.

I would first look at what hardware is useful for the application. If
there is a need for an FPGA, you can look at stuff like NIOS or
Microblaze, that can be programmed in the FPGA without the need for
additional hardware.

-Michael

> Any links or tips in selecting a particular version of Linux is appreciated!
>
Don't know if you need hard real time system, if not try your own
distriution - I've been using snap gear to building one
http://www.snapgear.org/snapgear/faq.html

Thus IMHO using an FPGA would be the most intelligent choice. Here you
can create any "Hardware" you want (including as sophisticated watch
dogs as necessary) and you can include a 32 bit processor (e.g. NIOS
with an Altera FPGA) with nearly no additional cost. You can use µCLinux
(or one of about 10 other) OS and do the critical stuff in hardware.

You even can put two processors in the FPGA (one running Linux and one
for critical stuff) if appropriate. Of course you should use some
external watchdog device.

The "hardware" and the "firmware" can mutually watch each other for
safety. Of course you should add some simple external watchdog device do
do a reset and shut down any harmful hardware. I use a small PIC
processor for this purpose.

-Michael

Thanks Michael for the excellent info and for opening my eyes to soft-core
CPU technology using FPGAs.

It looks like a flexible and lower-cost alternative to using a single-board
computer, though my unfamiliarity with it makes me a little shy about
recommending it for our new product. I'll do more online research, and will
add it to our list of hardware possibilities for this project.

DK

"Michael Schnell" wrote in message
news:fe2b65$fru$1@murphy.mediascape.de...
> > At this stage, we have not decided which CPU will be used, but I suspect
it
> > will be a single-board computer (such as a PC/104 form factor) with an
Intel
> > x86 or compatible processor.
>
> IMHO a x86 CPU is much too high performance level and not enough "long
> living chip-design" for this "deeply embedded" application.
>
> I would first look at what hardware is useful for the application. If
> there is a need for an FPGA, you can look at stuff like NIOS or
> Microblaze, that can be programmed in the FPGA without the need for
> additional hardware.
>
> -Michael

"DavidK" wrote in
news:rZXMi.122$LD2.46@newssvr17.news.prodigy.net:

> Hi,
>
> I've just begun working on a new project for a medical device, and I'm
> in the early stages of deciding which RTOS we'll use.
>
> To summarize the device, it's a medical device that will have a
> graphical user interface (and possibly a touchscreen), a control knob
> to set the power level, a footswitch, an RF power generator, and an
> 'applicator' that's connected to the system by a long cable.
>
> The doctor will use the device by setting the desired power level
> using the knob (the knob position is read by the software), and when
> the footswitch is pressed, the device will deliver the appropriate
> level of RF energy to the patient via an applicator. During the
> 'treatment', the device will display the setpoint power level, the
> measured power level, the time in seconds since the treatment was
> started, and the temperature of the patient's tissue that's being
> 'treated'. The device will emit a beep tone every three seconds
> during 'treatment' to indicate that RF energy is being applied. When
> the doctor deems the 'treatment' is complete, he will release the
> footswitch, and the RF power will be turned off. Data aquisition
> (temperature and measured power level) will be performed every 10ms or
> so.
>
> Of course the final device, including its software, will be run
> through rigorous testing and clinical trials as required by the US
> FDA. But it would be nice to select an operating system that has been
> used successfully in safety-critical (such as medical) applications,
> so that I won't be the first one going down that road with the OS we
> select.
>
> At this stage, we have not decided which CPU will be used, but I
> suspect it will be a single-board computer (such as a PC/104 form
> factor) with an Intel x86 or compatible processor.
>
> I am considering using embedded / RT Linux for this project, to help
> keep costs down by avoiding operating system per-copy royalty charges.
> How should I go about selecting a particular distro or Linux? I was
> reading about uCLinux, but it doesn't seem to have been ported to
> Intel x86 CPUs yet.
>
> Any links or tips in selecting a particular version of Linux is
> appreciated!
>
> David K
>
Hi David,

Interesting project. Your company costs will be dominated by the
approvals and testing time. Everything else will disappear, in relation
to those.

You don't give much information. The only timing info you gave was 3
seconds for a beep and 10 ms for a input check. If those are your only
constraints I would consider a 8051 or a PIC with no operating system.

Why do we use an operating system at all and a RTOS in particular? To
allocate resources; sometimes control response time, cpu availability
etc. The big plus with an OS is I/O. Display drivers, control input
drivers, higher level things like tcp/ip or usb really need a decent OS.

If all you are doing is reading a pot for the foot control and doing
other similar, slow timing a much smaller no-os cpu is indicated. It
will make your testing much easier.

Regards, Steve

Thanks for your input, Steve. You're right-on regarding the cost of FDA
approvals and clinical trials.

I did over-simplify the description of our project, in order to keep this
post from becoming a software specification in itself.

We'll use an RTOS because we'll have several tasks/threads running, in order
to keep the design modular, so that some modules can be reused in a future
scaled-up or scaled-down product. Our system will have a cooling system
that's controlled by a PID algorithm, as well as other heating elements
that we're switching on and off based on thermistor reading inputs. Along
with the previously-mentioned touchscreen and footswitch inputs, and the GUI
screen output (where we'll be displaying time, temperature and power
output), it's easiest to break these up into separate tasks that have just
one thing to handle each.

We'll also be logging treatment data to a hard disk or disk-on-chip (or
memory card), which is indispensable during clinical trials. Finally, the
device will have a Setup and Calibration Mode whereby we can tweak treatment
parameters while we're running tests in our lab environment.

Dave


"Steve Calfee" wrote in message
news:Xns99C1AB3232113stevecalfeehotmailco@208.49.8 0.253...
> Hi David,
>
> Interesting project. Your company costs will be dominated by the
> approvals and testing time. Everything else will disappear, in relation
> to those.
>
> You don't give much information. The only timing info you gave was 3
> seconds for a beep and 10 ms for a input check. If those are your only
> constraints I would consider a 8051 or a PIC with no operating system.
>
> Why do we use an operating system at all and a RTOS in particular? To
> allocate resources; sometimes control response time, cpu availability
> etc. The big plus with an OS is I/O. Display drivers, control input
> drivers, higher level things like tcp/ip or usb really need a decent OS.
>
> If all you are doing is reading a pot for the foot control and doing
> other similar, slow timing a much smaller no-os cpu is indicated. It
> will make your testing much easier.
>
> Regards, Steve
>
>

> to keep the design modular, so that some modules can be reused in a future
> scaled-up or scaled-down product.

IMHO, long-time product management and flexibility is another argument
for using an FPGA with a built-in processor running Linux.

OTOH Development will be more demanding, as you need to do both firmware
development (in C) and "hardware"-development in VHDL.

If you decide not to use Linux, there are similar options using "virtual
peripherals with a modern "multi-threading" CPU. Here you only need to do C.

-Michael

"DavidK" skrev i meddelandet
news:rZXMi.122$LD2.46@newssvr17.news.prodigy.net.. .
> Hi,
>
> I've just begun working on a new project for a medical device, and I'm in
> the early stages of deciding which RTOS we'll use.
>
> To summarize the device, it's a medical device that will have a graphical
> user interface (and possibly a touchscreen), a control knob to set the
> power
> level, a footswitch, an RF power generator, and an 'applicator' that's
> connected to the system by a long cable.
>
> The doctor will use the device by setting the desired power level using
> the
> knob (the knob position is read by the software), and when the footswitch
> is
> pressed, the device will deliver the appropriate level of RF energy to the
> patient via an applicator. During the 'treatment', the device will
> display
> the setpoint power level, the measured power level, the time in seconds
> since the treatment was started, and the temperature of the patient's
> tissue
> that's being 'treated'. The device will emit a beep tone every three
> seconds during 'treatment' to indicate that RF energy is being applied.
> When the doctor deems the 'treatment' is complete, he will release the
> footswitch, and the RF power will be turned off. Data aquisition
> (temperature and measured power level) will be performed every 10ms or so.
>
> Of course the final device, including its software, will be run through
> rigorous testing and clinical trials as required by the US FDA. But it
> would be nice to select an operating system that has been used
> successfully
> in safety-critical (such as medical) applications, so that I won't be the
> first one going down that road with the OS we select.
>
> At this stage, we have not decided which CPU will be used, but I suspect
> it
> will be a single-board computer (such as a PC/104 form factor) with an
> Intel
> x86 or compatible processor.
>
> I am considering using embedded / RT Linux for this project, to help keep
> costs down by avoiding operating system per-copy royalty charges. How
> should I go about selecting a particular distro or Linux? I was reading
> about uCLinux, but it doesn't seem to have been ported to Intel x86 CPUs
> yet.
>
> Any links or tips in selecting a particular version of Linux is
> appreciated!
>
> David K
>

It looks to me that you can solve your control problem in a small
Microcontroller
connected to a display unit which does not need to have any real time.

1 ADC channel to measure "knob".
1 ADC channel to measure temperature over NTC
1 Digital input to measure footswitch
1 Timer for beeper.
1 black box to generate RF power. (SPI?)
1 black box for applicator (What's an applicator?)
1 Communication channel to display unit.
1 measurement cycle per 10 ms.
115,200 BAUD UART => 115 characters per cycle
You need to transmit
* setpoint power level (2 bytes)
* the measured power level (2 bytes)
* the time in seconds since the treatment was started (2 bytes)
(Assume shorter than 16 hours)
* Temperature (2 bytes)
SPI to communicate with SD-Card.
EEPROM to handle Setup & Calibration.

Sounds like it easily could be done in an AVR
communicating with a display controller.

You did not mention the resolution/colourdepth of your screen.
This is quite important.
Also, what type of volume are you planning.
Just a few, and an off the shelf PC communicating with a USB device
doing the real measurement should do.
With some volume behind it, then there are several cheap ARMs with LCD
display.
(AT91SAM9261 is but one)



The displayunit can run Linux, but writing to a double buffered
screen without a large RTOS is probably not a big deal.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

> 1 ADC channel to measure "knob".

I would use pure digital signals whenever possible. there are
incremental coders (with LED positions notifiers when appropriate) that
do the "knob"

> 1 ADC channel to measure temperature over NTC

There are temperature sensor chips with I²C, "one-wire"and other serial
digital interfaces

-Michael