naftilos76

Hi everyone, This is my first serious project but also a huge challenge for me as i am not doing this out of spare free time, as i don't have any, but because i want to know more about electronics, programming and most of all be part of something that just isn't there. Ever since the early days (maybe not that early) of DSOs first both pc-connectable and standalone portable devices, i wanted to get my hands on a high speed, but not 8-bit, portable DSO that could eliminate the use of a multimeter. What i am saying is that i want to be able to actually see what i am measuring in terms of waveform, distortion, frequency, harmonics etc (except of course DC). That is why this is my attempt to approach a design of a multipurpose multimeter-like DSO that does all the things that a high speed & resolution digital oscilloscope is capable of but also offers all kinds of measuring capabilities of advanced high resolution expensive bench multimeters including V, A, R, L, C and lots of other functions. If you take a look at bench DSOs that integrate a LCD on them you will notice that most of them are 8 bit and 320x240px or a little bigger than that. Higher resolutions are indeed there but usually cost much more and tend to be difficult to be reached by an average hobbyist or even professional. Something else which i totally consider a must as far as portable DSOs as concerned is the presence of touch panel capabilities which may exist in the market but in a limited range (at least for now). Buttons can simply be no more by using touch panel enabled devices which will make the design less complex as far as the pcb design is concerned but also when you reach the point of 3D designing the plastic/metal enclosure that will hold the pcb, lcd and batteries. The current hardware is based on a STM32F4 discovery board, a LCD 800x480 configured to work with the FSMC of the STM32F407 and a touch panel that came with the LCD. The mcu seems to be fine for now but i will probably move to another ARM mcu probably clocked at >500MHz. Time will show as the processing demands will increase. It is not necessary but i will say that ChibiOS & uGFX will star in this device as i think that both ChibiOS & uGFX are quite remarkable pieces of software. So i will give you an idea of my target features for this project whose completion is not to be expected in a few months but rather in a few years time, hopefully not more that 2-3. 1) LCD 800x480 or higher resolution TFT <=16bit colors 2) Resistive touch panel 3) 1 channel x 24bit 4Msps mostly for low frequency but high precision multimeter like measurements of V, A, R. 4) 2 channels x 16bit greater than 200Msps for high freq content being able to measure both non-repetitive and repetitive signals (in much higher frequency). 5) Power analyzer (W/VA/PF etc) for up to 100KHz with integrated current transformers (2 channels to compare with each other - will use the 24bit adc to capture) and optional external Rogowski coils (1 channel 3 phase capable - will use the 24bit adc to capture) displaying both HV and A waveforms (cool) including extended (days) logger of consumption (W, VA, PF) all simultaneously appearing on the lcd with zoom-in & out capabilities. 6) FFT analyzer 7) LC high precision meter. 8) (Considering) Logger of V, A, R, Temperature, Lux, Pressure and virtually every single type of sensor out there. 9) (Considering) Megger test up to 600V 10) (Considering) 10 channel digital logger for analysis of various protocols such as RS232, SPI etc My first video for this project is already on Youtube one month after i started the project. Wish me luck and lots of patience! Any suggestions are welcome.

Thank you sir for your time to clarify on my issue. My thought is that any window drawn over another could impose a clipping area that would prohibite the window on the back to draw there. After setting visibility of the foreground window to false then the window on the back could be redrawn / refreshed etc. However i have not studied the background code of they window manager inside uGfx and therefore i may just being silly! Anyway, i got my answer and will probably will find an indirect way to do things like i am now. That is, i stop all activity on the background window when i trigger a menu items list to appear on it an re-start it when the list goes invisible through the use of semaphores as i am using a few threads. Thanks again. Regards naftilos76

Hi, I noticed that while setting visibility of an items list to "on" on top (overlapping) of a GGraphObject window area, where a waveform is being drawn, the waveform draws on top of the items list instead of staying in the background. So my question is whether an items list can exist unharmed (not affected) on top of other windows or graph objects (within a window) while drawing operations take place on them. Regards naftilos76

