Jump to content

AnSc

Members
  • Posts

    20
  • Joined

  • Last visited

Everything posted by AnSc

  1. Hi, sorry for the delay, was busy elsewhere… Please find attached the diff of my changes. gdisp_lld_SSD1322.diff
  2. Hi, thanks for this tip. As I wrote it was a crude first try. I changed the macro to this: #define xyaddr(x, y) ((x/2) + (y)*SSD1322_ROW_WIDTH) and did see the same correct behaviour after reverting the code line to: ram = RAM(g)+xyaddr(x,y);
  3. Yes this is right. Currently it works as expected on my side. Thanks for asking.
  4. Ok, I think I fixed it now: Summary of all required changes:
  5. Fonts look like the high and low Half-Byte are swapped:
  6. After quite some back and forth I got my debugger running again. Looks like it did not like to work on my USB hub… Used another USB and now it seems to work more reliably. I found this thread here: Then I added gdispFlush() to my code and voilla, line is displayed. I find the documentation on that a bit lagging. This was not obvious from the examples I found. However, maybe due to my crude hack, the line is a bit jagged:
  7. After my initial euphoria I'm now stuck using the library as such. Below is my code in my thread and it does not send any data to the display after initialization. I attached an oscilloscope to the chip select line and would expect to see data transfer to the display every 500 ms. But there is nothing. What am I missing?
  8. As a quick test I just made a crude change to the code: This does give me a nice picture of the uGFX logo for a short period after reset. No crash.
  9. After playing with the numbers: The end of the allocated block is at 0x20004FA8. The calculation with the numbers from the affected code lines gives (0x20002FA8+(255+63*128)) = 0x20005027 The difference is 0x20005027-0x20004FA8 = 127 This does not look like a random number. So where do those extra 127 come from? It looks to me like x is too big. ROW_WIDTH is SCREEN_WIDTH/2 and this value is used to allocate the memory: Is'nt it then necessary to reflect this requirement also when trying to access the "framebuffer" for each pixel?
  10. I had an error in my calculation which Giovanni from ChibiOS pointed out: So the allocated memory is fine. But somehow the graphics driver goes beyond that. Where do I need to fix the code so that this does not happen any more?
  11. Just found out that g->priv is a return from chHeapAlloc(). Therefore ChibiOS should raise an error in my opinion since the requested heap size results in an end address beyond RAM end. Not sure what's happening there.
  12. I thought about this a bit last night. I don't understand how uGFX handles this "framebuffer" if this is what it is. From my limited understanding of the code in gdisp_lld_SSD1322.c (lines 216, 217) it looks to me like some "random" pointer somewhere into the RAM and not into some "reserved" area because of the "on-the-fly" calculation. There is no function call involved or I didn't get it. How is there a safe-guard that this does not try to access non-RAM area or RAM area that other code uses? ram = RAM(g)+xyaddr(x,y); *ram &= ~xybits(x, y, LLDCOLOR_MASK()); Is there any working project (stub) that uses this display on this controller? So I could try to run this and compare to my code to exclude things on my end that may contribute to this error?
  13. Currently it works, but no promises as how long.
  14. Addition: this is the state of various variables when it fails. g->priv is well within the memory range. So why does ram = RAM(g)+xyaddr(x,y); end up in such a high region?
  15. Thanks for helping me. I pushed my code to github: https://github.com/transistorgrab/RT_HPS_STM32F103 This is the output from a clean build: 17:20:48 **** Build of configuration Default for project RT_HPS_STM32F103 **** make -j all Compiling crt0_v7m.S Compiling vectors.S Compiling chcoreasm.S Compiling crt1.c Compiling hal.c Compiling hal_st.c Compiling hal_buffers.c Compiling hal_queues.c Compiling hal_flash.c Compiling hal_mmcsd.c Compiling hal_adc.c Compiling hal_gpt.c Compiling hal_i2c.c Compiling hal_pal.c Compiling hal_pwm.c Compiling hal_serial.c Compiling hal_serial_usb.c Compiling hal_spi.c Compiling hal_usb.c Compiling nvic.c Compiling stm32_isr.c Compiling hal_lld.c Compiling hal_efl_lld.c Compiling hal_adc_lld.c Compiling stm32_dma.c Compiling hal_pal_lld.c Compiling hal_i2c_lld.c Compiling hal_spi_v2_lld.c Compiling hal_st_lld.c Compiling hal_gpt_lld.c Compiling hal_pwm_lld.c Compiling hal_serial_lld.c Compiling hal_usb_lld.c Compiling board.c Compiling osal.c Compiling chsys.c Compiling chrfcu.c Compiling chdebug.c Compiling chtrace.c Compiling chvt.c Compiling chschd.c Compiling chinstances.c Compiling chthreads.c Compiling chtm.c Compiling chregistry.c Compiling chsem.c Compiling chmtx.c Compiling chcond.c Compiling chevents.c Compiling chmsg.c Compiling chdynamic.c Compiling chmboxes.c Compiling chmemcore.c Compiling chmemheaps.c Compiling chmempools.c Compiling chpipes.c Compiling chobjcaches.c Compiling chdelegates.c Compiling chfactory.c Compiling chcore.c Compiling chprintf.c Compiling chscanf.c Compiling memstreams.c Compiling nullstreams.c Compiling bufstreams.c Compiling gfx.c Compiling gos_chibios.c Compiling gos_freertos.c Compiling gos_win32.c Compiling gos_linux.c Compiling gos_osx.c Compiling gos_raw32.c Compiling gos_ecos.c Compiling gos_rawrtos.c Compiling gos_arduino.c Compiling gos_cmsis.c Compiling gos_zephyr.c Compiling gos_nios.c Compiling gos_x_threads.c Compiling gos_x_heap.c Compiling gdriver.c Compiling gqueue.c ./uGFX/src/gos/gos_x_threads.c:10:5: warning: "GOS_NEED_X_THREADS" is not defined, evaluates to 0 [-Wundef] 10 | #if GOS_NEED_X_THREADS | ^~~~~~~~~~~~~~~~~~ Compiling gdisp.c Compiling gdisp_fonts.c ./uGFX/src/gos/gos_x_heap.c:10:5: warning: "GOS_NEED_X_HEAP" is not defined, evaluates to 0 [-Wundef] 10 | #if GOS_NEED_X_HEAP | ^~~~~~~~~~~~~~~ Compiling gdisp_pixmap.c Compiling gdisp_image.c Compiling gdisp_image_native.c Compiling gdisp_image_gif.c Compiling gdisp_image_bmp.c Compiling gdisp_image_jpg.c Compiling gdisp_image_png.c Compiling mf_encoding.c Compiling mf_font.c Compiling mf_justify.c Compiling mf_kerning.c Compiling mf_rlefont.c Compiling mf_bwfont.c Compiling mf_scaledfont.c Compiling mf_wordwrap.c Compiling gevent.c Compiling gtimer.c Compiling gwin.c Compiling gwin_widget.c Compiling gwin_wm.c Compiling gwin_console.c Compiling gwin_graph.c Compiling gwin_button.c Compiling gwin_slider.c Compiling gwin_image.c Compiling gwin_checkbox.c Compiling gwin_label.c Compiling gwin_radio.c Compiling gwin_progressbar.c Compiling gwin_list.c Compiling gwin_container.c Compiling gwin_frame.c Compiling gwin_tabset.c Compiling gwin_gl3d.c Compiling gwin_keyboard.c Compiling gwin_keyboard_layout.c Compiling gwin_textedit.c Compiling ginput.c Compiling ginput_mouse.c Compiling ginput_keyboard.c Compiling ginput_keyboard_microcode.c Compiling ginput_toggle.c Compiling ginput_dial.c Compiling gadc.c Compiling gaudio.c Compiling gmisc.c Compiling gmisc_arrayops.c Compiling gmisc_matrix2d.c Compiling gmisc_trig.c Compiling gmisc_hittest.c Compiling gfile.c Compiling gfile_fs_native.c Compiling gfile_fs_ram.c Compiling gfile_fs_rom.c Compiling gfile_fs_fatfs.c Compiling gfile_fs_petitfs.c Compiling gfile_fs_mem.c Compiling gfile_fs_chibios.c Compiling gfile_fs_strings.c Compiling gfile_printg.c Compiling gfile_scang.c Compiling gfile_stdio.c Compiling gfile_fatfs_wrapper.c Compiling gfile_fatfs_diskio_chibios.c Compiling gfile_petitfs_wrapper.c Compiling gfile_petitfs_diskio_chibios.c Compiling gtrans.c Compiling gdisp_lld_SSD1322.c Compiling main.c In file included from main.c:21: oled.c:8:34: warning: 'rxbuf' defined but not used [-Wunused-variable] 8 | CC_ALIGN_DATA(32) static uint8_t rxbuf[128]; | ^~~~~ Linking build/ch.elf lto-wrapper.exe: warning: Options to Xassembler do not match: -alms=./build/lst/crt1.lst, -alms=./build/lst/hal.lst, dropping all -Xassembler and -Wa options. Creating build/ch.hex Creating build/ch.bin Creating build/ch.dmp Creating build/ch.list text data bss dec hex filename 38536 0 20480 59016 e688 build/ch.elf Done 17:21:09 Build Finished. 0 errors, 3 warnings. (took 20s.472ms)
  16. This is my config file. I'm currently running out of ideas how to proceed further. so any ideas are welcome. gfxconf.h
  17. Hi again, Had some time today to dig in. Model of the controller is STM32F103RBT6 with 128K FLASH, 20KB RAM. Compiler is GCC (using ChibiStudio). I did clone the main repository and stumbled again over the missing driver.mk file. I created one with the lines above, which led to a successful build without the problem with a "wrong" ChibiOS version. I get warnings about "GOS_NEED_X_THREADS" is not defined and "GOS_NEED_X_HEAP" is not defined. I also get many warnings about "GFX_MEM_LT64K" is not defined. I would feel more comfortable if there was some documentation on the individual options so I knew how to rate these warnings. The first two read to me as if they do not apply since I'm using ChibiOS. The GFX_MEM_LT64K is not so clear to me. I set it to "GFXON" for now since I only have little RAM. However, it still seems to crash. My debugger still does not work reliably, so I don't know at what point it crashes. But during my last debugging there was no error during the allocation of the memory but only when it tried to access it. However, if I take these 20kB RAM and convert this to hex I end up with 0x5000 as the amount of bytes. Therefore, 0x2000 4fff would be the last RAM address in my understanding. If the frame buffer is set to 0x20005027, this would be behind the last available address. Have I a problem with my understanding and calculations or does the OS or uGFX make some error here?
  18. Thanks for your detailed answer. I'm traveling for a few days but will get back to this starting next week. As for the .mk file. I did create one from an example of the other drivers. But can't currently access it to check for its content. But it was as simple as two lines of code. The MCU is a STM32F103 but I need to check the exact model. Should be a 128k type with 20 k RAM.
  19. My debugger worked again, so I could step through the initialization. at this point it stops: uGFX init gdisp_lld_SSD1322.c [code] *ram &= ~xybits(x, y, LLDCOLOR_MASK()); [/code] Debugger says: [code] ram gU8 * 0x20005027 <error: Cannot access memory at address 0x20005027> [/code] and then Chibios stops with _unhandled_exception Is this a problem with uGFX or Chibios? Any ideas?
  20. Hi, I currently try to get my custom board up and running with a SSD1322 based OLED. However, when I tried to build the code I got this warning: ugfx/drivers/gdisp/SSD1322/driver.mk: No such file or directory And indeed it was missing. Version of ugfx: 2.9 I'm using the current version of Chibios (21.11) as a basis and after creating the .mk file I get now this error: ./ugfx/src/gos/gos_chibios.c:15:3: error: #error "GOS: Unsupported version of ChibiOS" from this line: #if CH_KERNEL_MAJOR < 2 || CH_KERNEL_MAJOR > 5 after changing the max kernel version to ">50" it compiles but throws some warnings which seem to relate to the OS porting: cast between incompatible function types from 'gThreadreturn (*)(void *)' {aka 'long int (*)(void *)'} to 'void (*)(void *)' [-Wcast-function-type] gos_chibios.c /RT_HPS_STM32F103/ugfx/src/gos line 185 C/C++ Problem cast between incompatible function types from 'gThreadreturn (*)(void *)' {aka 'long int (*)(void *)'} to 'void (*)(void *)' [-Wcast-function-type] gos_chibios.c /RT_HPS_STM32F103/ugfx/src/gos line 192 C/C++ Problem and some additional warnings: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] gdisp.c /RT_HPS_STM32F103/ugfx/src/gdisp line 586 C/C++ Problem duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] gdisp_driver.h /RT_HPS_STM32F103/ugfx/src/gdisp line 735 C/C++ Problem duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] gdriver.h /RT_HPS_STM32F103/ugfx/src/gdriver line 90 C/C++ Problem But I'm new to working on STM23 and also new to uGFX so I'm not sure about the consequences of all these warnings. My small application seems to start but no graphics output occurs. The code also seems to go to a halt during initialization "gfxInit();" of the display. When I do start the initialization in the main() it freezes after reset. When I put it in a thread I see the other threads starting (setting LEDs) and then freezing. I would have expected from the comments in the code that some uGFX logo should display during initialization. I'm currently unable to debug. My debug probe does not work correctly (no idea why this happens from time to time). If I use a smallish self written function that only sends some random data to the display there is an output, althoug nothing meaningful. Therefore, the hardware is fine. Are there any hints how to setup this correctly? I did find this thread but I'm not sure what to use of this for a minimum setup for initial testing if it works at all: Thanks for reading. :)
×
×
  • Create New...