Some background

I've been working with the Zilog eZ80F91 for four years now, and I'm a senior developer with 15 years of experience.
My experience includes writing complete network stacks, operating systems and large-scale embedded systems with hundreds of devices cooperating.

During my professional (and personal) career, I've never come across anything with this many problems.

Here follows a wall-o-rant I want to clarify that this is only a small subset of the problems we've had and have with Zilog, specifically developing for the eZ80F91. Disregard everything for any other product as it does not apply (entirely).


Network stack
Works fine (although very poorly optimized) until you start doing anything above the basics such as several multi-threaded servers and clients on several different protocols. I'd deem it very unstable. If you like history, there is some nice (read: laughable) information to find on the origins of this stack, and how/for what purpose it was originally developed...

Compiler
Completely untrustworthy. I've lost count on how many times the compiler has generated incorrect code, become unstable (compiling differently for same code at different times) or misunderstanding simple operations resulting in execution times in the factor of hundreds of times what is necessary. This has cost us more than I'd dare to contemplate on...

Compiler optimizations
Completely breaks every single larger project and has to be turned off at all times. Okay, it's better in the later versions I'll admit. Still ways to go though.

Compilation choices
What are the developers doing here? It seems they've missed half of the tricks in the book (the one written in the early '80s that is...) Thankfully they did choose to implement some of the things i pointed out which has sped up code significantly. Although the new compiler bugs had me jump back to an earlier version since there, they are at least predictable (in most cases).

Updates
They come way too seldom, and usually contains more new bugs than old ones are fixed. I am stuck using ZDS II 4.11 because of several bugs that make the newer versions not just unbearable but economically unfeasible.

Breakpoint management
Less than five minutes after downloading some test code onto the Zilog Development Board, using the Zilog UsbSmartCable, running Zilog ZDS II 5.1 it was clear that something was broken here. Breaks often occur at the wrong address rendering debugging useless for me. This was not so before... five minutes... how is this possible to miss?

Support
First line support is what it is, I understand. But seriously, rarely anything leads to anything even when it's legit. No following up on old issues. I have a three year old ticket, with several reminders regarding spice files. Still no answer.

Hardware
The eZ80F91 (amongst others) have a very nice debugging interface using JTAG. There is no product to interface it except the FS2, which is no longer in development and doesn't work very well at all today. Seriously, step up and renew your programming equipment to let your customers take the leap into the '90's, we're tired of disco.

Partners
Zilog seems to have had a "falling out with" every partner they've had, that I've talked to. CMX and the original FS2 developers are good examples. They all had good products that raised Zilog products to far above what they are now, what happened?

UI bugs
The development environment is faulty in several places and has been since I started using it. One favourite example is when trying to dump a memory range to a binary file. Lots of odd stuff going on in that dialog.

Watching C extern's declared in assembly
Forget it.

