Standardized (Nicely Organized) Embedded System Programming Library/API

[Mechatrommer]

is there a such thing?  intro... for a proper library, we dont have to touch the API, we only need to provide the driver specific to a device, link it to API and done. all our program/App to do is call the API. the chronology/topology is something like this (for someone who not aware of this)...

Application -> API (device independent library) -> Driver (device dependent library)

for those of you who are PC/Win/Linux programmer, you should already aware of this and its beautiness. now for embedded system. please suggest if there is such any library (C/C++ language), that is generally applicable to most mcu like avr, pic, arm and their compiler/ide etc. the simpler one is much preferable rather than bloated aimed at higher end mcu (like RTOS etc). i've downloaded a few library (only one or two actually ) from certain good individuals, but either lack of documentation and/or the library is highly "corrugated" dependent to one another, up and down in the hirarchy, and/or using fancy/unneccessary classes, namespaces etc making using C alone quite a mixed up. not so nice but kudos for the effort.

what i want to do right now is... i have a lcd monitor, mmc/sd card that i want to drive/access from atmega 8bit mcu (or perharp ram/eeprom access) that all my application to do is call functions like printf, or MessageBox, or assert, and then it will popped up in our stdio (standard input ouput) ie the monitor (in my case my 3.2" tft monitor) or any other type of device that the driver has been setup for and linked to the API. same with memory (alloc, dealloc, AllocMemory etc), for file/sd/mmc/usb (OpenFile, OpenDrive etc etc). when i move to another mcu/ide/monitor/device then i can reuse the App and only changin certain thing that is specific to the newly installed devices.

i'm going to start the journey and reinventing the wheel, to organize my lcd, mcu, library and stuffs. but if i got a better solution from all you guys, i may stop that time consuming effort and re-organize the existing library to suit my need. thank you all.

ps: and err, about GNU. i quick read their agreement. its indicated the developers that using the library are "encouraged" to open source their code to public/GNU. i'm quite hesistant or just i misunderstood something. its like (just an example) if say TI make an agreement, if you use our product/chip/opamp, you need to make your schematics/circuit public.

[Mechatrommer]

since this thread is sooo hot damned popular, with 107 views (out of tens of thousands) and zero reply. so i think i will just publish what i've came across these few days. my newborn "mcuApiC" API (GUI) C/C++ Library for simple 8bit Microcontroller... HY32D 3.2" LCD Screen with Touch Screen i got from ebay with my Arm Dev Board few months ago, teared apart and connected to my Arduino Mega 1280. unzip the file (attached) and the first file you should go is "readme.htm" and/or "readme.txt". and then to the sample/test program (AVR Studio 4)... only if, you have such devices and/or want to



and also i believe i've broke my comfy zone by uploading a video to uuutube, i hope it'll get through...

[HLA-27b]

Well half of the forum is at the level of "which soldering iron should I buy to make a led go blink" and the other half prefer to do "coding" with their soldering irons anyway )  So it may take a few bumps until the right folks notice your thread and respond.

They tried to teach me programming back in the 90's but unfortunately they tried to use BASIC which ruined my programming enthusiasm forever. Maybe I would have been a programmer now had they tried to use a proper language that could actually do something.

[westfw]

you should already aware of this and its beautiness.

Yeah, right.  And its bloatedness too...
Any RTOS does this to at least some extent, and many are multi-platform including some rather small chips.
CMIS does this Cortex.  ASF does this for AVR.  Arduino does this for several platforms now.  Every serious chip vendor has some set of libraries that they suggest you use, and occasionally there are significant pieces that are pretty much platform independent (a lot of libc and posix is  pretty universal.)  It probably doesn't help much that vendors don't see making their chips behave "just like everyone else's chips" as very valuable.

One of the things that makes a library like that valuable is completeness, permanence, and support.  Yet Another Beginning of an Open Source Project by some individual is  ... not at all interesting.  (Nothing personal, and no offense or particular criticism intended.

[Mechatrommer]

Well half of the forum is at the level of "which soldering iron should I buy to make a led go blink" and the other half prefer to do "coding" with their soldering irons anyway )  So it may take a few bumps until the right folks notice your thread and respond.

i kind of aware of this, on and off. so i struggle hard enough to remember this fact i have to stick hard in my brain that... my purpose is to educate and share, so, the thing is... FWIW (for what its worth).

