Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - g3gg0

Pages: 1 ... 110 111 [112]
2776
success.
i am able to access the LED to drive some photodiode/opamp circuitry that amplifies the signal.
still have to increase amplification, cancel overshoot, add schmitt-trigger and feed that to some MAX232, but as proof of concept this is fairly good :)

not sure if i will do that. i dont need it ;)

circuit:

2777
So instead of re-writing all of the boot code (which appears to be the problem with the 5dc, some cameras work some don't. The ones that don't are halting on the bootcode I have written), we call the camera's normal boot procedure directly and hardly have to do a thing :)

yep, thats the point about the cache hack :)
minimally invasive patching of instructions "pseudo-in-place"

unfortunately we got weird results on models like 60D, i was not able to explain :(

2778
Region 2, not sure about. I know the flag area is at 0xF8000000 so maybe related to that.

Region 2 is data flash. this must not be cached else flashing will not work as expected.


2779
General Chat / Re: 5Dmark II warming - CMOS TEMPERATURE
« on: August 08, 2012, 04:03:10 PM »
For me it's around 172–180 degrees.

i really, really hope this is wrong :)

2780
the only thing i will open is the card slot to swap CF card and the battery slot if the camera locks up ;)
both will be done a few hundred times i guess.

my SD card reader slot in my PC is already defective due to plugging/unplugging the card too often :)


2781
Reverse Engineering / Re: How does the camera take a picture?
« on: August 07, 2012, 11:26:13 AM »
you mean, switching WB/Picstyle on a per-frame basis?
what use is that for?

2782
Reverse Engineering / Re: How does the camera take a picture?
« on: August 06, 2012, 12:36:44 PM »
thanks alex,
a really useful log :)

i just looked deeper into movie recording state machine.
i think i will apply your logging routines to the movierecorder also.
especially file opening and closing is some unclear stuff.

br,
g3gg0

2783
here the try to make some RS232 compatible transmit function.
will build an optocoupler to verify if it works.

Code: [Select]

#define BITBANG_BAUDRATE       9600
#define BITBANG_TIME_NORMAL    10000
#define BITBANG_TIME_TRANSFER  (1000000/BITBANG_BAUDRATE)

uint32_t bitbang_orig_handler = 0;
uint32_t bitbang_time = 0;
uint32_t bitbang_bits = 0;
uint32_t bitbang_tb = 0;
uint32_t bitbang_hook_counter = 0;


void bitbang_main()
{
    uint32_t *led_port = ((uint32_t*)0xC0220134);
    uint32_t led_status = 0;   
   
    led_status = (*led_port) & (~0x02);
    led_status |= ((bitbang_tb & 0x01) << 1);
    (*led_port) = led_status;
   
    bitbang_tb >>= 1;
    bitbang_bits--;
}

void bitbang_transmit(uint32_t data, uint32_t bits)
{
    /* called from user space. we have to wait until transfer is finished */
    while(bitbang_bits)
    {
        msleep(1);
    }
   
    bitbang_tb = data;
    bitbang_bits = bits;
}

void bitbang_transmit_rs232(uint8_t character)

    uint32_t data = 0;
   
    /* invert data bits */
    character ^= 0xFF;
   
    /* we transmit in RS232 mode 8,N,1. add 4 idle bits bit and start bit */
    data |= (1 << 4);
    data |= ((uint32_t)character << 5);
   
    /* no parity, stop bits are zero, so we are done */
    bitbang_transmit(data, 5 + 8 + 1);
}

uint32_t bitbang_timer_hook()
{
    uint32_t *timer_reg = ((uint32_t*)0xC0210208);
    uint32_t (*handler)() = bitbang_orig_handler;
   
    /* for debugging */
    bitbang_hook_counter++;
   
    /* check if we have to transmit data */
    if(bitbang_bits)
    {
        /* use high timer rate while shifting out the bits */
        *timer_reg = BITBANG_TIME_TRANSFER - 1;
       
        /* call the bitbanging routine */
        bitbang_main();
   
        /* get as close to 10 ms as we can get. for longer use, we need fraction correction */
        if(bitbang_time > BITBANG_TIME_NORMAL)
        {
            bitbang_time -= BITBANG_TIME_NORMAL;
            handler();
        }
       
        /* when we get called the next time, time has advanced by BITBANG_RATE_TRANSFER */
        bitbang_time += BITBANG_TIME_TRANSFER;
    }
    else
    {
        /* no data to transmit, low timer rate, directly call original handler */
        *timer_reg = BITBANG_TIME_NORMAL - 1;
        handler();
    }
   
    return;
}

void run_test()
{
    /* install bitbang handler */
    bitbang_orig_handler = *((uint32_t*) 0x40000720);
    *((uint32_t*) 0x40000720) = &bitbang_timer_hook;
   
    int loops = 0;
    while(1)
    {
        msleep(100);
        bmp_printf(FONT_SMALL, 10,50, "Calls: %d", bitbang_hook_counter);
       
        if((loops++ % 10) == 0)
        {
            bitbang_transmit_rs232(0xAA);
        }
    }
}


2784
ok i tested my blink function.

a) the frequency seems to be 4800 Hz, so we have 9600 baud (~2% accuracy), 19200 might also be possible using that method
b) about the LEDs maximum frequency, i cannot tell if it will work or not. just had an IR LED as "detector" on oscilloscope.
its producing that little energy when the red LED lights it, i think the input capacitance of my oscilloscope is causing the slopes on the plot.


i think i should get some powered photodiode instead of that LED ;)

2785
General Development Discussion / Re: 600D Audio Controls?
« on: August 02, 2012, 10:23:41 PM »
really exhaustive configuration possibilities :)
good work!

2786
@cgapeart:

can you live with a LED-driven (optocoupled) solution?
but first we have to check whether the LED pin is low pass filtered with R/C or not.

if yes, can you give this code a try? dont have enough time at work to check that.
 - add it to debug.c (replacing run_test)
 - click "don't click me"
 - attach a photo transistor to the LED
 - measure if the LED is pulsed with 9600 baud alternating bits (4800 Hz)

Code: [Select]
uint32_t timer_hook_func = 0;
uint32_t timer_hook_counter = 0;

uint32_t timer_hook(uint32_t parm1, uint32_t parm2, uint32_t parm3, uint32_t parm4)
{
    uint32_t (*callee)(uint32_t, uint32_t, uint32_t, uint32_t) = timer_hook_func;
    uint32_t *led_port = ((uint32_t*)0xC0220134);
    uint32_t led_status = 0;
   
    timer_hook_counter++;
   
    /* blink LED */
    led_status = *led_port & (~0x02);
    led_status |= ((timer_hook_counter % 2) << 1);
    *led_port = led_status;
   
    /* get as close to 10 ms as we can get. for longer use, we need fraction correction */
    if((timer_hook_counter % 96) == 0)
    {
        timer_hook_counter = 0;
        return callee(parm1, parm2, parm3, parm4);
    }
}

void run_test()
{
    /* let system timer tick with 104 µs tick rate */
    timer_hook_func = *((uint32_t*) 0x40000720);
    *((uint32_t*) 0x40000720) = &timer_hook;
    *((uint32_t*) 0xC0210208) = 103;
   
    while(1)
    {
        msleep(50);
        bmp_printf(FONT_SMALL, 10,10, "Function: 0x%08X", timer_hook_func);
        bmp_printf(FONT_SMALL, 10,30, "R0:%08X R1:%08X R2:%08X R3:%08X", hijack_parm1, hijack_parm2, hijack_parm3, hijack_parm4);
        bmp_printf(FONT_SMALL, 10,50, "Calls: %d", timer_hook_counter);
    }
   
    return;
}


if this works, we have quite a good solution for two reasons:
 - we are optocoupled and dont have to mind about destroying the audio IC
 - we can do it without a lot of work to make audio ic transfers working from high resolution timer interrupts
 - it is simple ;)

br,
g3gg0

2787
thats quite simple if you look at the changes i made to the tools.

2789
noticed this thread and the questions.
its already late - will answer tomorrow :)

cya

2790
its not related to the firmware.
its the general problem about how to hijack the original firmware to execute ML.
also not clear: how to make ML run on both digics - and if this is really necessary.

my first task is to execute code on 7D and dynamically patch code in camera.
next is injecting own tasks into the system.

thats enough for the first few weeks :)
but we havy only one camera. ML developers share one body over some continents
thats the main problem.

if anyone can help us out, he would be our hero!

2792
Reverse Engineering / good book about ARM software developing
« on: July 10, 2012, 08:22:11 PM »
ARM System Developer’s Guide
Designing and Optimizing System Software

http://sundyn6410.googlecode.com/files/ARM%20System%20Developer%27s%20Guide.pdf

its really worth reading :)

2793
well, maybe this tool may help you in finding the best frame rate:
http://www.g3gg0.de/wordpress/uncategorized/eos-timergen-tool/

br,
g3gg0

Pages: 1 ... 110 111 [112]