Any kind of modern watch functionality like basic (by today's standards) syntax parsing
Forget it.

Memory watch for variable pointers
Forget it.

Timeouts
The IDE often goes nuts trying to download huge amounts of memory because of things such as an asciz watch or similar.
Requires you either to unplug the programmer or in some cases forcibly killing the IDE. And speaking of time, how is it possible that every programmer operation takes such a long time? I've benchmarked some custom solutions reaching speeds FAR above what's possible with original equipment...

Compile time
Not sure what's wrong here, but the compiler takes nearly the same time compiling on an 8-core 3.6Ghz computer with a 250MB/sec SSD and 12GB of DDR3 memory as it does on a single core 1.6Ghz box with 2GB slow RAM and a hard-drive that's hardly worth the materials it's made of... We are working with huge projects, not too happy about this. Smells like hard-coded delays.

Xtools USBSmartCable
Not so much a complaint, but they do break very easily. ESD is a bitch, but perhaps a few transorbers on the header would improve things, unless they'd muck up the edges too much. We've gone through nearly 10 programmers in the last few years, although we don't have much ESD security I'll admit so consider this for what it is.

Eclipse
It's where all of the smart vendors are going... Less work for you, a whole new world for your customers. Hey, I'm allowed to dream aren't I? But seriously, you are nowhere close to and will likely never be able to come close to what Eclipse can offer and after experimenting on my own I can surely say it wouldn't take that much of an effort. It is already possible to do all development (debugging aside) in Eclipse if you're willing to put the effort into configuring everything. Debugging support is key though.

eZ80F91
I like it. No big complaints. Very nice device. The architectural design choice of not being able to access the top 8 bits of any 24-bit register was not a good one, but there were probably (hopefully) reasons for it. The erratas pertaining to the RTC (glitches and power consumption) are the only big show-stoppers we've encountered.


In conclusion

I'm at the point today where I've had to write my own:

Operating system
Network stack
Flash download solution
Compilation verification (part c-parser, part diff. tool)
Eclipse integration
Watch expression parser
CPU emulator

All of this simply to be able to trust that our products will work, and that development runs smoothly and efficiently.
These are all things I would expect to work out of the box for any microprocessor and accompanying development environment.

Ah yes, a few other things regarding the assembler that sprung to mind when I read a few other posts on this forum:

Instruction replacement
It is absolutely NOT, I repeat NOT OK to replace an instruction such as
with

I'm not sure this is the exact case, but this does happen and it completely pisses people off when you are trying to (and think you are) writing efficient code, but it turns out you were using all the wrong registers. Programmers usually do not write assembly with a complete OP code reference at hand, today it is much more common to test compile and change if you code an illegal combination.

Macros for such things are great, LDBCDE would be appreciated as a predefined readability macro for such things.

I'll buy "Jump optimizations" - but only because it's an option.
Unless it already is, you should make sure it can be turned on and off using code directives.

Displacements

Since d is an 8-bit two's-complement displacement (according to the manual), the range should be -128...127, right? Although I haven't really hard-coded the instruction to see if the hardware supports it, the compiler fails to compile for x=-128. If nothing else, the manual needs to be updated for these instructions to specify that -128 is not allowed.

Yes, I did have a routine that was dependant on this particular value. Had to work around it.

Register validation
Several instructions where A is the only register allowed still allows compilation if A is replaced with another 8-bit register such as E, resulting in incorrect code without any warning. That is, it compiles as if the source had said A.

Thoughts
If you can't get something as simple as an assembler for your own processor right in the number of years that have passed since it was released, shouldn't you seriously start thinking about replacing the development team working on this?

I work at a pretty damn relaxed company, but if I had made mistakes like this they'd toss me head-first through the window!

How long would it take to write a simple test-case for your assembler and run it before each release? A day?
Compare that to the number of hours things like this will cost your customers and, in effect, the ill-will you are getting.

Cheers

Hello Davey
I appreciate your candor and we are listening. One of the purposes for the forum is to provide our customers a voice into Zilog. All of this is good information to help us improve our products, our customer relations and our core business. Not all of our business decisions will be popular but with comments from our customers, we can make the right decisions for the right reasons.
We do value your opinions, knowledge and experience and hope you will continue to share your expertise.

Tom

Davey,

By any chance, did you successfully moved over to Eclipse and have you documented the process?

Don

Depends on your definition of success. I can edit code and manage my projects and do basic compilation but have to revert to ZDS when I need to download code via the SmartCable, do configuration changes or make a release. Debugging is definetely not anywhere near functional.

There is no documentation at all, sorry.
The process has been mostly hack n' slash squeezed in whenever I get angry enough to set aside some time for it.

The first thing I always do when working on a project for the platform is write my own flash downloader. This decreases the time to download code by a factor of roughly 5 minutes to 10 seconds using either USB or Ethernet. The solutions are always platform specific but I can tell you that the work is ALWAYS worth it. This has been the single most useful change we've implemented in our development cycle. Attempts at moving to Eclipse are mostly ... recreational.