In several previous LTspice posts I described how to use the simulator as a test jig for single IC’s and gates. Each block in a circuit should be tested within LTspice before creating a multi-circuit simulation to verify performance against expected results. The test jig process included downloading a custom gate, IC, and spice code for the cd4066 bi-polar analogue switch from the yahoo LTspice user group, and the creation of my own 74LS193 pre-setable up/down counter from primitive logic gates. Ltspice is very flexible. Most discrete components are readily available in the library, with a great support group from on yahoo. There are a wide variety of spice and pspice models to important from many Internet sources as well..

The Circuit to Simulate

I came across this digital volume control circuit during a web search. The circuit seems to be fairly popular as it shows up in thousands of places on the web. I thought it would be a good place to start my investigation of digital volume control even though there are many industry specific chips out there to manage some of these functions as well as chips that offer much larger feature sets. With this circuit I hope to expand on the features to create new volume control and measurement circuits – perhaps while investigating the value in using an more advanced volume control chip.

This circuit could be used for replacing your manual volume control in a stereo amplifier. In this circuit, push-to-on switch S1 controls the forward (volume increase) operation of both channels while a similar switch S2 controls reverse (volume decrease) operation of both channels.
Here IC1 timer 555 is configured as an astable flip-flop to provide low-frequency pulses to up/down clock input pins of pre-setable up/down counter 74LS193 (IC2) via push-to-on switches S1 and S2. To vary the pulse width of pulses from IC1, one may replace timing resistor R1 with a variable resistor.

Operation of switch S1 (up) causes the binary output to increment while operation of S2 (down) causes the binary output to decrement. The maximum count being 15 (all outputs logic 1) and minimum count being 0 (all outputs logic 0), it results in maximum and minimum volume respectively.

The active high outputs A, B, C and D of the counter are used for controlling two quad bi-polar analogue switches in each of the two CD4066 ICs (IC3 and IC4). Each of the output bits, when high, short a part of the resistor network comprising series resistors R6 through R9 for one channel and R10 through R13 for the other channel, and thereby control the output of the audio signals being fed to the inputs of stereo amplifier. Push-to-on switch S3 is used for resetting the output of counter to 0000, and thereby turning the volume of both channels to the minimum level. — Sheena K. for electronicsforu magazine

Dual-Channel Digital Volume Control Circuit (click to enlarge)

The LTspice Simulation

The Circuit

Volume Controller Schematic in LTspice (click to enlarge)

The Simulation Results

LTspice Simulation Results (click to enlarge)

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

Ron Fredericks writes: Engineers want to build compelling products that meet their project requirements. Corporate executives want to invest in innovative people that build products that, in turn, meet their market’s window; while, both want to stay within budget. Yet both groups may feel overwhelmed with the prospect of expressing the very heart of their inspiration at some critical times during the life of these projects. In today’s post, I try to address this issue from the engineer’s perspective reaching out to the financial decision makers that ultimately control the purse strings of every project.

Table of Contents

Introducing Financial-Speak to Engineers
ROI Example: Embedded Linux
Evaluating Incremental Cash Flows
ROI Example: Simple Project Comparisons Using Net Present Value
ROI Example: Evaluating an Infrastructure Project
ROI Example: The Original Design Manufacturer
References
Errors and Changes Planned for this Blog Post

Introducing Financial-Speak to Engineers

In a previous post I introduced the idea that ethics might be the common framework between this dichotomy in communication between engineers, marketers, and executives. In this post, I suggest that engineers might apply this ethical approach by taking some time out to learn the language of business development from a financial management perspective – a conversational framework suitable for an interdisciplinary team concerned with engineering risk and strategic business value, but expressed using financial definitions.

The term Return On Investment (ROI) can be used for all three disciplines: engineering, marketing, and finance. ROI is just vague enough to cover most any discussion an engineer may encounter through-out the life of a project: from the initial decision to fund your project, to evaluating change requests during the design, build, test, and deployment cycle of an ongoing project. Evaluating ROI from a financial perspective is an ethical approach to decision-making because the financial terms I promote for this ethical framework have very precise meanings. So precise in fact, that I too have had to go back and rewrite several sections of this blog post thanks to One Nomad’s Blog comments received in this blog’s first posting.

It was the lack of financial precision embedded within my first draft for this blog post which my guest reader used to convince me of my own mistakes. Yet to be clear, identifying my mistake is also my gain. Effective communication is a process of two or more people sharing ideas…

Learning to converse and plan using financial terms for ROI decision-making can level the playing field between engineers, marketers, and business executives since ROI itself is not a common financial term. Engineers practicing Financial-Speak centered around ROI as the goal, can help reduce many of the common problems related to individuals trying their best to participate in team decision making. This leveling of the playing field – between team members – can also enhance the power of their conversation, leading the way for the much sought after innovations that are in popular demand today.

Consider building a financial model around ROI before presenting your most important technical needs to executives, marketers, and other decision makers. Read on to learn how. Of course ROI from a financial perspective is not the only way to build effective interdisciplinary teams with engineers involved. In a future post I may suggest a corollary to this ethical approach for executives and marketers who would like to reach out to engineers – using Six Sigma, CMMI, and emerging techniques developed by Dr. Thomas J. Buckholtz as useful processes seeped in ROI terminology.

Figure 1: Net Present Value Equation

Where:
is the Net Present Value function, in dollars
is a project’s Cash Flow, in dollars
is the hurdle Rate, in percent per period
is the Initial Investment (a negative number), in dollars
And:
is the cash flow’s time increment, or period
is the total number of cash flow periods for
Time increment for and might be in years, quarters, or months, for example

