I've been porting and rewriting the microchip USB host stack.
I came to the conclusion that it doesn't work with composite
host properly. The problem is that each host driver has it's own
control block and there is no easy way to have more than one.
The problem is that with Android, the (deactivated) MSD driver
still override the ADB driver. I can rewrite the parser from
bottom up, instead of top down, but it still won't allow more
than one driver loaded.
Anyway, the USB enumuation codes could be shared and the DCBs
should be shared. I am going to move the DCBs to a new file
and add functions to retrieve pointers to the DCBs. I also
need to move the debug port to uart 4, and free up 1 to 3.
It won't work with low end chips anyway. I need 256K flash.
Also, I am going to remove all PIC18 codes.
I am going to post the mods. We might be able to get paid
helps, if we can get enough supports. We need to work on FAT,
ADB, BEE, etc.
-------------------------------------------------------
<<Old>>
*.c: DCB *; // Device Control Block
adb[0].shit = other shit; // index is always 0
-------------------------------------------------------
<<New>>
dcb.c: DCB {union cdc, cdd, nsd, adb} dcb[6];
cdc.c: cdc = &dcb[0]; // CDC control
cdd.c: cdd = &dcb[1]; // CDC data
nul.c: nul = &dcb[2]; // Not used
nul.c: nul = &dcb[3]; // Not used
msd.c: msd = &dcb[4]; // Mass Storage
adb.c: adb = &dcb[5]; // Android Debug Bridge
DCB *adb = dcb_init("ADB"); // return &adb[5];
void dcb_task("ADB"); // run ADB task
adb->shit = other shit;
The "latest" USB library for AVR is LUFA - Lightweight USB Framework
for AVRs
http://code.google.com/p/lufa-lib/
http://www.fourwalledcubicle.com/LUFA.php
Free, reasonably mature, used in Arduino Uno
-
AVR-USB is a software-only implementation of a low-speed USB device
for Atmel's AVR microcontrollers.
http://www.obdev.at/products/avrusb/index-de.html
-
LPC214x USB stack:
http://sourceforge.net/projects/lpcusb
Citat: "...This is a USB core stack for the built-in USB device of
LPC214x microcontrollers. It handles the hardware interface and USB
enumeration/configuration. Also included are examples like USB
joystick HID, USB virtual COM port and USB mass storage on SD-card..."
This page is the homepage for an open-source USB stack for the built-
in USB controller in LPC214x microcontrollers:
http://wiki.sikken.nl/index.php?title=LPCUSB
Citat: "...LPC2148 microcontroller (I'm using an Embedded Artists
LPC2148 quickstart board + prototype board) running on a 12 MHz
crystal..."
http://wiki.sikken.nl/index.php?title=Main_Page
-
Does ARM provide drivers for the USB controller on my development
board?
http://www.arm.com/support/faqdev/13593.html
Citat: "...Philips have now released their Linux drivers for ISP1761
under a GPL licence. These are available from...":
http://sourceforge.net/users/philips_usb/
-
Have you tried running the USBCV (compliance verifier) tool with your
device? It's at:
http://www.usb.org/developers/tools
http://www.usb.org/developers/docs/
Yes, but it doesn't work with PIC and have the same problem with
composite host.
>
> -
>
> AVR-USB is a software-only implementation of a low-speed USB device
> for Atmel's AVR microcontrollers.http://www.obdev.at/products/avrusb/index-de.html
Too slow, low speed only.
> Does ARM provide drivers for the USB controller on my development
> board?http://www.arm.com/support/faqdev/13593.html
> Citat: "...Philips have now released their Linux drivers for ISP1761
> under a GPL licence. These are available from...":http://sourceforge.net/users/philips_usb/
Linux is too big. The RF chip MRF24 is PIC specific.
>
> -
>
> Have you tried running the USBCV (compliance verifier) tool with your
> device? It's at:http://www.usb.org/developers/toolshttp://www.usb.org/developers/docs/
Will have to, alone with ZigBee alliance.
On 11-04-25 09:56 AM, linnix wrote:
> I need protocol stacks for Android, including ADB, MSD, BEE, etc.
> Says Linux? It's too big and no native support for BEE (ZigBee).
> Says Atmel or Microchip? I've worked with both USB stacks.
> They are both very similar: inefficient and deficient. I wonder
> who copy whom.
>
> I've been porting and rewriting the microchip USB host stack.
> I came to the conclusion that it doesn't work with composite
> host properly. The problem is that each host driver has it's own
> control block and there is no easy way to have more than one.
>
> The problem is that with Android, the (deactivated) MSD driver
> still override the ADB driver. I can rewrite the parser from
> bottom up, instead of top down, but it still won't allow more
> than one driver loaded.
Would Forth be of any help?
https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi
mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJNtbj4AAoJEJXfKw5kUPt7/yIH/jI2KiXoGb9Ot4+H4Sdj54Gf
QR0iErjMFMaowjnH2760WcYnrL2otSy2S2KHiZe+S3jIa0HrYDMYND1TuBV79BwH
4miy1Hmj5Cxb7cvpyWlBHowrlx3I8C/GS3R5pPe5YelbAlnsLj3fSLVDfahOTSIe
1BYswIzqnrlXHIhVAcaxMSgXhAbKfMaIO6vB9MI25kzn8dmdaf9sxCbb1xAWEP8J
7etCQr1nrEi8xWpfjRj6sFZS8LocpOOoPYN72wu6gWeLBbP1qRYM4XGqoP6Zbq99
WZFmtaxEUn+aPtBnE07hOG/U60z6+pXAc7tUnF/BDA957mI/fG12C4fyyn7ZhyA=
=QqXg
-----END PGP SIGNATURE-----
>Linux is too big. The RF chip MRF24 is PIC specific.
I'm not familiar with your platform but Linux can be made pretty small
... I've seen (extreme) kernels stripped down to around 80-90KB. A
lot of it can go depending on what options you need.
George
Although the pic24 compiler is gcc based, it has not migrated back to
the main source base. Setting up gcc and Linux would be a great deal
of work. We don't really need full multi-tasking, since we will just
be dealing with USB most of the time. Most other features are in the
Microchip and ZigBee libraries, we just need to merge them and fix-up
the USB composite drivers.
We got ADB running on the PIC, talking to the Droid. We need to
implement file "push" and "pull" on the PIC, but can't find the spec.
In the Android source tree ADB directory, the "protocol.txt" file
mensions "sync.txt". But it's not there. Does anyone have a copy, or
know where to get a copy of "sync.txt"? Thanks.
--------------------------------------------------------------------------------------
PIC24FJ256 at 32MHz
6 Interfaces, Type 2, Max Power = 250mA
#0(1) Communication Device Controller Command
#1(2) Communication Device Controller Data
#2(2) Class 255, SubClass 255
#3(3) Class 255, SubClass 255
#4(2) Transparent SCSI Mass Storage Device
#5(2) Point multipleXer Point
<= 43 4E 58 4E 00 00 00 01 00 10 00 00 0C 00 00 00 C4 04 00 00 BC B1
A7 B1 68 6F 73 74 3A 3A 6C 69
CONNECT(01000000, 00001000); (12) "host::linnix"
=> 43 4E 58 4E 00 00 00 01 00 10 00 00 09 00 00 00 E4 02 00 00 BC B1
A7 B1 64 65 76 69 63 65 3A 3A
CONNECT(01000000, 00001000); (9) "device::"
<= 4F 50 45 4E 01 00 00 00 00 00 00 00 1E 00 00 00 04 0A 00 00 B0 AF
BA B1 73 68 65 6C 6C 3A 6C 73
OPEN(00000001, 00000000); (30) "shell:ls /sdcard/DCIM/Camera/ "
=> 4F 4B 41 59 28 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 B0 B4
BE A6 73 68 65 6C 6C 3A 6C 73
OKAY(00000028, 00000001); (0) ""
20110501113127.jpg
20110501113141.jpg
20110501113148.jpg
20110501113154.jpg
20110501113212.jpg
<= 43 4C 53 45 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BC B3
AC BA 00 35 30 31 31 31 33 31
CLOSE(00000001, 00000000); (0) ""
>I need protocol stacks for Android, including ADB, MSD, BEE, etc.
Silly rabbit. Tricks are for kids.
Don't really understand your response. But its a response
nonetheless. So, I don't have to talk to myself again.
I was hoping to build the interface without changes on the Android
side, which can be accomplished with the ADB protocols. There seems to
be several ways of moving data across the pipe, but the specs are
sketchy. Namely: file sync and fs-bridge. Without public docs, it
might be easier to build my own protocols.
All we need is a simple file server module on the Android. However,
writing native C program on the Android is anything but simple.
Building the native C compiler on the Android should be doable, or
getting it from someone who had done it. Unfortunately, Google is
making it much more difficult than it really should be.
Going to download the full 8G Android Source to dig deeper.
>On May 2, 4:50 am, UpYerNose <UpYerN...@witarubbahose.org> wrote:
>
>> Silly rabbit. Tricks are for kids.
>
>Don't really understand your response.
It's a misspelled reference to a line of cereal commercials:
http://www.youtube.com/watch?v=qXa0ukxnKhU
George
Still not sure if he is responding to my Request For Comment or just
off-topic remark. Anyway, i need meaningful comments before facing
the firing squad (design review): No problem with coding style
requests, but substances... (Style over Substances).
Initial requirement is just to read image files off the Android:
Progress:
Basic ADB/PXP working over USB.
Basic RUMBA female socket installed on Android.
Will post files to linnix project under code.google.com
----------------------------------------------------------------------------------------
This is a microcontroller stack for droid.
Hardware:
Master (male): PIC24F256
Slaves (females): LG VS740 with Android 2.2
Software:
Mplab C30 IDE
Android Native Development Kit
Protocols:
RUMBA: End Point pipes.
FAT: file system.
MSB: Mass Storage Device.
PXP: Point multipleXer Point.
ADB: Android Debug Bridge
USB: Universal Serial Bus
Files:
yadm.c: Yet Another Driver Maker
Driver Maker for the two devices:
PXP is very simliar to MSD.
However, the current PXP implementation is incomplete,
since it's using polling rather than interrupt.
dev.c: Yet Another Driver Maker template
Template files for both drivers.
msd.c: yadm msd
Output of MSD maker
pxp.c: yadm pxp
Output of PXP maker
dcb.c: Device Control Block for MSD and PXP
To be determined
fat.c: FAT file system
Module for handling FAT file system.
usb.c: End Point server on master
Master USB host driver
female.c: End Point socket on slave
End Point female socket on Android.
Compiled on PC with NDK.
ADB push to:
"/data/local/inc/rumba.h"
"/data/local/src/female.c"
"/data/local/bin/female"
rumba.h: RUMBA definitions
Rumba is not Samba.
Directories:
Most Rumba calls are straight forward, with the exception of CMD_DIR.
Initial call from male to female lists path with sequence of 0.
Subsequent calls with unique sequence returns ordered files in path.