nucleus 嵌入式系统的一些问题集合

Q: “How much RAM and ROM does PLUS use?”

A: This varies by tool chain and processor. Also, PLUS is scalable, so services not used will not be linked into the image. However, typically code size will run 5-45K bytes and ram usage will run 2-8K bytes.

Q: "How many of the microprocessor's timers does the Nucleus Plus RTOS occupy? "

A: Nucleus Plus RTOS uses just one timer for generating all timing services provided by the kernel. In the event no timing services are required, then no CPU timer is required. Typically our customers use 10ms as the granularity of the kernel timer, although this can be modified depending on the needs of your application.

Q: "Does Nucleus have a protect mechanism?"

A: Yes, Nucleus PLUS uses a protection structure to avoid data corruption within a service. The structure maintains a list of pointers to the task or interrupt thread control structures that are using the protected area as well as an indication that another thread is waiting for the protected area.

Q: "Does Nucleus support intertask communication?"

A: Yes, Nucleus PLUS provides mailboxes, queues and pipes for task communication. These are independent public facilities and association with tasks or other system facilities are determined by the application. Each structure may be dynamically created and deleted and there is no preset limit on the number of each structure the application may use.

Q: "What's the difference between a queue and a pipe?"

A: Both provide a method for intertask communication. Nucleus PLUS queue messages consist of one or more 32-bit words. Pipe messages consists of one or more bytes.

Q: "How does Nucleus PLUS handle interrupts?"

A: Nucleus PLUS uses a two stage interrupt handling scheme, which accomplishes the following:

Interrupts are locked out for as brief a time as possible

Interrupt service routines can be associated with particular interrupt vectors dynamically, from the application.

A Low level Interrupt Service Routine is registered with a specific interrupt vector, using the NU_Register_LISR service call. It is this LISR which responds directly when the interrupt signal is asserted. This routine does only the most immediate portion of interrupt servicing. This can be as little as clearing the cause of the interrupt and 'Activating' a High level Interrupt Service Routine with a call to NU_Activate_HISR. When this short LISR completes, it returns control to the scheduler, not to the point of interrupt. As soon as control passes to the scheduler, the 'Activated' HISR is found ready to run, and control passes to the HISR, which runs to completion, unless another interrupt signal is asserted before it can finish. Interrupts are re-enabled in the process of returning control to the scheduler. To take full advantage of the opportunity to minimize interrupt latency, as much of the interrupt servicing as possible should take place in the HISR, rather than in the LISR.

The HISR has much in common with a task. Like a task, it runs subject to the scheduler, but because all HISR's run at a priority above all tasks, no task will run before all 'Activated' HISR's have completed. This includes the task that was interrupted by the 'Activating' LISR. Any changes to the readiness status of tasks that result from calls made by the HISR will not take affect until the HISR is finished.

A LISR has practically no access to system calls, except for NU_Activate_HISR and a handful of informational calls.

HISRs are allowed to make practically any system service call, as long it does not lead to a suspension. This makes it necessary to use the NU_NO_SUSPEND option for many of the service calls where suspension could otherwise occur. Nothing should be allowed to prevent a HISR from running to completion.

Q: "What are Board support packages (BSP)?"

A: If an OS comes only as binary executables, or as an object library, the vendor must either provide a version built to run on your exact hardware, or provide the routines to handle hardware specific functions and interface with the more generic binary code. They often call this target specific code a 'Board Support Package', and if none is available for your board, you either change boards or wait for the BSP to be done.

With a source code OS the situation is much different. With every port, we provide the source code to the target-specific low-level routines. In almost every case, (including our embedded x86 port) these have been built and run on at least one actual target board. We refer to that as a 'run-time package' for that particular board. If you want to use a different board, you alter these files to match your particular peripheral set and memory mapping, and move on.

We generally do not attempt to initialize and provide a driver for every peripheral device on a board (or on a highly integrated chip). We do enough to get our demonstration program running, which requires, at a minimum, that a timer be initialized to provide a periodic interrupt. This must be captured and serviced by Nucleus PLUS in order to provide the system timer. We also provide a basic serial driver. For the NET product, which provides TCP/IP support, we have a number of drivers available for on chip and discreet Ethernet controllers. For GRAFIX we provide drivers for several display controllers. Contact AT for the latest list of controllers supported.

Practically all of the many customers who have used PLUS have done so without 'board support packages' from us. Many of those customers have used boards for which even a "run-time package" was not available

Q: "Does Nucleus PLUS require a BSP?"

A: A BSP is not required for Nucleus PLUS since source code is provided. The Nucleus PLUS code supplied has initialization code for a particular eval board. This code sets up the interrupt vector table, an interrupt handler for the timer used by Plus timer services and sometimes cache and MMU (depending on CPU). Certain peripherals may also be initialized.

Q: "Does Accelerated Technology do anything about priority inversion?"

A: We use a proprietary protection mechanism. It uses a scheme comparable to priority inheritance when a higher priority task needs a resource that is in the exclusive possession of a lower priority task. The lower priority task is allowed to run just far enough to release the resource, and then control returns to the higher priority task, which is then able to continue, with exclusive access to the resource it needed.

Q: "Why does PLUS run all tasks in Supervisor mode instead of using User Mode for tasks and Supervisor mode for PLUS system calls? "

A: Portability and ease of use. Without having to worry about User/Supervisor mode, the PLUS function calls can be function calls. Without it, you usually have to map all of the OS function calls into some type of software trap mechanism. This complicates the system and usually adds overhead that is not needed. Also, our PLUS is a Real Time Kernel, not a full blown OS. The distinction is that a Kernel needs to be small and efficient while still providing System Calls that are robust. A Trap mechanism adds code and hurts performance.

However, AT does provide an MMU support package for selected ports that does allow for memory protection of tasks and enables application tasks to run in User Mode while the kernel runs in Supervisor mode.

Q: "How does JTAG debugging work?"

A: The debugger communicates directly to the core through a JTAG connection. This means that there is no need for on board monitor to be running. Basically, JTAG debugging is a much less intrusive and more robust means of debugging. There are a number of ‘flavors’ of JTAG debugging used by various silicon vendors such as BDM, COP and ONCE.

Q: "What is the intrusiveness of Nucleus SHELL?

A: Nucleus SHELL runs as a task. It is minimally intrusive until a command is received, at which point Nucleus SHELL will query the kernel for information and return it to the host. Nucleus SHELL can run over a serial link or over TELNET.

Q: "Can Nucleus PLUS be used without a BIOS?"

A: Yes, Nucleus PLUS can be used without BIOS.

Q: "What drivers are supported by Nucleus PLUS?"

A: Generally a basic serial driver is provided with PLUS. Also support for the CPU interrupts and a timer. Drivers for other devices are also available. Check with Accelerated Technology for an up to date list of drivers available.

Q: "How do I modify the assembly file to get a new port when I am using another compiler with Nucleus PLUS? "

A: The batch files need to be modified to support the new tools. Most Nucleus PLUS ports have three assembly files. The three assembly files may need to be modified to support different assembler directive key words or syntax. Also, with some ports there may exist a start up routine required by the compiler. This routine may be different depending on the tools.

Q: "Does Nucleus PLUS answer to OSEK specifications (cars)?"

A: Yes. Nucleus OSEK adheres to specification 2.2. Please click here for further info.

Q: "What is your licensing policy?"

A: AT offers flexible licensing models to support customers building end products, reference designs, and chip-sets for SoCs. AT's basic licensing policy is one CPU, one product, one development facility. However, these three parameters can be modified to allow increased flexibility to match your requirements. We provide the source code without royalty fees as a benefit to the user.

Q: "What does Accelerated Technology have regarding PCMCIA support and what is the strategy? "

A: AT has a PCMCIA driver for ATA type devices (hard drives and memory cards).

Q: "Do we offer I20 support?"

A: No, we do not offer I20 support.

Q: "Does PLUS have virtual memory support?"

A: PLUS supports a flat memory model.

Q: "Does PLUS have memory paging?"

A: PLUS does not use memory paging.

Q: "Does Accelerated Technology offer BDM or other JTAG Support?"

A: Yes, AT offers BDM and other JTAG support for a large number of targets.

Q: "Do we offer flash file support?"

A: Yes, AT can provide support for flash file devices such as M-Systems and Sandisk devices. For raw flash a flash media manager is typically required to address problems of wear leveling and sector at a time erasure. A third party provides an integrated solution.

Q: "Is PLUS scalable?"

A: Yes, Nucleus PLUS is scalable.

Q: "Are all products sold by AT provided with source code?"

A: All target and prototyping products are delivered with source code. Development tools such as debuggers, compilers and some host side tools do not come with source code.

Q: "Is Nucleus ROMable?"

A: Yes, Nucleus is ROMable.

Q: "Does Nucleus support multiple threads?"

A: Yes, it does.

Q: "Does Nucleus provide application memory protection?"

A: An MMU product is available for select CPU targets that provides memory protection for application code and data.

 

Nucleus GRAFIX FAQs

Q: “How much RAM and ROM does Nucleus GRAFIX require?”

A: Nucleus GRAFIX has two components – a rendering services component and a windowing toolkit component. Both components build as libraries that are linked with the application. The code included from the libraries is very dependent on the application. However, typically the code size is 200-400K bytes for the rendering services library and 100-200K bytes for the windowing toolkit component. RAM usage is even more dependent on the application and can run into the megabytes.

Q: "Is it possible to use GRAFIX with multiple LCD Panels?"

A: Yes, the GRAFIX package is designed so that output can be sent to many different devices.