ROI Example: NPV’s Effect on Embedded Linux

The equation in Figure 1 forms the heart of my “ethics in engineering” proposal. Namely, the sooner a new device gets to market, the sooner a firm can realize new income. New income realized sooner, is much better than income realized later. A finance discussion around NPV would call this time’s negative impact on the value of money. I’m talking about the exponential effect that the prevailing interest rate, R, has in the NPV equation shown in figure 1.

A few years ago several of the leading embedded operating system suppliers used this equation to show that embedded Linux was a poor choice for new embedded device development projects. One such paper published by Dr. Jerry Krasner in 2003, Total Cost of Development, presents the typical argument pretty well. At that time Dr. Krasner and many others may have been right. Now in 2007, times have changed significantly. A recent blog entry on CNET shows the missing element from Dr. Krasner’s report and is a Harold for the embedded industry going forward: Oracle touts Linux deals.

How times have changed…

Because of the significant adoption of Linux in enterprise projects, the total project cost of using embedded Linux has gone down too. Indeed, the migration and reuse of enterprise Windows operating system application programming interfaces (API’s), kernel components, and development tools into embedded device projects was a key part of Dr. Krasner’s report, see link above. Dr. Krasner concluded at the time that embedded Windows CE made the best choice for new projects from a total cost of ownership perspective – just another way of looking at NPV!

Now the ROI benefits behind projects that select embedded Linux follows Dr. Krasner’s logic perfectly. Embedded Linux is now experiencing the same reduced total cost of ownership that only embedded Windows CE enjoyed just a few years ago. The reduced total cost of ownership comes from new and improved tools, components, and API’s that cross over from enterprise projects to the embedded marketplace. There is a significant overlap in Linux kernel updates, components, and tools driven by enterprise projects that are also suitable for use in embedded projects.

The available pool of engineers that know how to work with Linux can now support embedded development projects that use embedded Linux too. The marketing movement around the value and excitement of using Linux may also reduce the cost of taking an embedded device to market. In short: lower upfront costs, more options, more solutions, and faster time to market. Even Dr. Krasner has decided to post an update to his old white paper showing total cost of development to be favorable for embedded Linux projects. Download his updated paper.

None of these enterprise driven benefits exist with respect to the traditional embedded real-time operating system (RTOS). To be clear, there are other benefits to using an RTOS. I discuss one significant benefit to using an RTOS in another post: How to Leverage the Value of a Board Support Package.

Evaluating a Project’s Incremental Cash Flow

NPV is just one example of applying the principle of ROI to making project decisions. NPV falls into the general category of capital budgeting, a process of evaluating proposed investments into new projects. The capital budgeting process is concerned only with incremental cash flows. So the vague concept of ethics can be transformed into a specific financial discussion.

Two financial functions can measure time’s effect on money:

(1) Net Present Value (NPV) expressed as a monetary value,
and

(2) Internal Rate of Return (IRR) expressed as a percentage.

Where:

Net Present Value (NPV) of a capital budgeting project is the dollar amount of change in the value of the firm as a result of undertaking the project [Ref: Financial Management: Principles and Practice P.234]. The mathmatic definition for NPV is:

Where:

= Initial Investment (a negative number)
= cash flow value (project outputs – project inputs) for period
= hurdle rate per period, where period is a unit of time, typically year, quarter, or month
= total number of periods for the project

Present Value (PV) is the value today of a future, or expected, cash flow. The mathematic definition for PV is:

NPV can be expressed in terms of its present value (PV):

Hurdle Rate is the required rate of return before launching a new project. The hurdle rate must be carefully chosen. It can be expressed as a percent per period. The period is commonly defined as one year, but other convenient time period could be selected such as one quarter, or one month. The same unit of time will need to be associated with cash flow. Other rate terms can be used in addition to, or instead of, hurdle rate: discount rate, cost of capital, or interest rate.

Internal Rate of Return (IRR) is the discount rate at which the
NPV of the project is zero. [Ref: Financial Management: Principles and Practice P.240]. The mathematics definition for IRR is related to NPV:

NPV and IRR are related to each other:
What follows is a list of relationships between NPV and IRR. Use these relationships after calculating the NPV and IRR for each of the proposed project alternatives.

(1) If NPV(CF, R, IV) = 0,
then the hurdle rate, R = IRR

(2) For any set of cash flows estimated for a prospective project,
there is only one value for NPV.
But, the same project model can result in several IRR values,
where NPV = 0.

(3) If IRR > Hurdle Rate,
then a prospective project may make an acceptable
investment.

(4) If IRR >> Hurdle Rate (i.e. significantly greater than),
then a prospective project may carry too much risk.

(5) The hurdle rate includes both a minimum desired rate
of return for a project, and a threshold representing risk.
(5-a) A typical hurdle rate for an E-Business project
might be 15%.
(5-b) A typical hurdle rate for an embedded systems project
might be 18%.
(5-c) Embedded Components, Inc. is focused on lowering risk
for its members by promoting the re-use of pre-existing
components through its online marketplace
for embedded device manufacturers and their
communities.

(6) In general seek to maximize NPV, not IRR.

(7) Yet, if two projects have NPV curves that cross over each
other,
then the interest R where the curves cross is called
the Crossover Point.
(7-a) If the Crossover Point > IRR,
then accept the project with higher NPV.
(7-b) If the Crossover Point <IRR,
then accept the project with higher IRR.

