This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Late Night Question

Please bare with me, oh and don't laugh..

If/when I get a dev board, I would like to try and port a small (3-5Mb) windows program. The problem is I have no experience with this sort of thing. I don't know a lot about linux, or any programming language (I once made a "hello world" program and a few other things in c++)...

I have this camera LINK it has a basic GUI and a boot screen. Well a while ago I wanted to try and change the boot screen, so I got hold of some firmware for it so to see how it's made up. I was expecting to find some sort of jpg/png file for the boot screen, but the firmware comprised of just two bin. files.

I got a program to open and edit the bin files, saw the contents and thought, I have no idea what I'm doing. I closed the program and gave up.

Now here comes my question. In a case like this would you have to convert the bin files to some other file format so that you can edit it, I mean for the boot screen you must have a image file of some sort, a jpg etc, so where is it!? does the boot screen file just get turned into 1's and 0's?

Back to the windows prog I wanted to try and port. I think it's just in bin format too, so I tought if I can understand how my camera GUI/OS works it may help with porting that windows app...I may be way off the mark here, hopefully someone can put me straight...Cheers

Parents
  • All images are stored as ones and zeroes. That is the contents of gif, jpeg, png files.

    It is possible to place a gif or jpeg file inside another file, so a bin file can contain both a program and an image. Then there normally exists program that can locate the image inside the bin file and replace that part with another image, as long as the new image is small enought that it will fit.

    Sorry, but looking at a bin file will not tell you how a real program works. You have to go the other way. Either write larger and larger programs yourself, or read existing example source and try to understand what the source does.

    Next sorry: There are just zero correspondence between the functioning of an embedded application and a Windows program. A few (but huge) differences:

    - the embedded application does everything itself.

    - the windows application has a huge set of advanced functions available from the OS.

    - the embedded application either jump around looking at all serial ports, keyboard buttons etc one by one in a continuous sequence (super-loop) or you must buy, write or find a free real-time OS that allows the processor time to be switched between different tasks.

    - the windows application is event driven. it has a queue where Windows adds information about a huge number of events that happens, and where the application then eats them one by one and decides if the events should affect what you see on screen, or if they represent input data or commands to react on.

    - the embedded application is a 24x7 self-contained program that is expected to do its work without supervision. Hence, embedded equipment normally have a minimum of interfaces. They may have inputs but are often very lacking when it comes to outputs. A LCD display showing a number of characters is often a huge luxury.

    - the Windows application is more or less assumed to be fully controlled by an end user, so the primary interfaces - display, sound, keyboard, mouse have a huge bandwidth for interaction with a user. The remaining interfaces are often quite lacking - Windows can have problems taking full advantage of a USB, network or serial interface, since the primary concern is the interactive channels.

    Because of this, a GUI application (Windows, Mac, X-Windows, ...) can with experience be ported to another OS with similar capabilities. Simpler programs can also sometimes be ported to a PDA or a mobile phone or similar.

    But these are advanced tasks, and unless you have a software framework for porting from target A to target B, you must know a huge amount of details about the source and destination hardware (and - if applicable - source and target OS).

    In your case, I would recommend that you start off by taking on larger and larger projects developing programs for your development board. When you have managed to develop a couple of reasonably complex applications, then you will also have an idea what makes the applications tick, so you will have a better understsanding of what new challenges you can aim for.

    It is possible to do a lot of fun things with a text or graphical LCD. Then there are all the mass-produced hardware where people have reverse-engineered the hardware design and developed own software, allowing people to write their own applications for game consoles, network routers, mobile phones... The sky is the limit when it comes to challenges, but it is important not to set too difficult goals or you will get disappointed and frustrated and end up with an unfinished project.

Reply
  • All images are stored as ones and zeroes. That is the contents of gif, jpeg, png files.

    It is possible to place a gif or jpeg file inside another file, so a bin file can contain both a program and an image. Then there normally exists program that can locate the image inside the bin file and replace that part with another image, as long as the new image is small enought that it will fit.

    Sorry, but looking at a bin file will not tell you how a real program works. You have to go the other way. Either write larger and larger programs yourself, or read existing example source and try to understand what the source does.

    Next sorry: There are just zero correspondence between the functioning of an embedded application and a Windows program. A few (but huge) differences:

    - the embedded application does everything itself.

    - the windows application has a huge set of advanced functions available from the OS.

    - the embedded application either jump around looking at all serial ports, keyboard buttons etc one by one in a continuous sequence (super-loop) or you must buy, write or find a free real-time OS that allows the processor time to be switched between different tasks.

    - the windows application is event driven. it has a queue where Windows adds information about a huge number of events that happens, and where the application then eats them one by one and decides if the events should affect what you see on screen, or if they represent input data or commands to react on.

    - the embedded application is a 24x7 self-contained program that is expected to do its work without supervision. Hence, embedded equipment normally have a minimum of interfaces. They may have inputs but are often very lacking when it comes to outputs. A LCD display showing a number of characters is often a huge luxury.

    - the Windows application is more or less assumed to be fully controlled by an end user, so the primary interfaces - display, sound, keyboard, mouse have a huge bandwidth for interaction with a user. The remaining interfaces are often quite lacking - Windows can have problems taking full advantage of a USB, network or serial interface, since the primary concern is the interactive channels.

    Because of this, a GUI application (Windows, Mac, X-Windows, ...) can with experience be ported to another OS with similar capabilities. Simpler programs can also sometimes be ported to a PDA or a mobile phone or similar.

    But these are advanced tasks, and unless you have a software framework for porting from target A to target B, you must know a huge amount of details about the source and destination hardware (and - if applicable - source and target OS).

    In your case, I would recommend that you start off by taking on larger and larger projects developing programs for your development board. When you have managed to develop a couple of reasonably complex applications, then you will also have an idea what makes the applications tick, so you will have a better understsanding of what new challenges you can aim for.

    It is possible to do a lot of fun things with a text or graphical LCD. Then there are all the mass-produced hardware where people have reverse-engineered the hardware design and developed own software, allowing people to write their own applications for game consoles, network routers, mobile phones... The sky is the limit when it comes to challenges, but it is important not to set too difficult goals or you will get disappointed and frustrated and end up with an unfinished project.

Children