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.
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;
RFC: Android Protocol Stack
Started by ●April 25, 2011
Reply by ●April 25, 20112011-04-25
Have you seen: 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/
Reply by ●April 25, 20112011-04-25
On Apr 25, 9:14=A0am, Glenn <glenn2...@gmail.com> wrote:> Have you seen: > > The "latest" USB library for AVR is LUFA - Lightweight USB Framework > for AVRshttp://code.google.com/p/lufa-lib/http://www.fourwalledcubicle.co=m/LUFA.php> > Free, reasonably mature, used in Arduino UnoYes, 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/inde=x-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/dev=elopers/docs/ Will have to, alone with ZigBee alliance.
Reply by ●April 25, 20112011-04-25
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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-----
Reply by ●April 26, 20112011-04-26
On Mon, 25 Apr 2011 09:22:39 -0700 (PDT), linnix <me@linnix.info-for.us> wrote:>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
Reply by ●April 27, 20112011-04-27
On Apr 26, 10:24=A0am, George Neuner <gneun...@comcast.net> wrote:> On Mon, 25 Apr 2011 09:22:39 -0700 (PDT), linnix > > <m...@linnix.info-for.us> wrote: > >Linux is too big. =A0The 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. =A0A > lot of it can go depending on what options you need. > > GeorgeAlthough 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.
Reply by ●May 1, 20112011-05-01
On Apr 27, 8:43=A0am, linnix <m...@linnix.info-for.us> wrote:> On Apr 26, 10:24=A0am, George Neuner <gneun...@comcast.net> wrote: > > > On Mon, 25 Apr 2011 09:22:39 -0700 (PDT), linnix > > > <m...@linnix.info-for.us> wrote: > > >Linux is too big. =A0The 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. =A0A > > 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. =A0Setting up gcc and Linux would be a great deal > of work. =A0 We don't really need full multi-tasking, since we will just > be dealing with USB most of the time. =A0 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 =3D 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 <=3D 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" =3D> 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::" <=3D 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/ " =3D> 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 <=3D 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) ""
Reply by ●May 2, 20112011-05-02
On Mon, 25 Apr 2011 08:56:52 -0700 (PDT), linnix <me@linnix.info-for.us> 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. > >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;Silly rabbit. Tricks are for kids.
Reply by ●May 3, 20112011-05-03
On May 2, 4:50=A0am, UpYerNose <UpYerN...@witarubbahose.org> wrote:> On Mon, 25 Apr 2011 08:56:52 -0700 (PDT), linnix <m...@linnix.info-for.us= > > wrote: > > > > > > > > > > >I need protocol stacks for Android, including ADB, MSD, BEE, etc. > >Says Linux? =A0It's too big and no native support for BEE (ZigBee). > >Says Atmel or Microchip? =A0I've worked with both USB stacks. > >They are both very similar: inefficient and deficient. =A0I 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. =A0The 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. =A0I 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. =A0I am going to move the DCBs to a new file > >and add functions to retrieve pointers to the DCBs. =A0I 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. =A0I need 256K flash. > >Also, I am going to remove all PIC18 codes. > > >I am going to post the mods. =A0We 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 *; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // Device Control Block > > >adb[0].shit =3D other shit; =A0 // index is always 0 > >------------------------------------------------------- > ><<New>> > > >dcb.c: DCB {union cdc, cdd, nsd, adb} dcb[6]; > >cdc.c: cdc =3D &dcb[0]; =A0 =A0 =A0 =A0 =A0 // CDC control > >cdd.c: cdd =3D &dcb[1]; =A0 =A0 =A0 =A0 =A0 // CDC data > >nul.c: nul =3D &dcb[2]; =A0 =A0 =A0 =A0 =A0 // Not used > >nul.c: nul =3D &dcb[3]; =A0 =A0 =A0 =A0 =A0 // Not used > >msd.c: msd =3D &dcb[4]; =A0 =A0 =A0 =A0 =A0 // Mass Storage > >adb.c: adb =3D &dcb[5]; =A0 =A0 =A0 =A0 =A0 // Android Debug Bridge > > >DCB *adb =3D dcb_init("ADB"); =A0 =A0 =A0 // return &adb[5]; > >void dcb_task("ADB"); =A0 =A0 =A0 =A0 =A0 =A0 // run ADB task > > >adb->shit =3D other shit; > > =A0 Silly rabbit. =A0Tricks 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.
Reply by ●May 4, 20112011-05-04
On Tue, 3 May 2011 03:24:46 -0700 (PDT), linnix <me@linnix.info-for.us> wrote:>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
