Jump to content

kamocat

Members
  • Posts

    15
  • Joined

  • Last visited

Posts posted by kamocat

  1. 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

  2. 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.

  3. 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?

  4. 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

  5. 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

  6. 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)

  7. 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

    Quote

    Unable to initialize SDL: Could not initialize UDEV

    Is this a permissions issue? Or a udev issue?

    I'm running arch linux 64-bit, if that helps.

×
×
  • Create New...