They tried to teach me programming back in the 90's but unfortunately they tried to use BASIC which ruined my programming enthusiasm forever. Maybe I would have been a programmer now had they tried to use a proper language that could actually do something.

well i havent told you a story. i first met computer at the late age of like 13-15 where 5" floppy is at its golden age. its like magnet ever since. my first proper taught language is fortran and then i self learnt from there... pascal/delphi, basic, borland & ms c/c++, even tried java and flash to no success . i stick with basic and c/c++.

Yet Another Beginning of an Open Source Project by some individual is  ... not at all interesting.

my intention is to educate (if i ever eligible for that). if you look closely at my library, it pretty much nothing! it only has one display device and one touch screen device connected to arduino. give 'you' a break!? everybody expect 'all in one' completeness theorem library, but yet condemning complexity ('bloat'ibility). one of my intention is to show the basic idea how to avoid this complexity (bloatness) by coding only whats (device) related/necessary to us, but at the same time still maintaining a nice (hopefully) managable structure, portability and reusability, and the most important thing of all, is the power at our own hand to change things, not reading thick pages of one party's documentation (and paradigm) of bloated library, or going round the internet globe to find a connection between a poorly documented library/code chuck. and since i didnt get any reply last time, indicating that i'm good to go with my DIY library. past one week or so, i will say i'm satisfied, i've built a basic structure for my library, and the idea is i would like to share... FWIW.

i 200% agree with your point about the few flaws and 'defficiency' of existing rtOS, library etc esp this.. 'One of the things that makes a library like that valuable is completeness, permanence, and support' other than bloatness i dont require. this is 'exactly' the reason why the my first choice is will be... 'DIY'. i dont want to become dependent and stuck with ones paradigm. and i wont expect some people 'with knowledge' to accept my 'paradigm' and use the library aS is, they can make their own paradigm (notation or structure idea) and i will be glad if they can share and we learn.

ps: from my tiny experience... making 'all in one' system is pretty much impossible without sacrificying 'bloat'ability.

[Bored@Work]

ASF does this for AVR.
[...]
One of the things that makes a library like that valuable is completeness, permanence, and support.

You haven't worked much with ASF then? It is incomplete and the second thing you encounter is that you have to debug it before it becomes useful. Than it is bloated and you have rather strange side effects, like functions turning off completely unrelated interrupts. Support? Well, the library is developed by Atmel in France. They show more arrogance than knowledge when it comes to ASF support. Or it is maybe that I cant appreciate there dick waving, because I didn't study at an école nationale supérieure.

(a lot of libc and posix is  pretty universal.)
[...]
Yet Another Beginning of an Open Source Project by some individual is  ... not at all interesting.  (Nothing personal, and no offense or particular criticism intended.

Well, the standard avr-libc for AVRs just works, as opposite to ASF. But the standard arv-libc happens to be an open-source project, done by individuals. Uh, don't you hate it when facts getin the way of a good story?

[westfw]

making 'all in one' system is pretty much impossible without sacrificying 'bloat'ability.

Agree.  This is a generic problem with software. Adding flexibility decreases simplicity...

It is incomplete and ... you have to debug it before it becomes useful.

Ah, yes, I failed to mention that many of the "standard" libraries are well-hated by people who have tried to use them.  Because of bloat, slowness, errors, unacceptable licensing terms, and general uselessness.  I've heard particularly bad things about CMSIS libraries.

arv-libc happens to be an open-source project, done by individuals.

You have an important "s" after "individual" that I didn't have in my complaint.  There's a critical mass of some kind to an open source project.  If I had a dollar for every college project that someone put up on github because they though that "the open source community" would pick it up and support it after their own interests had wandered...

[obiwanjacobi]

I am relatively new to the Arduino but I am a programmer for over 20 years (17 years professional).

The Arduino library is totally useless (for me ) for all but the simplest experiments. The problem has to do with the composability of the different parts of the library.
That is why I started my own library which strictly separates responsibilities into different (template) classes. The library allows you to 'click' together the pieces of code you need without making assumptions on the protocol or pins you will be using. For instance, I wrote a Midi Reader class that implements the Midi Protocol (for the receiving side). That class has absolutely no knowledge on where the bytes come from, or how they get there. The Arduino MIDI lib is bound to the serial capabilities, and even the board pins and is always send/receive.

I use a template trick (deriving from a template parameter) that makes all this possible. Thus far this seems a very good way to build very lean and to the point code (no bloating). I aim for the least amount of RAM usage. A lot of information usually stored in variables (RAM) do not need to be dynamic for an MCU. For instance there is no program loader that dynamically determines the address, so function pointers are always static.

My Library is still in its humble beginnings...

So, to the point, I do believe you can write a good library that will not bloat. If you put the user in control on what is pulled into the project, any resulting bloating is his/her own fault ;-)

