Jump to content

Resident monitor

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Peter Flass (talk | contribs) at 17:30, 21 March 2018 (Current use: fix link). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In computing, a resident monitor is a type of system software program that was used in many early computers from the 1950s to 1970s. It can be considered a precursor to the operating system.[1] The name is derived from a program which is always present in the computer's memory thus being "resident".[2] Because memory was very limited on these systems the resident monitor was often little more than a stub which would gain control at the end of a job and load a non-resident portion to perform required job cleanup and setup tasks.

On a general-use computer using punched card input, the resident monitor governed the machine before and after each job control card was executed, loaded and interpreted each control card, and acted as a job sequencer for batch processing operations.[3] The functions that the resident monitor could perform were: clearing memory from the last used program (with the exception of itself), loading programs, searching for program data and maintaining standard IO routines in memory.[2]

Similar system software layers were typically in use in the early days of the later minicomputers and microcomputers before they gained the power to support full operating systems.[2]

Current use

Resident monitor functionality is present in many embedded systems, boot loaders, and various embedded command lines. The original functions present in all resident monitors are augmented with present day functions dealing with boot time hardware, disks, ethernet, wireless controllers, etc. Typically these functions are accessed using a serial terminal and or a physical keyboard and display, if attached. Such a resident monitor is frequently called debugger, boot loader cli, etc. The original meaning of serial or terminal accessed resident monitor is not frequently used, although the functionality remained the same, and was augmented.

Typical functions of a resident monitor include examining and editing ram and/or ROM (including flash EEPROM) and sometimes special function registers, the ability to jump into code at a specified address, the ability to call code at a given address, the ability to fill an address range with a constant such as 0x00, and several others. More advanced functions include local disassembly to processor assembly language instructions, and even assembly and writing into flash from code typed by the operator. Also, code can be downloaded and uploaded from various sources, and some advanced monitors support tftp, ftp, http etc networking as well as formatting and reading FAT and other filesystems, typically from flash attached memory on USB or CFcard buses.

For embedded processors, many "in circuit debuggers" with software-only mode use resident monitor concepts and functions which are frequently accessed by a GUI IDE. They are not different from the traditionally serial line accessed resident monitor command lines, but users are not aware of this. At the latest, developers and advanced users will discover these low level embedded resident monitor functions when writing low level API code on a host to communicate with an embedded target for debugging and code test case running.

Several current microcontrollers have resident serial monitors or extended boot loaders available as options to be used by developers. Many are open source. Some examples are PAULMON2 AVR DebugMonitor Bamo128 Arduino boot loader and monitor. In general, most current resident monitors for embedded will be compilable in various sizes, from small and minimalistic, to large, filling up to 25% of the code space available on an AVR 328 processor with 32kBytes flash, for example (see Bamo128).

In many cases resident monitors can be a step up from "printf debugging" and are very helpful when developing on a budget which does not allow a proper hardware ICD (in circuit debugger) device to be used.

See also

References