View previous topic :: View next topic |
Author |
Message |
six1
Joined: 27 Feb 2009 Posts: 553
|
Posted: Sun Nov 07, 2010 11:23 am Post subject: |
|
|
Hi Apollo,
no, i was talking about the structured Version i've made, with includes and the advantage of very clear Code in Mainfile of only a few lines
The Core you've assembled ist quite good and there is (for me) no reason to change anything!
Once again: You've done a great job Apollo!
Best regards, Michael _________________ For technical reasons, the signature is on the back of this message. |
|
Back to top |
|
|
ollopa
Joined: 03 Sep 2007 Posts: 233 Location: California
|
Posted: Mon Nov 08, 2010 11:14 am Post subject: |
|
|
Got home and worked on the keyboard code a little tonight. I'll work on it some more tomorrow after I get some sleep and maybe I'll be able to put out an update before bed tomorrow. |
|
Back to top |
|
|
ollopa
Joined: 03 Sep 2007 Posts: 233 Location: California
|
Posted: Wed Nov 10, 2010 10:13 am Post subject: |
|
|
No luck yet, guys. I don't have a USB analyzer and my logic analyzer has an extremely small memory, so it's difficult to capture the particular packets that are causing problems. Software like USBTrace doesn't help either, because it doesn't show the raw packets on the wire. Good for capturing working communications, but not so good for debugging failing communications.
I really hate to do this but I'm going to have to write an FPGA design to capture the USB data the way I need so I can find out what's going wrong. I'm just wasting time trying to do it any other way.
From experience, it should take a couple days to get the design done and then I can make progress debugging. I'm probably going to visit a friend in the hospital tomorrow, but I'll spend the rest of the week working on USB stuff.
Just to be clear on the status right now:
I have an updated version of the swusb library that fixes a bug. With this fix, I can make a keyboard device. I found a second bug, however, and I want to fix this before I release more code. This second bug is preventing control transfers larger than 1 data packet (8 bytes) from being received by the host. It just happens that when a computer sends keyboard LED status information back to a USB keyboard, it uses this kind of control transfer.
The driver currently supports 12MHz and 15MHz crystals. Once I fix the bug with control transfers, I will add support for 16MHz, 18MHz, 18.5MHz, 20MHz, and if possible 18.432MHz.
Once all of that is done, I may turn my attention toward the virtual serial port driver and towards optimizing some of the BASCOM code. Just to repeat what I have been saying all along: The virtual serial port would require a custom driver which I will have to write. Even though it will look like a serial port to the PC, it will look very different from a serial port to the AVR. It won't be usable for a bootloader and in many cases I would recommend the FTDI chip over the software USB library.
compurap and radan,
I'm doing all my development and testing on a keyboard implementation right now. Everything works except receiving LED status bytes from the PC. In other words, I can type letters on the computer from the AVR, but if I type caps-lock, for example, the computer tells the AVR to turn on the caps-lock LED but there is an error in this communication. The next code I publish will be an updated library and an example keyboard. I'll even do the serial port <-> usb keyboard bridge. |
|
Back to top |
|
|
compurap
Joined: 23 Oct 2007 Posts: 43
|
Posted: Wed Nov 10, 2010 9:17 pm Post subject: |
|
|
Thanks ollopa!!!!
I will test it when release... |
|
Back to top |
|
|
radan
Joined: 06 Jan 2007 Posts: 35
|
Posted: Fri Nov 12, 2010 8:41 pm Post subject: Thanks! |
|
|
We expect from you library, and you can expect from us examples |
|
Back to top |
|
|
hgrueneis
Joined: 04 Apr 2009 Posts: 902 Location: A-4786 Brunnenthal
|
Posted: Sat Nov 13, 2010 2:05 am Post subject: software USB |
|
|
Hi,
is there still enough processing power left to do time critical things with the MCU.
I doubt that very much. As six1 already wrote, the FT232
and also the FT245 versions provide all that and more with hardware for about $5
and the drivers for all versions of Windows OS are alailable license free for download.
The extra programing effort in my humble opinion justifies an extra chip.
SSOP-28 is still possible for hobby PCBs if you do the film with a high resolution printer.
Have fun
Hubert |
|
Back to top |
|
|
ollopa
Joined: 03 Sep 2007 Posts: 233 Location: California
|
Posted: Sat Nov 13, 2010 2:42 am Post subject: |
|
|
hgrueneis,
I've covered all this before but the thread is 9 pages, so I'll collect it for you:
ollopa wrote: |
Turning your project into a USB peripheral puts a lot of constraints on it, though. If you're just looking for an easy way to communicate with a PC, then a USB to RS232 adapter may end up being a better solution. It depends on what you want to do.
[...]It will also spend a fair amount of its time servicing interrupts from the USB host. Unfortunately, USB is fairly constant stream of chatter so the primary function of the AVR has to be blabbering away on the USB bus. There is time left over for other things but if your project is timing critical or has to do large calculations in a short period of time, then the load from USB communications will probably be too much.
[...]You could, of course, use one AVR to do something timing critical and then use another to be your gateway to the PC, but in that case you could just use the FTDI chip instead.
[...]The virtual serial port would require a custom driver which I will have to write. Even though it will look like a serial port to the PC, it will look very different from a serial port to the AVR. It won't be usable for a bootloader and in many cases I would recommend the FTDI chip over the software USB library.
[...]You are right that in many cases a dedicated chip is a better solution. The FTDI chips, however, are limited to emulating RS232 and parallel endpoints as far as I know. There are times when you want to make a custom class device or a HID class joystick or keyboard and then the FTDI chips are no good.
[...]From the FTDI FAQ:
"Can I make FTDI devices appear as a different device class?
FTDI have defined our own device class, so FTDI devices return a 0 for the bDeviceClass (Vendor class).
The class cannot be configured by the designer.
Our devices do not return the correct USB device descriptors to be USB HID class or USB Mass Storage class. It may be possible to write a filter driver that will make our chip appear to be a HID or mass storage class device, but to do this would involve a lot of work."
|
|
|
Back to top |
|
|
compurap
Joined: 23 Oct 2007 Posts: 43
|
Posted: Thu Dec 02, 2010 5:43 pm Post subject: |
|
|
Yes, and FTDI Chips not have an "No driver Needed" version.
Thanks Ollopa for great efforts |
|
Back to top |
|
|
Petr_
Joined: 24 Mar 2010 Posts: 66
|
Posted: Fri Dec 03, 2010 8:07 pm Post subject: |
|
|
Is there any news on this theme? |
|
Back to top |
|
|
ollopa
Joined: 03 Sep 2007 Posts: 233 Location: California
|
Posted: Fri Dec 03, 2010 9:33 pm Post subject: |
|
|
I've been working on it but it turns out most of issues I was having were actually 2.x compiler bugs, so I lost a lot of time debugging non-issues. I did build my FPGA USB sniffer and capture the communications, but there weren't any obvious problems there. I'm gonna work on it some more this weekend and hopefully fix it. |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Fri Dec 03, 2010 10:31 pm Post subject: |
|
|
The usb data capture debugger sounds great. is this something we can build?
Were the problems you found fixed in the 2.0.2.1 update?
If not please send it to support.
The xmega pinout files were not included so if there is a problem i like to know about if for the 2.0.3.0 release. _________________ Mark |
|
Back to top |
|
|
ollopa
Joined: 03 Sep 2007 Posts: 233 Location: California
|
Posted: Fri Dec 03, 2010 11:59 pm Post subject: |
|
|
The USB sniffer is built around the Nexys-2 dev board. It's just a quick and dirty hack I put together--far from usable for most things right now. It has three inputs: two for USB D+/D- and one for a trigger. There's a basic delay counter after the trigger so I can control what % of communications I capture before the trigger and after the trigger. The device just buffers the data to BRAM with some modified RLE compression. Once the capture is done, I transfer the BRAM samples to my PC via USB and then I have to run a PowerBASIC program to decode the two signals into USB J and K states, sample the data and do bit unstuffing, and then search for the start-of-packet identifier and assemble the packets. It doesn't do any protocol analysis but it does check for bit stuffing errors and CRC errors. Maybe one day I will develop it into a useful product but right now it's just a clumsy tool for my own personal debugging.
I think the major bugs were taken care of in 2.0.2.1. My device seems to enumerate more reliably under 1.11.9.8 but I don't think that's because of a compiler bug. I think the code might be running a little too slow and violating the USB timing requirements, so I'll test that hypothesis this weekend. I'll compare 12MHz with 15MHz and if everything runs fine at 15MHz then I'll optimize the code some more. |
|
Back to top |
|
|
ollopa
Joined: 03 Sep 2007 Posts: 233 Location: California
|
Posted: Wed Dec 08, 2010 12:45 am Post subject: |
|
|
Well I didn't get to spend any time on this over the weekend like I'd planned. Some things came up at work and I wound up busy all weekend.
I just tried the 15MHz crystal and things worked better. That's the first progress in a long while. So I think I just need to optimize a couple routines and things will be working fine at 12MHz.
So "typing" from the keyboard -> PC works fine and now so does handling when the PC tells the "keyboard" to turn on LEDs for caps-lock, scroll lock, num lock, etc. |
|
Back to top |
|
|
ex4
Joined: 13 Jan 2006 Posts: 1062 Location: indonesia
|
Posted: Wed Dec 08, 2010 12:58 am Post subject: |
|
|
wow, nice sir
any code to share so far sir? |
|
Back to top |
|
|
ollopa
Joined: 03 Sep 2007 Posts: 233 Location: California
|
Posted: Wed Dec 08, 2010 11:29 am Post subject: |
|
|
Will be coming soon, I hope. What I have right now isn't suitable for release because of the performance issues and debug junk strewn about. I'll keep posting as I make progress. |
|
Back to top |
|
|
|