[Mechatrommer]

i dont see your download link obiwan... "This project has no releases." i did try virtual functions, polymorphic class slows the code performance significantly (the compiler really complying to C++ definition, ie runtime decision or virtual classes/functions) making me to rule out any class abstraction attempt. now the simple class alone... i have an issue now... https://www.eevblog.com/forum/microcontrollers/idiotic-me-or-the-compilerlinker-fo-the-avr-studion-4/msg121604/#msg121604 sigh!

[ee851]

If you want what you call a "proper library", you will have to build it yourself.

For example, if you want to write general text messages, be they error messages or values of state variables using printf() function to an LCD, then you must write an interface (API) that actually works with your particular LCD.

Suppose you define an interface as a call to function printfck().   This function is supposed to do exactly what printf() does, but to your particular display device.  If you only have one text output device, the arguments might correspond exactly to those supplied to a call to printf() on your personal computer.    If you have more than one text output device, you might need to supply the output device ID as an additional parameter to the printfck() function call.

Your API will then enable you to substitute a call to function printf() to a corresponding function call to printfck().  This will translates a call to function printfck() into a hardware-dependent function call.

You will then have to do multiple aspects to make it work.

First, you must define a pre-processing step that translates printfck() calls into device-dependent code that works.   This might be as simple as writing macro's that the C preprocessor substitutes from your own include files.   This is the technology that implements your API.

Second, you must ensure the specific hardware-dependent code works for every possible call to printfck().     You might be able to copy and paste driver code written by others, with their acknowledgement and written consent, if it is written in the correct language, or if the corresponding object code can be copied into ROM or RAM that can be called by your process.

Those are my thoughts on this matter.   In essence, building your own API is simply a means of building/using your own set of library calls that you know and trust.    This is a commendable project.    I would encourage you to share both your device-dependent code and this conceptual idea of your own device API with other developers for the particular device, an AVR 32-bit microcontroller, for example, on whichever CPU you tested your code.

Note there may be other hardware-related issues to actually using such an API.    For example, it takes a finite time to write a text message to an LCD.   You might write code that writes the desired text message to an LCD, but you never see that
message--simply because another function writes another message to that same LCD that obliterates your first message.   You can only see the text message last written.

[Mechatrommer]

Your API will then enable you to substitute a call to function printf() to a corresponding function call to printfck()

1) blending in my library into a as standard function as printf() is something that to be learnt for me. for now, i will skip this attempt.
2) since standard c library doesnt provide full graphics implementation, i deviate my attention to another system, ie Win32 API, which i'm already familiar with. but i maybe off since i cannot copycat 100% of the system, such as how font, color, hwnd handlers etc works. trying so, i believe i will complicate my library unecessarily.

I would encourage you to share both your device-dependent code and this conceptual idea of your own device API with other developers for the particular device, an AVR 32-bit microcontroller, for example, on whichever CPU you tested your code.

its all there 'complete' in the zip file above (so far that i have done), including htm documentation that i struggled hard enough to write (albeit simple stuffs). if you read that from start to end, you should be able to get the idea of how the structure works. any CnC is always welcomed.

You might write code that writes the desired text message to an LCD, but you never see that message--simply because another function writes another message to that same LCD that obliterates your first message

thats why i stick to only one system (window like API), separating it with others, such as standard c lib. i dont want the MessageBox function does the same thing as printf does. my library should be supplementary, not complimentary (to existing standard c library).

[andyg]

Thanks, look forward to seeing how this turns out.

[Mechatrommer]

Thanks, look forward to seeing how this turns out.

yes i will keep expanding this. but two things are certain.
1) i cannot quickly develop this to meet everybody need, let alone support by me alone.
2) i cannot build every device driver/class that i dont have. so if no one with me. i'm with me alone
but hopefully i will keep updating this thread until the library is at its usable state, at least for somebody other than me.

[ee851]

Yes, I do think modeling your API after a Windows PC API would unnecessarily complicate it.    The PC windowing system for a PC involves attributes that an embedded system will not--having multiple viewports (windows), only one of which will have input focus at any instant, for example.      This may change in the future.

