I jumped in late on this thread.
I read you were after the project running under Crossworks CWARM.
I ported the project a little while ago to CWARM for the hell of it.
It worked great - wasn't much to it , really.
If you still need the project, send me an Email, and I'll zip it for
you.
I have a client that extensively uses CP1201 (Si Labs), and it's same story
with that
driver.
The terminal program I use crashes if you hot-unplug it.
The exception is Telix for DOS, that handles it (also COM3), but I've
always been a big
fan of Telix.
(I hate the win version though)
About unplugging during COM, (don't quote me on this) AFAIK an UNPLUG
event, and then a
PLUG/resume event, will need the whole enumeration process to restart (the end
points are
reset)
and since WIN sees your COM process still running, it will not and can not give
that
resource to
the LUN.
For example, with Mass Storage devices you can see that the driver (in device
manager XP)
properties gives you the option to allow unplug while running, albeit reduced
disk
performance
(caching is turned off).
I never tried whether that helps on XP.
I despise it myself too though, when you're forced to fire up the
"safe HW removal"
_every_time
you want to unplug....
For my 802.11 I use Digimates, that have the ZD1201 chipset, and they too
require safe HW
remove first, but that doesn't matter there, since they always stay
connected.
B rgds
Kris
>-----Original Message-----
>From: AT91SAM7@AT91... [mailto:AT91SAM7@AT91...] On Behalf Of
>vt_snapshot
>Sent: Sunday, 27 November 2005 3:24 PM
>To: AT91SAM7@AT91...
>Subject: [AT91SAM7] Re: USB - Reconnect process after disconnect/ halt
>
>Hi Scott,
>
>I am using a derivative of Atmel's Basic USB code.
>I agree that it was very limited in how it was set up.
>I found where I needed to add checking for USB power / connect events
>as well as some exit methods from some of their never ending loops.
>Pulsing the pullup resistor was the solution I found after posting
>that last message to help with reconnect.
>
>So I've solved half of my problem but as you said, I'm not sure
there
>is a good solution for some of these Terminal programs to re-connect
>once they think that a COM port is no longer there.
>
>I will take a further look through your FreeRTOS and see if I can
>adapt to some of the USB routines. My first ARM application can't
>justify the full RTOS but I'm sure it will become handy at some
point
>down the road on other projects.
>It looks like a great program and is well documented.
>
>My PC application will be running under the LabView programming
>language. It's a great language for graphs, data processing and
>control systems.
>
>--- In AT91SAM7@AT91..., <scott@o...> wrote:
>>
>> Which CDC code are you using? I wrote the one that I think is
>included with
>> FreeRTOS now. I don't think there *is* a way to not have to
>disconnect from
>> the COM port, at least not with the standard CDC driver. You could
>probably
>> cause a disconnect event so that the terminal program automatically
>releases
>> the COM port. It's been awhile since I messed with it, though.
>>
>> As for reconnecting when the SAM7S restarts, I always set up my
>startup code
>> to force a disconnect for a few seconds (through the USB pull-up
>control)
>> before reconnecting. If the SAM7S never resets the bus, the host
>doesn't
>> know what's happened and it won't go through enumeration
again.
>>
>> If you're using the FreeRTOS code, let me know and I'll find
the
>reset code
>> I'm using. If you're using Atmel's, then you're on
your own. I
>really
>> didn't like how that one was put together, and it wasn't
well
>suited to a
>> multitasking environment if I remember right.
>>
>> Scott
>
>Yahoo! Groups Links
>
>
Reply by vt_snapshot●November 27, 20052005-11-27
Hi Scott,
I am using a derivative of Atmel's Basic USB code.
I agree that it was very limited in how it was set up.
I found where I needed to add checking for USB power / connect events
as well as some exit methods from some of their never ending loops.
Pulsing the pullup resistor was the solution I found after posting
that last message to help with reconnect.
So I've solved half of my problem but as you said, I'm not sure there
is a good solution for some of these Terminal programs to re-connect
once they think that a COM port is no longer there.
I will take a further look through your FreeRTOS and see if I can
adapt to some of the USB routines. My first ARM application can't
justify the full RTOS but I'm sure it will become handy at some point
down the road on other projects.
It looks like a great program and is well documented.
My PC application will be running under the LabView programming
language. It's a great language for graphs, data processing and
control systems.
--- In AT91SAM7@AT91..., <scott@o...> wrote: >
> Which CDC code are you using? I wrote the one that I think is included with > FreeRTOS now. I don't think there *is* a way
to not have to disconnect from > the COM port, at least not with the standard CDC
driver. You could probably > cause a disconnect event so that the terminal
program automatically releases > the COM port. It's been awhile since I messed
with it, though.
>
> As for reconnecting when the SAM7S restarts, I always set up my startup code > to force a disconnect for a few seconds (through
the USB pull-up control) > before reconnecting. If the SAM7S never resets the
bus, the host doesn't > know what's happened and it won't go
through enumeration again.
>
> If you're using the FreeRTOS code, let me know and I'll find the
reset code > I'm using. If you're using Atmel's,
then you're on your own. I really > didn't like how that one was put together,
and it wasn't well suited to a > multitasking environment if I remember right.
>
> Scott
>
Reply by ●November 26, 20052005-11-26
Which CDC code are you using? I wrote the one that I think is included
with
FreeRTOS now. I don't think there *is* a way to not have to disconnect
from
the COM port, at least not with the standard CDC driver. You could probably
cause a disconnect event so that the terminal program automatically releases
the COM port. It's been awhile since I messed with it, though.
As for reconnecting when the SAM7S restarts, I always set up my startup code
to force a disconnect for a few seconds (through the USB pull-up control)
before reconnecting. If the SAM7S never resets the bus, the host doesn't
know what's happened and it won't go through enumeration again.
If you're using the FreeRTOS code, let me know and I'll find the reset
code
I'm using. If you're using Atmel's, then you're on your own.
I really
didn't like how that one was put together, and it wasn't well suited
to a
multitasking environment if I remember right.
Scott
> -----Original Message-----
> From: AT91SAM7@AT91...
> [mailto:AT91SAM7@AT91...] On Behalf Of vt_snapshot
> Sent: Saturday, November 26, 2005 4:18 PM
> To: AT91SAM7@AT91...
> Subject: [AT91SAM7] USB - Reconnect process after disconnect/ halt
>
> Hello SAM7 Group,
>
> I got the USB to work via the CDC Serial port emulation.
> When I connect, it maps in as the next available COM port.
> In my case, it maps as COM3.
> If I ever unplug or stop my program for a recompile, I lose the COM3
> link and must exit the Terminal program and re-enter the terminal
> program to have it find COM3 again.
>
> This is only half of my problem.
> The other half is I'm not sure how to get my program in the SAM7S64
to
> properly reconnect without a full reset of the chip.
>
> If I simply unplug, I'm not sure what register sets to use to
monitor
> this other than just looking at the USB power pin.
>
> Any tips or suggestions on how the reconnect can be done so that COM
> programs don't have to exit and restart and how to avoid resets of
the
> ARM chip?
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Get fast access to your favorite Yahoo! Groups. Make Yahoo!
> your home page
> http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/dN_tlB/TM
> --------------------------
> ------~-
> Yahoo! Groups Links
Reply by vt_snapshot●November 26, 20052005-11-26
Hello SAM7 Group,
I got the USB to work via the CDC Serial port emulation.
When I connect, it maps in as the next available COM port.
In my case, it maps as COM3.
If I ever unplug or stop my program for a recompile, I lose the COM3
link and must exit the Terminal program and re-enter the terminal
program to have it find COM3 again.
This is only half of my problem.
The other half is I'm not sure how to get my program in the SAM7S64 to
properly reconnect without a full reset of the chip.
If I simply unplug, I'm not sure what register sets to use to monitor
this other than just looking at the USB power pin.
Any tips or suggestions on how the reconnect can be done so that COM
programs don't have to exit and restart and how to avoid resets of the
ARM chip?