Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - aaronlawrence

Pages: [1] 2 3 ... 5
1
NXPTM LPC2XXX and LPC17XX / Re: USB for LPCXXXX
« on: September 16, 2010, 11:38:15 PM »
Vinita,
have responded to your PM. Please post further discussion here.

I think you should be asking on the Keil forum, no?

I'm prettty busy and can't help you in depth but below are some hints

I am at present working over USB device sstack in LPC1768. I want to establish USB Virtual port communication. But on loading the program and connecting the device to PC i get USB device Unrecognized.

What is the exact message?
What operating system?
What device driver are you using? Which .INF file?
If you are using Windows Vista or 7 you may need to switch off signed drivers (boot time option) before it will even ask you to load your device driver.
You should know I could not get it always to work reliably on XP either - sometimes it worked, sometimes not.

Quote
Now the next thing is that in soft connect mode insead of using a switching transistor i am using soft connect line as GPIO line and pulling D+ line to high.
When this GPIO line is low system doesnt detect any device when pulled high shows unknown device.
This sounds about right. So long as your GPIO link can drive enough current to pull it up properly.


2
NXPTM LPC2XXX and LPC17XX / Re: USB for LPCXXXX
« on: July 30, 2010, 02:48:50 AM »
It turns out that Microsoft added a CDC serial driver in Windows CE6, although without announcing it.
It seems to be somewhat buggy ...
http://social.msdn.microsoft.com/Forums/en-US/winembplatdev/thread/2f01150e-b094-44a9-a6f4-8909d2c41c80

Our device end is working with LPCUSB
http://sourceforge.net/projects/lpcusb/

since the uTasker USB support was not released.


3
To be specific about our problem.
lost packets such as those described here, should be retransmitted by TCP. However, there are or were some bugs in uTasker TCP such that retransmits didn't happen.
In our case it was because data was being received continually. This was incorrectly resetting the TCP retransmit timer, so it never fired. Hence, TCP transmit was stuck.

4
Hello all,
Just noticed this topic.
We also have a lot of problems with EMC immunity and our USB connection.

I don't understand why the host is unable to detect the device has gone to sleep. Isn't it constantly accessing the device if it wants to send something by sending an IN token? It would expect to get either data or a NAK, if it gets neither it should be able to judge there's a problem...
I suppose if it were a one-way only (OUT tokens only) then maybe there's no response to Start of Frame, normally...


5
µTasker general / Re: uTasker Documentation and Operation
« on: June 27, 2010, 04:50:34 AM »
Yes, but to fund a team - or even one person full-time, it's just Mark part time now - will require greatly increasing the price.
At the moment testing costs are effectively paid largely by customers. This allows the cost to be much lower, which is a reasonable business model, though some commercial customers would not be comfortable with it.

6
Ouch. Can you explain more what the consequences of this problem are?

7
NXPTM LPC2XXX and LPC17XX / Re: USB for LPCXXXX
« on: June 15, 2010, 07:47:04 AM »
OK, that's clear - we would be one of the first major test cases. 

No, Windows CE does not have a CDC driver, and uses completely different drivers from the desktop.

Anybody have experience developing a custom USB driver for a desktop OS? It looks a bit nightmarish to me, but I imagine once you get all the layers in place it's just passing packets back and forth...

8
NXPTM LPC2XXX and LPC17XX / Re: Ethernet controller
« on: June 15, 2010, 07:41:15 AM »
As a note on this topic, that may be helpful for others.
Indeed the LPC23xx has (by default) a weak pullup on all lines. This means that the RX_ER, which also serves to configure the PHY Address, may get a high value at reset and thus the PHY would be at address 1 insetad of 0 as uTasker expects.
We added a stronger 10k pulldown on RX_ER/PHY_AD0 and this problem was resolved without needing to change other things.
Or so it seemed... we are still struggling with the LAN8720.

9
µTasker general / Re: uTasker Documentation and Operation
« on: June 03, 2010, 12:31:14 PM »
Yes, you may be right that uTasker is as good as it gets. It seems we have been too ambitious with the technologies we picked for our product.


10
NXPTM LPC2XXX and LPC17XX / Re: USB for LPCXXXX
« on: June 03, 2010, 12:15:29 AM »
So... just how thoroughly is the USB CDC support tested?
Will it handle high baud rates with lots of randomly timed data? (You know the kind of thing now Mark ;)

Our Ethernet approach has proved fairly problematic, so I'm casting around for alternatives. At the uTasker end, we have USB as an option. At the other end we will have to buy a CDC driver for Windows CE which makes me very nervous, but one step at a time!

11
uTasker TCP/IP works on LPC23xx reasonably well.

But flawless is a strong word ... NXP only just added an errata item about failure to increment one of the Ethernet counters after the first or second packet transmitted. And they had some horrendous bugs on the earlier revisions of the silicon.

Also I am having some problems with transmitted packets going missing, and failure to maintain connection on a LAN with lots of traffic, which could well be LPC limitations (they don't seem to be uTasker problems).

12
µTasker general / Re: uTasker Documentation and Operation
« on: June 02, 2010, 11:22:50 PM »
Quote
the strategy is to allow as many users to test the code in as many situations as possible.

Mark,
I think that you should be upfront about this in your marketing (ie. website). People buy a product like this because they want something that you have ALREADY tested thoroughly, they don't want to pay to help you test and fix bugs. I certainly expected that you would have a pretty thorough test suite and was unpleasantly surprised to find large numbers of pretty basic bugs. We have spent weeks (thousands of dollars) testing and debugging your code.

Of course, if you put on the front page that this is your strategy, you will probably lose some potential customers. But that is the price of being honest.

I know you will argue that our case was special. That's really besides the point. The point is that by simply saying you have a TCP/IP stack, with lots of features, and no caveats about level of testing, you create a false impression.


13
µTasker general / Re: Using TCP in the uTasker project
« on: April 30, 2010, 01:03:52 AM »
Mark,
can you either "pin" this topic so it stays at the top, or link to it from the documentation page?
I came back to try and find it and could not, even knowing it was there in the general forum.
Thanks.
(unfortunately the code explorer still doesn't have some of this stuff)

14
µTasker general / Re: Support for AUTOIP
« on: April 30, 2010, 12:50:17 AM »
Just to note, we will want this feature also - within about 1 year time frame.

15
µTasker general / Re: uTasker Documentation and Operation
« on: April 30, 2010, 12:45:35 AM »
Hello SVC1,
Having just written a bunch of code that effectively stresses uTasker TCP, I can tell you that there were a number of very severe problems. Mark has fixed what has been identified so far - excellent support as usual - but does not have any automated testing of his own so you will likely find many more.

It seems to me that uTasker TCP has been mostly used in strict client-server situations, mostly with it's built in webserver and other protocols. The underlying TCP/IP protocols were originally not exposed (as far as I can tell) and have not been thoroughly tested, or even documented.

Sorry, Mark, but that's the clear situation from our perspective.

Pages: [1] 2 3 ... 5