(8) An NPV value of zero also means the investment into that
project would neither gain nor loose value for the company.

Define a project’s return on investment (ROI):

1a) Profitability Index (PI), measured in % percent

1b) Open Source Profitability Index (PI_FOSS)

2a) Payback Period (PP), measured in time such as years, quarters or months

2b) Open Source Payback Period (PP_FOSS)

3) Sensitivity Analysis, a plot of NPV verses Interest Rate

Return on Investment (ROI) is a business case analysis concerned with the net financial impact associated with a set of costs and benefits. Most research around capital budgeting does not define a specific calculation associated with ROI. Unlike NPV and IRR, which use formulas generally agreed to by industry, ROI calculations can be industry specific. I found an excellent overview of ROI in a paper by Dr. Jeffery [Ref: Return on Investment Analysis for E-Business Projects equation 6, page 6]. In his paper Dr. Jeffery presents a definition for ROI as:

ROI = 100% x (Project Outputs – Project Inputs) / (Project Inputs)

Where:

Project Outputs represent the value created by a project such as new income generated, efficiency gains, cost savings from improved internal processes, new intellectual property created, and strategic benefits (such as increased marketshare, brand name recognition, incremental gains in product mix, and improved vendor relationships).

Project Inputs represent expenses related to a project such as the initial investment in software and tools, development costs (such as professional employee salaries), facilities expenses (including building depreciation, grounds maintenance, service level agreements, and equipment depreciation,) deployment costs (such as sales commissions, marketing, shipping, and 3′rd party software run-time fees), goernment fees (such as sales taxes, patent filings, and corporate governance), and legal fees.

The sections below are under re-construction as of 3/3/08

Profitability Index (PI):

PI adjusted for Free and Open Source Software (PI_FOSS):

So one of several projects under consideration to fund, may be the most acceptable if its NPV is a large enough positive number. In other words, a project is acceptable if the IRR is greater than or equal to the hurdle rate. Where the hurdle rate is defined as the expected rate of return on a potential investment that a manager demands before investing his or her money into a project. I have seen hurdle rates in the range of 8% to 18%, for example.

Measuring the risk of a capital budgeting project can be done by calculating the coefficient of variation (CV) on the expected returns from a firm’s asset portfolio with and without the new project being undertaken. Since the CV is defined as the ratio of the standard deviation to the mean, it can be used to determine how much volatility (risk) will be assumed in comparison to the amount of return expected from the proposed project.

There are several wrinkles in the capital budgeting decision process to consider:
(1) Non-simple projects,
(2) Projects that have multiple IRRs,
(3) Comparison of projects with unequal project lives, and
(4) Strategic benefits.

Read on to learn how to manage the financial data behind project proposals with all 4 of these complicating factors taken into account.

ROI Example: Project Comparisons Using Financial Terms

I developed a MathCad program to compare and plot two projects based on several financial terms. The MathCad equations can be used if you already have this math package. Download the MathCad template [tbd]

If you prefer to use Microsoft’s Excel, an open source office package, or google’s hosted office suite, then you can use the equations I develop here to handle the calculations.

In this Mathcad example, two projects with the same basic financial data are compared. Project A is a typical project with estimated sales (as a result of project completion) that builds up over time. Project B is not typical, but is a good test case. Project B uses equal payback amounts over time – similar to an annuity.

Define Initial Data for Two Projects

Time, N (in years)

Initial Investment, IV, in $ dollars

Interest Rate, Rate, in % percent

Cash Flow, CF, in $ dollars

Define Equations

Net Present Value, NPV, in $ dollars

Present Value, PV, in $ dollars

Coefficient of Variation, CV

Return On Investment, ROI

Compare Results for the Two Projects

Results for project A

Results for project B

Plot of Projects Over a Span of Rates

Discussion

The plot of NPV vs. Rate shows that if the Rate is zero, the NPV for both projects are the same. The plot also shows that the hurdle rate must be set much lower for Project A to be approved by a firm’s finance team in comparison to project B (looking at NPV equal to zero in the graph). Yet project B is not a likely outcome either because the sales forecasts aren’t realistic. Therefore the features and benefits of project A could be re-evaluated such that estimated sales over time increases enough to outweigh the initial lag in projected sales – to make up for the time-cost of money burden.

ROI Example: Evaluating an Infrastructure Project

I like this example even though it is far from embedded device projects. It provides a solution to the comparison between project choices that go beyond just simple cash flow. It points out that the process of getting to an ROI number can be more important to the success of some projects than the number itself.
Beyond ROI … Justifying a Business Intelligence Initiative, Digital Review Magazine, January 2004, Thomas Groh

ROI Example: The Original Design Manufacturer

An ODM is a good reference point for engineers and executives alike in the embedded systems industry. An ODM is a design to manufacture house, often located in Taiwan, People’s Republic of China (PRC), or Singapore. These companies work with their local silicon vendors and other regional suppliers to keep themselves informed of what tools, application frameworks, middleware, and silicon that may work together for various projects they are considering. To be clear, these local component vendors are integral partners for the ODM – right where the parts are often made. The ODM then has many advantages with respect to cash flow and its associate time-cost of money: lowest possible cost for parts, improved supply chain advantage without the need to pre-purchase in bulk, lower cost of knowledge, and cheaper labor costs. The ODM also focuses on the engineering effort rather than the marketing, brand recognition, and product sales efforts that their OEM (original equipment manufacturer) clients face. The goal of the ODM is to design cool stuff and manufacture all or part of the final product for its OEM client.

Figure 2: Sample Financial Spreadsheet

