Skip to main content
Software Engineering

Return to Answer

Fixed minor typos and fixed numbered list
Source Link
gnat
gnat
  • 20.5k
  • 29
  • 117
  • 310

The simplest solution is to use interrupts and timers.

The interrupts indicate:

  1. User I/O inputs
  2. Timer expiration

Two separate programs could communicate via two pipes or msgsnd() or semaphores or mutexes or signals.

(I think there is no need for multiple programs.)

If you write the program so that everything is interrupt driven, along with a 'background' activity that is running when no interrupt is being serviced. Then the program should be 'relatively' easy to implement.

Some experience with real-time embedded program would greatly assist you in the design, coding, debugging and documenting of the program.

The simplest solution is to use interrupts and timers.

The interrupts indicate:

  1. User I/O inputs
  2. Timer expiration

Two separate programs could communicate via two pipes or msgsnd() or semaphores or mutexes or signals.

(I think there is no need for multiple programs.)

If you write the program so everything is interrupt driven, along with a 'background' activity that is running when no interrupt is being serviced. Then the program should be 'relatively' easy to implement.

Some experience with real-time embedded program would greatly assist you in the design, coding, debugging and documenting of the program.

The simplest solution is to use interrupts and timers.

The interrupts indicate:

  1. User I/O inputs
  2. Timer expiration

Two separate programs could communicate via two pipes or msgsnd() or semaphores or mutexes or signals.

(I think there is no need for multiple programs.)

If you write the program so that everything is interrupt driven, along with a 'background' activity that is running when no interrupt is being serviced. Then the program should be 'relatively' easy to implement.

Some experience with real-time embedded program would greatly assist you in the design, coding, debugging and documenting of the program.

Fixed minor typos and fixed numbered list
Source Link
edit approved Jun 27, 2015 at 17:02
Greenonline
edit approved Jun 27, 2015 at 17:02
Greenonline
  • 145
  • 2
  • 2
  • 11

theThe simplest solution is to use interrupts and timers.

The interrupts indicate 1) user I/O inputs 2) timer expiration:

  1. User I/O inputs
  2. Timer expiration

twoTwo separate programs could communicate via two pipes or msgsnd()msgsnd() or semaphores or mutexsmutexes or signals.

(I think there is no need for multiple programs.)

If you write the program so everything is interrupt driven, along with a 'background' activity that is running when no interrupt is being serviced. Then the program should be 'relatively' easy to implement.

Some experience with real-time embedded program would greatly assist you in the design, coding, debugging, and documenting of the program.

the simplest solution is to use interrupts and timers.

The interrupts indicate 1) user I/O inputs 2) timer expiration

two separate programs could communicate via two pipes or msgsnd() or semaphores or mutexs or signals.

(I think there is no need for multiple programs.)

If you write the program so everything is interrupt driven, along with a 'background' activity that is running when no interrupt is being serviced. Then the program should be 'relatively' easy to implement.

Some experience with real-time embedded program would greatly assist you in the design, coding, debugging, documenting of the program.

The simplest solution is to use interrupts and timers.

The interrupts indicate:

  1. User I/O inputs
  2. Timer expiration

Two separate programs could communicate via two pipes or msgsnd() or semaphores or mutexes or signals.

(I think there is no need for multiple programs.)

If you write the program so everything is interrupt driven, along with a 'background' activity that is running when no interrupt is being serviced. Then the program should be 'relatively' easy to implement.

Some experience with real-time embedded program would greatly assist you in the design, coding, debugging and documenting of the program.

Source Link
user3629249
user3629249
  • 256
  • 1
  • 6

the simplest solution is to use interrupts and timers.

The interrupts indicate 1) user I/O inputs 2) timer expiration

two separate programs could communicate via two pipes or msgsnd() or semaphores or mutexs or signals.

(I think there is no need for multiple programs.)

If you write the program so everything is interrupt driven, along with a 'background' activity that is running when no interrupt is being serviced. Then the program should be 'relatively' easy to implement.

Some experience with real-time embedded program would greatly assist you in the design, coding, debugging, documenting of the program.