USB ZX chips?

[dlh]

Don,

While researching the newer USB-capable PICs I came across this...

• http://www.obdev.at/products/vusb/index.html

I have no idea how practical it is in terms of code space or whether it uses the Virtua Serial Port approach on the PC.

[dkinzer]

I have no idea how practical it is in terms of code space or whether it uses the Virtua Serial Port approach on the PC.

I've looked at that briefly and I think it's interesting. I don't know if it can be reconfigured to run on a 14.7MHz device like the native mode ZX's. If not, or if the overhead is too high, one could employ, say, a dedicated mega328P for this purpose.

[dlh]

I glanced briefly at a couple of their example applications and some were on ATTiny chips so it's hopeful. Of course, I know next to nothing about these lower level machinations.

[twesthoff]

FYI, I believe it, or something like it, has been implemented in Bascom with AVR chips. I don't know any of the details.

[dlh]

FYI, I believe it, or something like it, has been implemented in Bascom with AVR chips. I don't know any of the details.

I have BasCOM but haven't updated it in a few years. Maybe I'll explore that. I really don't have an application but thought others might find it of interest.

EDIT: Aahhh - very interesting. The BasCOM add on can support host (on some chips) or client. If Don could implement something similar I might have ZX applications for a USB host.

• http://www.mcselec.com/index.php?page=s ... p&Itemid=1

It also does HID & CDC. The CDC examples I've seen for PICs use Virtual Serial Ports but I don't know if that's always the case or whether it's just in Microchip's implementation.

AFTER FURTHER REVIEW: The BasCOM add on is only for Atmel's USB-capable chips so it's of less interest than the code only library approach.

[dlh]

I don't know if it can be reconfigured to run on a 14.7MHz device like the native mode ZX's.

The web page says...

Can be clocked with 12 MHz, 15 MHz, 16 MHz or 20 MHz crystal or from a 12.8 MHz or 16.5 MHz internal RC oscillator.

[dkinzer]

The web page says...

Can be clocked with 12 MHz, 15 MHz, 16 MHz or 20 MHz crystal or from a 12.8 MHz or 16.5 MHz internal RC oscillator.

I saw that. What I meant was that I'm don't know if it is feasible to reconfigure by modifying the code to run at 14.7MHz. It could range from easy to impractical/impossible.

[twesthoff]

The bascom usb works with any avr chip,but better with the ones that have usb harcware support. Sde AN-178
As far as the clock frequency goes, Usb needs timing based on 125us intervals. If the zbasic can accurately do that it should work(I think).

[dkinzer]

As far as the clock frequency goes, Usb needs timing based on 125us intervals. If the zbasic can accurately do that it should work(I think).

The best that could be attained would be 124.99uS, an error of about 0.01%. Perhaps that's close enough?

[dlh]

The bascom usb works with any avr chip,but better with the ones that have usb harcware support. Sde AN-178
As far as the clock frequency goes, Usb needs timing based on 125us intervals. If the zbasic can accurately do that it should work(I think).

Thanks for the reference to AN-178. That explains a lot and some BasCOM forum discussion explains more.

What I meant was that I'm don't know if it is feasible to reconfigure by modifying the code to run at 14.7MHz.

After reading the app note and forum discussions it doesn't look like it's possible to use clock frequencies other than those noted earlier.

[dlh]

The best that could be attained would be 124.99uS, an error of about 0.01%. Perhaps that's close enough?

That might be close enough - the discussion (by an author of one of the three software approaches) was rather adamant that it had to be 125 but he might interpret 124.99 as 125. There was discussion that 12MHz was no good for serial comms.

At this point it would probably be best if you communicated directly with the author(s).

I think it would be a great feature if it could be used in place of a high speed serial port for PC to ZBasic, and especially if you could do USB OTG which would give the option of using a USB device as a slave.

Here are the links I found most interesting...

This caught my interest:
http://www.obdev.at/products/vusb/index.html
ADD ON:
http://www.mcselec.com/index.php?page=s ... p&Itemid=1
AN-178:
http://www.mcselec.com/index.php?option ... &Itemid=57
Forum:
http://www.mcselec.com/index2.php?optio ... pic&t=7537
Other approaches:
http://www.cesko.host.sk/
http://www.xs4all.nl/~dicks/avr/usbtiny/
http://instruct1.cit.corn

[twesthoff]

This AVR app note explains a lot.
http://www.atmel.com/dyn/resources/prod ... oc2556.pdf

Since the code needs to written at such a low level I think only Don K. can say whether it could work with a Zbasic device at 14.7 MHz.

[dlh]

This AVR app note explains a lot.
http://www.atmel.com/dyn/resources/prod ... oc2556.pdf

Since the code needs to written at such a low level I think only Don K. can say whether it could work with a Zbasic device at 14.7 MHz.

Agreed! I was in over my head after the first post.

From the author of one of the software-only approaches (in the forum)...

The crystal requirement is because low-speed USB works at 1.5Mbps and does not tolerate any error. 12MHz allows for 8 cycles between bits, 15MHz allows for 10, 16.5MHz gives 11. 14.74, on the other hand, would be 9.826666 cycles between bits. You can see that the error would accumulate and it would be impossible to maintain accurate USB timing at that frequency.

But the AVR AppNote (for a USB-serial adapter) you referenced has a table of error rates for various baud rates and they don't look too bad. But only Don knows how much work would be involved to use a 12MHz crystal.

[dkinzer]

But only Don knows how much work would be involved to use a 12MHz crystal.

A 12MHz clock is not very compatible with the various timing needs of ZBasic. But even if it were, the more significant problem is the very tight timing requirements of the USB data stream. The application note refers to needing to process the external interrupt resulting from the USB data stream in 8 cycles. As the application note describes, that is a difficult proposition even when you have the full power of an AVR dedicated to do the work. It would be impossible if any other interrupts also need to be serviced (e.g. ZBasic RTC, HW or SW UART, etc.).

[dlh]

The application note refers to needing to process the external interrupt resulting from the USB data stream in 8 cycles. As the application note describes, that is a difficult proposition even when you have the full power of an AVR dedicated to do the work. It would be impossible if any other interrupts also need to be serviced (e.g. ZBasic RTC, HW or SW UART, etc.).

OK. I don't see that it makes much sense to use an AVR chip just to do USB-serial so it looks like it's a dead issue. It certainly was intriguing. Thanks for looking into it.