No, No! Tom is right. ez80f91 is not dead. The major thing that has happened to this MCU in the late few years is HACK-RTOS. It is the fastest and the smallest! It has a TCP/IP stack that can run days after days in any network environment. Well, it is simply the best! I happen to be the author, as you might have guessed. Seriously, I would never use ZTP again myself.

When you get it running 24/7/365, on a busy network with any manner of malformed packets, let me know. That requirement seems to elude most software stack providers. <Grin>

In other words, if you would send you product and stack on a critical un-manned Mars mission - something that is out of physical reach to hit the reset button for at least years, would you stand behind it? Obviously this applies to the stack itself, not the code the stack is running....I'll stand behind that part.

Tom Ormiston wrote:

ZMotion products have been released as well as the Z16FMC motor control part. We were able to get 16 new app notes out last year, most of them since August. We have a number of reference designs and app notes in process. One of our app notes came from the forum, a request for an SD card interface. That should be posted in the next couple of weeks. I am working to funnel all app note and reference design requests from the forum into the team to make them happen. We have released the ZDS II for the Acclaim 5.1 and we have the ZDSII for Encore 5.0 in beta, to be release here shortly. There are a few other activities going as well. I have found it is getting much louder here.


Is anyone tasked with fixing the web site ?
Fluff like Smiling market-droid faces, just starts to annoy, when I'm looking for information

Let's take some topical examples, from your post :

"We were able to get 16 new app notes out last year, most of them since August"

Great, now please show us how to use this website, to get a date sorted list of what' s new, showing those app notes ?
Simple things.

For the Z16FMC, please point us to the press release, giving price indications on this part ?

Why does the Z16FMC not appear under Products.Microcontrollers ? Is it not a microcontroller

John Anderson wrote:
When you get it running 24/7/365, on a busy network with any manner of malformed packets, let me know. That requirement seems to elude most software stack providers.
I find your lack of faith disturbing.

HACK-RTOS has several TCP/IP related examples. Namely - Example7 and Example8. To my knowledge, no-one has ever been able to break any of them (given the unfailing power source, of course). Though I deliberately encouraged them to do so by providing the Windows-based testing tool - TCP_Client.exe. So far no-one succeeded.

No no - not lack of faith in you. Its just that 100% reliability of a RTOS/ TCP stack on a very wild network environment is a very hard goal to achieve. Providers usually test stuff on the bench or with stress test software, but that's not the real world. It is really hard to estimate the "lack of competence" these things face in the wild.

I think my message was more in the spirit of what we're looking for: Where have you tested your system in different commercial environments, and on how many hundreds / thousands of units in the field?? Is it on its own switched port or sharing a single hubbed node with about 200 other machines? What happens when VLAN packets hit? What happens when users setup their Cisco "store and forward" system so that your stack suddenly gets hit with a huge amount of packets? What happens when your stack is hit with IPv6? Will it recover from a DOS attack? How many simultaneous users? Or a real favorite: What happens when end-users setup their SNMP monitoring to issue about 500 GET reqs all at once with some malformed packets mixed in?? What happens to interrupt latency when the RTOS / stack gets snowed under with IP traffic - ie what is the maximum interrupt / thread switch latency? And so on. These are types of things that are hard (or impossible) to test on your desktop with "stress test" software.

I went to your website and didn't see the FAQ page, or latency timing specs.

John Anderson wrote:
What happens when VLAN packets hit? What happens when users setup their Cisco "store and forward" system so that your stack suddenly gets hit with a huge amount of packets? What happens when your stack is hit with IPv6? Will it recover from a DOS attack? How many simultaneous users? Or a real favorite: What happens when end-users setup their SNMP monitoring to issue about 500 GET reqs all at once with some malformed packets mixed in?? What happens to interrupt latency when the RTOS / stack gets snowed under with IP traffic - ie what is the maximum interrupt / thread switch latency?
That's a lot of questions! Well, VLAN's are ignored by EMAC, IPv6 and all forms of malformed or unsupported packets are detected and discarded by the stack itself. Obviously the amount of testing a single man could do is only so much, but when you develop something, and you understand how and why it all work, you don't need to test it in every conceivable combination of switches, packet timings and GET requests. You just know what really mattes and you only check for that things. You may call it overconfidence on my part, but this is a fact. You cant be so much sure with something that another person did, and that is a mystery to you. In that case you will have to test it endlessly to become sure all works fine.

I don't have FAQ on the site, but the documentation is there in the archive. I want to believe it is the reason I don't get asked questions frequently.

I have to admit that precise ISR delays have not been calculated by me for HACK-RTOS for eZ80 (as they have been for other, simpler, variants of HACK-RTOS). Theoretically, nothing prevents me from calculating them though (the hard part is to make you believe in my calculations). HACK-RTOS uses only normal-priority interrupts, so if you assign high priority for your interrupt, its maximum latency would depend only on the length of code in OS that execute with disabled interrupts, not on the frequency of coming Ethernet packets, not on the frequency of other interrupts. All I can tell now is that the latency is minimal. Much less than that you can get from RZK.