In this post I describe how flexible LTspice can be as a general SPICE circuit simulator, and how accurate its behavior can be in comparing LTspice test results with the physical IC’s datasheet. In this example I use the CD4066B as the IC to model. I test the model using its characteristic “on” resistance curves under various voltage and current operating conditions. I conclude by using a standard CD4066 datasheet to verify the accuracy of the model.

Meanwhile this is the last IC I need to simulate the analog section of the digital volume control circuit using LTspice I mentioned in two of my previous blog entries:

• Digital volume control’s heart beat: Simulating the 555 IC with LTspice and
• Digital volume control’s logic: Introducing 74HC193 Simulation to LTspice.

Define one of four bilateral switches on CD4066 for LTspice

To get the CD4066 IC into my circuit simulation, I first created a symbol for one of the four bilateral switches in this package, and defined a SPICE subcircuit definition for the switch using existing SPICE CD4007 gate models as the starting point.

Symbol for one of four bilateral switches on the CD4066 IC

LTspice symbol for one of four bilateral switches on cd4066 (click to enlarge)

LTspice Subcircuit Definition for CD4066
Note the LTspice implementation of the SPICE language is highlighted (below) using my own GeSHi language highlighter library with key sections of the language (.model and .subcircuit) hyper-linked into SPICE language definitions that I have created on the contributor pages of this website. SPICE is a difficult language to highlight using GeSHi because many of the SPICE language constructs are so short that they overlap with longer language constructs. I plan to add more language definitions in the future as my circuit models need them, and I continue to find unique look-up algorithms to match GeSHi language highlighter categories.

Testing the CD4066 Circuit in LTspice

Finally, I dragged the symbol with subcircuit models into my LTspice program and ran a series of tests to demonstrate the “on” resistance characteristics associated with the switch at various voltage and current values. Note the multicolored graph showing the resistance curves at various VI levels.

VI curves and circuit schematic for cd4066 bilateral switch under test (click to enlarge)

Get these files from LTspice Yahoo Group

The 4 main files used to create this demo circuit can be obtained from LTspice Yahoo Group. Special thanks to Helmut Sennewald

See the figure below…

LTspice Yahoo Group File List (click to enlarge)

Comparison of LTspice circuit simulation with datasheet

The TI datasheet compares favorably with my simulations. The LTspice “on” resistance curves and values are nearly exactly the same as those shown in figures 2,3, and 4 of TI’s datasheet (page 6) for the range I tested.

At this stage of development in simulating the analog path for my automatic volume control circuit, I see that the “on” resistance curve may create an unstable signal path under normal audio conditions unless the operating voltage (Vcc ) is much higher than the original circuit’s proposed 5 VDC power supply.

References

Linear Technologies LTspice Landing Page

Texas Instruments datasheet for the CD4066B

What’s All This CD4007 Stuff, Anyhow?
Bob Pease | ED Online ID #6073 | April 5, 1999
http://electronicdesign.com/Articles/ArticleID/6073/6073.html

Fault in CD4066 Model
kcin_melnick | LTspice Yahoo Tech Group Message #16897 | June 24, 2007
http://tech.groups.yahoo.com/group/LTspice/message/16897

Technorati Claim Tag
SH66YHJAPDBA

Technorati Tags: bilateral switch, cd4007, CD4066, Helmut Sennewald, ltspice, simulation

Enjoy…

Technorati Tags: Ron Fredericks, google android, developer ecosystem, LectureMaker, Marko Gargenta, marakana, Software Developer Forum

Ron Fredericks writes: I have completed the design and test of a new component for LTspice/SwitcherCAD III circuit simulation and schematic capture. In a previous post I discussed my interest in the 74193 presettable synchronous 4-bit binary up/down counter IC for a digital volume control circuit I am building. The circuit simulation described below focuses on how to simulate the 74HC193 IC, but timing and voltage parameters built into this design allow a designer to easily simulate other variants of this IC from high speed Si-gate CMOS HC and HCT devices to low power Schottky TTL devices.

All circuits related to this 74HC193 simulation are available here>

The 74HC193 Component

See figure 1 below for a screen shot of the completed design. The circuit was built from the digital gates in the component library supplied with the original Linear Technology‘s free LTspice tool.

Figure 1 – 74HC193 Circuit and Related Components

View larger image>

To keep the design looking like the original data sheet logic diagram, as published by companies that include NXP Semiconductors and Texas Instruments, a custom “T notS-R FlipFlop” subcomponent and corresponding assembly file was first created. This subcomponent was reused 4 times in the main IC logic diagram. An assembly file called 74hc193.asy was also created. It includes all pins used on the commercial IC except ground and Vcc. The IC’s internal power supply is not simulated by the Linear Technologies’ gates, and so they are not used or required in this design either.

