|
I unboxed my fancy new ESP32-S3 yesterday. I intended to connect it to a parallel display and start banging on it until I realized that no toolchains are really ready for developing against it yet except for the ESP-IDF's which can limp along and do it if you're willing to devote your life to driving python scripts from the command line. So back in the box it goes.
I unboxed my ILI9341 display driver with an 8-bit parallel interface. Usually they come with a serial (SPI) interface.
I need to write a driver for it, and the ESP32 does not have hardware support for a parallel bus, meaning I have to bang the bits myself by controlling the individual pins.
And the trick is getting the timing right.
This is the part where I hate GCC (which I usually adore), because it doesn't respect "inline" very well. That means code like this:
#define HTCW_RS_C GPIO.out_w1tc = (1 << pin_rs)
#define HTCW_RS_D GPIO.out_w1ts = (1 << pin_rs)
#define HTCW_CS_L if(pin_cs>31) { GPIO.out1_w1tc.val = (1 << pin_cs-32); } else { GPIO.out_w1tc.val = (1 << pin_cs); }
#define HTCW_CS_H if(pin_cs>31) { GPIO.out1_w1ts.val = (1 << pin_cs-32); } else { GPIO.out_w1ts.val = (1 << pin_cs); }
#define HTCW_WR_L if(pin_wr>31) { GPIO.out1_w1tc.val = (1 << pin_wr-32); } else { GPIO.out_w1tc.val = (1 << pin_wr); }
#define HTCW_WR_H if(pin_wr>31) { GPIO.out1_w1ts.val = (1 << pin_wr-32); } else { GPIO.out_w1ts.val = (1 << pin_wr); }
#define HTCW_RD_L if(pin_wr>31) { GPIO.out1_w1tc.val = (1 << pin_rd-32); } else { GPIO.out_w1tc.val = (1 << pin_rd); }
#define HTCW_RD_H if(pin_wr>31) { GPIO.out1_w1ts.val = (1 << pin_rd-32); } else { GPIO.out_w1ts.val = (1 << pin_rd); }
#define HTCW_WRITE8(C) GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t)(C)); HTCW_WR_H
#define HTCW_WRITE16(C) GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 0)); HTCW_WR_H
#define HTCW_WRITE32(C) GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 24)); HTCW_WR_H; \
GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 16)); HTCW_WR_H; \
GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 8)); HTCW_WR_H; \
GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 0)); HTCW_WR_H
Forgive the formatting. There I'm using a combination of the preprocessor and constexpr charged ifs to get them to resolve at compile time based on the pin assignments. It's a mess that should have been able to be done without the preprocessor at all.
That mess is to get it as fast as possible, so that when I do insert delays, they are minimal and controlled - I'm not blowing overhead on branch prediction misses from function calls and the like.
Anyway, at least the bit banging is fun, even if what I have to do to the C++ language isn't.
I love coding the metal. I love writing hardware interfaces. It dovetails with my love of circuit building, right there where the rubber meets the road. Turn this pin on in software, send that bit to the 8080 parallel interface connected to the display. Woo.
Something about it just feels pure.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I love coding the metal. I love writing hardware interfaces. It dovetails with my love of circuit building, right there where the rubber meets the road.
I had the pleasure of spending half of my career straddling the hardware/software design boundary.
I'd be designing some chunk of programmable hardware in one hand, and writing snippets to run on it in the other. In those days we built things out of SSI/MSI in DIPs, a hundred or two on a 15" square circuit board.
It was a great way to avoid shooting myself in the foot with the kind of hardware quirks you often describe here.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Well, my process is going to have to adapt when I start doing some industrial automation-like controllers, which it looks like I might be diving into. Wago PLC specifically, which seems pretty simple.
Right now, I'm often dealing with stuff that's thrown together, or sourced from chinese manufacturers with documentation to match, or just dealing with cheapo chipsets that themselves are quirky.
That's kind of the hobbyist IoT realm, which is a pie I have some fingers in because of the IoT dev I do. I prototype at home using stuff I buy on amazon, and then I have someone I work with fritz it and make the boards with parts sourced from a reliable supplier like digikey. I'm not the only one who touches the circuits though. I'm one of three, and the least skilled at it. The other two people are electrical engineers. I'm software, but on the other hand, I know more hardware details about the particular MCUs we're using right now than anyone I work with. So we kind of lean on each other where we need to. It works.
Another reason I run into the quirks a lot is performance. I have to rip the wires from the walls sometimes to get the thing to perform like I need it to, and that comes with a lot of problems.
An article I wrote recently in fact is basically one big workaround:
Render Professional Screens on IoT[^]
Real programmers use butterflies
|
|
|
|
|
I am writing on some sort of vector drawing application, as a pet project, at home.
On the right side I have a property screen where I can set my current tool's property.
My.. issue, shall we say, is some of those simple property have ginormous base editor. Like color value editor is huge.
Here is a snippet: top rect is the property row, bottom rect is half of the color value picker.
So my property list usually rather short, some property editor however could be huge and that can destroy the simplicity of the UX (in the shot above only half of the color editor is seen, and some tools have multiple color properties!!)
Now I wonder what kind of UI mechanism I could use to improve that...
- having a second panel side by side for advance value editor? takes too much space! 
- using popup/drop down? might be the right way... but... it's annoying how those popup always close at the most inopportune moment... beside if you click the magnify glass you have a "screen picker" where one could chose a color anyway on screen by clicking on it (which would close the popup)
- modal dialog, or even window a bit too far.. this break the workflow, I feel...
Anyway, share your thought please?! 
[EDIT]
I think I might go with popup panel after.. I realized this afternoon they don't auto close like menu items do, it's up to me! I think that's a winner! 
[EDIT2]
I went with popup, with a TODO to be able to "pin" them one day, i.e. turn them in sticky windows like Paint.NET
I like it.
Result / Screenshot
modified 6-Dec-21 5:54am.
|
|
|
|
|
I would somewhat mimic the interface Xara uses on their vector editing program. You can see a video at Xara Designer Pro Tutorial Movies. At about 2:20 in the Beginners 2 video, the color editor tool is demoed. That modal window can stay open without getting in the way of your chores, until you close it manually. It updates to the selected item as it changes, of course.
|
|
|
|
|
Thanks, watching the videos now!
|
|
|
|
|
I'm not a WPF lover expert, but maybe you can use the DockPanel control and let the user decide where to dock it.
If this is still too limited then maybe a tear-off panel would do the job, found something here:
GitHub - CommunityToolkit/Sample-TabView-TearOff[^] Sadly it has a limitation: Quote: Dragging a tab to another monitor/position doesn't open the window on the other monitor/position
|
|
|
|
|
I contemplated this...
I think I might go with popup panel after.. I realized this afternoon they don't auto close like menu items do, it's up to me! I think that's a winner!  
|
|
|
|
|
And to confuse the user further: add lots of configuration options!
|
|
|
|
|
Having dealt with interfaces that were far too complex, I would ask yourself, what am I going to use on a regular basis? The list you come up with is your primary property page. Then there is the Advanced... button.
As for the color picker, I'm not sure my suggestion is doable.
I have long been an advocate to adding code all UIs to track over time what is being used and what is not. I'd love to see the metrics on something like Word or Excel... I'd wager 95% of what is in there is rarely if ever used.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
mm.. interesting. will see if i can do something like that...
the color picker is super easy to use in fact, mouse down on the icon, the cursor turn into a magnify glass, move the mouse (while the button is still pressed) on a pretty part of your desktop screen, release, done, color selected!!
|
|
|
|
|
Paint.NET has a hideable "on top" Color window that you can drag onto another monitor which is usually what I wind up doing so it's useful; at least for me.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
For some reason I read "Pain.NET" maybe its time for new glasses 
|
|
|
|
|
yeah.. the idea crossed my mind..
I think.. I'll be starting with a popup.. that can be "pinned" into a dialog just like that one 
|
|
|
|
|
Looks very interesting !
I'd favor a separate window/form for really complex tool ui's ... let the user move it where they want it, move it to another monitor, resize it to taste, etc.
Since certain subsets of "specialized" tools ... tools whose icons you may wish to not always be visible ... may be used frequently in a given workflow, consider:
1) configure/reorder menus
2) or, define custom tool palettes
3) or, use a "shelf" ui as found in NeXtStep [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
|
|
It's hard problem...
on one hand, one keeps piling up an infinite amount of tools, properties, functionality,...
on the other hand, one wants a slick, simple and intuitive UI! 
|
|
|
|
|
one approach is user-defined ui's (themes, or modes, as you will).
issue of "piling up an infinite amount" ? imho, a data structure containing a list of visible ui elements, etc., and their visual/size/location, etc., properties, is practical.
let's say ... when i create a new document, i can choose from one of my previously saved themes, or open with the default theme.
from there:
1) open a theme editor app, and let me create, save, modify, etc.
2) or, let me save the current ui config as a new theme ... of course that implies the user can modify ui element visibility as they work on a document. in the case of using docking windows, or, tear off tool palettes ... that's present.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
sorry.. I am not in the mind to have customizable UI like Word or Excel (yet)
but hey.. you can load and save favorite all at once. so you can have multiple favorites and load the one for the job! 
|
|
|
|
|
Super Lloyd wrote: I am not in the mind to have customizable UI like Word or Excel (yet)
That's interesting: how do you see those Office apps as customizable ?
Also, not clear what "favorite" means in terms of your app.
And, now, since you reject me, i'm going to have to withdraw my one-time-only, unbelievably generous, offer to sell you an infinitely customizable UI at a price you'll never see again, and, also to cancel buying you a beer when you visit Chiang Mai next time   
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
|
dnGREP has a very nice feature Perhaps it is the kind you were referring to re/ the option to pin I mention it here because I am enthralled by it and may quite probably utilize it in a future project and perhaps may be useful to yourself dnGREP displays the source file of found matches in a docked right pane That pane has an NE pointing arrow in its' top right corner Whilst clicking upon said arrow the pane becomes floating It too has an arrow in the same top right corner this time pointing SE which of course re-docks it back to its' original location - Cheerio
|
|
|
|
|
sounds interesting, thanks!
|
|
|
|
|
It took most of the day between repeated merge conflicts and C++ linker weirdness coupled with toolchain weirdness but I got GFX and the GFX Demo project updated at github.
That's a huge weight off my mind. Whenever I have something that I know is being used that I also know has problems it eats at me.
Now that I've identified and fixed (I hope) all the potential issues, and reposted the massive updates I feel so much better about today.
This was the mountain of code I mentioned the other day. As far as maintaining it, that tiger has successfully been grabbed by the tail.
I even updated the esp32 subreddit with my changes.
I don't know if any of you get that gnawing concern over broken source, even if it's only broken for certain scenarios, but once I've published an article about something, if I know something has been wrong with it this whole time it puts me on edge.
Real programmers use butterflies
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