In Figure 2 above, I show a sample spreadsheet that would be a typical tool used by an ODM and its OEM client. How much should an ODM project cost? Take a look at the bottom line. For this project, the ODM figures on a shared IRR of 43% over an 8 year time line (only 5 of the 8 years are shown in Figure 2) using this set of numbers. A rate of return higher than most any hurdle rate. As a result, the OEM client may find funding this project to be attractive (remember that the OEM will have to factor in brand, marketing, and sales costs). The 8-year time line in this example may be too long for some projects. You can download a working copy of this cash-flow spreadsheet or their task-based budget spreadsheet from Bird Foundation’s web site and use any time-line you like for your next project.

Take a look at lines D, for development expenses, and C, for capital expenses. These two lines are where the operating system, development tool, and component vendors live. The cost of engineering and project management charged by the ODM lives here too.

The Bird Foundation
It is interesting to take note of the software tools and operating system choices available to the ODM. These are some of the only components that are not designed and built in or near the ODM’s location. Does Microsoft Windows CE make a better choice, or Wind River’s VxWorks, or should an embedded Linux version be the bases for development tools on this project? Well it all depends. Flexing the financial estimates for these two lines D and C are often a point of significant debate for a sales team or a roll-your-own internal engineering team. In this case, startup and recurring costs are important. Time to market is another point of consideration – here again the time-cost of your firm’s monetary assets will come into play. I invite sales and engineering teams to study the other numbers on this sample spreadsheet and envision how their product or service value might affect the final calculation of IRR. There can be further discussion on the effect of each financial component with respect to your position – there is likely no single right or wrong answer. One ROI strategy for embedded components and tools software vendors is to consider building more relationships with an ODM’s trusted local hardware component suppliers.

So where can you get more information on this spreadsheet? The answer can be found with the Bird Foundation. A grant giving organization that focuses on building engineering relationships between Israeli companies and OEM companies in United States – who in-turn may include an ODM partner. The spreadsheet example in Figure 2 comes right out of their guidelines for financial and project management (see Proposal Preparation Guidelines page 28). I invite you to learn more about this foundation, how it may work in developing technical partnerships with international companies you can leverage; and their great guidelines offered on the Bird foundation web site. Indeed this is a great example of using ROI as an ethical framework between partner companies from a global perspective.

References

This section under construction as of 12/8/07

Internal Rate of Return

Perils of the Internal Rate of Return

http://hspm.sph.sc.edu/COURSES/ECON/invest/invest.html

Text Books

Financial Management: Principles and Practice
by Timothy J. Gallagher and Joseph D. Andrew, Jr.
Copyright 1997 by prentice-Hall, Inc.

Research Papers

Return on Investment Analysis for E-business Projects
by Dr. Mark Jeffery, Northwestern University

The old reference section below

An overview of ROI from a sales and marketing perspective – a rich alternative perspective from the financial content on this blog post:
Customer Centric Thinking and ROI (turn your speakers on)

The Bird Foundation project guidelines, and project spreadsheets, can be reviewed and downloaded from here:
www.birdf.com/Index.asp?ArticleID=57&CategoryID=77&Page=1

A great Windows calculator (see Figure 3 below) for most of your engineering and financial needs can be downloaded from here:
www.hp41.org/LibView.cfm?Command=View&ItemID=458

The original HP financial support software module works within this simulated HP41 programmable calculator and can also be downloaded from the same site, here:
www.hp41.org/LibView.cfm?Command=View&ItemID=3

The original HP How To manual for financial decision making can be downloaded or read from this the site as well, from here:
www.hp41.org/LibView.cfm?Command=View&ItemID=445

Figure 3: The HP41 Calculator Emulated on a Windows Desktop

Next steps…

I invite you to use this blog post’s comment facility to share your experience as an engineer, innovator, sales manager, marketer, or executive. Do you think a financial vocabulary can be used to build an effective (and ethical) balance for your team between consensus and innovation?

Technorati Tags: Ron Fredericks, Engineer, project, requirements, executive, invest, budget, financial management, Return On Investment, Six Sigma, CMMI, Dr. Thomas J. Buckholtz, cash flow, Net Present Value, Internal Rate of Return, Hurdle Rate, NPV, coefficient of variation, standard deviation, mean, embedded device, Thomas Groh, Original Design Manufacturer, ODM, embedded systems, tools, application framework, middleware, silicon, OEM, original equipment manufacturer, IRR, hurdle rate, Windows CE, VxWorks, embedded Linux, development tools, Bird Foundation, project management, ROI, marketing, team, consensus, innovation, Ethics, Business, United States, Israel, China, Singapore

Figure 1: HPP-16K Emulator Connected to HP-41 Calculator

Photo by Ron Fredericks using Canon EOS-10D 34mm fluorite lens, UV Filter, 1.5s & f/22 @ ISO 100, on tripod, from Embedded Components’ HP lab collection.

Business Development using EPROM

The HHP-16K represents, a stepping-stone from source code to mass marketing through the use of HP’s commercial software development tools and it’s professional services team. Advertisement and promotion of HP’s professional services to productize HP ROM modules from EPROMs could be found within HP’s own software development tools, and in newsletters — newsletters published by HP and by independent self-assembling developer communities such as national and international versions of the HP Computing Club or HPCC.org. HP’s fee for this service was not trivial, often HP computer clubs would collect donations from 100′s or 1000′s of their members to raise the $20,000 to $60,000 (in 1980′s dollars) to produce these ROM modules for their members – all before the Internet.