Each gate within the design has a few variables assigned to them so that the IC remains flexible and easy to reuse in new projects:

• tdgate td (propagation time delay assigned to each gate)
• tdgate2 td (propagation time delay assigned to the D FlipFlop)
• tripdtgate tripdt (td’s accuracy band assigned to each gate including the D FlipFlop)
• vhighgate logical high value for each gate and D FlipFlop
• vlowgate logical low value for each gate and D FlipFlop

These variables can be assigned their corresponding time and voltage values using a .param statement placed in the main circuit. These values are then within scope for automatic reuse by the 74HC193 component and flipflop subcomponent simulations. Below is an example of how parameter assignment can be made (as used in the test circuit described next):

.param tdgate=10n tdgate2=3*tdgate tripdtgate=1n vhighgate=5v vlowgate=0v

The Test Circuit

See figure 2 below for a screen shot of the completed simulation test circuit.

Figure 2 – 74HC193 Test Circuit and Truth Table Waveforms

View larger image>

The test circuit demonstrates the use of the 74HC193 component assembly.

Individual pulse voltages are applied to the component’s input pins to validate the new device:

• (asynchronous master reset) pulsed high at the beginning and end of simulation. Unlike the waveform often shown in the 74xx193 IC’s datasheet sequence diagram (see page 7 of 29 in this version published by NXP), the second reset pulse was added to insure that Q0 to Q3 output values really do reset.
• (asynchronous parallel load) pulsed low near beginning of simulation to set flip-flop outputs (Q0 to Q3) to the data input values (D0 to D3).
• (rising edge triggered count up clock) pulsed low several times to demonstrate both the count up behavior of the flip-flop outputs and the terminal count up, or carry, () output.
• (rising edge triggered count down clock) pulsed low several times to demonstrate both the count down behavior of the flip-flop outputs and the terminal count down, or borrow, () output.
• to (data input pins) tied to either logic-high or logic-low for this simulation. The logic-low is constructed from a zero voltage component instead of simply being tied to the LTspice global circuit common node (ground). This is because of the LTspice gate component’s special behavior in removing the simulation of individual gate pins tied to the common node ground.

All voltage sources are referenced using the same high and low voltages described in the previous section: vhighgate and vlowgate. These values can be reassigned to all gates, all at once, using the .param statement discussed above.

Download the Circuits

The 74HC193 component, subcomponent, assemblies, test circuits, and plot control files can all be downloaded without restriction in their use. The datasheet supplied does have some licensed use restrictions, as defined in its last page. The reference to the 74HC193 data sheet from NXP Semiconductors is in no way an endorsement of the company or its products, but it is the most recent and best documented behavior for this device that I have found.

1. 74hc193.74hct193.pdf 74HC193 data sheet published by NXP Semiconductors in Adobe Acrobat PDF format
2. 74HC193_test.asc test circuit as shown in figure above
3. 74HC193_test.plt plot control file used by the test circuit above
4. 74HC103_test2.asc debug circuit used to debug errors in original design
5. 74HC103_test2.plt plot control file used by the test2 circuit above
6. 74HC193.asc circuit component
7. 74HC193.asy circuit component assembly used in the test circuit above
8. TnotSRFlipFlopFromD.asc circuit subcomponent used by 74HC193.asc file above
9. TnotSRFlipFlopFromD.asy circuit subcomponent used by 74HC193.asc file above
10. The screenshots saved as png files – as shown in this blog post
11. readme.txt text file granting a license to use the 74HC193 simulation files listed above without restriction and without warranty

Download the files listed above for your LTspice designs all in one zipped directory.

Technorati Tags: Ron Fredericks, component, LTspice, SwitcherCAD III, circuit simulation, schematic capture, 74193, IC, circuit, simulation, timing, voltage, CMOS, Schottky, TTL, Linear Technology

Technorati Tags: circuit, ltspice, schematic, simulation

Well, I did not find a previous inventor for my IC simulation, but I did get confirmation that the gate build-up was a common strategy. And, this same forum engineer supplied me with a copy of an IC simulation of his own – one very similar to my IC requirement – he supplied a symbol and sample test bed to accelerate my learning curve. Here is a link to my support dialog.

I would like to thank Helmut Sennewald for his time and excellent service to the LTspice yahoo forum. It is his effort and many others who make this forum such a valuable community resource. This forum in turn, has made the LTspice/SwitcherCAD III circuit capture and spice tool a viable design tool for many embedded component users and EE designers.

Introducing the T S-R Flip-Flop

To build my new IC, I had to build a new digital logic block. This component is a Toggle Flip-Flop with Set and Reset functions added. In this blog post I introduce my readers to this new component and share the simulation circuit for others to use and learn from.