This is not to say, however, that you can't use a PC programmer's API to build & test your own embedded-systems API on the PC.     Not all of it, but some of it.

I don't know enough about your touchscreen-sensitive display device to know if implementing a general windowing system for input/output/menu selections or for graphics-related
operations would be worthwhile for an embedded device.   

Does this device have its own graphics memory and controller onboard, or does it rely on signals from the microcontroller to refresh its display?

[olsenn]

While I absolutely love the idea of a clean, well written (perfect) set of libraries being put into the public domain for integration into ANY project, it is ultimately impractical. Arduino has some libraries for basic I/O operations... but those can be programmed in C in no time at all, so it doesn't save much time. Furthermore, it is restricted to the Atmega168/328, and a handful of other supported devices... not very universal.

However, if you are programming in HDL (Verilog or VHDL) for an FPGA or ASIC (unlikely), OpenCores is a great hub for finding portable hardware code, which is a bit more future-proof.

[obiwanjacobi]

C/C++ is fine to program any MCU library in. If I understand correctly, most MCU's have compilers that support C/C++. The problem arises when you start to couple the logic with platform specific code. At that point you've narrowed the application of your lib. So its key to have those platform and chip specific code separate - or don't provide them at all.

When writing support for something, say your display, it is important to identify some different layers of logic that go into a working program for that device.

There is the hardware (abstraction) layer (HAL): this knows how the device is wired up, what pins represent what function. This should be easily replaced by something the user writes and it should be easy to write. What if I connect my display using serial to parallel shift registers? I should only have to change this 'driver'.

There is the protocol layer: this where the language of the device is implemented. The commands it can respond to etc. It communicates via "virtual pins" to the HAL - or via a fixed set of functions.

Then there is the Component layer: this is a pure software layer that just adds nice routine to the the device. For a display think of something like screen transitions or other fancy functionality. This is the added value of your library.

And the last one: the application layer: this is the application that uses your library. Not really your concern other than that you need to make your API as simple and sweet as possible.

This is the approach I've taken with my library. It allows for a high level of flexibility and the user can customize any of the layers it wishes. The way I achieve this is by using template classes for small piece of logic that can be stacked together and leaves the user in control on all the details. I will admit that this is no library for beginners (there are plenty of those libraries around), but for intermediate to advanced users it will enable them to build what they want, how they want it.

Also note that I don't speak of task scheduling at all. First I think a preemptive multitasking system is out of place on an single core MCU, second it is a separate concern, so my lib is not a RTOS. I may end up building something, but the main goal is to provide functionality and logic for devices and constructs you really can reuse for a range of different (kinds of) projects.

[nctnico]

The problem with most libraries is that they are full of bugs. Same goes for Opencores. I looked into several projects but the quality ain't great.

[Mechatrommer]

Does this device have its own graphics memory and controller onboard, or does it rely on signals from the microcontroller to refresh its display?

the hy32d lcd in particular has built in chip and memory management (refresh to monitor) so i dont have to manage them everytime. just sending one setpixel function, and the pixel will be there forever. other devices maybe different. about the touch screen, its based on mcu request (polling), other device may implement interrupt request by the device to mcu, so i provided poll() and interrupt() member function to mouse (touch screen) class, maybe for the display class will be too, for memoryless/chipless monitor. but mastery in hardwares implementation and standard is required to build a robust library, which i'm not. this is my best attempt to my knowledge, but not the best of all existing library (far from perfect i believe).

Arduino has some libraries for basic I/O operations... but those can be programmed in C in no time at all

the idea is to get rid of specific device protocol, programming DigitalWrite HI, LO in a specific sequence in 'device class'. once there, we'll use the library to make native/primitive/common function calls that already well accepted, such as setpixel, line etc. the Arduino IDE provided a level of abstraction to device (AVR chip) implementation, this api library even higher. possibly meant for other mcu as well, such as PIC, ARM and what not. and if you are using arduino library, i believe it wont be portable to say PIC IDE, or otherwise you have to build another library for PIC that implement DigitalWrite, AnalogRead etc. maybe its already there in the PIC-duino kit released earlier.

There is the hardware (abstraction) layer (HAL): this knows how the device is wired up, what pins represent what function. This should be easily replaced by something the user writes and it should be easy to write. What if I connect my display using serial to parallel shift registers? I should only have to change this 'driver'.

