Here's an open source project I've spent dark winter nights putting together... a window manager with overlapped windows for small-ish embedded systems with a touch screen. It works well with ARM Cortex M3 and above driving a QVGA screen. It's completely open source and non-commercial. The license is unrestrictive (MIT) so anyone can do what they want with it, & its website is advert free (apart from a link to the hosting company WIX, I don't pay for the hosting so that's inevitable). I gain nothing from it other than the crack of doing it. Rather then describing it in detail here I'll link to the project's website...

https://miniwinwm.wixsite.com/miniwinwm
https://miniwinwm.wixsite.com/miniwinwm
It's written in standard C99 and builds easily with GCC derived compilers, although as there's nothing GCC specific it will build for other compilers. The hardware abstraction layer is separated out and minimized as much as possible. Sample projects are included for Atollic TrueStudio as that's free. It can be built and run straight out of the zip file for the ST dev board STM32F529I DISC1. It can also be built using AtollicTS to run in Microsoft Windows for a quick trial, although debugging for this platform, while possible, is a bit clunky.

This project uses no dynamic memory, requires no display shadow buffer, uses minimal RAM and doesn't need an OS to support it. On the other hand, as it uses co-operative multi-tasking it requires a certain coding discipline for the user interface to remain responsive. However, it's all explained in the documentation.

In case anyone asks, it won't run on 8 bit PICs, there's just not enough flash space or processing oomph on them. The target audience for this project is probably not complete beginners to embedded programming. Getting going with the dev board/IDE mentioned above will be quick, but to port to any other board or LCD screen you will need to write (or obtain) a LCD dsiplay driver, a touchscreen driver and a few other simpler ones like a timer and non-volatile storage.

 

Very cool effort on your part, but this has already been done, and way better, tighter, faster-- an entire context switching, cooperative multi-tasking kernel, in < 7K. Straight C and works on 8-bit embedded's.

I'm curious whether you fully appreciate how much horsepower an ARM Cortex M3 processor has... I mean it's so far beyond overkill for a task like this.

 

Very cool effort on your part, but this has already been done, and way better, tighter, faster-- an entire context switching, cooperative multi-tasking kernel, in < 7K. Straight C and works on 8-bit embedded's.

I think you have missed the concept. This is not an operating system, this is a window manager. If you are aware of a window manager that provides overlapped windows for embedded devices that is open source then I would be interested in a link. The only one I am aware of is emWin from Segger, but that's commercial and costs. I do not intend to provide OS services, because there are plenty of open RTOS's that do that. However, my window manager can run within a thread of an existing OS like FreeRTOS, but the user interface will all run within one thread, like Win16 did if you remember that far back - each window's code must be co-operative with the other windows or else the UI becomes un-responsive.

I'm curious whether you fully appreciate how much horsepower an ARM Cortex M3 processor has... I mean it's so far beyond overkill for a task like this.

Again, I think you are talking about a context switching OS rather than a window manager. As I work for a major silicon vendor writing those nice libraries of device drivers that you download when you start work on a new ARM Cortex chip so that you don't have to all that tedious register poking yourself, I a bit aware of what M3 chips can do.

An 8 bit processor has not the flash, RAM, nor processing power to run an overlapped window manager at a useful speed. The paint algorithm itself (if you want to implement anything more complex or useful than the basic painter's algoritm where you draw everything up the Z order every time) is a formidable processor hungry beast on its own before anything is written to the display.

 

I do understand what you are referring to.

A 32-bit 25Mhz ARM Cortex M3 processor is not necessary to do this. A MacSE did a lot more than what you're doing in 8-bits at 1Mhz. Understanding how to write code for performance, in the right way, at the right time, allows me to do everything your doing and more, in an 8-bit MCU, running as low as 16Mhz.

I know what these chips are actually capable of. You do realize that a 25MHz pipelined ARM chip can execute assembly instructions at close to its clock frequency, right? How in the world anyone can kill the performance of being able to execute 25 Million assembly instructions every second is beyond me, when C is about as close as you're going to get (since it's considered the high-level assembler) to bare metal without going there.

Xerox, Apple... they are the roadmap. They did far more, with far less.

 

What happened decades ago with Xerox PARC, MacSE, 8bit vs 32bit et al has nothing to do with the presentation of this ARM-based windowing display system. It is also not an RTOS so let's not argue about it. The topic is the display subsystem.

 