See the figure below for an initial design of the T S-R Flip-Flop, including a truth table in the form of a waveform diagram, the circuit, a pulse detector sub-circuit and their related assemblies. This circuit is just an initial design because it uses an S-R Flip-Flop and a simple pulse detector sub-circuit for its clock.

View larger image>

Final Design for the T S-R Flip-Flop

This section of my post is an update, thanks to a review by Helmut Sennewald. See figure below for my final design of the Toggle S-R Flip-Flop. This design overcomes two problems in my initial design, both resolved by starting with the D Flip-Flop with its built-in clock. The reuse of this more full-featured LT supplied component in my design eliminated the home-brew pulse maker sub-circuit. And in so doing, the slower S-R Flip-Flop. Slower because I had to set the SpiceLine time delay to a minimum of 20 nanoseconds (or td >= 2x the gate time delay) to support the simulation of my simple pulse maker sub-circuit. The D Flip-Flop has an internal clock so I could eliminate the pulse maker sub-circuit. End result: one less sub-circuit and faster Flip-Flop simulation using a time delay set to a minimum of 10 nanoseconds (or td >= 1x the gate time delay).

View larger image>

Download

To test my knowledge of digital design using the LTspice tool, I created a number of similar flip-flop components which are included in the download:

1. S-R Flip-Flop test circuit
2. S-R Flip-Flop with Enable gate and test circuit
3. S-R Flip-Flop with rising edge clock and test circuit
4. J-K Flip-Flop with rising edge clock and test circuit
5. D Flip-Flop with Enable gate and test circuit
6. T S-R Flip-Flop from S-R Flip-Flop and test circuit (initial design)
7. Rising Edge Pulse Detector (not high performance design)
8. T S-R Flip-Flop from D Flip-Flop and test circuit (final design)

Download the components listed above for your LTspice designs all in one zipped directory.

Technorati Tags: Ron Fredericks, component, circuit, simulation, LTspice, Linear Technologies, Helmut Sennewald, embedded

SwCAD III First Time Use

The tool is free and comes with a lot of support. I downloaded the software and installed it very easily on my Windows XP PC. It includes a graphical schematic design tool with lots of ready made simulated components, including an NE555 for my initial project. Designing the circuit with the built-in CAD tool works very intuitively. While the LTspice simulation took a bit of head scratching before it worked for me.

I was able to configure and run the simulation using the drop down tools menu and the little “running person” icon on the tool bar. But all I could get out of the simulation was a black screen with voltage and timing ticks along the left and bottom edges. So my first problem was in realizing that the visual display would remain black and traceless until I put the mouse cursor over a wire then click. When the little instrument probe showed up as my mouse icon, I realized what was going on here. With the mouse click, waveform tracings would appear in the black panel.

My second problem was that the circuit would not oscillate. Not good for an oscillator design. First, I forgot to connect the 555′s threshold + trigger pins to the R2-C2 node using the wire tool. But still no oscillation, just flat line traces were observed. Now I already know that getting circuits to oscillate follows Murphy’s Laws: Oscillators remain stable, Amplifies and Buffers oscillate, whenever possible. I found a note on the Old School Hacker blog with a fine solution. You must simulate the circuit with a power supply starting from 0 volts rather than just have an instant on Vcc power supply.

In hind sight dah, its the initial transient response from the circuit’s components that kicks the oscillator into oscillating.

After a little practice I improved the schematic diagram with the use of named nodes and seperation of the temporary load resistors R3 and R load from the more permanent circuit components. The load resistors are just place holders for a real load to be added to the circuit schematic next. Look for my next blog post on this subject.

Finally, I used the cursor measurement facility built into the LTspice window (trace window). With this feature, I was able to make “real” measurements on the waveform for frequency and duty cycle.

Circuit

Here is what I was able to generate using the LTspice/SwitcherCAD III tool:

View larger image>
Download 555 Astable Flip-Flop Schematic Circuit Diagram>

Referring to the figure above:
   Green Trace -> Output (IC 555 pin 3)
   Blue Trace -> Trigger / Threshold (IC 555 pins 2 & 6)
   Red Trace -> Discharge (IC 555 pin 7)

The Astable Multivibrator

The circuit shown above will trigger itself and free run as a multivibrator. The capacitor C₂ charges through resistors R₁ and R₂ yet discharges through R₂ only. Thus, the duty cycle (D) may be precisely set by the ratio of these two resistors. The capacitor charges and discharges between 1/3 Vcc and 2/3 Vcc. But the initial pulse charges C₂ starting from 0 Vcc and so this first pulse duty cycle is unique. Since the charge rate and the threshold levels are directly proportional to the supply voltage Vcc, the frequency of oscillation (f) is independent of the supply voltage.