This emulator is an example of an important design pattern for modern day software developers forming into ecosystems around mass marketed smart consumer devices!

A typical consumer device in today’s market often has gigabytes of flash memory or other extensions via cellular networks, enterprise networks, or WI-FI Internet access, that behave just like this old 16 kilobyte emulator. With this design pattern – developers can improve the consumer’s experience on popular devices by adding new software applications, middleware, content, and development tools. While at the same time, developers gain significant new business development opportunities for themselves, content providers, software tools vendors, professional services teams, and device manufacturers alike.

Although this emulator is an old technology, circa 1981, the EPROM chips, development tools, and HP-41 calculator itself are still in use by many collectors and developers alike. I decided to write about this particular unit because documentation is not readily available – making this project an interesting reverse engineering challenge for me. But I am also writing this post to unravel the mystery behind the business case for the HHP-16K. Only by resurrecting the engineering steps to use this device can we be certain that we have understood its business impact on software tool vendors, consumer device manufactures, and third-party software developers. Read on to learn, with me, how to use this device, and uncover the historical documents related to this device. Then perhaps we can extend this example from a reusable embedded engineering method to fresh reusable ideas for building business relationships with today’s software, tools, and mass marketed smart consumer devices.

I will continue to update this post until I am satisfied others can use it to build their own programs for their HP-41 using this unit. Only then can I be satisfied that I have fully documented how to use this unit and appreciate its impact in the marketplace – historically and as a future design pattern for others. This paragraph will be erased at that time.

“Kelly McClellan, Jim De Arras and other users reverse-engineered the [HP-41] Nut processor bus and instruction set [PPCV6N6P4][PPCV7N3P20], and built EPROM boxes and MLDL (RAM) devices in order to run their own microcode.”
Link to this article…

This unit appears to be the work of Mr. De Arras, since the printed circuit board has the following title:

41C EPROM Interface Copyright 1981 by J DE ARRAS REV C

The unit was manufactured by:

F.M. Weaver Associates
Hand Held Products Div.
6201 Fair Valley Drive
Charlotte, NC 28211
USA

Overview of EPROM Emulation

There are over 100 HP software solutions and community software built onto ROM modules listed on popular HP-41 web sites that can be stored on EPROM. HP authorized their reuse in emulators several years ago. In addition user code and assembly language code can be compiled and linked for deployment on EPROMs as well using freely available open-source tools.

The idea is to burn EPROMs following the M-Code 10-bit word format used by the HP-41 series calculators. I have not found the original documents for the HHP-16K unit but there are a few online resources to help guide a current-day embedded engineer tracing the footsteps of the past and current HP 41 developers.

Figure 2: HPP-16K Main Circuit Board

The figure above shows the top view of the circuit board: note the two DIP switches (I still need info on these) and three EPROM sockets.

Click here to see the bottom view (inverted so it can be overlaid with the top view).

ROM Memory Requirements

There are a few articles on burning EPROMs for the HP41. The table below was extracted from one such article titled: “Creation of EPROMs for EPROM readers”. Link to this article (in French)…

The lower 8 bits would use the two larger EPROM sockets and the upper 2 bits would use the smaller EPROM socket.

In the table above, U2 and L8 refer to the EPROM sockets on the circuit board – see the figure above.

Use the table above to define the HP41 I/O Ports required to access programs stored in ROM. See figure below for location of I/O ports on the back of the HP41 device. Typical HP-41 ROM modules are shown to the right of the calculator, while the electrical contacts can be seen within the other empty port bays.

Figure 3: HP-41 I/O Ports (back view)

HHP-16K Emulator Hardware Discussion

Figure 4: HPP-16K Interface Circuit Board

The figure above shows the interface from the HHP-16K device to the HP41 calculator ROM bay.

In this section I discuss the HP-41 calculator I/O ROM port in detail. Much of this information comes from HP’s internal documentation – specifically the “HP-41C/CV/CX Alphanumeric Programmable Scientific Calculator Service Manual” record number 00041-90472, printed 1983. You can read this and other HP internal documents on the HP-41 from Warren Furlow’s site here.

Input / Output Ports
The four I/O ports on the HP-41 allow the user to expand the calculator’s capacity and to have it interact with external components (like the HHP-16K Emulator). Electrical contact is provided by a flexible printed-circuit strip mounted on the contact frame. The system lines which are accessible at the I/O ports are defined below.
VBAT	Battery voltage: Four 1.5 volt N size batteries.
VCC	System voltage: While the display is active (RUN and STANDBY power modes), the system voltage is regulated at 6V (at VCC). When the display is inactive (SLEEP power mode), the voltage output is unregulated and set to 1V less than the battery voltage.
GND	Ground
DATA	Data timing line: 56 bits of data make up one data word, with data represented as BCD (Binary Coded Decimal) numbers. Instructions and addresses are represented as binary numbers. The timing of the system is referenced to the Ø2 signal from the CPU. A bit time (the period during which a single bit of data is transferred) is the time interval between the trailing edges of two successive Ø2 pulses. A word time consists of 56 bit times (0 to 55) and is the basic interval for information transfer.
ISA	Instruction/Address line
Ø1	Timing lines with a system operating frequency between 343 and 378 kHz. Ø1 pulses lead the Ø2 pulses by approx. 3/8′th period.
Ø2
SYNC	Timing/Information line: The SYNC signal, consisting of a 10 bit pulse during bit times 44 through 53, has two main functions. The first SYNC pulse generated during power-up is used to initialize the timing circuit of the system IC’s. Subsequently, the presence or absence of the SYNC pulse indicates whether information on the ISA line is an instruction or and address. The SYNC pulse is suppressed when the system is controlled by a plug-in accessory. Additionally, when the CPU timing circuit is disabled (STANDBY and SLEEP modes), the CPU sets the SYNC line equal to the DPWO signal from the display driver for access at the input/output ports.
F1	Input flag line
PWO	Power on/off line
B3	ROM port identification lines: The B3 and B4 lines from each of the four ports are wired differently at each port so that each plug-in accessory will have a unique identification code. I/O Port Location I/O Port Number B3 Contact B4 Contact Upper Left 1 Open Open Upper Right 2 Vcc Open Upper Left 3 Open Vcc
Lower Right		4	Vcc	Vcc

