Jump to content

Recommended Posts

Posted

You have to set GFX_USE_OS_RAW32 to TRUE in your configuration file to enable the BareMetal (no operating system) port.

You can have a look at this example which is a bare metal project for the STM32F746G-Discovery board:

 

Posted

Judging from your screenshot you are using Keil µVision, is that correct? Given the information from your previous forum topics I assume that you have been using an RTOS before and are now switching to a baremetal solution. In that case, please double check to ensure that there is no operating system running in the background. With Keil µVision it is quite easy to have software components enabled that get initialized automatically due to the package manager.

After that... Did you specify the CPU in the configuration file? As forum search will tell you the ARMCC compiler will complain about the syntax of the assembly code that gets enabled when specify any of the Cortex-M architectures. Therefore, I assume that you are using GFX_CPU_UNKNOWN - is that correct?
There's a known issue with the implementation of setjmp() and longjmp() of the libc that comes with ARMCC. As far as I remember that issue never got resolved as it's really a bug in the upstream. @inmarket might have more information on this.

To actually debug this: Please check whether the scheduler is up and running. You can easily do this by creating multiple thread and making sure that all of them are working. You might want to run the demo you can find in /demos/modules/gos/thread.

In general: We can't really help based on "It doesn't show anything". More background information is always required. If you are encountering compilation errors and similar you can always attach the compiler output log as a text file to your forum post.

Posted

Hello,

That configuration file looks fine. However, I am really surprised.... are you able to compile that with Keil µVision? Because if you set GFX_CPU_CORTEX_M7_FPU it enables the architecture specific assembly code that we wrote for the baremetal port. That code is known to compile well with GCC but not with ARMCC (which is the compiler that Keil µVision uses by default). Are you 100% sure that you can compile with that configuration without any errors?

Posted

Based on that output please run the demos/modules/gos/threads demo and verify that threading is working correctly.

I suspect that although it has compiled that basic threading is not working due to bugs in the Keil C library and this would certainly cause a blank display.

  • 4 weeks later...
Posted

Hi 

I wanted run demo,threads but it gave error

IMG_20161207_162116.jpgIMG_20161207_162113.jpgIMG_20161207_162109.jpg

what's problem?

really i need ugfx in bare metal. can I use IAR COMPILER in order to have ugfx in bare metal with out any errors ? 

Posted

Please check out the latest master branch of the official uGFX library repository. @inmarket pushed a couple of commits a few hours ago which implement an alternative scheduler written in assembly that compiles with ARMCC. However, please note that we didn't have time to thoroughly test it so far.

Posted

You havent updated all the source files from the master. i can see that your editor window is displaying the old version of gos_x_threads.c

Please properly update your ugfx from the master repository.

Posted

Please onebody help me

I add the latest version of ugfx but it gave 180 errors when I wanted to run demo_003 in bare metal with keil!

Really it's problem that we can't use ugfx in bare metal with keil

Posted

We are running µGFX on a bare-metal platform with a Keil µVision project ourselves successfully so this really shouldn't be more than a configuration issue.

Can you please do what @inmarket told you and ensure that you updated all the files. On a side note, note that we just pushed a change/fix for the RAW32 memory manager, maybe you want to upgrade to the latest master branch at this point.
If you keep having these problems, please attach the complete compilation output log from a clean-build as a text file.

 

Posted

We just pushed a fix for this. The reason was a missing __cpp() wrapper macro around the C function call to gfxThreadExit() inside the inline assembly code.
Note that we haven't tested this ourselves yet, this has to wait a couple of days.

We'd appreciate it if you could grab the latest master and let us know whether it works now for you.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...