Comments on PE Micro's Cyclone Pro for 6808/6812?

After several intsruments built with the 6805, I'm looking to upgrade to a more modern processor with more code space and RAM, as well as more modern debugging schemes. The 6808 series seems to fit the bill, specifically the GP32 chip.

One of my biggest hangups about the 6805 is the ancient and poorly supported debugging/emulator tools (I use the Cosmic compiler which I DO like). After my emulator apparently died, I'm hesitant to put in more money toward the 6805 tools.

The Cyclone Pro product from PE Micro looks like a very useful tool.

formatting link

Is it reliable? Is the interface software stable and reliable for both programming the flash and remote debugging through a MON08 port? How's the support from PE Micro? Does the MON08 debugging capability provide enough info to be useful during the first stages of product development and bypass the need for an emulator?

Your input appreciated.

Also, a technical question: the datasheet for the 908GP32 seems to indicate that it is not possible to use a 4 MHz crystal for the clock such as is possible with the 705C9A. One must either use a 32.768 kHz crystal and the PLL feature to synthesize the clock (and implement the external filter), or use a CMOS level oscillator? Is this correct?

--
Michael McCulloch
Reply to
Michael McCulloch
Loading thread data ...

Motorola, err Freescale Semiconductor has a CD-ROM tutorial that uses that particular chip as a reference. The CD in question is CDV110CT (Rev1) - "68HC08 8-bit FLASH Microcontroller" which can be ordered gratis via phone at 1-800-441-2447 or via the net at Motorola.com.

Gary Schnabl

Reply to
Gary Schnabl

Michael,

Although I have not used the CyclonePro, I have used used P&E's MON08-Multilink and others. A few years back I did a GP32 based project. Overall I was pretty happy with the tools, especially Metrowerks' CodeWarrior environment. But I found debugging via the MON08 interface and it's built in ROM to be pretty painfully slow. While debugging it will not step as fast as you press F10, often you wait 2 to 6 seconds between every step. I can't say how much of that is program overhead and how much is MON08, but my work with the HC08QY4 makes me want to point at the MON08 architecture: Slow serial link & on-board debug ROM code. Also, I found reliability to be only fair. The serial interface would often time out, and there are many things that simply can't be debugged with scheme, e.g. stepping through processor speed changes on a QY4.

Moving forward I would be sure to look at what Motorola adds to their HCS08 line. The HCS08 family has been a total pleasure to work with. They have added the Background Debug technology from the HC12 family, and it has been very reliable for me and much faster. It doesn't consume on chip resources like serial ports and other I/O lines to implement. Of course currently they only offer a small variety of MCU's in the family. Hopefully they will add more at the lower end.

BTW, when working with the QY4, I had a real problem getting P&E's Prog08z to run under Windows XP, until I tried boosting the privledge level of the app. Although it was still not perfecty stable, it worked well enough to use. I made a little batch file to start from an icon:

start /AboveNormal C:\Progra~1\pemicro\pkg08sz\prog08sz.exe

About P&E support, I found it to vary between sometimes poor to mostly okay, but then I am not a big company buying tons of hardware from them, you might have better luck.

About the clock on the GP32, my memory is really fuzzy on this, but I seem to recall having to use an external 4.9152MHz osc if I wanted to be able to reprogram the MCU in-circuit via the MON08 interface. I could be wrong here, but I think that was the only option.

Rich

Reply to
Rich

I'm happy with the Cosmic compiler for the HC05 and HC11 and will most likely use it for the HC08. A wait of 2 seconds doesn't sound intolerable (my serial interfaced HC05 emulator is not much faster than that), but 6 seconds would be quite frustrating.

I rarely use the emulator after the first few builds. After that it is usually much more useful to be able to simply run new code builds at full speed for testing. To do this with the HC05 requires swapping/trashing OTP chips or waiting 30 minutes for a UV erase for a handful of $50 windowed parts. The flash capability of the HC08 alone is almost worth the switch.

The Cyclone Pro uses USB or ethernet comm options to the PC, so that should eliminate any comm bottleneck between the device and the PC. I'll have to inquire with PE Micro about the debugging response time and see if they echo your comments.

The serial interface between the computer and PE Micro device would time out? Again, I would hope the newer USB driver would be faster and more reliable.

As a point of reference, I have the Stingray debugger interface for my HC05 emulator that somehow succeeds in hanging up to the point that a reboot of Win2000/XP is required to clear it. Sometimes I have to cycle power on both the computer and emulator. Yuck. It can't get much worse than that.

The problem we have with the HCS08 is that we cannot currently manufacture SMD boards in-house and the only HCS08 part I see that offers through-hole is the MC9S08GT32B. But the SDIP package is not apparently stocked by distributors. We need to stick with a well-supplied and widely available variant of the HC08 since we buy small quantities. The HC08GP32 looks like the most stocked part in the family by distributors in both DIP and QFP packages.

What particular software/hardware do you use to interact with the BDM port on the HC12? The Cyclone Pro says it supports BDM on the HCS08 and HC12.

Hmm. After looking at the software they provide with the Cyclone Pro, it does look a bit arcane. Is there anyone that produces nice emulator and flash prog interface software? If so I haven't seen it... sigh.

We are a small company and won't be a high volume buyer. Your comment about poor support is a concern.

Thanks,

--
Michael McCulloch
Reply to
Michael McCulloch

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.