A place to discuss ZBasic and ZX series microcontrollers.
https://forum.zbasic.net/
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 wrote: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 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.twesthoff wrote:FYI, I believe it, or something like it, has been implemented in Bascom with AVR chips. I don't know any of the details.
The web page says...dkinzer wrote: I don't know if it can be reconfigured to run on a 14.7MHz device like the native mode ZX's.
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.dlh wrote: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.
The best that could be attained would be 124.99uS, an error of about 0.01%. Perhaps that's close enough?twesthoff wrote: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.twesthoff wrote: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).
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.dkinzer wrote: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.
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.dkinzer wrote:The best that could be attained would be 124.99uS, an error of about 0.01%. Perhaps that's close enough?
Agreed! I was in over my head after the first post.twesthoff wrote: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.
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.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.
dlh wrote: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.).twesthoff wrote:But only Don knows how much work would be involved to use a 12MHz crystal.
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.dkinzer wrote: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.).