C++ hardware library for (small) 32-bit micro-controllers

> Considering the GUI part only...

The first foremost aim is to allow you to write a GUI and then switch it 
between a number of LCDs (and a PC window for protocotyping).

>    - drawing graticule

IMO too trivial to provide as library element (looking it up is probably 
more work than writing it yourself)

>    - drawing textual annotations

Drawing text: yes.

>    - drawing individual "random" pixels of different colour
>      and brightness

of course, that is the basic interface to any graphics screen.

>    - drawing soft buttons (plus notifying my code when
>      button clicked)

That is GUI stuff rather than just graphics. I have tinkered with it, 
but untill I find a way that does not clog the graphics part: no.

Wouter

On 08/12/13 18:24, Wouter van Ooijen wrote:
>> Question for a library implementer developing a
>> library that will work with more than one device:
>> "does your library library expose the union or
>> intersection of all the devices' capabilities?"
>
> For me: definitely intersection, and probably a lot less than that.

A rational decision, provided either:
  1 I only need to use generic functions, not those
    that make full use of my peripheral's capabilities, or

  2 I can "go around" or ignore your library for some
    subset of the peripherals (can be difficult where
    several peripherals are accessed via a single
    register), or

  3 your libraries' algorithms are sufficiently complex
    that it is simple for me to ignore the library, or

  4 I need to "nearly repeat" an earlier design's
    functions in a later design (so that I can amortise
    the learning curve)

To me, (3) seems the most probable to be of interest
to me

On 08/12/13 18:26, Wouter van Ooijen wrote:
>> Considering the GUI part only...
>
> The first foremost aim is to allow you to write a GUI and then switch it between a number of LCDs (and a PC window for protocotyping).
>
>>    - drawing graticule
>
> IMO too trivial to provide as library element (looking it up is probably more work than writing it yourself)

Drawing lines is definitely /not/ trivial, except in special
circumstances (e.g. there is an n:1 mapping (n an integer)
between the pixels in my application's space and the screen,
and the lines are horizontal or vertical). In many cases
there are unpleasant "gotchas" associated with the "corner
cases" (no pun intended); ask any numerical analyst!

>>    - drawing individual "random" pixels of different colour
>>      and brightness
>
> of course, that is the basic interface to any graphics screen.

I didn't mean to imply that one pixel in my user space maps to
one pixel on the display. In one current application I'm working
on the user-space pixels map to many screen pixels and the user-
space pixels may or may not appear square depending on the
magnification. Indeed in come cases they appear as a rectangle
with a 10:1 aspect ratio :)

>
>>    - drawing soft buttons (plus notifying my code when
>>      button clicked)
>
> That is GUI stuff rather than just graphics. I have tinkered with it, but untill I find a way that does not clog the graphics part: no.

Um, the G in GUI means "graphics", so I'm not sure I understand you :)

>   3 your libraries' algorithms are sufficiently complex
>     that it is simple for me to ignore the library, or
>
> To me, (3) seems the most probable to be of interest
> to me

??
I must be missing something here. (Note English is not my native 
language, so I might occasionally misinterpret a word or nuance.)

Wouter

>>>    - drawing graticule
>>
>> IMO too trivial to provide as library element (looking it up is
>> probably more work than writing it yourself)
>
> Drawing lines is definitely /not/ trivial

Agreed, but you asked about drawing a graticule, which is (if I 
understand correctly) the raster of lines and then some more that make 
up the 'silkscreen' on the O'scope's tube.

Drawing a line should certianly be part of the interface.

>> That is GUI stuff rather than just graphics. I have tinkered with it,
>> but untill I find a way that does not clog the graphics part: no.
>
> Um, the G in GUI means "graphics", so I'm not sure I understand you :)

Graphics = output to a screen. When you add the UI you somehow use it as 
input to, directly via eg. touch, or indirectly by eg. a mouse.

Wouter

On 08/12/13 19:35, Wouter van Ooijen wrote:
>>   3 your libraries' algorithms are sufficiently complex
>>     that it is simple for me to ignore the library, or
>>
>> To me, (3) seems the most probable to be of interest
>> to me
>
> ??
> I must be missing something here. (Note English is not my native language, so I might occasionally misinterpret a word or nuance.)

The nuance is that I wrote rubbish :(

3 your libraries' algorithms are sufficiently complex
   that it is NOT simple for me to ignore the library, or

(... if your library's function is simple then it is
also easy for me to duplicate it)

Your English is perfectly sufficient, which is typical
of people from the Netherlands.

Hi,

Wouter van Ooijen wrote:
> I am working on a portable C++ hardware library for real-time
> applications on small (but still 32-bit) micro-controllers. My typical
> (and current only) target is the Cortex M0 LPC1114FN28 (4k RAM, 32K
> Flash) using GCC. Efficiency is very important, in run-time, RAM use,
> and ROM use. The typical restrictions for small microcontrollers apply:
> no RTTI, no exceptions, and no heap (or at most just an allocate-only
> heap).

I've been using an implementation using classes with virtual functions
for that, in programs from bootloaders to application programs (well,
actually I did a little template magic to implement vtbls "by hand", so
I can control when and how things are constructed). But effectively, I
have classes
    class InputPin { virtual int get() = 0; };
    class OutputPin { virtual void set(int) = 0; };
and their descendants.

Your fully template-based approach looks neat and appropriate for things
with as little "meat" as an I/O pin, but for more complicated things
like "SPI transaction", "parallel NOR flash", "NAND flash" I'd like to
know where in the object files my code ends up.

Plus, an I/O pin may end up to be more than just read-bit-from-register:
for applications that occasionally read a pin, I've got an
implementation of the InputPin interface that performs a remote
procedure call into the driver, saving the application from having to
map physical memory.

> If this is all too abstract, I have a more concrete question, mainly for
> C++ architects. For I/O pins and ports I use class templates with (only)
> static functions. This matches well with reality (the hardware circuit
> is generally fixed), and is much more efficient than using inheritance
> and virtual functions.

"The hardware circuit is generally fixed" is one of the biggest lies of
embedded software development :-)

