ChibiOS Free Embedded RTOS

Just enabled MCO1, I get 16 Mhz...

This is using the default values in board.h for the STM32F4 Discovery.

There is probably some prescaler value in place in RCC_CFGR.

Yes I think there is. You could check in the mcuconf.h file.

However, it isn't possible to give 168MHz out on MCO. Max. I think is 100 MHz only.

Abhishek wrote:I must admit, I also thought of the external memory part.

But my idea now will be to run it on battery power. We could use a 3.7V 2500mAh battery with a charge controller. What do you have to say?

I just saw this on eBay, looks cool: http://ebay.com/itm/Mini-STM32-STM32F10 ... 4aaa11e77f

I am still paying with the idea of doing some board like that with would be battery powered too, but I guess this dosen't belong into this thread.


~ Tectu

Abhishek wrote:Yes I think there is. You could check in the mcuconf.h file.

However, it isn't possible to give 168MHz out on MCO. Max. I think is 100 MHz only.

There is a divisor, you can divide the clock by N before outputting it on MCO, it is configurable in mcuconf.h.

Giovanni

By default:
#define STM32_MCO1SEL STM32_MCO1SEL_HSI
#define STM32_MCO1PRE STM32_MCO1PRE_DIV1

I should have got 8mhz. I will recheck, maybe I did something wrong.

I will replace with:
#define STM32_MCO1SEL STM32_MCO1SEL_PLL
#define STM32_MCO1PRE STM32_MCO1PRE_DIV2

I should get 84Mhz.

I downloaded the latest code in the hopes of using it as a framework to implement my own graphics interface based on a different CPU and LCD.

The code is an amazing work and a lot of people have put a lot of time into this.

I have however discovered a number of short-comings in the high level code based around assumptions made to do with the specific architectures currently implemented.
For example,

• Implementation specific include files included in the high level code
• Assumes a particular pixel format that is implementation specific (in particular RGB565)
• Types such as "orientation" are defined but not used in function prototypes
• Assumes that all functions defined will actually be needed in any project ie. There is no way defined to turn off code (and data) not used eg. Character generation and font tables
• Does not allow for low level code to hardware accelerate functions (eg string functions, circle drawing)
• Does not allow for threading and messaging to be turned off for simple applications or where they are not supported by the platform efficiently.
• Mixes high level code with drawing support algorithms which may or may not be needed by an application or low level driver

Some of these would make implementing my platform using the same interface very difficult (and non-optimal).
I am therefore going to work on taking the excellent work done so far and generalising it to allow multiple different implementations and archetecture drivers to be built while keeping the same interface accross platforms.

Who should I send code to for review and upload if deemed appropriate?

Those are all fair points! The library is in its early stages, so the priority has been to get things working before making everything 'nice'. Some of the points are easier to fix than others; e.g the pixel format will be a more drastic change, but is worth doing for the long run.

Implementation specific include files included in the high level code

I see two solutions to this: split lld by directory like chibios has, and add to the inc path according to the selected driver, or have a common lld_inc.h that isn't included in glcd.h but rather in library files that need to access the lld.

Assumes a particular pixel format that is implementation specific (in particular RGB565)

I guess we define a new type pixel_t or something, that would be uint16_t for the current drivers. Then each device can provide some inline functions to abstract conversions.

Types such as "orientation" are defined but not used in function prototypes

pretty obvious fix for this one - use them everywhere

Assumes that all functions defined will actually be needed in any project ie. There is no way defined to turn off code (and data) not used eg. Character generation and font tables

definitely an area to work on, but should be easy enough to have some defines to turn off/on each feature.

Does not allow for low level code to hardware accelerate functions (eg string functions, circle drawing)

good idea, we could have macros or weakly defined functions (is that supported by more than gcc?) to allow a lld to overrule a high level function

Does not allow for threading and messaging to be turned off for simple applications or where they are not supported by the platform efficiently.

that is easily done, and I was thinking the same for applications in which the multithread was not needed. I will add this mode tonight.