exactly what the object/class layer in my library does. all the application care about is calling object.setpixel() or API SetPixel() function. the class must do what it takes to render a pixel on the screen, be it serial or parallel protocol, its the class job, if it want to store a buffer/variables to do the task then, its up to the class (if the hardware doesnt provide it.

Also note that I don't speak of task scheduling at all. First I think a preemptive multitasking system is out of place on an single core MCU, second it is a separate concern, so my lib is not a RTOS. I may end up building something, but the main goal is to provide functionality and logic for devices and constructs you really can reuse for a range of different (kinds of) projects.

i will be looking forward to your 'template' implementation on how to make things generic, as i cant download full version of your library and documentation of the architecture, i only can view single file at a time of your code in the site you provided earlier, harder to get general view of your idea. of course, multitask scheduling is out of league in this small mcu system library.

The problem with most libraries is that they are full of bugs. Same goes for Opencores. I looked into several projects but the quality ain't great.

it get worse if you want to do it for profit or tight schedule. i treat software development as an art. and no one can rush art.

[westfw]

A big problem is that much of embedded programming is about manipulating the peripherals and hardware that is both intimately and peripherally connected to your cpu, and there is only so much that can be done to wrap that up in a library in any way that is at all portable.  Despite what manufacturers will tell you, I really have a hard time seeing the value of a sequence like:

Code: [Select]

ADC_CommonInitStructure.ADC_Mode = ADC_Mode_Independent;
ADC_CommonInitStructure.ADC_Prescaler = ADC_Prescaler_Div2;
ADC_CommonInitStructure.ADC_DMAAccessMode = ADC_DMAAccessMode_Disabled;
ADC_CommonInitStructure.ADC_TwoSamplingDelay = ADC_TwoSamplingDelay_5Cycles;
ADC_CommonInit(&ADC_CommonInitStructure);over just manipulating peripheral registers directly (using similar symbolic names.)  It adds memory, and cycles, and code, and doesn't really give you much in return.

A good library should add abstraction and/or portability.  If your library makes it so that all I have to implement is "init" and "setpixel", that's pretty good. (But it's probably not going to have performance matching a more device specific function set having sprites and fonts and bitblt.)   I think the Arduino abstraction of "pins" is pretty brilliant, for example.  I mean, it's pretty slow, and really annoying when you want to manipulate more than one bit at a time, but you get a new way of looking at microcontroller IO that lets people understand and use it without having to understand binary first.

[obiwanjacobi]

In my library, those parameters would all be static template parameters. They wont change during the execution of the program, so no use sacrificing RAM to it. That way it's just like programming constants into your program. I do realize that at some point you do need dynamic memory allocation and such (use of the new operator), but I want my library also to function (at an optimal level) for very small MCUs that hardly have RAM at all...

[free_electron]

Brokencores... The problem is that stuff is mainly written by people that have no clue how a hdl works. It's all either 'textbook' code, or made by academics, or made by people that come from the software world. If you synthesize it it is invariably large and slow.....

There is an incredible amount of really bad hdl code out there becasue almost none of the hdl coders understand how a synthesizer works. It is all treated as 'sourcecode', like a program code... In order to write efficient hdl you need to think in terms of logic, and you need to know how a synthesizer translates a , sequential list ( because that is what we humans write.. It is line after line of code) into something that hapens at the same time, and how you can exploit that.

One of the least understood things in hdl's ( all flavors of verilog or vhdl have this concept ) is scheduling. Both hdl's have a clause that says : logic shall be implemented in the order it is written. Understand this, know how it works,  and you can write incredibly compact hdl that synthesises to the smallest possible implementation.

One of these days i need to write an article about this..

Here is a classical example : make a synchronous up/ down , parallel loadable counter with an enable reset and preset. The following signals are used :
Clk , reset, preset, enable , up/down and load.

So the 'coders' start off :
Always @ posedge clk
If reset
Else if load
 Else if . . Yadayada jakkety jak

Throw a few other conditions in there, change some priorities and you have two pages of code that is a mess to maintain.. And you drown in it...

If you understand scheduling you don't need al that code.

Code: [Select]

Always @ posedge clock begin
If updown count <= count + 1 else count <= count -1
If ~Enable count <= count
If load count <= din
If preset count <= 9
If reset count <=0
End

note : in above code i didnt write any semicolons or other 'ballast'. This is a principle example only.

