Menu

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.

Show posts Menu

Messages - g3gg0

#2876
Tragic Lantern / Re: Limits be gone.
August 03, 2012, 04:05:33 PM
i updated the file for 600D in post above as it didnt work clean:

http://upload.g3gg0.de/pub_files/774d811f625071bfbd66d7d7f1e71e93/autoexec.bin

now just press "dont click me" and *then* you can start recording..

top bar shows:
R0: (upper 32 bit max size) R1: (lower 32 bit max size) R2: (upper 32 bit current size) R3: (lower 32 bit current size)

can anyone try if the 4GiB file limit is still true?
bitrate viewer at least shows no errors, but a clean, constant bit rate.
VLC still fails to play beyond 4GiB
#2877
Tragic Lantern / Re: Limits be gone.
August 03, 2012, 10:21:03 AM
an alternative for finding the right addresses would be

0xFF04E88C void mvrAppendCheckSetRecLimit ( uint32_t max_bytes, uint32_t max_seconds)
#2878
Tragic Lantern / Re: Limits be gone.
August 03, 2012, 01:51:12 AM
first progress here on 600D. (although not working fully)
you have to format card in exFAT format.
if you use FAT, the file will definitely be truncated to zero.


    uint32_t *movRec = *((uint32_t**)0x1E40);
   
    /* set maximum to 0x3FFFFFFFF bytes (16GiB) */
    movRec[80] = 0x00000003;
    movRec[81] = 0xFFFFFFFF;


this increases the recording limit to 16GiB, but after 4GiB the file only gives a white noise and no video anymore in VLC.
already late, dont have time to find the reason right now. maybe its VLC, because in hex editor the file doesnt look corrupted.
not sure. maybe i am wrong.

initialized here:

str_MVR_Initialize
...
ROM:FF04E5EC 00 00 E0 E3                 MOV     R0, 0xFFFFFFFF  ; set maximum size
ROM:FF04E5F0 10 70 84 E5                 STR     R7, [R4,#0x10]
ROM:FF04E5F4 40 01 84 E5                 STR     R0, [R4,#0x140] ; lower 32 bits
ROM:FF04E5F8 00 50 A0 E3                 MOV     R5, #0
ROM:FF04E5FC 02 0C 84 E2                 ADD     R0, R4, #0x200
ROM:FF04E600 44 51 84 E5                 STR     R5, [R4,#0x144] ; upper 32 bits


any 600D user with proper toolchain wants to try?
http://upload.g3gg0.de/pub_files/774d811f625071bfbd66d7d7f1e71e93/autoexec.bin
click "dont click me" while recording.
#2879
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 ;)
#2880
General Development / Re: 600D Audio Controls?
August 02, 2012, 10:23:41 PM
really exhaustive configuration possibilities :)
good work!
#2881
@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)


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
#2882
Tragic Lantern / Re: Limits be gone.
July 31, 2012, 05:32:00 PM
(tried to send this message some days ago, but the forum told me, i would spam :) )

i looked at the code you found, but its just the code that checks if appending is possible.
also i dont think that "just continuing" writing will work. i bet, you get files of size 0+ after 4GB.
copying to PC will for sure make problems.

will look into this in spare time again.

br,
g3gg0
#2883
Tragic Lantern / Re: Limits be gone.
July 27, 2012, 01:49:56 AM
i would recommend this method:

1) hook the check function
2) when coming near the 4GB limit, signal some ML thread to open another file (async in low prio task)
3) when hitting 4GB limit, use the file handle ML created and continue writing there
4) tell ML the old file handle and ask to close that file (again async in low prio task)

that would enable seamless video recording without any loss. in theory :)
#2884
thats quite simple if you look at the changes i made to the tools.
#2886
noticed this thread and the questions.
its already late - will answer tomorrow :)

cya
#2887
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!
#2889
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 :)
#2890
well, maybe this tool may help you in finding the best frame rate:
http://www.g3gg0.de/wordpress/uncategorized/eos-timergen-tool/

br,
g3gg0