The CPU checks status of the system and the I/O ports by setting the PWO line high at bit time 54to enable the ROM. The CPU carries out specified operations by executing a series of instructions contained in ROM. The CPU obtains each instruction from ROM by transmitting the 16-bit address of the instructions over the ISA line during bit times 14 through 29. The ROM containing the address transmits the contents of that location over the ISA line during bit times 44 through 53.

HHP-16K Hardware Bring-up

Upon initial inspection, the HHP-16K device and ROM interface have likely been opened many times. So before risking potential damage to a HP-41 calculator and to insure best chance of success in my first use of this device I use a Digital Multimeter (DMM) to trace continuity and measure DC voltage levels at the Vss (ground) and Vdd (DC supply) pins of the various logic chips.

Figure 5: Reverse Engineer the HHP-16K Interface Circuit

Larger view in separate window

Start with the ROM interface that plugs into one of the four HP-41 I/O ports. In this way we can insure that the small circuit board inside the interface is oriented correctly with respect to Vdd and Ground when we plug it in and turn on the calculator.

Note the DMM reading is in megohms (less accurate readings) and not in just ohms (more accurate readings). The reason for choosing the high ohm scale is that the voltage across the probes is much less: 1 volt across probe tips on megohm scale vs. 6 volts on the ohm scale. The lower voltage insures no risk of damage to parts during resistance/continuity measurements.

Figure 6: Check DC Voltage on HHP-16K Main Circuit Board

Second, proceed with DC voltage test of power rails by putting the HPP41-16K Emulator into a calculator ROM bay. Apply power to the unit by turning on the calculator. Measure the 6 volts from Vdd to ground on the logic chips located on the main board. The various chips on-board are all CMOS logic packages manufactured by Motorola. Pin-outs and logic details are easily found from online datasheets by searching on easy to read part numbers.

Third, confirm our findings and test the dynamic behavior of the interface using a logic analyzer. I have a HP 1631D that will do the job very nicely. Note how similar my captured waveforms are to the HP service manual’s waveform diagram for the calculator’s I/O port (see above):

• The SYNC line is inverted since the interface buffers it with only one hex inverter/buffer from the MC14049 CMOS chip.
• The x-to-o cursor measurement was done at 4X magnification. The period as seen on the display is 2.8 microseconds, or 357 kHz – well within the reported frequency range discussed above for Ø1 (PHI 1 label) and Ø2 (PHI 2 label) timing lines.
• The HHP-16K interface includes logic to multiplex ISA signals to and from the main circuit board. The ISA I (or ISA Input) line shows the address and instruction data while executing a “Catalog 3″ operation – so the signals shown were captured while the calculator was accessing onboard ROM. ISA O (or ISA Output) is held low since the EPROM chips have not been programmed yet and therefore offer no function headers to support the Catalog operation.

Figure 7: Capture an HHP-16K Waveform Diagram

Larger view of test bench setup in a seperate window

EPROM Configuration Logic

The HP-41 ROM space uses a 10-bit word size. To store the ROM words in standard EPROMs (8-bit bytes), the HHP-16K uses separate EPROMs for the lower eight bits (L8) and upper two bits (U2). To conserve space the onboard logic translates the upper two bits of four consecutive 10-bit ROM words into one 8-bit byte on the U2 EPROM.

Burn EPROMs

There are three different starting points to this step depending on where the source code resides. We could start with user code (high level source code), microcode (assembly code), or a previously built ROM module already in use on HP-41 calculators (binary code). I will focus on the use of previously built ROMs as there are so many license-free and available for use on an HP-41 calculator emulator. The HP-41 calculator emulator is available for Windows, Linux, Palm, and Pocket-PC platforms. It’s a great way to gain access to all the software stored in emulated ROM modules.

Also, the emulated ROM module, saved as a binary file, is the end point for the other two forms of code since source or assembler code will ultimately need to be located to a ROM address and built into a binary footprint suitable for placement onto ROM modules or EPROMs as is the case here.

Two types of ROM module are of interest to me:

• The first use case is a ROM module I already have. In this case I can compare function access with test cases on the real device and on the emulated ROM using the HHP-16K EPROM Emulator.
• The second use case would be to use ROM images that cannot be simulated on a virtual HP-41 Emulator. These ROMs would include the HP Service Diagnostic ROM, an HP-IL network diagnostic ROM, or a support ROM for communication services like the ZENROM that are rare finds (and expensive) to buy for a HP-41 calculator.

MOD File Format
Go to Warren Furlow’s web site and download a selected ROM module: Stat Pac

Extracting the zip file’s contents leaves one file named STAT.MOD. The .mod file format is a custom binary image file format created by Warren Furlow as a way to extract the contents of physical HP ROM modules for reuse in his great HP-41 emulator.

