|
|
All of the sudden I'm no longer stumbling, and I've broken into a run.
Got my user interface library UIX up and functional. Well, a button control and a label control anyway, but that includes the considerable foundations to make it work.
Just an alpha blended button and a label
UIX initial demo - YouTube[^]
Fortunately it's downhill from here.
It feels good to have the rough parts of this behind me.
I've never done this before. I think I did okay.
I'm pretty proud of the rendering code below
uix/uix_screen.hpp at master · codewitch-honey-crisis/uix · GitHub[^]
Productive weekend.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Nice!
I love those days when I fly but today I'm grounded...nothing has gone right.
|
|
|
|
|
You are shaking a bit. Excited!
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
No, just shaky
To err is human. Fortune favors the monsters.
|
|
|
|
|
Magnified view will make it shaky.
You really work down in the weeds on your hardware and software.
Actually pretty cool to see it in action at that level.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Is it OK for you?
I never used, so far, but wondering about.
(This is NOT a programming question  )
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
If you mean things like malloc(), yes and no.
Heap fragmentation is a constant battle because you're dealing with very little SRAM.
Therefore, you need to be strategic about your allocations. Allocate, use, toss, as quickly as possible, OR allocate a large buffer initially, and then work from that.
I'll assume C++ below, though the above principles apply to things like C as well.
One caveat is you don't usually have debugging facilities, so it can be difficult to find leaks. Judicious use of the RAII pattern should take care of this. I usually delete copy constructors and implement move constructors for most of my classes that allocate to avoid casual allocations.
You'll probably want to avoid using The STL since they didn't really consider constrained memory environments when they made it - it whips the heap with a lot of little allocations. It *is* possible to cajole The STL into using a custom allocation scheme but there's also the issue of The STL not always being fully available, such as on 8-bit platforms, so I usually avoid it unless I'm targeting a particular platform and I know it supports it, if that makes sense.
The bottom line is: Be careful, be strategic, and you'll be okay.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Yes, I mean malloc and the like (in fact, since I saw malloc in your code I am wondering about...).
Thank you.
I am curious to know if someone uses a custom allocator.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I tend to use malloc because many platforms have custom allocators to allocate things like external memory.
For example, on the ESP32 you can allocate from extended RAM (PSRAM) by using ps_malloc instead of malloc.
By accepting a void*(allocator)(size_t) pointer as an argument to my constructor for example, I can use custom memory. With new and delete or even calloc that becomes problematic, as there are no corollaries.
That's primarily why I use malloc in so much of my C++ rather than the C++ish alternatives.
It's kind of an aside to what you were asking, but may be of some significance to you. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: With new and delete or even calloc that becomes problematic, as there are no corollaries.
I don't get this, since you might, for instance, use your own allocator in new.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I should have been more clear.
Sure if you do that it would work, but with new there are also other issues. It's not always possible/ideal to use new, such as for example, when you need to allocate an uninitialized array of bytes. It's not a good idea to preinitialize a gob of memory you're going to be overwriting entirely anyway, such as bitmap data. No sense in clearing it if you're just going to fill it with purple as your next step. This gets important on little CPUs.
Also, it's actually easier in practice to tie an allocator to a function pointer and keep things consistent. new can be overloaded inside classes with different behavior. I haven't really thought about the ramifications of that, in terms of a graphics library on IoT, where different memory has different characteristics but it smells to me, as though it would create confusing bugs - allocating from PSRAM in one instance because you call it from somewhere else where it would usually allocate from SRAM.
To err is human. Fortune favors the monsters.
|
|
|
|
|
CPallini wrote: I am curious to know if someone uses a custom allocator.
Back in the day for my 'limited' systems (64k to 1 meg)
# I wrote my own heap for use in C replacing what was there. Replacement managed different sizes.
# I wrote my own C++ allocators. That was to manage strings (my class) more efficiently.
I also wrote my own virtual memory manager for a limited use role to switch in and out code for printing a graph (if I recall correctly.)
|
|
|
|
|
Wow.
You should write one article (or possibly many articles) on the argument. 
I need to perceive full control, but a little scared of writing my own one.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I always avoid it: my realtime stuff is always expected to run 24/365, so any heap fragmentation is a major problem. I allocate ram at init or preferably compilation, and it doesn't change from there, except for the stack obviously.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That was I've done so far. However, systems are getting more complex...
Thank you.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I've found that you can create robust systems that malloc just fine as long as you're careful.
I mean, I'm not saying you shouldn't avoid it, but used judiciously you can get away with it without having to worry that your code will crash a week in.
Basically, you allocate small amounts and throw them away quickly.
Then if you're really concerned you can profile to make sure you aren't leaking and have enough headroom, but in practice I don't even find I need to do that most of the time.
Edit: If you use common libraries like LVGL to provide a user interface for example, those will often malloc in the background.
To err is human. Fortune favors the monsters.
modified 26-Feb-23 4:55am.
|
|
|
|
|
If you have a memory controller or if your micro controller has a memory controller in it then yes. Because to use DRAM something has to be in charge of the refresh cycle(s).
That is if I understand your question properly.
|
|
|
|
|
I meant malloc/free (or new/delete). I'm dealing with SRAM-only microcontrollers.
Thank you.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I just had a "High Sea" in a restaurant in the fishers town of Urk, a variation on "High Tea" which will probably raise eyebrows with English CodeProject members.
It was deliceous, with all kinds of fish accompanied by chips, I also had a glass of Sauvignon Blanc to flush it all away (my favourite however still remains Muscadet) 
|
|
|
|
|
how high did the waves break over the table ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
We ended up at the sea bottom (name of the restaurant: "De Zeebodem")
|
|
|
|
|
RickZeeland wrote: which will probably raise eyebrows with English CodeProject members.
With the dutch as well.
Can you not afford real meat?
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Well, they also had a "High meat" for the same (very reasonable) price, but as the dish was for 2 persons we had to choose. Next time we will go for the meat I think 
|
|
|
|
|
High meat.
I'm thinking a pig that's stoned like a garnaal.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
