Small update about the DSO calibration. As I mentioned I was measuring each combination of input voltage and channel vertical position. The dependency of ADC output from input voltage is pretty linear (at least in the range 16…240), so the only issue to achieve small error is compensating the vertical position. For each position I was calculating the linear approximation of measured values (adc => voltage) with well known formula Y=k*X+q. The “q” coefficient is function of vertical position and is pretty linear. The interesting thing is, that the “k” coefficient is really strange and I had to use 6-point linear approximation curve for it. Everything is calculated in HTML/javascript and all the charts / coefficients you can see here:
http://pub.valky.eu/dsocalib/calib_display.html
The javascript calculates everything necessary and produces directly C code that can be compiled with the DSO. Don’t worry, it was only for the development/debugging purposes. I am working on onboard calibration algorithm, but it doesn’t achieve so nice results because the internal generator of DSO cannot generate negative voltages. Currently I was able to calibrate my device in 200mV range and the results look really good!
Anyway, if it doesn’t measure accuratelly, you can play a snake game I designed for DSO and is part of the User applications of latest firmware
Regarding the double linked list that alys mentioned. Yes I know about that. But I was thinking hard to design the CWnd class as simple as possible to keep the memory requirements as low as possible. Reverse iterator is only used when the back key is pressed and the window system is looking for previous children to give focus to it. Instead of having pointer to the previous children I decided to find it programatically by iterating the window parent’s children. It is slower, but it doesn’t matter, because the user can’t notice it. So the pointer to previous window is redundancy and I was trying to remove all redundancy I was able to find.
The window system I designed is lightweight and easy to maintain. I am not using any dynamic allocation or other C++ things. I used only the C++ features to keep the code nicely organized and easy to read. I am not C/C++ expert, but I am sure that by using C++ your code will not require more than 10% extra rom/ram than the same project written in C.
Maybe the seeedstudio team will design new version of DSO with more powerful CPU and this will not be an issue at all Currently the binary size of my firmware is 64kB, so the half of the program space is still available…
Gabriel