ROM File Format
Convert the STAT.MODfile into a binary image consisting of two 8-bit bytes for each 10-bit HP-calculator word using Warren Furlow’s MODFile.exe program. Get this MS-DOS or Windows program as a free download.

The result is a new file STAT.ROMand a text file STAT.TXT. The .ROM image is now in a binary form that EPROM burners can use. But the format is still not suitable for our HHP-16K as the upper 2 bits of the 10-bit word are stored in an 8-bit byte (the upper 6 bits wasted) format. The .TXT file is useful as a way to insure that the ROM module will work in our HHP-16K unit.

Listing 1: STAT-I HP ROM Module Structure

Note that the flag for RAM is set to No (line 26 in listing 1 above). Some HP-41 ROM modules include RAM for special operations. If RAM is being used, our simple HHP-16K EPROM Emulator will fail unless we modify either the source code or the EPROM Emulator. Also note that the ROM page and position fields show that our EPROM Emulator can support this module interfaced to any HP-41 ROM bay.

STAT.41L and STAT.41U File Formats
Now we can use our STAT.ROM file as an input to a utility bundled with HP’s own Software Development System (SDS-II, released in 1986) for MS-DOS computers called IGHLOW.EXE. The HIGHLOW.EXE program expects the .ROM image to have a file name ending with .41R. So I make a copy of STAT.ROM and save it with the new name STAT.41R. This is the only bridge needed between Warren Furlow’s after-market software emulator tools and HP’s original SDS-II software tools. Neat. The HIGHLOW.EXE program converts the two 8-bit bytes of the HP-41 executable code into 8-bit bytes for lower 8-bits of the HP41 word and 4 packed 2-bit chunks for the upper 2 bits of the HP41 10-bit word. The SDS-II document points out that this is the format we need for Hand-Held Products EPROM Emulators.

Now we have two files suitable for our EPROM Burner:

• STAT.41L for 1/2 of one of our two 2764K EPROMs
• STAT.41U for 1/4 of the 2732K EPROM

(Remember I am using these chips because I have them on hand, so I will leave the remainder of EPROM memory filled with 0xFF values just as the UV erase lamp left them.)

Listing 2: STAT-I HP ROM Module Software Files

I use a Needhan Electronic’s EPROM burner and MS-DOS tools to massage ROM coded files and burn EPROMs. Because the interface requires a Centronics printer port, I use an Ampro Pentium II board with CIFS/SMB Ethernet connected to my main computer to drive the burner. I use a Walling Co. UV lamp assembly for erasing code previously stored in EPROM chips. Needham has a chip selector search engine online for their burners here.

Figure 8: EPROM Needham Burner and Walling UV Lamp

Using Programs Loaded in HHP-16K

tbd…

HHP-16K in the Marketplace

The Canadian Infantry used the HP-41CV and HHP-16K as part of their mortar firing training course.

Figure 9: Canadian Infantry HHP-16K Mortar Firing Training Application

In the figure above, the HHP-16K is located in the lower left.

The entire document titled “LAND FORCE INFANTRY INSTRUMENTS FOR CALCULATING MORTAR FIRING DATA” is online here.

The document discusses a few user tricks with the HHP-16K, such as how to determine key assignments associated with functions loaded on the HHP’s 3 EPROMs – page 16 (page 28 of 259 in the PDF).

Next steps…

I invite others to post their comments, online links, or other suggestions, so we can ALL continue to learn more about this device, the software it supported, and the business development model it represents today!

Technorati Tags: Ron Fredericks, Community, Software, Engineering, Projects, Embedded Device, Personal Programmable Calculator, The Museum of HP Calculators, Jim De Arras, EPROM, HHP-16K, Hand Held Products, Emulator, Compiler, Decompiler, HP-41, Logic Analyzer, DMM

• 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

Ron Fredericks writes: I envision the day when community software engineering projects are commonplace for embedded devices. Like the PPC ROM demonstrated back in 1981.

What follows is a review of the PPC ROM community development project – a first for smart mobile devices, then an offer to help others in moving this great body of open source professional tools to modern devices: comment on this post if you are interested in this project or in community development of software for embedded devices in general.

Wouldn’t it be nice to have powerful new applications built on top of our routers, digital recorders, HDTV‘s; or even industrial process monitor and control systems, or lab instruments; hey how about our cars and public transport vehicles? No I don’t mean that you buy a new device or car with new applications pre-loaded by the device manufacturer and shipped with the soon to be obsolete device – I mean groups of experts organizing into communities with other experts to design, develop, test, document, package, and deliver new software solutions onto devices for their own members’ sales channels. Does this sound far fetched?

Community development around open-source software such as Java, the Linux operating system, or Mozilla‘s Firefox web browser have emerged as reusable project management solutions to complex software engineering issues – See Asa Dotzler’s Job Morph: Herding Cats to see how Mozilla motivates workers who aren’t actually on the payroll.. So I know the engineering community is ready for a new challenge – one that has already been solved back in 1981 – one that affects the speed of technology reuse around the globe today.

Photo by Ron Fredericks using the same settings as the previous photo, of his favorite mobile smart device.

So let me share with you a project I recently discovered. It’s embodied in a user’s manual published in 1981 by a community of engineers – no, not your typical product manual ticked out on a company payroll. The forward describes a first-of-its-kind effort behind this user manual, and the embedded software it documents. The author expresses his excitement in being part of the “first community developer” project for a smart mobile computing device and it is so similar to the smart devices we use today! Did I mention that Linux, or even community networks like web and email didn’t exist back then? How did they do it? Can we learn from their effort and apply this community project, or its method, for today’s embedded devices? I think the answer is yes – with a little help from the embedded operating system suppliers’ communities and some innovative hardware device manufacturers. The embedded operating system, software community project management, and smart device platforms have come to a wonderful cross-road that truly supports community software development as a ripe low-hanging opportunity for us today.

