#if CAM_CONSOLE_LOG_ENABLED#define DEV_HDR_WRITE_OFFSET (0x14C/4)#define DEV_HDR_READ_OFFSET (0x148/4)#define DEV_HDR_READ_SEM_1 (0x14)#define DEV_HDR_READ_SEM_2 (0x3c)#define DEV_HDR_READ_RNGBUF (0x10/4)typedef int DEV_HDR;int (*_tyWriteOrig)(DEV_HDR *hdr, char *buf, int len);int hook_tyWriteOrig(DEV_HDR *hdr, char *buf, int len){ // Slow, but stable writes FILE *fd = fopen("A/stdout.txt", "a"); if (fd) { fwrite(buf, 1, len, fd); fclose(fd); } return _tyWriteOrig(hdr, buf, len);}int replaced_tyRead(int pTyDev, char *buf, int buflen){ // this can't just be replaced when the system's already up, because // the original tyRead is already called by then (and it will wait indefinitely) // unless ... semGive is called on the 2 semaphores inside the original routine // note: buflen is 1 !! static int firsttime = 1; if (firsttime==1) { firsttime = 2; FILE *fd = fopen("A/chdklog.txt", "a"); if (fd) { char buff[64]; int bufflen = sprintf(buff, "pTyDev: %x, buf: %x, len: %x\n", pTyDev, (int)buf, buflen); fwrite(buff, 1, bufflen, fd); fclose(fd); } if (buflen>0) { msleep(2000); buf[0]='?'; return 1; } } else if (firsttime==2) { firsttime = 0; if (buflen>0) { buf[0]='\n'; return 1; } } while(1) { msleep(1000); } return 0;}void cam_console_init(){ DEV_HDR *DRV_struct; int tmp; extern DEV_HDR* _iosDevFind(char*, void*); DRV_struct = _iosDevFind("/tyCo/0", &tmp); _tyWriteOrig = (void*)DRV_struct[DEV_HDR_WRITE_OFFSET]; FILE *fd = fopen("A/chdklog.txt", "a"); if (fd) { // can't be used with "Fut" API //fprintf(fd, "DRV_struct: %x, _tyWriteOrig: %x\n", DRV_struct, _tyWriteOrig); char buf[256]; int buflen = sprintf(buf, "DRV_struct: %x, _tyWriteOrig: %x\n", DRV_struct, _tyWriteOrig); fwrite(buf, 1, buflen, fd); } FILE *fdout = fopen("A/stdout.txt", "r"); if (fdout) { // replace device write handler DRV_struct[DEV_HDR_WRITE_OFFSET] = (int)hook_tyWriteOrig; // replace device read handler DRV_struct[DEV_HDR_READ_OFFSET] = (int)replaced_tyRead; extern int _semGive(int semID); // low level Vx function extern int _rngBufPut(int id, char *buf, int len); // Vx ringbuffer related function // put some data into the read ringbuffer (in order to allow the read handler to return) int r1 = _rngBufPut(DRV_struct[DEV_HDR_READ_RNGBUF], "\n\n\n\n", 4); // unblock the 2 possible read semaphores (only the first appears to be needed, they are actually the same semaphore) int r2 = _semGive((int)DRV_struct + DEV_HDR_READ_SEM_1); int r3 = _semGive((int)DRV_struct + DEV_HDR_READ_SEM_2); // the original read handler will now return, the replaced one will be called from now on // get some debug info char buf[64]; int buflen = sprintf(buf, "rngbp: %x, sg1: %x, sg2: %x\n", r1,r2,r3); fwrite(buf, 1, buflen, fd); fclose(fdout); fwrite("tyWrite replaced, camera log enabled\n", 1, sizeof("tyWrite replaced, camera log enabled\n")-1, fd); } if (fd) { fclose(fd); }}#endif
I have extended the latter by replacing the read handler routine of the /tyCo/0 device.
I am a little unclear on this, do we need to modify the /tyCo/0 device, or the default stdin,stdout and stderr handlers?
If we modify the /tyCo/0 handler, does this not then render the UART unusable for anything else?
If you redirect the default stdin,stdout and std err handlers, that then frees up the UART for other purposes. If on the other hand, you patch the UART handler, then anything which subsequently attempts to use the UART will instead read and write to your patched handler.
Quote from: ahull on 13 / December / 2013, 00:57:38I am a little unclear on this, do we need to modify the /tyCo/0 device, or the default stdin,stdout and stderr handlers?Since the earlier hacks modified the read/write handlers, I followed that route. It's possible to modify the global std* file descriptors too (on VxWorks at least), you can give that a try: ioGlobalStdSet, you can find the address in the above patch. You most likely won't get usable results with 'disk' files. BTW, the pipe library is available on the ixusW, I checked it.
QuoteIf we modify the /tyCo/0 handler, does this not then render the UART unusable for anything else? QuoteIf you redirect the default stdin,stdout and std err handlers, that then frees up the UART for other purposes. If on the other hand, you patch the UART handler, then anything which subsequently attempts to use the UART will instead read and write to your patched handler.My intention was to "talk" to the camera console, in a quick and dirty way. If that goal can be achieved differently (for example by creating a custom device for the standard file descriptors), then it's probably possible to talk to the console and use the uart at the same time.I'm now trying to research the same in DryOS. Only succeeded to replace the write handler, the trick I used on the read handler in the above example doesn't seem to work yet...I changed the topic title.
BTW, the pipe library is available on the ixusW, I checked it.
/pipe/id%03d%cpipe0pipe1wpipe0wpipe1cat: write error: Broken pipe
It would also be useful to have access to ioGlobalStdGet( ) so we can check to see the values they are currently assigned, and restore them when we have finished using them.
if you have anything you want me to test, let me know
Quote from: ahull on 14 / December / 2013, 00:41:26It would also be useful to have access to ioGlobalStdGet( ) so we can check to see the values they are currently assigned, and restore them when we have finished using them.It's right after the other routine, @ 0xffc1b154.
Quoteif you have anything you want me to test, let me knowNo progress yet. I simply don't have an idea what's happening. I have replaced both the read and write handlers during the boot process, and the read handler is simply not called at all (the other one is working). No such problem on VxWorks...
Very odd, for DryOs, sounds like either you have misidentified it (unlikely, but perhaps a typo somewhere in your code), or it is somehow already redirected.
Dry> dminfo[Driver Entry] total : 5 (DRV_ENTRY_MAX) used : 3[Created Devices] drvNo name 2 A 0 /_term[Default Device] device name : [File Descriptor] total : 31 (DM_FILE_MAX) used : 6 open : 3Dry> exit
Started by ..::T3::.. Creative Uses of CHDK
Started by alvm General Discussion and Assistance
Started by dclaar General Discussion and Assistance
Started by bootstrap DryOS Development