Q: "How is the LCD screen interfaced and controlled by the Nucleus GRAFIX application? "

A: The LCD screen is interfaced and controlled through a device driver. GRAFIX interacts with the driver through memory used as one or more frame buffers.

 

Nucleus NET FAQs

Q: “How much ROM and RAM does Nucleus NET require?”

A: Nucleus NET can require 26-80K bytes of ROM space depending on CPU, tools and what functionality is included.

Q: "Does NET offer support for 100Mb/s Ethernet?"

A: Yes. Drivers for a number of 100mb/s Ethernet controllers are available.

Q: "Does NET offer support for 1000Mb/s Ethernet (Gigabit)?"

A: Yes. Drivers for 1000mb/s Ethernet controllers are available

Q: "Does Nucleus NET support multiple IP driver interfaces?"

A: Nucleus NET supports multiple physical network interfaces. This means that NET can handle multiple Ethernet controllers at the same time, or an Ethernet controller and a serial (PPP) interface, or various combinations thereof. To a customer this means that Nucleus NET can be used in products like routers and switches, which by definition have more than one physical network interface.

Q: "How many IP addresses can we handle in Nucleus NET?"

A: Under Nucleus NET the number of simultaneous network connections, each of which requires an IP address, is limited only by the resources available to the system - not by any restrictions in the code.

Q: "Can Nucleus NET route between these interfaces?"

A: Nucleus NET has the capability to route packets from one connected network to another. This capability is made possible by the inclusion of RIP 2 (Routing Information Protocol) in Nucleus NET.

Q: "Does Nucleus NET support multi-cast routing between these driver interfaces? "

A: Nucleus NET can send and receive multicast packets but it is not a multicast router.

Q: "Does Nucleus NET support IPv6?"

A: Yes, an add-on component for NET supports IPv6. With this add-on component, Nucleus NET can be used in IPv4 networks, IPv6 networks, or in networks with a mix of IPv4 and IPv6 nodes.

 

Nucleus WEBSERV FAQs:

Q: "Do you offer support for CGI?"

A: Yes, we do.

 

Nucleus Prototyping FAQs

Q: What is the difference between Nucleus Prototyping tools and a Simulator?

A: The simulator is more hardware related and the prototyping is more Nucleus Code related. A simulator simulates the target instruction set on a host system. The MNT** prototyping tools mimic the API (application programming interface - basically the functions visible to the outside) but doesn't try to simulate the target instruction set.

 

Java Technologies: Skelmir CEE-J

Q: Is source code provided for the Nucleus CEE-J JVM solution?

A: Source code is provided for a board specific layer. The Virtual Machine itself is provided as a binary library.

Q: What configurations are available?

A: There are two configurations available. From smallest footprint/functionality to largest they are:

Embedded Java
Personal Java

Embedded Java provides greater functionality including full graphics and would be appropriate for point of sale devices and industrial controllers. The Personal Java supports the requirements of set top boxes and full featured PDAs.

Q: Is CEE-J VM a Sun licensed product?

A: No, CEE-J VM is a clean room solution. The advantage here is we can provide a full JAVA VM solution without our customers incurring the cost of the Sun royalty.

Q: How can I be certain CEE-J VM is compliant with a Sun licensed VM?

A: CEE-J VM is the first JAVA VM to pass the extremely demanding Espial Validation test suite. Extensive on going testing of real world Java applications provides further corroboration that the CEE-J VM is a very robust Java VM solution.

 

Nucleus SNMP

Q: "How can you define your own MIB using Nucleus SNMP?"

A: AT's Nucleus SNMP product comes with an example enterprise MIB which provides an example of how to define your own MIB.

 

Nucleus RMON

Q: "In regards to the RMON light package (first 4 levels of RMON), can I pick and choose the 4 levels I want? Or are levels 1-4 required for the remaining levels to work?"

A: The 9 levels of RMON are:
1) Statistics
2) History
3) Alarm
4) Host
5) Host Top N
6) Matrix
7) Filter
8) Capture
9) Event

Levels 1,2,3,9 are not required for the rest of the levels to work. These are simply the easiest to implement, since all they require is stATstics collection. If group 1 is there, then groups 2,3, and 9 may be derived.

Q: "Do levels 3 & 9 need to be used together?"

A: Yes

These first four levels allow you to collect stATstical data. They will let you know if have a problem on your network but they will not tell you which machine it is on. Other groups are required for more in depth information.

The Alarm/Event groups will send a TRAP (asynchronous message) to a manager if a threshold is reached.

The less groups you have incorporated the faster your app will be (i.e.: when you give up groups you gain speed)

All groups depend upon how much hardware assist they have.
Current state of technology is that 1,2,3,9 are easy.
All other groups depend upon per-packet processing and tend
to slow down systems without adequate hardware assist.