ZBasic Forum

I'm a new user of ZBasic controllers. While I find the language and it's hardware embodiment powerful, support for program debugging is non-existent. What passes for debugging amounts to nothing more that output to the console. Even the standard BASIC statement STOP is non-functional.
What passes for an IDE is nothing more than an editor that calls a compiler, calls code down-loader and serves as an output console at runtime.

Why doesn't a product that 's been around for years support even a simple debugger?

oldhack wrote:Why doesn't a product that 's been around for years support even a simple debugger?

In a word, priorities.

Welcome, by the way. Which ZX are you using and how long have you been using it? What kinds of things are you doing?

As an aside, while it is permitted to maintain anonymity via a nom de plume, you will notice that many posts, if not most, have the author's name in the signature.

oldhack wrote:Why doesn't a product that 's been around for years support even a simple debugger?

Well, maybe I am just not good at debugging, but I find debuggers of limited value.

I take it you want to be able to single step, watch variables, and have breakpoints? I have used these functions in Visual Basic and via JTAG ICE (and DebugWire) on the ATmel ATMega hardware. THese functions help a little, but I, personally do not find them to be a big advantage. Probably I use signle stepping most often.

I do find that sending diagnostic data to the console is very often a reasonable method. Crude... yes. Effective too, IMHO.

One of the reasons I end up using the "more sophisticated" debugger functions is due the INABILITY to have simple diagnostic output.

While the ZX platform does not have those advanced debugging features, I think that you will find that the advantages outweigh the disadvantages when you compare your alternatives in using a microcontroller. Directly accessing the hardware can be done, but then you will have to write or adapt nearly all the programming support modules to fit your needs (or buy an EXPENSIVE C programming platform which supplies a reasonable set of support modules).

I find that I can get the job done quite efficiently with the ZX platform, (including the new Native-mode processors), and with its cousin, the OakMicros devices. I still do use the plain vanilla Atmel devices (like the ATTiny devices) for true embedded applications.

-Tony

Besides the requirement to type in lots of extra code to send debug information to the console, the problem is the intrusive effect of the debug statements have on the execution timing of the code. Not only the Console.Writeline() statements, but the additional "If.. Then .. Else ... End If code required to limit the output of those statements to be concise and meaningful. Debugging of timing critical code can be significantly impacted by the additional non-functional code. This is especially true in system with multi-tasking, and interrupts where the effect of the debug overhead will be erratic and seemingly indeterminate. Having the VM check a 'break point bit' on each statement, or the inclusion of a BREAK POINT instruction[STOP is good candidate ] , would have significantly less, and a consistent impact on execution and speed. Either method could be disabled for production code eliminating all overhead.

Besides, all the debug code is fugly, especially with all the #ifdef and #endif preprocessor instructions required to en/disable.

A minimal debugger should provide: Break, Single Step, Run/Resume, View/Set variables and Examine memory by address. Since ZBasic is a PCode interpreter, this should be fairly simple to implement ... the VM is the gateway to all these functions.

-Darrell

oldhack wrote: the problem is the intrusive effect of the debug statements have on the execution timing of the code.

I'd never given much thought to the timing effects of my debugging code. In my experience, an application that needs particularly high resolution control over timing wouldn't be using basic as a programming language in the first place. I'll concede that there is most certainly overhead incurred when debugging in this manner.

I've found that most code that is so very particular regarding timing is poorly written in the first place (usually because I wrote it). Obviously, serial port and other timing critical tasks need to be handled correctly, but our wonderful virtual machine takes care of all that ugliness for us. What I mean are things like variables getting stepped on, or queue over/underruns. Typically, the problems arise when I don't use the proper techniques for handling the data, forgetting to set a semaphore or some such.

To put this perspective though, what are the timing effects of running a VB application from the IDE vs a compiled application? Is the application running in the IDE actually running at the proper speed? It might, I've never checked.

oldhack wrote:Besides, all the debug code is fugly, especially with all the #ifdef and #endif preprocessor instructions required to en/disable.

I'll have to respectfully dissagree on this one. While it is nice to have perfectly streamlined code with perfect indentation and no extraneious characters to muck things up, I personally prefer well commented and spaced out code. Typically, I'll place comment blocks around each logical function describing the functions purpose as well as it's dependancies and such. It takes up a tremendous amount of room with all of the included white space and extra lines, but it makes the application much easier to maintain and debug.

I didn't always have this opinion. Like yourself, I didn't want to have to add things that I thought were not really needed to my code. I have since gotten through that phase. Now, most of my code looks bloated and not tidy, although I can hand it to a complete stranger, and they would be able to understand and even maintain it if the need arose.

I too would like the ability to watch variables as they change, but to be honest, they usually change so fast that I'd miss it anyway, unless I'm single stepping, in which case the timing/speed issue becomes a moot point anyway.

As an aside, I'm interested in hearing your opinions primarily because those who post here regularly sing nothing but praise about the platform, and another point of view can be quite constructive sometimes.

-Don

oldhack wrote:the problem is the intrusive effect of the debug statements have on the execution timing of the code.

For code that is time critical, neither "print statement" debugging nor a debugger with single stepping and breakpoints is suitable. For such applications, the least intrusive debugging tools are the most preferable and they are typically hardware based.

One technique that I've used successfully in such situations is to employ a logic analyzer or oscilloscope to provide visibility of what is happening in the software and the external hardware. The software can use output lines to provide information about what it is doing.

Here is some input I gave to Don in the middle of 2005 (before the first ZX device was released):

