Using uGFX on bare metal

[Pablo2048]

Hi everybody,

at first i have to say big thank You for such great library.

Now to my question - in GOS documentation is written "...or also just a stand-alone library like the STDperiph library from STmicroelectronics." Is there any example for that? After studying gos source code I think that gos module is not ready for this yet.

Thank for advice.

Pablo2048

[inmarket]

We have currently written full GOS layers for Linux, OSX, Win32 and ChibiOS. We have chosen these simply because those are the operating systems that most of our user community want.

A bare metal implementation will be very dependant on what that bare metal is so bare metal implementations would normally be written by the end user for their specific hardware. We might in future do one for the most popular hardware but this is not high on our priority list currently. We would be very happy to receive a contribution from a user for this however.

In practice, implementing the full GOS layer is probably not required for many situations.

For example, if you are only using the GDISP module you will not need to implement any of the multithreading support (or mutexes, semaphores. memory allocation etc) in the GOS layer.

If however you are using GTIMER timers, the GINPUT subsystem and/or the GWIN widget library then you will probably need most of the GOS layer implemented.

Have a look at the existing GOS layers. They are VERY easy to implement. In most cases it is just a bunch of macro definitions to the equivalent functions in your OS or hardware library.

Note that while all the drivers are operating system independent, many board files use the operating system mechanisms to talk to the real hardware. You might need to adjust the board.h files for your drivers in order to talk directly to your hardware (just as you would have to if you were using custom hardware).

We would happy for a contribution to implement a partial or full GOS layer for a hardware specific library.

[Pablo2048]

Thank You for explanation - i will try to write some code to test...

Pablo2048

[Pablo2048]

Ok, Tectu ask me, but i can't send PM, so I have to answer this way - here is my current status:

My plan is to create project using Em::Blocks IDE for STM32 Camera rev. 3.1 board with uGFX. Currently i've created project, added ugfx and created gos/baremetal.c and gos/baremetal.h - actually based on Chibios template. I've created gfxconf.h and set new definition GFX_USE_OS_BAREMETAL. Now i'm resolving compilation errors because of the new system definition (i'm totally new with mutexes, semaphores, etc... so please be patient)

Pablo2048

[Joel Bodenmann]

Nice to hear that you did some progress! Feel free to ask whenever a question rises.

What's exactly the issue that you cannot send PMs?

~ Tectu

[radiotech]

Ok, Tectu ask me, but i can't send PM, so I have to answer this way - here is my current status:

My plan is to create project using Em::Blocks IDE for STM32 Camera rev. 3.1 board with uGFX. Currently i've created project, added ugfx and created gos/baremetal.c and gos/baremetal.h - actually based on Chibios template. I've created gfxconf.h and set new definition GFX_USE_OS_BAREMETAL. Now i'm resolving compilation errors because of the new system definition (i'm totally new with mutexes, semaphores, etc... so please be patient)

Pablo2048

Hi Pablo2048. I want make project with STM32F103 and SSD1289 + uGFX (on bare metal). Wanted to know what the progress in your work?

[Joel Bodenmann]

Hi Pablo2048. I want make project with STM32F103 and SSD1289 + uGFX (on bare metal). Wanted to know what the progress in your work?

Hi radiotech,

The bare metal port has been finished and is available from the repository. You can enable it by setting #define GFX_USE_OS_RAW32 to TRUE in your gfxconf.h.

Please feel free to open a new thread should you face any problem.

~ Tectu

[fastlink30]

I try to compile 'on bare metal' but i receive some error about 'previous declaration of 'int32_t' this happen also for int8_t e uint32_t,

i use coocox ide and stm32f4discovery and ugfx 2.1 and ssd1289 , there are conflict with win32.h file & 'gnu tools arm embedded\4.8 2014q2\lib\gcc\arm-none-eabi\4.8.4\include\stdint.h'

is possible avoid this? there are tips?

thanks

[Joel Bodenmann]

I try to compile 'on bare metal' but i receive some error about 'previous declaration of 'int32_t' this happen also for int8_t e uint32_t,

i use coocox ide and stm32f4discovery and ugfx 2.1 and ssd1289 , there are conflict with win32.h file & 'gnu tools arm embedded\4.8 2014q2\lib\gcc\arm-none-eabi\4.8.4\include\stdint.h'

Could you please attach or paste the entire build log? If it's not too much trouble, please attach a .zip with your project code and especially the gfxconf.h file.

I'm not quite sure, when you say you use CooCox IDE, is that just the IDE or does it force you to use the CoOS RTOS at the same time? Does the IDE use Makefiles?

I am just curious from where the type conflicts (redefinition of the int types) come from. Are you using some other subsystem? Some STDperiph library maybe?

is possible avoid this? there are tips?

This is surely fixable ;-)

~ Tectu

[fastlink30]

i've attached the build log and project, is only ide, i not use coos, not use makefile, i use cmsis

