Remote iron debugging

Debug demoboard installed in WishBoard

I remember happy student years when there was a lot of free time. Golden times when a boring couple could write a program or read a useful book. Or sit with a soldering iron or in deep debugging for a day on the fly, without sleep.
These wonderful times of crazy creativity ended when I got a diploma and got a full-time job. Then the glorious freelance ended and harsh everyday life began. I had a strong feeling that someone had stolen 11 hours from my life (two hours of travel, one hour of lunch and eight hours of work). The saddest thing was that at work I was exhausted so much that I couldn’t even think of any night vigils: I came, had supper, and went to bed, otherwise a vegetable tomorrow. In the end, in the end, this state of affairs ceased to suit me, and I began to think what to do.
In my hobby - doing electronics, I mainly make devices on microcontrollers. The assembly of the debugging scheme, as a rule, is fast enough, the lion's share of the time is writing and debugging the program for the controller. And at work, I have such a resource as time (for example, lunch) and fast Internet. According to this, the idea of ​​remote debugging, and not only programs, but also hardware, was brilliant in its simplicity.

Concept

As the main operating system, I have Linux installed at home. This is a huge advantage and also a disadvantage.
What I love Linux for is its full versatility. The system is out of the box, there is immediately everything you need for complete happiness: a compiler, an office, a certain development environment and a package of necessary drivers. A huge plus - convenient work from the console, with the rapid forwarding of individual windows.
The main disadvantages are its relatively low prevalence, and the programs for controllers written in gcc are much less than on the same Keil. Also, for a long time I did not have a normal AVR programmer for Linux. Good programmers worked only in Windows, and under Vine they worked somehow crookedly and obliquely. Everything changed radically when I abandoned AVR and switched to workstations with bootloaders.
So, what do we need:
1. Remote access, with the ability to view various programs in graphical mode.
2. The ability to copy files and change them in real time.
3. Visual inspection.
4. Possibility of remote firmware
5. Remote emulation of keystrokes or other external events.

Plus, I had an additional option:

6. The ability to remotely turn on the computer.

Implementation

For the second point, I use a fairly obvious, but not the best solution - Dropbox. Not the best, because it does not allow you to control the versions of the programs that you write. My recommendations to those who will repeat to themselves - use SVN for software. It is much more convenient, and relieve headaches in the future.
For the third point, I chose the LPC2103 microcontroller (see the first picture), which allows you to flash yourself through UART. And there are already ready-made console programs in Linux that are simply registered in the Make-file, and it is flashed with one simple make program command

Remote inclusion

A faithful combat router

However, the most important and primary for me and my loved ones was that in my absence, by default, the computer should be turned off. Therefore, the implementation of Wake-on-lan was a priority. My computer is located behind the Asus WL-520 GU router. I already wrote in the article habrahabr.ru/blogs/easyelectronics/109395 about this router. Olegov firmware has a default program called ether-wake. The MAC address of the network card is substituted as parameters and the computer turns on. I wrote a small script that, after turning on, starts pinging the computer to set the boot time and the time when it will be possible to connect via SSH to my computer. The script looks like this

ether-wake 00: 1f: d0: 0b: 0b: 75
ping 192.168.1.109

Now, to turn on the computer, it’s enough for me to connect, for example using Putty to my router, run the script and wait for the pings to go:

[dlinyj @ WL-001E8C505364 root] $ ./wakeup.sh
PING 192.168.1.109 (192.168.1.109): 56 data bytes
84 bytes from 192.168.1.109: icmp_seq = 0 ttl = 64 time = 1.0 ms
84 bytes from 192.168.1.109: icmp_seq = 1 ttl = 64 time = 0.8 ms

Telework

It should be noted that at home I use Linux, but at work, which is logical, due to a number of circumstances, I use Windows XP. And if, to forward windows in Linux, it is enough to connect the following command to the remote machine:

ssh user @ host –X

Then in Windows this is not such a simple solution, and Putty cannot be avoided here. There are several options that I use one way or another. The first option, and the most brutal, is to install Linux on the working machine too, which I basically did. But due to the fact that we have very developed network services, as well as a strong workflow in MS Office format, I had to transfer it back to Windows. The second solution, similar to the first, but requires a lot of space on the hard drive, is installing Linux on a virtual machine.
The simplest is to use the Xming program, and I'm using this option right now. A description of how to do this can be found here www.openkazan.info/Linux_Desktop_from_Microsoft_Windows-Xming-SSH

Now it is possible to quickly launch graphical mode, for example gedit, which highlights the syntax well (I don’t like to use console applications because they occupy the console ) Or for example, you can see the last open tabs in the browser, the most common and necessary phenomenon. Usually at night, I look for the programming material I need, and in the morning from work on a fresh mind it’s good to process it. But it turns out that this is also the most important thing. Now there is the possibility of visual control!

Visual control

Agree, a special interest appears when there is an opportunity, how does your piece of iron blink with LEDs and do everything that you want. And there is such a possibility in the remote mode. It is logical that if you can forward the windows of programs, then you can forward the window that displays the image from the webcam. To transfer the image, I used the cheese program. To make it convenient to place the webcam on board, I just fixed it on the desk lamp


Webcam

Video course so slow and far transfer are not talking in real time, but you can see the blinking of the LEDs


The result of the cheese program

I want to note one nuance that in the light of sunlight - the glow of the diodes is completely invisible. Accordingly, I put in front of the board either a large sheet of cardboard, or books, so that they create a shadow.

Push buttons

Those who are engaged in electronics know that one of the main functions of the controller is the processing of environmental events. And for debugging these events - they must be created. There are many implementation options - hang a second controller, or an analog sensor, etc. I had to process a short pulse to work out an external interrupt handler program. For this, I took the old block of external relays.


Relay block

This thing is left over from my first job. There is a FT232BM chip, which is defined as a virtual COM port, Attiny2313 controller and a block of three relays. This is all controlled through a terminal program. The capital letter “A” turns on the first relay, “B” the second, etc., the small letters turn off accordingly. Alternatively, you can find some masterkit kits, or even do it yourself.

Conclusion

My post is a concept. It is not worth considering it as the ultimate truth. Instead of Linux, you can use Windows; instead of Dropbox, you can, and need to, use SVN; Instead of a powerful relay unit, you can use a second microcontroller, which will emulate the clicks. More smart people suggest that routers with Oleg firmware can also pick up a camera. In general, do not be afraid to experiment and remember that if you are an office rat and you cannot bring your shaitan device to work and poison all employees with rosin, this does not mean that you cannot do programming and electronics at work.

PS On GCC, I still could not debug the processing of external interrupts on the LPC2103 controller. If someone wrote on gcc for lpc21 ** controllers, then I will be grateful for all possible help, because I still could not find working examples and there is no one who can help me.