On May 3, 9:22=A0pm, George Neuner <gneun...@comcast.net> wrote:
> On Tue, 3 May 2011 03:24:46 -0700 (PDT), linnix
>
> <m...@linnix.info-for.us> wrote:
> >On May 2, 4:50=A0am, UpYerNose <UpYerN...@witarubbahose.org> wrote:
>
> >> =A0 Silly rabbit. =A0Tricks are for kids.
>
> >Don't really understand your response.
>
> It's a misspelled reference to a line of cereal commercials:http://www.yo=
utube.com/watch?v=3DqXa0ukxnKhU
>
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.
Reply by George Neuner●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.
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.
>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 linnix●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 linnix●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.
>
> 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.
>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 m II●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 linnix●April 25, 20112011-04-25
On Apr 25, 9:14=A0am, Glenn <glenn2...@gmail.com> wrote: