Background noise

Yes, as other half is marking a lot of software projects for 18 year olds at the moment. Many very late on their timescale, let alone quality.

Also a lot of Senior Engineers that appear to have little understanding of what they want to do, or the tools they are using.

I think there may be a lot of outsourcing to companies without checking their capabilities, because it was lowest bid.

Another way of looking at it is that some people's research process starts with a post to usenet asking "how do I do X?".

From the poster's perspective, that's not such a bad tactic. Posting a couple of paragraphs to usenet and reading the replies takes about as much effort as typing a query into Google and reading the first couple of paragraphs of the first ten hits, albeit with more latency.

Also, the usenet approach is more likely to turn up key pieces of information. E.g. if you didn't know that there's a big difference between implementing a USB host and a USB function, you could spend days reading tutorials and datasheets about implementing USB functions before you stumble upon this fact.

I agree with that. Signal to noise ratio in google search results is pathetic for any non-trivial topic (i.e. "right way to solve problem X"). Analyzing the mountain of data and discarding false positives and near misses is hard, boring work. There is no experience or knowledge gained from shoveling digital manure.

A few insightful pointers from seasoned experts can save you from several days of shoveling.

-- Kind regards, Tarmo Kuuse

LOL - I know that this is happening.

I looked at one project where the previous bidder had spent twice the client's time budget, and what they provided was FUBAR.

I dropped the project when the client couldn't accept that I wanted a higher hourly rate.

AL

Please do not top-post. Your answer belongs after (or intermixed with) the quoted material to which you reply, after snipping all irrelevant material. If I hadn't fixed it you would have lost all connection to the thread. See the following links:

(taming google) (newusers)

The problem, with USB specifically, is that it is stupidly complicated. I had some projects for the PIC which spoke on the serial port to my computer.

Serial was easy to figure out... look online a bit, lots of tutorials, read a book somewhere--I could code it in a handful of instructions on a PIC from the raw datasheet, and it Just Worked(tm).

Then, my ancient computer failed, and in getting a new one, there aren't any legacy ports on it. USB is it. I got a PIC18F4550, figured I'd read the USB portion of it and the USB spec, write a driver for it in a week or so (thinking that was a great amount of time), and WHAM 1000 pages of mind ripping complexity.

All I want to do is send some bits back and forth to the stupid PIC from the computer! Writing a 10,000 line USB driver is by no means the focus of my project, but I'm forced into it--since I use Linux and can't use the free solution offered by Microchip (which sdcc won't use since it is in a different dialect).

I don't argue against learning new things, in fact I rather enjoy it, I argue against having what used to be a tiny part of a project I didn't have to care much about balloning up hundreds of times in complexity and taking time away from real work. Imagine my surprise when my schedule to implement something slips months trying to comprehend the USB spec and seeing if I can just "write a simple driver without all of this complexity". It takes months to figure out the fact that you can't!

My burning desire to intuitively understand how it works so I can implement it myself (I am a geek after all) is in direct opposition to just wanting to send the stupid data from my device to the computer!

And don't get me started on having to pay 2000 or 4000 dollars each year to a commision to get some id numbers and a sticker if I wanted to sell my product.

Thank you.

-pete

And for all the above, my dear Peter, FTDI invented the FT232 and the likes :-)

Meindert

And if you don't want to use FTDI devices (though I recommend them), there is libusb - no need to write the 10,000 lines yourself.

Do you mean libusb as a library on a linux machine? Or libusb as in some collection of C or assembly for the PIC18F4550? That chip is the one I'm using so I'll have to write the USB firmware on the device itself if I want to talk to it.

The FTDI device does look pretty nice though...

Thanks for the information.

-pete

If you can use one of the FTDI devices, that's the easiest solution.

libusb can be quickly found with google - it's a general usb library for Linux. There is also a windows version that is almost api-compatible, and includes a windows driver. I haven't used them myself (FTDI have been good enough for my use), but if I had to make a more general USB connection, that's where I'd start.

Microchip provides a USB framework and sample source code. One of the example programs uses a PIC18 or PIC24 as a USB-to-RS232 converter.

Or if that PIC choice is not a hard requirement:

Writing a serial driver for the AT90USB162 is a matter of installing the free GCC toolchain and compiling and modifying the example:

The development board is $24 dollars and the toolchain is free. You can have blinking LEDs (hello world) connected to your USB port within

S.