(i must split the project file in 2 parts)

thanks

STM_OVEN.part01.rar

STM_OVEN.part02.rar

[fastlink30]

the gfxconf.h

gfxconf.rar

[Joel Bodenmann]

I did just give it a quick watch. Why are you including stdint.h in your main? Do you really need that? I though the CMSIS provides the necessary types.

Can you try to remove the type definitions in ugfx/src/gos/raw.h which are giving a conflict?

Note 1: I'd strongly recommend you to use the uGFX master state of the repository and not the 2.1 release.

Note 2: The guide for using the bare metal port is not finished yet in the wiki. However, the documentation of the RAW32 port states the following:

/**
 * The raw32 GOS implementation supports any 32 bit processor with or without an
 * 	underlying operating system. It uses cooperative multi-tasking. Be careful
 * 	when writing device drivers not to disturb the assumptions this creates by performing
 * 	call-backs to uGFX code unless you define the INTERRUPTS_OFF() and INTERRUPTS_ON() macros.
 * 	It still requires some C runtime library support...
 * 		enough startup to initialise the stack, interrupts, static data etc and call main().
 * 		setjmp() and longjmp()			- for threading
 * 		memcpy()						- for heap and threading
 * 		malloc(), realloc and free()	- if GOS_RAW_HEAP_SIZE == 0
 *
 * 	You must also define the following routines in your own code so that timing functions will work...
 * 		systemticks_t gfxSystemTicks(void);
 *		systemticks_t gfxMillisecondsToTicks(delaytime_t ms);
 */

But that is not related to your current issue with the types. Just that you know for when you have this type issue fixed ;-)

~ Tectu

[fastlink30]

i've removed the definitions of int32_t,uint32_t, etc. but there are also delaytime_t and systemticks_t that are depending from the uint32_t, so after i receive compilation error becouse systemticks_t is not defined

i've removed stdint.h, nothing happen

i know that i must add some subroutine, but first of all, i want that compile is successfull

where i found the uGFX master state? what is the difference from the 2.1 release

(i'm new on uGfx)

thanks

[fastlink30]

also with the version on the repository, is the same, nothing changed, conflict on typedef

[Joel Bodenmann]

That does not seem to make sense to me.

The first build log just tells you that stuff like uint32_t is redifined. When you comment those out in the )/src/gos/raw32.h file, then the second build log should not tell you that it is missing that definition now.

Try to include the file that does define the types (inttypes.h?) in /src/gos/raw32.h and see how that goes.

~ Tectu

[inmarket]

The problem is that the int32_t definitions in your system are conflicting with the defintions in uGFX.

There are two possible solutions to this...

1. Restore the definitions in raw32.h to what they were and remove the inclusion of in your project. uGFX should then define those types for you and there will be no conflict.

2. Include within the raw32.h file (somewhere around line 27 would make sense (just after the #if GFX_USE_OS_RAW32). Then comment out the definitions for int8_t through to uint32_t (lines 45 - 50) in raw32.h

Option 1 is the better solution.

If you post a copy of your stdint.h (each compiler uses slightly different definitions) I will try to add protection around the definitions to solve the problem in future where someone includes both files.

[fastlink30]

1) same of before, type conflict

2) no error with uint8_t, but now conflict error with size_t on raw32.h, if definition of size_t on raw32 is removed, i have error becouse function prototypes require it...

ach

attached file stdint.rar

thanks

stdint.rar

[Joel Bodenmann]

I took a look at the header that you're using and there is no definition for the size_t data type. Therefore there shouldn't be any reason for you to remove that from raw32.h. Can you please post the exact error message?

~ Tectu

[inmarket]

Please send me your main.c. There must also be other header files that are conflicting with the type definitions. Seeing your main.c will enable me to check the other header files.

Note with ugfx you typically don't need to include any standard header files as ugfx takes care of all that for you when you include gfx.h. You then add standard header files only for stuff the ugfx does not handle.

The error log should show which is the conflicting header file and you take the same approach that we took to resolve the stdint conflicts.

[fastlink30]

tectu: i removed the size_t (raw32.h) becouse i was trying to disable the various definitions, but without uint32_t must be undeclared, and for this, after appear errors

inmarket: attached main.c, the other include are needed, becouse i need other stuff/pin, i'm testing firmware on stm32f4discovery

thanks

main.rar

[inmarket]

I have uploaded into the repository a couple of fixes to raw32.h which should help prevent type definition conflicts with standard headers.

Hope this helps.

[fastlink30]

i have downloaded & compiled, now i can compile without errors

thanks

[fastlink30]

but now i have this error

undefined reference to `gfxInit'

[inmarket]

Check your make script and your linker script. gfxInit is a public function so if it is undefined it must be a linking problem.

[fastlink30]

not understand what mean this, i not have .a file to link, how i can make this?

i looked on internet, but i not have found exaustive solution about this

(there are gui editor to use with ugfx))

thanks (again)