Electronics > Microcontrollers
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 :P) 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 :P
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:
--- Quote ---you should already aware of this and its beautiness.
--- End quote ---
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:
--- Quote from: HAL-42b on June 16, 2012, 05:39:34 pm ---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.
--- End quote ---
i kind of aware of this, on and off. so i struggle hard enough to remember this fact :D 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).
--- Quote from: HAL-42b on June 16, 2012, 05:39:34 pm ---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.
--- End quote ---
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 :P. i stick with basic and c/c++.
--- Quote ---Yet Another Beginning of an Open Source Project by some individual is ... not at all interesting.
--- End quote ---
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!? :D 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.
Navigation
[0] Message Index
[#] Next page
Go to full version