1. Add checks for various kinds of ErrorSituations such as TaskStackOverflow and ArrayOverflow.
2. System library functions for I2C, DTMF, PWM, LCD, Servo and motor control.
3. In circuit debugging - i.e. ZX-24 virtual machine single-stepping.
4. Given that strings can now be stored properly in program memory, it seems reasonable to provide 64KByteEEPROM rather than 32K for the a very slight additional cost.
5. Complete remote debug control over the ZX-24 virtual machine. This covers a multitude of suggestions including single-step listed above. For an example see the OOPIC Serial Control Protocol.
6. Other physical configurations such as a 28 pin DIP (similar to BasicATOM28-M) or a ZX-35 variant.
7. More robust packaging in a sealed unit - see Tiger Modules for an example. It is easy to 'fat finger' the module as it is particularly tight in my breadboard (and I suspect others too). The crystal is particularly suspectible to damage.
8. With the extra RAM, double precision variables could be supported.
9. Add support for the Visual Basic Option Compare directive and compiler option.
10. Compilation to Atmel machine code similar to the Bascom idea. For ZX-24 you could prototype in ZBasic and then when ready compile to Atmel native code for production. I think you could charge a premium for this feature (probably more than what Bascom does because they do not support the intermediate prototyping stage).

I'm showing this list partly for historical purposes. A tremendous amount of progress has been made since that time and I really like the ZBasic platform. Let's do a quick review of these 10 items, now almost 3 years later:
1. Partly done - now have checks for TaskStackOverflow.
2. Partly done - system library functions added for I2C and PWM
3. Not done (subject of this thread)
4. Done - can use both 32 and 64 K EEPROMs
5. Not done (subject of this thread)
6. Done - we have both ZX40(a)/ZX44(a) as well as my own Oak Micros ZX24e/ZX24ae and also the mega128/mega1281/1280 based devices as well.
7. Not done and no strong requirement
8. Not done and no strong requirement
9. Not done and no strong requirement
10. Done - see recent announcement of native mode devices.

Over the years I have raised numerous other requirements and/or problem areas and Don has always been responsive and given me a considered and thoughtful response. For the record I normally get about 50% of what I ask for and another 150% of stuff I didn't ask for but is still welcome and very useful.

My thoughts on a ZBasic debugger? Well it might be useful for some very rare circumstances but I have written a large amount of both ZBasic and AVR C code without needing a debugger. Some of my code is quite complex with multiple tasks - see my application notes for examples. I still use print statements or simply thinking through the code as my debugging techniques. For AVR programming I also have both an AVR Dragon and a JTAG ICE mkII sitting on the shelf and have NEVER used either. In fact I'm thinking I should probably just sell them.

oldhack wrote:the problem is the intrusive effect of the debug statements have on the execution timing of the code.
-Darrell

I agree with you about the fugliness of the debugging print statements. As for the effect on execution timing, well, they DO take time. But with a multitasking operating system, precise timing is not going to be very reproducible anyway.

That said, I do make use of JTAG ICE and DebugWire when it is available. I would use a similar debugger for the ZX platform if it were available.

-Tony

@mikep

Since you brought up wish lists , I think its about time to move ZBasic off the 8-bit Atmel platform to one of the new 32-bit ARM Cortex-M3 based processors. Compared to the current 'high-end' ZX128x based chips, a Luminary Micro LM3S1608 is/has:

At Least 1,333K VM instructions/s (72 MIPs @50 MHz), probably faster do to 32-bit bus
13 GP 32-bit registers
2.4 mW/MIP power consumption @3.3 VDC w/5VDC tolerant I/O
128K Internal Flash
32K RAM
32-bit internal bus
32-bit single cycle H/W Mult
32-bit H/W divide
32KHz RTC w/ battery backup during sleep
and much more at about 1/2 the price per chip

-Darrell

oldhack wrote:I think its about time to move ZBasic off the 8-bit Atmel platform to one of the new 32-bit ARM Cortex-M3 based processors.

I think your suggestion is unlikely to happen. This would require a complete code rewrite and tooling change. What is more likely is a steady progression to better AVR8 chips, probably starting with newer devices such as the mega644p and mega1284p and then possibly later the much anticipated Xmega series.

If you want better performance you can also use the native-mode devices which look very promising. Most applications do not need this power.

mikep wrote: Most applications do not need this power.

This is very true. I think Darrell may be working on projects that are in a completely different realm than what the ZBasic platform was and is designed to do. There's something to be said for using the right tool for the job, and I don't think that ZBasic, no matter how good of a product it is, is the right tool in this case.

If I were programming for set-top boxes (with their huge processing requirements), or the latest and greatest LDC or Plasma TV set (with an enormous DSP engine needed to process gobs of video data), I too would find the ZBasic platform lacking in almost every way.

ZBasic was never intended to compete with the high end processor offerings. As far as I can tell, it was only ever intended to compete with BasicX and the Basic Stamp devices, which it has done exceedingly well. Not to say that there isn't any room for further improvement, but if you look at other devices in this market segment, you'll find that ZBasic is the most capable of all of them, by quite a large margin.


-Don

I took a quick look at the Xmega parts, a nice upgrade but remain fundamentally 8-bit parts. As for applications for ZBasic based chips. The ease of use, rich built-in library, and support for multitasking make it good tool for a lot of applications. The range of applications suitable for it's use would be extended if it is ported to a more powerful platform.

I don't know how ZBasic is implemented, but if written in C the porting shouldn't be all that difficult. Most of the work would be H/W specifics which seem to be implemented as subroutine/function calls as it is. Moving to a HAL based implementation which would make future ports even more straight forward.

I've hijacked my own thread, and I'm coming across as a newbie know-it-all party crasher.

-Darrell