At least I didn't yet encounter a project where hardware assignments
didn't change over time. Pins get moved, get inverted, new flash chip,
etc. So it's good I'm able to adapt by changing a (runtime) initialisation.

I'm paying one virtual dispatch per access. So, I wouldn't want do to
bit-banged SPI or IIC with my drivers. Thank god I don't have to :-)
It's probably not appropriate for 8-bitters, but it's efficient enough
to be useful in production bootloaders with a few k code.


  Stefan

On 08/12/13 19:39, Wouter van Ooijen wrote:
>>>>    - drawing graticule
>>>
>>> IMO too trivial to provide as library element (looking it up is
>>> probably more work than writing it yourself)
>>
>> Drawing lines is definitely /not/ trivial
>
> Agreed, but you asked about drawing a graticule, which is (if I understand correctly) the raster of lines and then some more that make up the 'silkscreen' on the O'scope's tube.

Correct, but it is not the general case since those
lines are also horizontal/vertical.

The only interesting part is how to merge the colour
of the graticule with the colour of the user-space
pixel "behind" the graticule. Not difficult, unless
if the API makes it difficult.


>> Um, the G in GUI means "graphics", so I'm not sure I understand you :)
>
> Graphics = output to a screen. When you add the UI you somehow use it as input to, directly via eg. touch, or indirectly by eg. a mouse.

Agreed, but I thought you mentioned GUI. But who
cares; that is a boring point and neither of us can
be bothered to excavate the archaeology of this thread!

> 3 your libraries' algorithms are sufficiently complex
>    that it is NOT simple for me to ignore the library, or

Ah, the "work required > work saved" requirement. Of course.

> Your English is perfectly sufficient, which is typical
> of people from the Netherlands.

Thanx, but occasionally I (we?) get something subtly wrong.

Wouter

Hi Don,

On Sunday, December 8, 2013 6:59:13 PM UTC+2, Don Y wrote:
> Hi Dimiter,
> 
> On 12/8/2013 5:15 AM, dp wrote:
> > On Sunday, December 8, 2013 1:55:59 PM UTC+2, Don Y wrote:
> 
> >> [We've finally touched 0C!]
> >
> > We got switched from a mild autumn into a harsh winter
> > overnight by the end of November... It is not a worst case
> > winter yet (-10 to -20) but way harsher than last year.
> 
> Yeah, but you *expect* The Cold!  <grin>  (I actually miss
> it -- when I am prepared for it! -- especially the fruits)

Oh expecting it does not make it any nicer. When we see
the apples go reddish in August we are reminded that "winter is coming",
you know. We both hate it, how can you possibly miss the cold :-) .

> >> Fitting the tool to its user is the key.  If you intend a tool to be
> >> used in a different way than the user will *want* to use it, you've
> >> got an impedance mismatch  :>
> >
> > Yes, this is a major part of it. Then when the tool/author combination
> > gets around 20 years old more effects can be observed, too.
> > The most obvious one being the fact that you keep on developing
> > the tools/language to suit what you need; I have been lucky enough to not
> > have to throw away much if anything written so far so things do pile up.
> 
> I tend not to reuse code as much as *designs*.  "How did I do this
> the last time" instead of "where is the *code* I wrote last time"
> And, more importantly, what did I *learn* the last time so that
> I can make improvements *this* time.

Well yes, of course the lessons learned are in one's head so they
come first, then comes the archive. Above I was referring not
to recycling code I have written, I rarely if ever do it; it is
more a pileup thing. DPS has grown a lot - it did have all these
windows, file systems at low latency etc. for a long time but
it keeps on getting better [for example at some point the mouse being moved
over things started to have effect (e.g. text rectangle with the meaning
of the hieroglyph you are at for a few seconds), most
recently those long file name directories I told you about
coexisting with the old ones etc. etc. ].

> > A may be less obvious one is that having to maintain/remember all
> > that stuff you wrote last 20 years all the time (a few tens of megabytes
> > of sources, about 1.5M lines (non multilined as C :-) in my case)
> > tends to keep you alert and in good shape; I am not sure if this is
> > any less important than anything else really.
> 
> "Inertia".  Keeps you from straying too far, too fast!  :>

Hmm, I guess this is useful only up to a point :D . Once inertia becomes
too dominant in what we do it gets obvious why we have the lifespan
timer designed to tick inside us :D :D .

Dimiter 

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/