Frequency Calculation	Duty Cycle Calculation
Measured = 1.8 hertz	Measured = 0.60
Where:      is frequency in hertz      is capacitance in farads      is resistance in ohms	Where:      is duty cycle      is non-zero output duration      is the period of the output      is resistance

Reference

• 555 Datasheet icm7555.pdf
• Linear Technology’s SwitcherCADâ„¢ III Landing Page

Technorati Tags: Ron Fredericks, schematic, LTspice, SwitcherCAD III, simulator, Spice, CAD

I chose to discuss Wind River’s VxWorks BSP because of my familiarity with their product line, my understanding of their BSP as a competitive product compared to other real-time kernels, and because of my industry accomplishments working with Wind River’s BSPs:

• Ron Fredericks wins Wind River’s prestigious Navigation Award for designing, launching, and marketing the first online interactive social network for BSP’s. more>
• Ron Fredericks wins Aiysis’ Million Dollar Club Award for nurturing a Wind River partnership between VxWorks and Aiysis DriveWay BSP tool kit that generated over one million in annual sales. more>
• Ron Fredericks co-author’s an article with Xilinx on How to Design Field Upgradable Systems based on FPGA Internet connectivity with VxWorks BSP’s. more>
• Ron Fredericks produces an online video: How to Prototype a Device Driver [or BSP] in Less Than – Wow! – 5 Minutes for a Freescale application processor / communications co-processor System on Chip (SoC). more>

A similar high level discussion can not be made for most embedded Windows or embedded Linux BSP’s today. This is because the BSP for these monolithic kernels are not as modular as a real-time executive kernel such as VxWorks. Indeed other real-time kernel vendors can and do take advantage of the BSP too. But, the VxWorks BSP just took more advantage of this natural separation between board support and kernel tasks earlier in the marketplace and has been an advantage for its customers as a result ever since.

Figure 1 – Embedded device with BSP connected to a host workstation

As shown in Figure 1, most BSP’s today, even those for embedded Windows and embedded Linux, do have a robust set of boot options. In many cases a BSP can be used on its own to network attach to a shared file system where the full operating system and application can be loaded. In this way, a device under development need not be the device where development takes place. The BSP in this case forms the basis for a cross-platform development environment – a big plus for developers of embedded systems. Developers often expect cross-platform development to include a BSP with a limited network stack to load new code onto the target hardware during a cold reset. The BSP might use JTAG on-chip run-time control, RS232 serial port, FTP, Bootp, TFTP and RARP, or even a command shell with a full network stack, as the boot loading protocol. But what ever host to target connectivity is used, cross-development allows a high end workstation to be used for time-saving development along with an easy way to download the resulting compiled relocatable object code or a linked and located image onto an embedded target.

For hardware vendors, the BSP is a very useful partner tool. If a hardware vendor makes a set of boards along with a bus pre-assembled as a subsystem or just a single board computer, the BSP allows its clients to leverage this hardware for software development right away. So a hardware vendor can select major operating systems that meet the needs of its target client base and offer a BSP suitable for these operating systems. Usually the BSP is not a licensed product from the operating system vendor and can be bundled royalty free or under very libral license fee conditions. In this way, the operating system vendor or the open-source community, can partner with this hardware platform as a known reference for direct end products or for development of custom products. The horrible alternative is a slow hardware bring-up using new hardware for the first time to build a unique BSP – a very slow and expensive procedure where few software debug tools are available. JTAG or other N-wire run-control devices can be used with an operating system vendor’s debugger in some cases when a robust BSP is not already available. Silicon vendors and I/O device vendors can leverage this technical marketing strategy too.

I encourage Microsoft and embedded Linux communities to consider improving their BSP strategy to deliver more value from a separate BSP structure too. I also encourage my readers to go ahead and submit comments to this blog post if you know of other vendors with good BSP designs as the marketplace is always changing.

View #1: A BSP is the kernel’s interface to device drivers

A VxWorks Board Support Package provides a standardized interface between hardware and the operating system. A BSP does not directly access hardware. Although a BSP does provide an interface to device drivers which in turn allows the kernel to communicate with the hardware’s assets such as device controllers, the microprocessor (CPU), memory, internal and external busses.

Figure 2 – BSP is an interface between kernel and hardware

Figure 2 demonstrates how VxWorks and the developer’s application software remain hardware independent while the BSP provides an interface to the embedded system’s architecture and hardware assets. Wind River BSPs conform to a standard, introduced with VxWorks BSP Version 1.1. The standard is fully described in the Tornado BSP Developer’s Kit for VxWorks. The BSP provides a common application programming interface (API) and a stable environment for the real-time operating system. The standard interface defines both BSP conventions and BSP validation procedures.