How does this work , and why does this work ? The basis of any synthesizer is the clause that code will be executed in the order it is written. Code exits at the end clause. So, any line of code that is closer to the end statement has HIGHER priority. If i apply 'reset' all the other lines are irellevant !
The reset signal has highest priority, preset has second highest.

By default my counter looks at updown and counts.
If enable is low ( tilde) i simple keep reloading the current value in the counter. I don't care about the previous line....
If somebody comes in and says : i need to have enable also block load and preset , the 'coders have to muck about with their if then else construction. I simply move the line that handles enable a bit lower in the list. Done.
You don't even need to make a testbench for it. It will work.

Why ? Because here is how synthesizers translate a list of instructions into logic : any if statement is a multiplexer.
Code is written from input to output. Every subsequent line of code injects a multiplexer with more conditions.
So my if statements switch multiplexers over. Anything before the multiplexer is void if the control line toggles it. This is the principle of scheduling. You can read it as ' do this ', 'unless ...', ' unless ', 'unless'. Any new condition is an 'unless'. The order of the unless statements switches multiplexers.

Multiplexer logic is AX+BXn. A chanin of multiplexer is an and-or ladder... And the easiest thing to logically minimize is an and-or ladder.... So the synthesizer has no problem whatsoever coming up with the densest solution. No risk for latch inferral due to unhandled clauses either. All condition paths are handled if you write scheduled logic.

Unfortunately almost none of the Hdl textbooks cover it.. Because it is not understood very well, yet every synthesizer works that way as it is part of both the verilog and vhdl standards...

If i have a moment of spare time i will work out a detailed post with better examples. It is very interesting and it has helped many people, that had trouble switching from 'code' to 'hardware thinking'. I had many people that were turned off and said 'fpga is too hard' that became fpga adepts after i explained this principle to them. I too struggled learning hdl's , until one of the experienced designers took my expensive '1000 page verilog book written by "experts"' and just ripped it to shreds... He started by explaining synthesizer technology and showed this multiplexer system step by step , and at that point everything fell into place.

[Mechatrommer]

A good library should add abstraction and/or portability.  If your library makes it so that all I have to implement is "init" and "setpixel", that's pretty good

this is what the mcuApiC has in mind. infact if you look at the sample code, it does just that, not even you have to type init (its done in class constructor). but not without a price, you need to build the "compliant class" and its pins assignment definition (or else rely and comply to existing built class for a particular hardware and pin connection setup). about the portability, this one need more testing as i only tested it in avrstudio, i believe once i get it completed (usable) and do some 1 or 2 project with it, maybe i'll get a chance to do a project on pic or arm and verify the portabilitiness. or make that 'typical' giant macro switches to accomodate for each environment possible.

But it's probably not going to have performance matching a more device specific function set having sprites and fonts and bitblt

exactly! esp when the library is becoming more generalized and bloated trying to support more 'device specific architecture'. using class alone already introduced some overhead. this is an inevitable compromise... nothing beats one flat assembly code with not much to no stack push popping. for performance compromise, i have to keep in mind that... "if i need more speed/performance/storage, i need to get higher end mCU/hardware". try running this library on pic10f200 is just delusional imho. but struggling to make the library as efficient as it can is a must effort and avoid unnecessary performance degradation effect. performance (ram or cpu) is the highest priority.

I think the Arduino abstraction of "pins" is pretty brilliant, for example

yes the idea is brilliant albeit not new (c/c++ abstraction already existed for decades), except its specific to avr chip family and the implementation is really inefficient (for that simple IO toggling).

They wont change during the execution of the program, so no use sacrificing RAM to it. That way it's just like programming constants into your program. I do realize that at some point you do need dynamic memory allocation and such (use of the new operator), but I want my library also to function (at an optimal level) for very small MCUs that hardly have RAM at all

the compromise for RAM usage is always.... cpu execution speed. you need to use less ram, but more processing extensive algorithm is required. dynamic memory allocation... i will avoid this in lowest layer abstraction, esp at device specific implementation. for higher layer functions/class, its probably acceptable (which is lesser get called by application, not like setpixel functions, which can be called hundreds to thousands of time in one function call, such as DrawBitmap).

[ToBeFrank]

as i cant download full version of your library and documentation of the architecture, i only can view single file at a time of your code in the site you provided earlier, harder to get general view of your idea.

Click the download link in the source code. Or alternatively, get his svn repo.

[nctnico]

