Open C source USB2 protocol for ATMEL's non USB ARM

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,

I am trying to find a tested open C source, USB2 protocol for ATMEL's ARM micros. I wanna use the UART peripheral and some external electronics without using any external ic (RS232 to USB) converter.

Thanks for your help.

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you can't use the UART for USB, without a converter... the framing and signalling is not compatible. You can bit-bang USB out two GPIO's however.

Honestly though, spend the $5 for the USB-Serial chip, and be done with it.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch,

I have used in the past the FT232R and FT232BM ics. But this time there is a need of low cost and small size psb that there in not enough space for a lot of electronics. Using a non USB ARM what do you suggest me to do or use without getting deep inside the USB protocol. Is there anything free I could find, test and use. I mean source code.

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm, in terms of space, the new FTDIs are really really small - no external crystal/memory and stuff - really simple.

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cp2102 is <$5 and requires no external components

FT232R is also <$5 and requires no external components

all you need is the space for a small 28 or 32 pin QFN.

Also note that that $5 is single piece pricing, from digikey, in quantity, from distribution, it is a fair bit cheaper.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I' ll check it. But if finally the design must be a single ic pcb, is there any posibility to do this just with code???

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you bit bang through some GPIO's yes. But not through the UART.

Also note that your idea of using the UART with "some external electronics" to implement the USB, would take up more space than one of the chips I listed above.

To bit-bang USB, you are going to be "deep inside the USB protocol"

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why wouldn't you simply pick an ARM that has USB? (it's not like there's a shortage of devices to choose from!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can't bitbang USB on an ARM, the I/O is way too slow.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You can't bitbang USB on an ARM, the I/O is way too slow.

ARM is just a CPU core licenced to 300..400 silicon vendors. Are you saying there's something fundamental in the design of the core that would prevent at least some of those vendors providing fast switching IO around it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Objective Development's software-only Easylogger works well on my ATTiny85 battery chargers. The '85 can run at 20MHz through a PLL which with run-time calibration is accurate enough timing for USB1. The code is under GNU GPL version 2, and their licensing terms seem very liberal, 0.1 Euro per unit above 10,000. You can't get much cheaper than that!

But for USB2 I think I'd sacrifice 10 bucks for an AT91SAM7S256 or the like.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:
You can't bitbang USB on an ARM, the I/O is way too slow.

ARM is just a CPU core licenced to 300..400 silicon vendors. Are you saying there's something fundamental in the design of the core that would prevent at least some of those vendors providing fast switching IO around it?

Yes, that's what I say.
The architecture with the AHB bus just does not allow it, also, the pipeline "breaks" when you have a tight loop.
The ARM is not designed for fast port fiddling. It has internal devices for such. Including USB. It was never meant for hacks like bit banged I/O.
The Atmel SAM7 is way faster than the Philips variants.
My test on a LPC2103 running at 60 MHz, show that the max frequency avilable on an I/O pin was 3.5 MHz for a loop that did:
start loop:
Pin lo,
Pin Hi,
loop

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.