ZBasic Forum

I noticed the Zbasic tech feature table for the ZX-32a4 device shows 10-bit ADC resolution. The ATMEL datasheet shows 12-bit resolution, with an 8-bit option to reduce propagation delay. Is the Zbasic device in fact 12-bit? Also, will there be a DIP version? Thank you.

liam.zbasic wrote:The ATMEL datasheet shows 12-bit resolution[...]

While that is true, the reports are that the 12-bit resolution is unattainable in single-ended mode. There has been quite a bit of discussion on this topic at the AVR Freaks forum.

The ZX devices based on the xmega chips return a 12-bit result allowing you to use the full resolution if you wish.

liam.zbasic wrote:Also, will there be a DIP version?

As far as I know, Atmel has no plans to produce xmega chips in DIP packaging. The only DIP-like options will be realized using a carrier board like the ZX-24x.

In the process of composing this reply, I realized that the discussion of the GetADC() function currently does not indicate that you must divide by 4096 (rather than 1024) for the xmega-based devices.

It is important to note that the xmega-based devices use an internally generated reference voltage of Vcc/1.6. Although there is no dedicated analog reference pin (as there is on the mega devices) you may use one of the analog inputs (A.0 or B.0) to provide an externally generated reference voltage. The other reference voltage option is an internally generated 1.0V source. In order to use any of the alternate references, however, you would need to write your own variation of the readADC() function described in another recent post (see http://www.zbasic.net/forum/about1397.html).

Okay, so the Zbasic getADC() function will return a 12-bit integer from 0 to 4096. This is very important for my feedback control law programs. On a different subject, if I use one of the analog inputs (A.0 or B.0) to provide an external reference voltage, will that degrade the resolution of the getADC() output? My concern is that the reference is a digitized version of the external analog reference. I remember in the 1980s copying Kraftwerk music onto cassettes from other cassettes - quality was degraded. Thanks for your response.

liam.zbasic wrote:Okay, so the Zbasic getADC() function will return a 12-bit integer from 0 to 4096.

The value will be 0 to 4095 - the maximum value representable in N bits is (2^N) - 1.

liam.zbasic wrote:if I use one of the analog inputs (A.0 or B.0) to provide an external reference voltage, will that degrade the resolution of the getADC() output?

No, the reference voltage isn't digitized. When you select A.0 or B.0 as the reference the internal circuitry of the xmega connects that input to the reference input of the ADC through an analog multiplexer. This is essentially equivalent to applying an analog level to the Aref pin on a mega-based device except that the reference pin is not dedicated and thus can be used for other purposes if the external reference is not needed.

Thanks for your responses.

On a separate subject, there seems to a noticeable level of buzz regarding 32-bit devices (Mbed, Xduino, Bugblat, etc.) Their features are extremely enticing such as RAM quantity, Ethernet MAC, USB, Built-in-Audio, etc. Question... do you plan on expanding the Zbasic product line with 32-bit devices within the next year or so?

liam.zbasic wrote:Thanks for your responses.
do you plan on expanding the Zbasic product line with 32-bit devices within the next year or so?

ARM M3!!

I think the 8/16-bit ZX-32a4 device is the next logical step before 32-bit chips. I'm stoked about the speed, additional serial ports, 12-bit ADC and the new DAC among other features. ADC resolution has been critical to my projects. My approach is a simple, tight, minimalist approach and now I don't need additional chips and circuitry for ADC. This reduces precious time & money and I can keep programming in Visual Basic. Purveyors like Mbed, Xduino, Bugblat, Coridium, Maple Leaf, etc., produce 32-bit kits, but the sparse documentation is no where near as tight, complete and integrated as ZBasic. So hopefully a 32-bit ZBasic device is on the drawing board. Of course, when and if that happens, we’ll be prodding for a 64-bit device. “We can’t get no satisfaction.”

Naturally, I am happy with the clock doubling of the new processors. Speed is right up there with "World Peace and More RAM". Pragmatically, though, what does the new architecture mean to us, speed aside.

When a processor is labeled "8/16-bit", what functions are handled as single-cycle words? Beyond 16-bit address space, what math is improved? If clock speeds are normalized with earlier devices, are Integers quicker in the Xmega parts? Is Long handling faster? Do these translate into (normalized) faster float processing, too? Can these parts do 16x16 multiplies or MACs, yet?

If the hardware is truly more efficient beyond the speed, has that been incorporated in the compiler, or can we also look forward to a gradually-improving IDE and compiler and the boosts from that?

My preference of next features would include longer floats. 32-bit floats are marginally limiting to my work in navigation, so even 40-bit float (or larger, naturally) handling would make me a happier guy.

[BTW, I mentioned the IBM 1401, my first real computer, in another thread. ( I actually first learned to program a fictitious accumulator-based machine, called TUTAC, before my first hands-on experience.) The 1401 was unusual, even today, in that it did decimal math of any length. It was great for tasks like calculating Pi to 5000 digits. If you wanted to divide a 7500-digit number by a 1300-digit number, all you needed was enough memory (core, then) to hold both arguments and the code. The machines were limited to 16k but most practical tasks, like running a commercial bank's accounting or an insurance company's statistics, were done within 4k (6-bit characters) of combined data and code space. It was speedy, too! The main cycle time was 11.5uS, determined by the magnetic core read/write cycle, an 87kHz processor. Whew!]

Well, I only understood half your comments, the rest was over my head. Not sure I need to understand it all to produce working projects. I'm sure ATMEL had good reasons to invest and distribute the 8/16-bit devices. Anyway, I definitely agree with the recommendation for higher precision math. I purchased a book on Kalman filters by Dan Simon and found that numerical instabilities are possible with inadequate arithmetic precision. I'm implementing a Kalman filter for the GBOT90 project (see link below).

http://www.youtube.com/watch?v=bxx14Xe2iNg

I said:

GTBecker wrote:Do these translate into (normalized) faster float processing, too?

On re-reading my post, I was not clear. The question is directed at Don and should perhaps be more concise: given the same source code, does the compiler optimize for a particular processor - or does the ATxmega32A4 processor receive substantially the same code as a ATmega644P would, for example?

GTBecker wrote:given the same source code, does the compiler optimize for a particular processor - or does the ATxmega32A4 processor receive substantially the same code as a ATmega644P would, for example?

In general, the generated machine code will be the same for a mega device as for an xmega device. It will be different if (a) it can be due to facilities that exist in one but not the other or (b) it must be because accessing a particular feature is fundamentally different.

An example of case (a) is that the xmega can set or clear a bit in the direction and port registers associated with an I/O port by writing a "mask" to the set or clear registers. In contrast, on the mega devices must use a read-modify-write operation.

An example of case (b) is when using virtually any of the peripherals. The xmega periperals are different from those in the mega devices such that it may take more or less code to configure say, the SPI controller, on one or the other of the devices.

In most cases, the difference will only be a few instructions so it is unlikely to make a difference in most applications. Also, some xmega instructions execute in fewer cycles than the same instruction on a mega. One example of this is the PUSH instruction - on a mega it is 2 cycles while it is only 1 cycle on an xmega.

Having trouble finding a carrier board or adapter for the ZX-32a4 chip that'll convert it to 44-pin DIP for my breadboard. Does such an adapter exist? Thanks.

liam.zbasic wrote:Does such an adapter exist?

You could buy an omxa4 from Oak Micros and ask them to ship it to us and we can install the ZX Bootloader for the ZX-32a4.

Another possible solution might be found in this blog post:
http://blog.omegacs.net/2010/05/15/rev- ... dapter-art

I don't know if boards are available yet or, if so, whether they are assembled or not.

dkinzer wrote:Another possible solution might be found in this blog post:
http://blog.omegacs.net/2010/05/15/rev- ... dapter-art

I don't know if boards are available yet or, if so, whether they are assembled or not.

I have some of the boards assembled, and if you're interested I can mail one or two out. The A4 boards are most plentiful, though I can see about soldering up some more A3's if you want the bigger one. Send me a PM if you're interested, though I'm on vacation for a week starting Wednesday so it might be a little bit...

liam.zbasic wrote:Having trouble finding a carrier board or adapter for the ZX-32a4 chip that'll convert it to 44-pin DIP for my breadboard.

Over the years I've grown to love Proto Advantage products, like this one:
http://www.proto-advantage.com/store/pr ... id=2200108

They are somewhat on a big side, but I am using extra space to mount decoupling caps and even oscillators right next to MCU. This way you have plug-and-play device that only needs power connections on breadboard.