It's 'Xerox Parc', not 'Xeroc'
https://web.stanford.edu/dept/SUL/sites/mac/parc.html

Not initially, but they invented the indexed color model most use today, and even the Mac II supported 8/16/24-bit color not long after it's inception- And they still used slower architecture than your ARM chip. In an 8-bit embedded system.

The trade off is purely cycles. You can either base your display around large blocks of pixels (RAM), or you can expect the application to be able to redraw a windows' contents on demand. The key is in moving or changing as little as possible, as efficiently as possible. One way uses more cycles, has more overhead (potentially a lot more), and the other has less, but requires the application to maintain it's data in its own way.

Which is used is a matter of project constraints.

Just a typo.

In my window manager when a window or part of it is needs to be repainted the manager calls the window's paint function to repaint itself (on demand as you describe it), triggered by a user event or a message from another window or control. Each area is only repainted once and only if it is on show, regardless of the level of overlapping of adjacent windows. Only the minimum is repainted - same as every other window manager there is. Each window must maintain its data and know how to repaint itself when requested, just the same as other window managers - again! The algorithm I have implemented to do this is a standard one. I doubt I have implemented it as efficiently as Xerox park could do, but then they had a team of geniuses and did it full time, I'm just me with a few evenings.

Each window paint function can either look at the clipping information structure it has been passed and repaint itself only partially taking into account the invalid rect, or it can just repaint itself completely. The clipping structure is passed down to the next layer (the graphics library) and that can handle the clipping. When a window or control invalidates its own client area, again it can just invalidate the whole thing for simplicity, or just a region to speed thing up. It really is easy to use.

This method is not as processor cycle efficient as it could be, but the trade off is an incredibly easy to use API for the programmer, and that was part of my original intention. Processor cycles are cheap now, why use a clunky old 8 bit processor with no hardware acceleration for driving modern LCD displays dismally slowly when better is available for buttons and microAmps?

My manager does not maintain clipping regions in memory, but recalculates them every time a repaint of a region is required for the region being repainted. There is a good reason for this - it makes it simpler and more memory efficient for a system that uses no dynamic memory, as mine doesn't. This makes it ideal for a bare bones system. If there's a hefty OS available, use Qt. This is the only main departure from the standard window manager model, but standard window managers have dynamic memory available to them.

Xerox and Apple may have been able to make a window manager run at 16 MHz on an 8 bit processor in monochrome, but what they couldn't do was have an 18 Hz full screen refresh rate with 16 bit colour on a 480 x 300 LCD, and still have cycles left over to run ethernet/USB/BLE stacks etc, as I can do. There's a reason why ST package a Cortex M7 with their Discovery board with a LCD of that spec : it's the right processor for the job and the UI remains responsive at all times if coded right. The whole idea is that this is a window manager for an embedded system - the processor will have much more important higher priority things to do than update the UI, so extra oomph is never a bad idea.

I'm sure my window manager could be made to run on an 8 bit limited system in some manner driving a titchy monochrome display, but with my growing family of UI controls, all the bitmaps, fonts, 3D controls coming, file system, image/video codecs and RTOS integration (all to come), sacrifices would have to be made. It was never intended to run on an old fashioned limited processor, because there are much better ones available for buttons. In future the project is going to grow, not be limited to run on the tiniest systems constrained by hardware, just because it can.

 

What happened decades ago with Xerox PARC, MacSE, 8bit vs 32bit et al has nothing to do with the presentation of this ARM-based windowing display system. It is also not an RTOS so let's not argue about it. The topic is the display subsystem.

The reason I felt it was germaine was as an example of what was achieved with significantly less horsepower.

 

The reason I felt it was germaine was as an example of what was achieved with significantly less horsepower.

I know, and its good to be reminded of what can be done with little horsepower and good programming. But the topic is to introduce this particular project so I felt that going further along the 8 vs 32 bit path would be counter to the main idea here.

Not to break my own rules but I'd be interested in the link to the <7K C RTOS. Thanks!

 

Yes, I agree with you entirely-- and I apologize to the TP that I derailed that aspect of his effort.

 

@BobaMosfet No worries and thank you.

 

Here it is running compiled for Windows (no code changes required, just different drivers). It's running abominably slowly in this video. Now that's probably because of my hugely inefficient programming wasting MIPS all over the place, or it could be that my ancient computer is struggling with doing a simulation and a video capture at the same time. Anyhoo, it runs a lot faster on real hardware, that kitty image takes less than 20ms to redraw on a STM32 with a LCD hardware acceleration module (FSMC).