Hi Tectu, After a few tests i noticed that no matter what the speed of the mcu gwinSetText() did let me see some frame-like-dropping artifacts. That of course is due to the gwinFillArea() that's probably used to wipe off the area of the char(s). Playing a little with my own routine, which double buffers and remembers what the previous string was, i got no artifacts as well as no noticeable reduction in refreshing speed. It is easily understandable that this concerns mostly the usage of fixed-width fonts while variable-width fonts can still be used with this method and eliminate the frame-like-dropping artifacts. That is definetely something that has to be integrated into ugfx because it simply can help increasing its' performance and fans. The code is a little messy. I have used it in the past with some fonts of mine generated by a win app generator. I have attached all of them for anybody's reference willing to explore it's functionality. Regards naftilos76 gstr.zip

Hi Tectu, Thanks for your prompt response. Your answer cleared things up. I will test the case of having multiple labels at a redrawing rate of 5/s and will give you my feedback. I have written my own code for drawing texts and updating only the chars that are different even if the different ones are the second and the 5th and so on. For example: 1st: 0.6754Vrms (first update - all chars drawn) 2nd: 0.6655Vrms (second drawing - only elements 3 & 5 will be updated) This however requires as you correctly stated double buffering and preferably malloc which however requires special handling in ChibiOS. Using gwin labels doesn't let me draw on them but only if i do not use windows at all and restrist my calls only to gdispDraw... That would need integrating the code in uGFX. When i try the labels i will give you my final feedback regarding whether i can see any frame-dropping artifacts. Thanks for your time Regards naftilos76

Hi, I would like to ask whether the redrawing of the labels means erasing the whole previous contents area with the selected background color or updating only the new or different chars or even comparing bit by bit every char with the previously one drawn. I initially tried drawing with gdispDraw.... lines, text etc and i noticed that a frame-like-dropping artifact was visible when i drew a black filled rectangle over the previously drawn text and then the new text on that area. So what kind of updating is going on on labels when a new text is drawn on it? Is there any margin of improving especially when updating 20 or 30 strings of 5-6 chars each? Regards naftilos76

Hi Tectu, You were absolutely right. That is probably the best method of doing things like drawing around, showing text etc. Everything must be an object with its' dedicated space to draw onto. I have tried so far creating a graph area and lots of labels which show various values. After struggling a little bit with the documentation and the uGFX website i got it working. Thanks a lot. Regards naftilos76

Hi everyone, I have a problem with a window widget which contains a list. It shows up on the lcd just fine, it interracts with the touch panel well but when i call gwinSetVisible(window_handle, FALSE) i get a white area previously occupied by the window. Furthermore and most important i cannot draw anything outside this area. I even tried calling gwinDestroy() to destroy the window but still the problem persists. A simple few lines of code confirmed to me my sayings above: gdispFillArea(100, 60, 300, 250, Red); chThdSleepMilliseconds(2000); // The red rectangle area was filled with red as expected on the lcd gwinSetVisible(ghList1, TRUE); chThdSleepMilliseconds(2000); // The window containing a list of items was drawn as expected on the lcd covering partly the red rectangle area gwinSetVisible(ghList1, FALSE); chThdSleepMilliseconds(2000); // The area occupied by the window got white gdispFillArea(100, 60, 300, 250, Blue); chThdSleepMilliseconds(2000); // The blue rectangle area was drawn only on the area previously occupied by the window ghList1 gwinDestroy(ghList1); chThdSleepMilliseconds(2000); // Nothing changed on the lcd gdispFillArea(100, 60, 300, 250, Yellow); chThdSleepMilliseconds(2000); // The yellow rectangle area was drawn only on the area previously occupied by the window ghList1 Am i doing anything wrong? What is the reason that i cannot draw outside the area of the window after setting its' status to invisible? Regards