0

I'am currently developing an application for an embedded system (RTEMS for RPI2). As you may know developing proccess on embedded systems imply:

  1. Modifing the program
  2. Compile it and load it into de SD card
  3. Insert the SD card on the board

It is a tedious process, and you can even break the SD slot for the constant usage. This is the reson why i'am trying to set up a comfortable enviroment for developing and deploying the application on the RPI. My idea is to use Eclipse as IDE for all the proccess (edit, compile and execute). So far these are my ideas for solving the different problems:

  • Usage of U-boot for loading the application images from TFTP. [That solves the problem of plug & unplug the SD card]
  • Use CTD eclipse pulgin [That solves the problem of compiling]
  • Use of Terminal View eclipse plugin instead of putty [That solves the problem of viewing the application console prints]

As you may notice the only problem i have unsolved is the one of executing. The idea is that whenever you compile the compiled file is located at the TFTP server directory, so it is accesible for u-boot client to load. The thing i don´t know how to do is how to tell remotely u-boot to reaload the image (the image would always have the same name). I know i can just simply reset the RPI but i don´t know if that can damage something, and also i'am curious to know if there is a more elegant way to do it.

Another thing i would like to do is to somehow specify if you want to run the application on the target or on a simulator like QEMU.

Thanks in advance

Mario
  • 19
  • 4
  • I think your main problem is that U-Boot hands over the system to the application. So if your application doesn't reset (embedded applications normally don't exit so I assume that's the normal case), you won't have a possibility to re-load your image. – Christian Mauderer Mar 13 '20 at 06:24
  • Yeah thats exactly the main problem, I don´t know first if you can cancel from u-boot the executtion of the image. And second if can do that remotely. – Mario Mar 14 '20 at 11:17
  • You can't cancel the execution from U-Boot because U-Boot stops running as soon as it hands over to the application. For that you would need a hypervisor or virtualization that continues to run in the background. But if you want to save your SD card slot you have multiple other possibilities: 1. Reset via a power cycle (maybe a switch). You can use a USB extension cord and risk only the two USB connectors. 2. There is a RUN two pin connector. According to some pages it might could work as a reset button. 3. Use a JTAG debugger to load your application. 4. Use a SD extension cable. – Christian Mauderer Mar 14 '20 at 19:47
  • Thanks for your answer Christian. From the solutions you say, i think they are more centered con the problem of plug-in and un-plugin the SD card, and that is actualy my current problem (that is solved with u-boot). What i need is to somehow cancel one execution and reload again the updated image. It totally makes sense what you said first (u-boot can not be canceled since it stops executing), the option you said of a hypervisor i think is too complicated (i´am currently doing this as an final degree project). Actually i am more interested in the JTAG debugger you mentioned. – Mario Mar 16 '20 at 14:55
  • (Sorry that i split my comment in two but i exceeded the maximun size in the previous). Does that JTAG let you to cancel and reload the image ?. Another idea i have, but i don´t know if it is feasible is to enable an interrupt on the application that strikes whenever i write to the serial input and aborts the execution. – Mario Mar 16 '20 at 15:00
  • With a JTAG debugger you should be able to cancel and reload an image if it is set up correctly and if the raspberry is supported. But setting up a debugger can be quite some work too and you have to invest into hardware before you know whether your setup works. The other solution you mentioned (an interrupt) is possible too. But it means that your application has to behave. If it hangs somewhere (e.g. in a higher prio interrupt) that won't work. But if you think about toggling a pin: Take a look at the RUN connector. Maybe you can force a reset with it. – Christian Mauderer Mar 16 '20 at 18:24

0 Answers0