Mixes high level code with drawing support algorithms which may or may not be needed by an application or low level driver

I guess this is an area that is harder to get right, to know what should be low or high level; can you describe in more detail what you think should be done?

If you have code to submit, easiest way is to use github, fork the main repo and then do a pull request.

what platform / lcd / driver are you using?

I agree with Badger, that are all fair points. Thank you for your feedback, this helps a lot!

inmarket wrote:The code is an amazing work and a lot of people have put a lot of time into this.

In fact that aren't so many people (4, to be correct) which contributed to the project. There are just people like Badger who know what they are doing and do the things they do the right way

You can send a pull request to the github repo whenever you want. If you want, I can give you a new branch on the repository where you can write your stuff (or simply fork it yourself).

I would be very very very happy if you would help to get a cool and good working GUI abstraction layer.


~ Tectu

mobyfab wrote:By default:
#define STM32_MCO1SEL STM32_MCO1SEL_HSI
#define STM32_MCO1PRE STM32_MCO1PRE_DIV1

I should have got 8mhz. I will recheck, maybe I did something wrong.

I will replace with:
#define STM32_MCO1SEL STM32_MCO1SEL_PLL
#define STM32_MCO1PRE STM32_MCO1PRE_DIV2k

I should get 84Mhz.

Actually the HSI of F2 and F4 is 16Mhz, not 8 Mhz. That explains your observation.

And @inmarket, Welcome to the community
You really have some interesting points. Thanks for your critical feedback. It'll go a long way in making our lib better.

Cheers
Abhishek

You can send a pull request to the github repo whenever you want. If you want, I can give you a new branch on the repository where you can write your stuff (or simply fork it yourself).

Yes please. Whilst doing a lot of embedded work, I haven't used Git very often so I will need to bring myself up to speed.

I have fleshed out the basics and will put it up as soon as I get a bit more detail in it.

Basic strategy...

High level code header

• Include the low level driver header using a generic name near the top of the high level header file. This is similiar to the other CibiOS drivers. The make system determines which low level driver & header is actually included.
• Define a few macros that handle the PIXEL types and format conversions. The needed format is specified by the low level driver header. Currently I have RGB565, RGB888, RGB888P, RGB444 and RGB444P. The "P" formats use packed bitmaps eg RGB444S describes 2 pixels in 3 bytes. A palletised format might be described as PAL8 (Pallet using 8 bits per pixel). Extra formats would be easy to add. I am not yet defining any of the palletised formats, just thinking about what is needed.
• Define a bunch of GLCD_NEED_XXX macros that determine which functionality gets compiled into the source code. These symbols can be defined at the board level (like the other hardware drivers) or by the project header file. This would specify functionality requirements such as threading or character drawing.
• Define a bunch of GLCD_NEED_SOFTWARE_XXX which would be defined by the low level driver header to determine compilation of functionality eg. software circle drawing is required (rather than hardware accelerated).
• Define a bunch of GLCD_SOFTWARE_METHOD_XXX which would be defined by the low level driver header to determine which algorithm to use in the high level driver for a function if there is more than one option and there are significant performance differences.

Using this method the high level driver can be code customised to the requirements of the low level driver and application. This simple method requires static compilation and source availability and has been used extensively in ChibiOS to keep code size down.
The downside is that if you want to have two LCDs using different low level drivers they would be required to have the same pixel format and any hardware optimisations in one but not in the other driver would not get used. Multiple low level drivers for a signle high level driver is not really supported in ChibiOS anyway so this may be academic.

Other probable changes...

• Move the setWindow to a low level driver function only. It is one of those algorithm choices I was thinking of above. If you want a real windowing system it would be easy now to add it as GLCD_NEED_ extension to define the extra needed functions. This would also allow multiple application windows/viewports rather than just the one allowed now.
• Seperate the text stuff into a TLCD high level driver interface. This interface could support both character line LCD's and graphics LCD's. The graphics LCD's would be supported using a TLCD low level driver implemented using the GLCD interface. Kind of like the "console" code but more specificly to allow character LCD displays