Wind River provides a standardized BSP validation procedure for engineers who are developing their own BSP’s. Validation is very efficient with a BSP designed for VxWorks because the BSP testing can be performed without having to test the operating system at the same time. Unlike Wind River’s real-time operating systems, most operating systems can not separate the testing of the BSP from the testing of the operating system itself making code coverage during testing a much larger and more inaccurate process. The BSP validation test suite provided by Wind River is repeatable and as such can be performed by the company developing a BSP as well as by others because of this standard. When I supported Wind River’s partners back in 2002, a partner could request that the WindLink partner program grant “Tornado Certified” status to a new BSP after passing the validation procedure as part of an overall certification process.

The validation procedure include tests for:
• Package validation
• Installation tests
• Functional tests
• Code review process including certification from the WindLink partner program

The Tornado BSP standard included conventions to be used by developers that fall into four main categories:
• Coding Conventions
• Documentation guidelines
• BSP Packaging
• Driver guidelines

Another strength of VxWorks is that it provides a high degree of architectural and hardware independence for application code because of this API. Application code and VxWorks can both more easily migrate from one architecture to an other because the BSP and related device drivers offer a consistent interface and modular design.

To further illustrate the BSP’s ability to interface hardware to software: Consider the process of laying carpet on your home’s floor. The carpet layer uses two-sided sticky tape to quickly attach just about any style carpet to any architectural floor plan beneath it. The BSP acts like this two-sided sticky tape attaching the embedded hardware to the operating system that uses it.

View #2: A BSP is a set of libraries offering a hardware abstraction layer to the kernel

The BSP enforces a modular design by isolating hardware-specific functionally into a set of libraries that provide an identical software interface to the hardware functions available on an embedded system. See detailed description of some of the common libraries and related files later in this blog post.

Figure 3 – Location of BSP files

Figure 3 shows an example of the typical files supporting a PowerPC target’s BSP and their location in a Tornado installation on a host computer such as Windows XP.

The BSP includes facilities for hardware initialization when power is first applied or when a hardware reset has been initiated. The BSP also includes support for interrupt handling and generation, hardware clock and timer management, and mapping of available local and bus memory. These basic services provide the real-time kernel with multi-tasking services and memory space for the designer’s application code.

Other device drivers and related support services can be included in this set of libraries extending the hardware abstraction to support the embedded system’s custom hardware services. These services would include networking, security, storage, graphics, and input/output to the outside world – for example. The devices referenced by the BSP can be located on a single board computer, a system on a chip (SoC), or on peripheral devices located across a wireless boundary or on a backplane using a hardware bus.

View #3: A BSP supports a host/target cross development environment

The BSP provides support for developers using Tornado tools on a host computer for engineering development such as an editor, compiler, linker, and debugger through a client/server communications protocol between the developer’s host computer and the embedded target’s CPU, hardware devices and on-board memory. For VxWorks developers, the BSP offers an interface to the WDB agent that provides an open standard for cross-hosted programming on a specific target’s architecture. The host computer supports these services using the Tornado tool suite through a target server acting as the communications agent. The target BSP can support a networked development environment using one or more of the following devices: Ethernet, JTAG, serial UART, ROM socket, or custom driver, to communicate with the host’s target server. When an application is complete and the embedded device is ready for production, the WDB agent can be removed from the target’s BSP.

Figure 4 – BSP supports host/target cross development

Figure 4 demonstrates a typical cross development embedded programming model. The WDB client on the target BSP communicates with the host’s target server. This host/target pair supports connecting other software and hardware tools that lower the cost of a typical engineering cycle: design, edit, compile, link, download, debug, test, and deploy.

There are advantages to having a BSP that is separated from the kernel….

A BSP allows target applications to be ported to many architectures.

The three views of a BSP described above are all consistent with today’s engineering needs for a common interface to development tools residing on a robust host computer in support of an embedded application requiring operating system support and services that is modular and portable across many different architectures.

Wind River and its board and silicon partners offer a wide variety of BSP’s for custom off the shelf (COTS) single board computers, and time saving reference designs on more than 12 different architectures. See the BSP web site I designed for Wind River back in 2002:

www.windriver.com/products/bsp_web/bsp_architecture.html

Description of BSP technical features

There usually is a file named target.nr defined in the BSP documentation standards for each BSP. The file contains a list of technical features supported and unsupported for a particular COTS or reference board. The list of features describes what a BSP is expected to do during hardware initialization when the CPU executes its first instructions as well as what hardware assets should be presented to the operating system. This information is summarized here.

