YM16CSPB Renesas Electronics America, YM16CSPB Datasheet - Page 7

• Manufacturer Part Number: YM16CSPB
• Description: DEMO PLATFORM M16C 20MHZ
• Manufacturer: Renesas Electronics America
• Type: MCUr

Specifications of YM16CSPB

• Contents: Demo Board
• Lead Free Status / RoHS Status: Contains lead / RoHS non-compliant
• For Use With/related Products: M16C Family
• Lead Free Status / RoHS Status: Not Compliant, Contains lead / RoHS non-compliant

When the compiler completes that operation, HTS detects this and reports the completion of the
build operation to the controlling Flash script. It responds by checking to see if a downloadable
“.X30” file was created. The existence of a “.X30” file verifies that the build was completed
without errors. If the compiler hasn’t produced such a file, then the Flash script asks the user to
go back and use the same procedure as before, to correct the errors in the code.
In summary, this interactive tutorial has been written in such a way that it can detect and respond
to a myriad of user and development tool stimuli, just as if the exercise had been monitored by an
application which guided the user through all the steps necessary to illustrate a successful
problem detection and solution process.
It is the “Request then Monitor” process that makes the flash script a truly interactive experience
and not just a standard instructional video. As with any scenario, some situations are outside the
scope of the HTS/HEW link. When this occurs, the issue is usually remedied using an application
called the “Interface Software,” which is written in Windows .NET. This application detects
when a window has opened, a .X30 File exists, or the SBP USB Driver is active. All of these
events are reported in status variables back to the Flash Program, which controls the instruction
based upon the variables.
The end result is that four software packages work together to enable this interactive
environment: HEW, HTS, the Interface Software, and the flash tutorial. Obviously, therefore, in
the context for the SPB, the term “interactive” designates a process — a capability — that’s
significantly more complex in the background, but much more effective in terms of the user
experience, than a simple video guide.
2.3 The “Bullet Proof” Demonstration Board with Intentionally Inserted Bugs
Of course, the effectiveness of interactivity would be limited or nil if the SPB demonstration
platform was in any way weak or faulty. Thus, users can be sure that a significant amount of time
was spent developing and testing the tutorial scripts to ensure they are as close to being “bullet-
proof” as possible.
Yet despite this fact, known bugs were inserted into to the code to implement an important part of
the instruction. Yes, the bullet-proof code has bugs in it! But are intentionally placed bugs truly
bugs at all? Bugs were placed intentionally in order to demonstrate the debugging process, an
important part of the learning process to understand the software and tools. They are the key
enablers of a capability, after all.
In developing the SPB, Renesas deliberately avoided producing a basic “Hello, World” type
canned tutorial. Instead the implementation lets the user play stereo “.wav” files from the target
board using simple instructions. The flexible design allows the user to change the sound files to
whatever they like. This capability for the tutorial and benchmarking software is enabled by the
resources built into the circuit board, such as 1Mbyte of SPI flash, an audio amplifier, a 2.5mm
stereo jack, a pushbutton switch, four LEDs, and a light sensor. These on-board peripherals give
the engineer various ways to exercise the MCU or MPU on the target board, so they can witness
the power of the tight coupling between the software and the hardware.
3. Installer Enhancements
SPB White Paper
Renesas Technology America
-7-