Ideas for taking input via telnet?

Started by dstan, October 25, 2014, 04:47:48 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

dstan

I'm working on a module to control my camera over wifi via a rooted transcend wifi sd card. Ive been trying to use the file io to detect and parse files that I write to the card via telnet into fake_simple_button commands , but with no luck. Does anyone have any ideas regarding how I could pass integer values from telnet into the module?

dmilligan

So what exactly are you having trouble with? Are you able to detect the files you add? Are you able to open them and read from them? Are you just having trouble with integers?

There are two ways you could read integers from files, either represent the integer as ASCII text and use atoi() or just write the integer into the file as binary.

Example to read a single integer out of a binary file:

int my_integer = 0;
FILE* f = FIO_OpenFile("fname", O_RDONLY );
if(f)
{
    if(FIO_ReadFile(f, &my_integer, sizeof(int)))
    {
        //do something with my_integer
    }
}

dstan

I've been using a similar function for finding the file and executing the button press that executes repetitively in a loop. It works if the command file containing the int is in place before the module is switched on. The problem I'm having is that after the initial pass of the loop, the module can't seem to recognize that the command file has been changed in some way. I've tried a lot of different things, including parsing the value of the file and having the presence of the file act as a simple flag to either press the shutter or not. I've also tried removing the command file after it has been parsed/executed and keeping the file but setting its contents to null.

In each case, I run into basically the same problem- the file io functions don't recognize that a command file has been created/changed. It's as if I need to call some kind of refresh function in order to see that a new command file has been added. If I create a file via telnet, I an see it via ls, but the camera (file manager and my functions) can't see it until after a reboot.

eduperez

Others who tried something similar (using a 400D and 400plus) faced the same problems: looks like the camera caches the content of the card, and thus external modifications remain unnoticed. As far as I know, they did not manage to find a way around this issue.

Recent Canon cameras have specific menu entries to control some functions from the Eye-Fi cards, so it seems there is a protocol to talk to the card from the camera; perhaps there is a way here...

dstan

Thanks, I'll look into that and see what I can find

dstan

I think there may be a simpler way of doing it than messing with eyefi stuff. When a picture is taken, file manager can see that there is a new file in /DCIM/100EOS5D and that the .CTG file in /DCIM/EOSMISC has changed size. File manager also can see a new .MLV file without a reboot. Does anyone know what's done when writing an MLV file that makes it show up in file manager without rebooting?

g3gg0

i already implemented smth like that.
there are some problems with those devices.

a) you can only write blockwise. there are no pipes or compareable thing. blocksize is 512 byte.

b) you can never simply write from the linux side onto the card and immediately see the content on the camera side.
on the linux side i always did a fsync() onto the files and a sync() to write back all caches.
and still it takes up to a second or more sometimes until the camera sees this data :(

c) these cards are crappy. mine died after only a few months. i only used it for ML on the 5D3.
first it was bent mechanically due to the wifi getting hot. then it sometimes destroyed file system sectors
when linux and dryos both accessed a file, altering its size (obviously not a good thing ;) )
and some time later it just didnt respond.

trwifi.c: http://pastebin.com/M3csG9Hw
daemon.c: http://pastebin.com/8Fdwad6G
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!