The forward to this 500 page user manual describes the struggle and accomplishment of 100 developers who formed their own community project to develop a “ROM” or read-only memory module they called a “PPC ROM” that plugs into an HP personal computer that is now 25 years obsolete called an HP-41. The “PPC” reference is to the names – Personal Programmable Calculator, or Personal Programmer’s Club, or Prolific and Productive Computing – as well as the PPC Calculator Journal that was the herald for the HP calculator’s developer community back in the day. Similar to the commonplace e’zines we read, or get spammed with today. But different because the taxonomy created by today’s almost endless stream of eBlasts, tagged content, blogs, forums, and RSS feeds by themselves don’t create an engineers’ sense of community. The spontaneous motivation to organize into a sense of community requires a mood that has only been created by a real person – a person that shifts a group of developers’ paradigm .

Perhaps many of you remember Philippe Kahn, who created a cozy engineering mood with his Turbo Pascal and Turbo C compilers – these cheap little things that were killer apps that grew the base of available programmers for several years. Prior compilers for the early PC’s cost 10 times more. Within the HP-41 community there was William Wickes – a community engineering leader that helped to grow the base of programmable calculator developers that in-turn grew the base of engineering, scientific, financial, and many other professionals and students so commonly outsourced by the global community today. Mr. Wickes lead the discovery of a new programming technique for the HP-41 called synthetic programming. Like Philippe’s community contribution to the PC developer community, Bill was able to drive significant developer excitement into an otherwise limited calculator programming community.

The PPC ROM’s core management team wrote in the forward to PPC ROM user’s manual…

“This project is unique in the history of software projects. IBM and other large corporations have assigned multi-tens of programmers to a software project, but never before have over 100 programmers worked so long and so hard on a project — without compensation of any kind. The PPC ROM PROJECT is a community project in the true sense of the word….It took two years and two months to complete…”

The forward then goes on to discuss the challenges of working with a personal computer that had so little memory and other constrained hardware issues – very similar to developing the content and applications in demand on mobile smart devices today! Their solution, why they did it, how they managed to stay together to finish it, and how they partnered with HP to build, and package the ROM Module itself is also described.

To be clear, the PPC ROM wasn’t a one-off, there were other community projects that replicated this first success with the creation of the ZENROM, HEPAX, and other plug-in modules for the HP-41 too. I get the impression that today’s embedded community could succeed in the creation and deployment of software onto aftermarket embedded devices by following the same process pioneered by the developers of the PPC ROM:

• Select a product mix with applications, tools, middleware, entertainment, and educational content that is attractive to end users but also encourages component reuse by more developers who in turn then create even more attractive reusable solutions.
• Select a project management model similar to other recent and very successful “cat herding” open-source web community efforts. The new social network communities frequented by developers make the PPC ROM story much easier to duplicate.
• Select a hardware platform vendor willing to facilitate software packaging, delivery, execution, and reuse methods such as over-the-air, network download, or even a group-published flash chip.
• Harness the power of a community manager. The likes of PPC ROM’s synthetic programming allure created by William Wickes, Linux’s Linus Torvald, and Mozilla’s Asa Dotzler are some of the more famous examples of community managers for engineering development.

Now that is just what I am proposing. Let’s revisit this community development effort by moving the freely available HP-41 applications to an emulator that can run on common mobile devices easily available in today’s community. First step might be to see how the existing HP-41 emulators works on your favorite device with the hope that all the engineering, scientific, financial and other professional applications can be downloaded and used too. More on this effort and community software development will follow…

References to the excellent HP-41 emulator work and open-source site by Warren Furlow and others…

You can download a Windows PC/Linux/Windows Mobile/PalmOS emulator of the HP-41 personal computer, add your own programs to it, and load the actual PPC-ROM module’s binary image [as well as 50 or more other professional solution packs and ROMs] and use this great little personal computer along with these PPC ROM applications as a perfect replacement for that dumb little Windows calculator:
www.hp41.org/Emulation.cfm

Oops, where’s the Java version?

You can get your own copy of the historically significant PPC ROM user’s manual from here:
www.hp41.org/LibView.cfm?Command=Image&FileID=23037

Add the PPC ROM code to your new HP emulated calculator from here:
www.hp41.org/LibView.cfm?Command=View&ItemID=20

Here are some other ROM code modules that work with your new emulator!

• Aviation
• Circuit Analysis
• Clinical Lab and Nuclear Medicine
• Financial Decisions
• Games
• Home Management
• Machine Design
• Math
• Navigation
• Petroleum Fluids
• Real Estate
• Securities
• Standard Applications
• Statistics
• Stress Analysis
• Structural Analysis
• Surveying
• Thermal & Transport Science

Technorati Tags: Ron Fredericks, community, software, engineering, projects, embedded device, router, digital recorder, HDTV, industrial, instrument, car, vehicle, open-source, Java, Linux, Mozilla, Firefox, project management, community developer, PPC ROM, Personal Programmable Calculator, Personal Programmer’s Club, Prolific and Productive Computing, PPC Calculator Journal, Philippe Kahn, constrained hardware, ZENROM, HEPAX, component, community manager, William Wickes, Linus Torvald, Asa Dotzler, Warren Furlow