Boot Monitor
• Describe the methods and devices available for booting RTOS on this board. (sm, SCSI, Ethernet, vendor-bug ROMs, open firmware, visionWARE, etc).
• Describe the network support available for booting; bootp, proxy-arp, etc…

Default Ram size
Additional supported memory options
Cache support
Flash and ROM memory
• How are ROMs made and installed? (How do they split?) Can FLASH ROMs be burned on board? If so, how?

Timer support in addition to system clock
• Describe routines that are associated with speed of CPU and Timers

Devices supported:
• The chip drivers included are:
templateSio.c – template serial driver
templateTimer.c – template timer driver
templateVme.c – template VMEbus driver
templateNvram.c – template non-volatile RAM driver
• Describe the device drivers for this board. Are there special driver ptions that must be used with this board such as CompactPCI hot swap support? Read the specific driver documentation and describe any special options used with this board.
Memory Map
• Provide a detailed memory map of the local bus, and all additional busses from a bus master point of view. Identify only slave devices actually on each bus, not their apparent address on some other bus. (i.e. if a serial device is a PCI device, do not list it on the local bus memory map, just the PCI memory map). Identify all addresses that the user can adjust by changing config.h, as being software controllable. Identify all bus master devices (DMA) on each bus.
• If VME is present, describe the default parameters for the master windows and how to change them, if possible. (master access means accessing some other board from this board). Describe the default parameters for the slave access windows, and how to change them, if possible. (Slave access means an access from another bus master). The normal VxWorks default is to enable the slave access window(s) only on CPU 0, as part of the routine sysProcNumSet(). Otherwise, slave accesses are not normally permitted.
• If PCI is present, describe the configuration access methods used to access PCI configuration space. Describe any address mapping from local addresses to PCI addresses and vice versa. Describe how the user can alter this, if appropriate.
Shared Memory
• If appropriate, identify the main bus and the type of shared memory support provided, if any. Identify the type of mailbox support and Test-And-Set support used. Identify any special support, or consideration, necessary from other boards in a multi-board system.
Interrupts
• Provide a list of interrupts/exceptions by priority and/or vector number. Describe any special interrupt connection routines or considerations used with this BSP.
Serial Ports
• Identify the default configuration for all serial ports. Document any special considerations: i.e. hardware flow control cannot be disabled thus requiring a jumper to be installed when no terminal device is connected.
SCSI Support
• Are there any known SCSI configuration limitations? Does the BSP support SCSI-1 or SCSI-2? Describe any special connectors or adapters. Does the board include terminators on-board? Is there a jumper to activate the termination network?
Ethernet Support
• Describe the Ethernet ports on the board. Identify how the MAC address is obtained or specified for each port.
Delivered Objects
• Which pre-compiled objects are delivered with the BSP?

Make Targets
• If there is any special information about a specific make target, then it should be explained. Identify any standard targets that do not build or run correctly. (bootrom, bootrom_uncmp, bootrom.res_rom, examples on VxWorks also include: vxWorks, vxWorks.st, vxWorks.res_rom, vxWorks.res_rom_nosym, vxWorks_rom).
Special routines
• Are there any unique BSP routines available to the user?
Divide by zero exception
• Describe exception handling of divide by zero event.
Host-Target Communications Support
• Name of client server agent such as WDB for VxWorks
• Describe additional WDB agents supported for debug support with host if any.

Some details on the collection of BSP libraries

BSP Source and Include Files reside in the following two subdirectories of a Tornado installation:
• TornadoBaseDirectory/target/config/all
• TornadoBaseDirectory/target/config/BSPname

See figure 2 for a view of these subdirectories and files. The subdirectory TornadoBaseDirectory /target/config/bspname contains the hardware dependent Board Support Package (BSP), which consists of files for the particular hardware used to run VxWorks, such as a CompactPCI board with specific semiconductor silicon assets for serial lines, timers, and other devices. The files include:

• Makefile
• sysLib.c
• sysSerial.c
• sysALib.s
• romInit.s
• bspname.h
• config.h

Two target-specific libraries, sysLib and sysALib, are included with each port of VxWorks. These libraries are the heart of VxWorks portability; they provide an identical software interface to the hardware functions of all boards. They include facilities for hardware initialization, interrupt handling and generation, hardware clock and timer management, mapping of local and bus memory spaces, memory sizing, and so on.

The System Library
The file sysLib.c provides the board-level interface on which VxWorks and application code can be built in a hardware-independent manner. The functions that should be addressed include:

• Initialization functions
1. Initialize the hardware to a known state
2. Identify the system

• Initialize drivers, such as SCSI or custom drivers