Here is a classical example : make a synchronous up/ down , parallel loadable counter with an enable reset and preset. The following signals are used :
Clk , reset, preset, enable , up/down and load.

So the 'coders' start off :
Always @ posedge clk
If reset
Else if load
 Else if . . Yadayada jakkety jak

Throw a few other conditions in there, change some priorities and you have two pages of code that is a mess to maintain.. And you drown in it...

If you understand scheduling you don't need al that code.

Code: [Select]

Always @ posedge clock begin
If updown count <= count + 1 else count <= count -1
If ~Enable count <= count
If load count <= din
If preset count <= 9
If reset count <=0
End

note : in above code i didnt write any semicolons or other 'ballast'. This is a principle example only.

How does this work , and why does this work ? The basis of any synthesizer is the clause that code will be executed in the order it is written. Code exits at the end clause. So, any line of code that is closer to the end statement has HIGHER priority. If i apply 'reset' all the other lines are irellevant !
The reset signal has highest priority, preset has second highest.

It is interesting but I know exactly why it is not in any textbook: code should always describe what it is supposed to do.
Many people write if (variable) { do something;} in C. I hate that because it obfusticates software. Same goes for HDL. Regarding your example: if you want to avoid if-then-else use a priority encoder to get seperate count modes and use those modes in a switch-case. The optimiser won't care.

[free_electron]

@nctnico : my code describes EXACTLY what it is supposed to do. there is no 'ballast'
it also reads extremely easy.

first line : we look at updown and either count up or down depending on it.
if enable is low we hold at current count value
if load is active we copy din
if preset is sactive we set count to 9
if reset is active we set count to zero.

as logic as can be. the order of prioerity is given by the order of instructions. since the line that dictates behavior of reset is the last, this has highest priority.

there is no obfuscation going on. ne need to build a priority encoder in a separate block of code and then use a switch case statement. the priority is built in.

for an outsider this is very easy to understand code as well. you don;t need to read and re-read the whole block fo code to figure out what happens when.

of course the example i gave is only very simple. For complex blocks the scheduled code has lots of advantages :
- no latch inferrence possible
- if reset is the lowest line the reset will always work. important in large asics... i have seen asics  prototypes power up where the reset didn't work properly... good luck troubleshooting that
- no 'hidden' conditions possible that may deadlock a state machine for example.
- can eliminiate a lot of logic errors
- minimizes the amount of simulation required.

anyway. i will try to make a more detailed explanation and open a different post on this.
the reason textbooks don;t include it is because it requires two things
1) an understanding of logic at gate level.
2) a thinking in terms of hardware... verilog and vhdl are always tried to be treated as programming languages..

Almost every book on vhdl or verilog starts with a hello world example... how stupid and absurd is that ? you can't even synthesize that ! the effort is always on the simulation part and very little on the synthesis part. they assume a code - synthesize -run testbench - correct code flow...

if you use scheduled coding the flow changes to an almost 100% first time right where simulation is only required to do  timing closure...
i have large designs that are written using this technique and most of them worked right without even simulating them. in case of a bug the culprit was very quickly found.

[westfw]

yes [Arduino subtraction of "Pin"] is brilliant albeit not new (c/c++ abstraction already existed for decades)

Oh, "abstraction" has been around forever.  My point is that programmers (and in particular library authors) still need to pick good things and good ways to create the abstraction.  All too often, they fail :-(  (implementing "sbi()" in avr-gcc is an example that came up recently in another thread.  Logical, useful, efficient; but a terrible example of abstraction.)

except its specific to avr chip family

No, it's not.  It's also been implemented on ARM, MSP430, and PIC32 (at least!)  Implementing it on your favorite CPU is a good learning experience, because there is more to it than it looks like at first glance.

and the implementation is really inefficient (for that simple IO toggling).

Eh, it's not so bad, for what it is documented to do.  It's a bit much when it comes to setting a constant pin number to a constant value (which is pretty common.)  That's been solved, too, in at least three different ways, while keeping the "abstraction" part quite similar.  (but getting the new code back into Arduino is tougher.  I think they're worried that having digitalWrite suddenly become 20x faster for SOME cases might be dangerous.  This is probably a valid concern.)

[Mechatrommer]

i quick read the stm32 embedded gui library... the so claimed cmsis compliant (whatever that is). the documentation... i prefer to print the whole source code is better, alot better making my own. its like robot generated documentation i'm clueless where to start. i dont get it why and what they have in mind, what a waste .