I don't know why the mouse pointer has a yellow circle around it all the time, I couldn't find a way of switching that off in the video capture software. So it's not that representative,, there's a lot more redrawing apparent in this video than real life and the control animations (button down/up etc.) look a lot better than here, but it gives an idea of what this window manager does.

 

I could not find a datasheet, or even a product listing for the STM32F5 series Discovery Kit you listed, can you tell us specifically what MCU it uses? When I went to http://www.st.com and looked, they jumped from F4 to F7 in their available kits. So I don't have any information to evaluate between F5 or later.

I had not jumped to ARM yet, and I looked at NXP, but I saw those at 25MHz (likely there are faster, I jut didn't see them right off), while ST's were at 32MHz, and I can see real benefits to the horsepower increase. Every cycle matters.

 

I could not find a datasheet, or even a product listing for the STM32F5 series Discovery Kit you listed, can you tell us specifically what MCU it uses? When I went to http://www.st.com and looked, they jumped from F4 to F7 in their available kits. So I don't have any information to evaluate between F5 or later.

I had not jumped to ARM yet, and I looked at NXP, but I saw those at 25MHz (likely there are faster, I jut didn't see them right off), while ST's were at 32MHz, and I can see real benefits to the horsepower increase. Every cycle matters.

It was a typo that I noticed too late, should be F4. I wish this site allowed edits after more than 10 minutes.

This is the dev board...

https://uk.rs-online.com/web/p/microcontrollers/9093660/?sra=pmpn

Now this really is way more powerful than I need, it's blisteringly quick, but at £22 including the LCD, I'm not complaining.

 

I could not find a datasheet, or even a product listing for the STM32F5 series Discovery Kit you listed, can you tell us specifically what MCU it uses? When I went to http://www.st.com and looked, they jumped from F4 to F7 in their available kits. So I don't have any information to evaluate between F5 or later.

I had not jumped to ARM yet, and I looked at NXP, but I saw those at 25MHz (likely there are faster, I jut didn't see them right off), while ST's were at 32MHz, and I can see real benefits to the horsepower increase. Every cycle matters.

I've also had the code running on a STM32F407 with a generic LCD and an IL9325 driver chip, but that's very similar to the 429 board, and a STM32F103 cheapy Ebay dev board with LCD from China, but it's hit and miss what spec LCD you get with those. Just for the fun of it a borrowed STM32F777 based project board with much larger display, and unsurprisingly it ran on that too. The code has also been compiled and run on a Renesas RX based system - when I say 'run', the code built and ran and seemed to be doing the right thing in the debugger, but there was no LCD attached . I'd like to try a PIC32 with a LCD, but not found a cheap dev board yet. We have dev boards from most manufacturers hanging around the place at work, but not found a PIC32 based one yet. I don't think it's seen as a serious competitor to ARM based stuff, unlike the Renesas RX which is seriously good!

 

I know that many vendors offer ISP or JTAG programmers for flashing their MCUs at reasonable cost (< $50 ). My interest isn't in being limited to a Dev Board, I would want to use it in my own project designs. Have you moved beyond the DevKit, and if so, what did you use to program/flash the chip?

 

I know that many vendors offer ISP or JTAG programmers for flashing their MCUs at reasonable cost (< $50 ). My interest isn't in being limited to a Dev Board, I would want to use it in my own project designs. Have you moved beyond the DevKit, and if so, what did you use to program/flash the chip?

For my hobby ARM based projects, no, because the dev kits are way cheaper than I could get custom boards made up in small numbers. I usually pay for this stuff myself out of my boys' toy fund, although I'm getting better at blagging freebies from silicon vendors! Some of the STM32F1xx dev boards only cost £7 retail, including an on-board ST-LINK! Even my wallet can stand that.

Professionally, yes of course I've worked on purpose designed boards. I've used J-Links, ST-LINKs, Lauterbachs, IAR I-jet during development (and probably others over the years, I can't remember). For factory production line flashing it's different again when thousands of devices are coming off the production line every day, but that's more specialised and often proprietary or custom designed programming systems are used for the particular board being made if the numbers are high enough. I don't get involved in mass production though, that's a whole different field of engineering. I know for ST-LINKs there is an API you can use to talk to their JTAG from Windows or Linux to implement your own programming system, but it's not publicly available. You need to persuade ST to give you details.