• Memory/address space functions
1. Get the on-board memory size
2. Make on-board memory accessible to external bus (optional)
3. Map local and bus address spaces
4. Enable/disable cache memory
5. Set/get nonvolatile RAM (NVRAM)
6. Define the board’s memory map (optional)
7. virtual-to-physical memory map declarations for processors with MMUs

• Bus interrupt functions
1. Enable/disable bus interrupt levels
2. Generate bus interrupts

• Clock/timer functions
1. enable/disable timer interrupts
2. set the periodic rate of the timer

• Mailbox/location monitor functions (optional)
1. Enable mailbox/location monitor interrupts

The sysLib library does not support every feature of every board: some boards may have additional features, others may have fewer, others still may have the same features with a different interface. For example, some boards provide some sysLib functions by means of hardware switches, jumpers, or PALs, instead of by software-controllable registers.

The configuration modules usrConfig.c and bootConfig.c in TornadoBaseDirectory/target/config/all subdirectory are responsible for invoking this library’s routines at the appropriate time. Device drivers can use some of the memory mapping routines and bus functions.

Each BSP also includes a boot ROM or other boot mechanism. Many of these import the run-time image from the development host. For information on boot ROMs and other booting mechanisms see Tornado Getting Started manual and VxWorks User ‘s Guide section 8.9 Creating Bootable Applications. For information on target-specific libraries, see 8.2 The Board Support Package (BSP) in the VxWorks User’s Guide and the target-specific reference entries for your board type starting with the file target.nr on the BSP distribution.

Virtual Memory Mapping
For boards with MMU support, the data structure sysPhysMemDesc defines the virtual-to-physical memory map. This table is typically defined in sysLib.c, although some BSPs place it in a separate file, memDesc.c. It is declared as an array of the data structure PHYS_MEM_DESC. No two entries in this descriptor can overlap; each entry must be a unique memory space.

The sysPhysMemDesc array should reflect your system configuration, and you may encounter a number of reasons for changing the MMU memory map, for example: the need to change the size of local memory or the size of the VME master access space, or because the address of the VME master access space has been moved. For information on virtual memory mapping, as well as an example of how to modify sysPhysMemDesc, see VxWorks User’s Guide section 7.3 Virtual Memory Configuration.

The Serial Driver
The file sysSerial.c provides board-specific initialization for the on-board serial ports. The actual serial I/O driver is located in the TornadoBaseDirectory /target/src/drv/sio directory. The library ttyDrv uses the serial I/O driver to provide terminal operations for VxWorks.

BSP Initialization Modules
The following files initialize the BSP:

The file romInit.s contains assembly-level initialization routines.

The file sysALib.s contains initialization and system-specific assembly-level routines.

BSP Documentation
The target.nr file located in the TornadoBaseDirectory /target/config/bspname directory is the source of the online reference entries for target-specific information in our new BSP web site. For a description on how to view the target.nr reference files supplied with our product distributions, see the Tornado Getting Started manual. The target.nr file describes the supported board variations, the relevant jumpering, and supported devices. It also includes an ASCII representation of the board layout with an indication of board jumpers (if applicable) and the location of the ROM sockets.

References

• Tornado Getting Started Manual
• VxWorks User ‘s Guide
• Tornado BSP Developer’s Kit for VxWorks: User’s Guide (some times referred to as a porting guide)
• Tornado BSP Training Workshop – book 1 (see Wind River training web site for BSP class times)
• Wind River’s BSP web site

The Wind River logo is a trademark of Wind River Systems, Inc., and Wind River is a registered trademark of Wind River Systems. Other marks used herein are the property of the respective owners.

Technorati Tags: Ron Fredericks, Wind River, VxWorks, Board Support Package, BSP, Tornado, FTP, Bootp, TFTP, command shell, RARP, Network Stack, JTAG, N-wire, Ethernet, JTAG, UART, ROM

• I discovered Dean Lee‘s Code Highlighter plugin for WordPress as the blogging solution for my source code display needs.
• I fixed a word wrap problem in Dean’s plugin.

During my research to solve the word wrap problem, I discovered a few more issues leading me to update Dean’s plugin with the latest version of GeSHI (an open-source project: Generic Syntax Highlighter for php. Highlight many languages, including PHP, CSS, HTML, SQL, Java, Assembler, and C for XHTML compliant output) and removal of unused files. I thought other WordPress bloggers might like to take advantage of the latest code too, so I document the steps needed to build a clean plugin with the latest components.

Flow Chart / Swim Lanes Widget
Below is a Flash widget I built to document the steps needed so you can roll your own up-to-date plugin. Follow these steps and you won’t have to be a programmer to get the benefits from the latest versions of these program components. The widget actively links to the latest PHP files and CSS classes:

Why Roll Your Own Plugin?
I have been working with components and tools on various projects long enough to realize a common problem. Whenever components are used from different projects, such as Dean’s plugin integrated with the GeSHi language components, each file and/or component continues to receive bug fixes and enhancements in real-time without regard to the other components and files. This is natural because each component’s project is managed by a different group.

So now I have an idea on how to fix this evolving problem of diverging code bases: create a flow-chart showing how to assemble the individual components into a final product. Use swim-lanes to highlight the different component resources being used. Document the whole work-flow into a Flash document so links to other web pages and/or live video’s can be included as hot-links to demonstrate the process.

Detailed Notes on the Problems Solved Here
Here are the issues I solve in this blog post:

• The version of GeSHi included with Dean’s code-base is now obsolete. The latest version of GeSHi includes a few bug fixes and a few new supported languages for syntax highlighting. By the time you read this blog post, perhaps GeSHi will have yet an even more improved and stable code base.
• One of the optional modules supplied by GeSHi, PHP samples found in the “contrib” directory; include a recently-identified security risk if included on a web server – such as your WordPress blog installation. Dean’s plugin includes this GeSHi directory by default.
• Dean’s plugin also includes a Mac temporary file called .DS_Store that is not used by WordPress either.

The Components and Their Versions
Dean’s original code has the following versions:

• WordPress should be version 1.5 or later
• Dean’s Code Highlighter v1.1
• Download link:
  www.deanlee.cn/wordpress/code_highlighter_plugin_for_wordpress/
• Dean’s code includes the following GeSHi components:
  geshi.php, contrib and geshi directories
  GESHI_VERSION, 1.0.7.14
• CSS classes for WordPress template style.css file
  www.deanlee.cn/wordpress/code_highlighter_plugin_for_wordpress/#ch_css_class

My rebuilt version of Dean’s plugin has the following components and version detail:

• I’m using Worpress version 2.0.4
• Deans_code_highlighter.php
  Version 1.1
  Download link:
  www.deanlee.cn/wordpress/code_highlighter_plugin_for_wordpress/
• geshi.php, and geshi directory
  GESHI_VERSION, 1.0.7.19
  Download link:
  sourceforge.net/projects/geshi/
• New CSS classes for WordPress template style.css file
  Version 1.0 from Embedded Components
  www.embeddedcomponents.com/blogs/2007/05/how-to-fix-dean-lees-source-code-highlight-plugin/#ch_css_class

A Final Note
The GeSHi code base continues to go through updates. At some point the logic behind my approach – mix and match the latest code from all resources required for Dean’s WordPress plugin – might break down. Perhaps GeSHi will adopt a new interface that’s not suitable to Dean’s WordPress plugin code, for example. In any case, if you are having trouble getting Dean’s plugin to work, I suggest the following:

Revert back to Dean’s complete code base. Install it as he suggests and try it. If Dean’s original code base does not work, then maybe you are not following the install instructions correctly or perhaps WordPress itself is at an incompatible version. If the plugin works, then try replacing code one step at a time. With each new file change, try your updated WordPress plugin to see if it still can be deactivated, reactivated, and highlights code correctly in a blog post. When the offending component has been identified, let me know so we can work out a new swim-lane diagram for others to follow.

Technorati Tags: Ron Fredericks, Dean Lee, Code Highlighter, WordPress, plugin, component, Flow Chart, Swim Lanes, Flash, widget, PHP, CSS, GeSHi

Embedded Components, Inc. has a short [and free] online lecture introducing the CIFS protocol to the embedded device manufacturing community. The CIFS protocol is likely the most ubiquitous file sharing middleware used in the desktop and enterprise computer markets today. Wow! If its so common why haven’t I seen it? Its embedded so it just works in the background.

What is the CIFS standard?

• Samba for UNIX users sharing MS Windows files and more
• Microsoft CIFS made for DOS and embedded in Windows
• SNIA: The open standard

What is the new event presented in this online lecture?

• CIFS NQ is available for {many embedded and real-time operating systems such as VxWorks, Integrity, and threadX} now
• Prior to CIFS NQ, there was no practical way for an embedded designer to take advantage of this very easy to use and very common desktop computer protocol

References:

• Get the CIFS NQ source code from Visuality Systems
• Watch the lecture: Introduction to the Common Internet File System (CIFS)
• Wikipedia: Server message block or SMB

Technorati Tags: Ron Fredericks, Visuality Systems, Brian Mork, Increa Technology Blog, Common Internet File System, CIFS, Embedded Components, embedded device, middleware, Samba, Microsoft, DOS, Windows, SNIA, open standard, CIFS NQ, VxWorks, Integrity, threadX, protocol, Server message block, SMB