What would you like to see improved on the SPBs?
I am the Marketing Manager that is responsible for the development of new SPBs.
Verify Hardware: Add a few more spots where you make sure we are with you before continuing. For example, when filling in the first part of the Project Generator, you provide information on the title, project name, toolchain and application all together. Also, make sure the YR8CSPB (for example) is highlighted in blue in the video. Right now you do not see it that well so people miss it.
Verify Hardware: When you start this activity, you should check to see if you can communicate with the kit. If the monitor is installed, they are re-running this activity and it will not work correctly. In that case, the activity center should reload the factory software at the beginning before you ask if the LEDs are flashing.
Linux host support :-)
Seconded :-)
third ! :-)
or at least, post the low level programming model/spec such that linux gurus out there can cook one.
1) Post some user guide / programming guide on the web, (to attract
) people can take a look before buying.
(by the way, it this the same board as the HTS demo kit?)
2) (I do not have the cd-rom of the SPB, so I am not sure if this is done already.) Have a HEW function to communicate with the M16C thru E8 thru the spi/uart, instead of just "memory get".
1. Take a look here to see more on the SPB.
2. Not sure I understand this comment. We do communicate to the target through the E8 (the E8 circuitry is cut down and placed on the top of the board). AND that E8 communicates to the target SPI peripheral (or UART on the H8 device).
3. These are not the same as the HTS contest kits and those kits will not work with the SPB software. (They do look identical, but they are not.)
Todd
1. I did. Only the white paper is more "solid" information to me. but not enough. Personally, I would like to see a user guide to have a more solid idea of what is on board.
2. Imagine developing an data monitoring prototype. Currently host can only examine the acquired data thru "memory monitor" thru the E8 debugging capability (which i am not sure if it will interrupt code execution.) Cannot continuously receive data thru spi, although the link is there, and M16C code can sent it out.
3. Too bad. :-(
best wishes.
(by the way, do you prefer reply by email or posting next time for similar kind of reply/response?)
1. Turn off Auto Updater when we first install it. Or, set it for 30 days from now or longer.
2. Make an activity to Turn on AutoUpdater. Explain what it does and the fact that you may get some new messages "New Firmware". Update
3. Make an activity to automatically (function) called Factory Default. When they user clicks on this we reprogram the SPB into the factory default configuration.
2. I think laich2 is looking for some kind of stdio simulation, where the application can use printf to send messages to a window in HEW.
Exactly. There should be an easy method of communicating with the running application from PC. The easiest way is to provide a virtual com port on the USB interface used for E8 equivalent and to allow the application to use UART 1 on MODE pin for bidirectional communication. This of course would require releasing the hidden details of UART1 operation to public. Less revolutionary approach would be to provide regular UART connection using two pins to the "E8" chip and present the "emulator" to PC as ordinary E8 plus VCOM - this is the approach taken by Luminary and TI in their design tools - single USB cable connection with two logical devices - emulator/Jtag device plus virtual com port.
How about Vista64 support?
I have had to dig out an old computer just to use it.
©2003–2010 Renesas Technology Corp. All rights reserved. Using Our Website | Privacy
Contact us