kamocat

Hi everyone, I know it's been a while. I haven't gotten the dial working yet, because as far as I can tell, events aren't triggering the geventEventWait() function on my laptop. I haven't tried on my stm32. Anyway, I'm running out of time before classes start, and so I wanted to upload my progress for the benefit of the community. I sqaushed it into a single git patch. What I settled on for the dial input was overwriting the first n digits of the value. This seemed to make more sense than modifying the least significant digit, since the dial input seems to be for analog dials with limited range, rather than rotary encoders. Also, it allows use of the dial without the keyboard - it didn't seem to make much sense to use the dial in conjunction with the keyboard. If someone wanted an exact number, they would just type it in. Anyway, that's what the gwinNumericSetIntVal() is intended for. 0001-Creating-Numeric-Control-and-demo.patch

I found the issue. I had the D/C pin polarity backwards. I finally noticed when I was reading the datasheet for my other display. Data is HI. Control is LOW. Oops. So, now I have it running beautifully on SPI at 21 MHz. A whole screen refresh takes about 0.5 seconds - not surprising, since it's a lot of data. Thanks for your patience.

I see. That's kind-of funny. This one has read support. I'll try to get info back from it, and see if it says it's the display I think it is. Next I'll try a display that's really a knockoff.

Well, I made a simple test to see if i'm actually writing data to the display. It turns out I am. At least, something is getting through. int main(void) { int color = 0; gfxInit(); write_index( 0, 0x2C ); // Write to frame memory while( true ) { write_data( 0, color ); ++color; chThdSleepMilliseconds(100); } } What shows up on the screen is dark grey for 1s (with vertical lines), light grey for 18s (with vertical lines), and white for 3s. What I was expecting was a rainbow of colors. Hmm. I even slowed it down to be sure I wasn't overwriting the whole screen. Now say I change it to write the whole color word. You would think that would change the width of the lines, or something. But no change. while( true ) { write_data( 0, color>>8 ); write_data( 0, color & 0xFF ); ++color; chThdSleepMilliseconds(100); } So, I'm confused here. Something is clearly happening, but not what I expect. I can't blame the uGFX library - I'm below that level, just trying to write data to the screen. Maybe this actually is supposed to be a 16-bit write?

Hi, I'm having trouble getting a display to work with uGFX. It's Adafruit's Raspberry pi 2.8" display, which uses an ili9341 over SPI. I am fairly confident that SPI is working, and that my wiring is correct. However, I'm not seeing anything show up on the screen. (My main.c uses the gdisp/basic demo, with a blinking LED in a seperate thread) So, I think there must be an issue with my board_ILI9341.h. Does it seem normal? I have it set up as simple as I could. I even dropped the clock speed all the way down. I did change the data and index variables to 8-bit integers, since it appeared it was 8-bit data being transferred into them in ili9341.c. Any ideas? board_ILI9341.h main.c chconf.h gfxconf.h halconf.h Makefile mcuconf.h

Back onto the numeric control I'm making: I'm having trouble with activating my git account. I'll leave that as a seperate thread. So, here's what I've done so far. These go in ugfx/demos/modules/gwin/numeric/ main.c gfxconf.h demo.mk These go in ugfx/src/gwin/ gwin_numeric.h gwin_numeric.c

From Valgrind: ==19659== Invalid read of size 1 ==19659== at 0x11300D: strip_spaces ==19659== by 0x1132E7: mf_render_aligned ==19659== by 0x10E30C: gdispGFillStringBox ==19659== by 0x11A6E6: gwinSpinboxDefaultDraw ==19659== by 0x1168C9: _gwidgetRedraw ==19659== by 0x11781F: WM_Redraw ==19659== by 0x117069: _gwinFlushRedraws ==19659== by 0x116E1F: RedrawTimerFn ==19659== by 0x11503C: GTimerThreadHandler ==19659== by 0x49CBFC1: start_thread (in /usr/lib32/libpthread-2.28.so) ==19659== by 0x4AE0CA5: clone (in /usr/lib32/libc-2.28.so) ==19659== Address 0x0 is not stack'd, malloc'd or (recently) free'd I've attached the demo I'm using, which I put in ugfx/demos/gwin/spinbox Strangely, it works ok for 4 items, but not for 5. (Although the first item is replaced with "f", and the last item doesn't show up) Anway, I'm done playing with this one for now. It doesn't quite do what I want, and I don't really want to debug the drawing routine. However, storing the value as an integer instead of a float is a good idea, and might very well be more effecient. I think I'll make a function for that too. main.c gfxconf.h demo.mk

I see. The numeric one seems to work fine, but the text one gives a segfault.

Hey, I just noticed the spinbox widget. This appears to be very similar to what Chris was asking for, but for text instead of numbers. Or maybe it works with both?

Hi, I created an account on git.ugfx.io so I could submit a pull request. However, haven't gotten a confirmation email, so I can't do much. I've checked my whole spam folder. I've searched for it. I've resent it several times yesterday and today. I guess I can submit a patch the old way if needed, using git format-patch.

Alright, I have the first two parts done. I'm creating a fork on the git site so other people can see where I'm at. Next is the dial input. How do I simulate that? Does the slider work for this?

I took a stab at this, basing my widget off of the Textedit widget. So far I have it ignoring letters and safely handling decimals. (If a new decimal point is inserted, the old decimal point is removed) Those are mostly cosmetic, though. Here's what I intend to do: Create a method to read the number, as a floating point. Change from insertion mode to overwrite mode, as this seems more intuitive for numeric entry. Add support for dial inputs Add support for negative numbers To make it more like the LabVIEW Numeric Control, you would also need those up/down arrows that emulate a dial input. I think this would make more sense as a separate widget. Honestly, I think they're hard to use, so I'm not planning on implementing that. Something that bothers me about the Textedit implementation is the dynamic memory allocation. I suppose it's memory-efficient, but since we're limited to 16 digits of precision in Double Floating Point, it seems reasonable to allocate 19 bytes and be done with it. (That's an extra byte each for the decimal and negative symbols and terminating character)

Hi Chris, I realize that this topic is 2 years old. Did you end up making the Numeric Control widget? @chrisjn52

Thanks! Xorg seems to work fine. I imagine that it's an issue with SDL on my computer - I don't think I have any other applications that use it.

Hi Folks, I'm trying to develop a UI on my Linux laptop, before migrating over to stm32. I can compile and run the demos with framebuffer, but as I then have no keyboard or mouse input, I don't see how I would interact with the programs. (My laptop does not have a touchscreen). So, I'm trying to use SDL2. I have installed the 32-bit libraries. It seems to compile fine, aside from warnings like "skipping incompatible /usr/lib/libSDL2.so when searching for -lSDL2". However, when I try to run it, I get Is this a permissions issue? Or a udev issue? I'm running arch linux 64-bit, if that helps.