Notifications
Clear all
Topic starter
2026-08-30 2:08 am
You might do a topic on that... I'd certainly be interested.
This post is a side stage of my debut project. The goal of this intermediate step is to get used on how to prepare programs for ESP32 systems or similar. This "apprenticeship" should be possible using simulators like those suggested in this clip. These are:
- Wokwi: https://wokwi.com/
Its pricing plan for 0,- monthly is, to generate a personal 30-day license for Wokwi VS Code. So I should change my identity every month to continue testing? - Cirkit Designer: https://www.cirkitstudio.com/
"Cirkit AI designs circuits, writes firmware, debugs projects, and researches solutions" (end of quote). So 'Cirkit' is primarily an AI front end? That could work due to the restricted focus, nevertheless I'm reluctant regarding AI, take me for too prudent -- so what. - Velxio: https://velxio.dev/
Near the bottom of its 'Pricing' section some common questions are answered. One of them is "Can I self-host Velxio for free? -- Yes." Plus a link to GitHub. In contrast to the '.msi Download for Windows' with the hint "30-day free trial" I didn't find (yet) a similar restriction on GitHub.
Since it's not a 'no installation, runs in your browser'-thing a. m. clip does not mention the simulation offered by Espressif. Alas, it's a bit puzzling, because one description lists considerable restrictions, while another reference does not show similar limitations (or I've overlooked it).
I'll give a try at Espressif's QEMU and Velxio. As first experiment I take HP41Kernel.cpp of V41 (what emulates an HP-41 but the Voyager's CPU is functionally the same) and interpret with it the f/w of an HP11C (see attached ROM copy). A trace log (if possible) should be the same as with another "emulator", at least it should end quite qick with the simulated CPU clocks stopped and virtual display on. (I will run this test w/o display, I'll check only the display's on/off bit.)
Don't expect me to report success tomorrow, it will take several weeks I guess. Until then, don't hesitate to post expedient comments.
Topic starter
2026-09-02 6:48 am
"The past is a foreign country; they do things differently there."
I could end this thread now, becaus I was told, what I try will fail. Recently I discussed my idea with a friend who made his living on embedded systems. "That's not possible since those simulators are imperfect, incomplete, inadequate. The only option is to use a development board and take the way of trial and error until it works", he said and also mentioned several examples.
That would mean, all the ESP32 simulators are a swindle? To make money with the stupid? I'm not convinced yet.
2026-09-03 3:19 pm
Hi @amphitryonoff,
I'll throw in a totally personal view. Please take it with an appropriately sized pinch of salt.
Simulators of electronic circuits are computer programmes which attempt to model certain behaviours of a circuit that the designer of the programme thought was important, and that could be practically represented by a set of software instructions.
I have only glanced at a few of the simulators of the type that you mention, which is insufficient experience to give you any advice about a specific product.
However, I will offer a suggestion as to how you might approach simulators in general.
In brief, I would support some of your friend's assertions. I think "simulators are imperfect, incomplete, inadequate" is implicitly true for most 'real' situations. The 'real' world tends to be far more complex and nuanced than can be captured in a general purpose programme.
However, I think "The only option is to use a development board and take the way of trial and error until it works" is overly dismissive of simulators.
In most cases, I think development boards and other means of 'playing' with real hardware is invaluable, because it exposes you to real world issues that the simulation does not even attempt to address by design. Thus relying on a software simulator to find all of the issues has considerable risks.
In reality, many hardware problems affecting mass produced products are only discovered after hundreds or millions of a particular design have been sold and delivered to customers, in spite of many hours of diligent testing by all means, including simulations, etc., long before the approval to start mass production was signed off. Of course, you may not be intending to mass product your design, but I mention it as a means of demonstrating the folly of assuming simulation is "all you need".
However, this coin has two sides. Simulation is not guaranteed to tell you "all you need to know", but it may tell you something(s) that will prove to be invaluable in you challenge. e.g. a simulation may point out something you were not expecting.
I would suggest that simulations are usually most useful in looking at a particular aspect that you think needs special attention, but for practical reasons is difficult to do on the bench. This can include the situation that the 'real hardware' system is not behaving in the required manner, and a focussed simulation may provide a valuable insight into what is happening, and maybe how to fix it.
For example, circuits which involve high voltage/current/power levels tend to have implicit dangers, where mistakes and oversights can easily be expensive and hazardous.
Simulators do not explode when huge currents flow in a simulated circuit! So discovering a design will cause excessive current to flow in a simulator can be much cheaper and safer.
However, a simulator will usually 'assume' that the insulation between two wires is 'perfect', whilst a real circuit may 'flash over', if the voltage difference between the wires becomes too high, or the insulation on the wires may melt, if the current flowing in the wire is too high. Most (but maybe not all) electronic circuit simulations do not simulate the temperature rise of a wire due to the current flowing.
The above examples are probably more dramatic than you are likely to meet, but I chose them, as they are easy to describe and visualise. More commonly, problems involve more subtle problems, like electrical noise, which are also easily overlooked in simulators.
-----------
To summarise, I think simulators can be very useful tools for the issues they are designed to address, but they do not replace building real circuits.
In addition, the 'components' of a simulation may be zero cost, but the time taken to build a useful simulation can be extensive, and by implication, expensive.
Best wishes and good luck. Dave
Topic starter
2026-09-04 12:53 am
Hi @davee !
TY very much for your detailed exposition of the subject in length. Special thank you for your time and effort.
I'd like to prepend my reply two quotes.
- Emulators are the poor man's hardware
- A software-defined emulator behaves like another system or computer, while a simulation imitates the operation of a real-world process only.
Because I use "emulators" of pocket calculators since long (and made one myself) I do know the difference between emulators and simulations. Even though those "emulators" run the original f/w of the role models by means of a simulated CPU they are as a whole simulations "only". When I simulate a printer under a primarily non-graphic system like VM/CMS I may omit all its graphical features -- just one example of an incomplete but useful simulation.
Then, emulators as poor man's hardware, this holds true for high-priced equipment like basement-filling mainframes wich I may use as a software implementation on a laptop (w/o water-cooling) while commuting. In contrast, to afford XIAO dev board for 3, 5, or maybe 8 USD I will not starve to death.
Simulators of electronic circuits are computer programmes which attempt to model certain behaviours of a circuit that the designer of the programme thought was important, and that could be practically represented by a set of software instructions.
Sure, simulators may be incomplete by design or involuntarily differing from the role model. Nonetheless, the programmer and/or her/his company/enterprise offer it in the hope it could be beneficial.
I have only glanced at a few of the simulators of the type that you mention, which is insufficient experience to give you any advice about a specific product.
NP. I silently hoped, one or two of the simulator creators could chime in and tell about the dos and donts.
However, I will offer a suggestion as to how you might approach simulators in general.
I'm happy for every expedient advice.
In brief, I would support some of your friend's assertions. I think "simulators are imperfect, incomplete, inadequate" is implicitly true for most 'real' situations. The 'real' world tends to be far more complex and nuanced than can be captured in a general purpose programme.
The subject is about simulatons, not emulators. We know about the afore-said distinctions.
However, I think "The only option is to use a development board and take the way of trial and error until it works" is overly dismissive of simulators.
I expressed it on purpose a bit provoking to get replies from those w/ positive experiences in using simulators. But, as we know, no answer is also an answer 😉
In most cases, I think development boards and other means of 'playing' with real hardware is invaluable, because it exposes you to real world issues that the simulation does not even attempt to address by design. Thus relying on a software simulator to find all of the issues has considerable risks.
Well, selection guides and comparison charts help not to pick a wrong module when I like to use WiFi. But the next assessment pass to narrow down the list of canditates, e.g. how to attach a display (and which kind of display), how to attach a keyboard, how to program it, younameit, should be possible to check within a simulator me think. Kind of proof of concept before the GO! to buy an apt dev board.
In reality, many hardware problems affecting mass produced products are only discovered after hundreds or millions of a particular design have been sold and delivered to customers
Thus some bugs will remain unnoticed since I will not vend my oeuvre.
but I mention it as a means of demonstrating the folly of assuming simulation is "all you need".
Hmm..., but exactly this folly works for me, it's crazy. Using the a. m. Hercules System/370, ESA/390, and z/Architecture Emulator I may code, compile, debug a program on my netbook while commuting and execute the running phase (w/o compiling the source once more) on a real iron at work. Inverse conclusion: if similar is not possible with ESP32 simulators, they are pretty much incomplete.
However, this coin has two sides. Simulation is not guaranteed to tell you "all you need to know", but it may tell you something(s) that will prove to be invaluable in you challenge. e.g. a simulation may point out something you were not expecting.
But the question is, which way is cheaper, faster, simpler, to use simulators or dev boards? In both cases it's kind of trial-and-error, or let's say it nicely: development. But when is the ideal point to switch from simulator to the dev board?
I would suggest that simulations are usually most useful in looking at a particular aspect that you think needs special attention, but for practical reasons is difficult to do on the bench. This can include the situation that the 'real hardware' system is not behaving in the required manner, and a focussed simulation may provide a valuable insight into what is happening, and maybe how to fix it.
I'm not convinced. Since simulations are no emulators, they highly likely map the real world only approximately. Thus to examine a root cause of real machinery failure with a simulation is odd me think, how about an oscilloscope?
For example, circuits which involve high voltage/current/power levels tend to have implicit dangers, where mistakes and oversights can easily be expensive and hazardous.
When executing practical experiments it may go bang sometimes, that's usual (and sometimes the purpose of the exercises).
Simulators do not explode when huge currents flow in a simulated circuit! So discovering a design will cause excessive current to flow in a simulator can be much cheaper and safer.
Sure, better safe than sorry, depending the value of the plant and/or if damage to persons may happen.
However, a simulator will usually 'assume' that the insulation between two wires is 'perfect', whilst a real circuit may 'flash over', if the voltage difference between the wires becomes too high, or the insulation on the wires may melt, if the current flowing in the wire is too high. Most (but maybe not all) electronic circuit simulations do not simulate the temperature rise of a wire due to the current flowing
As said before, simulations are no emulators. They simulate only what's required.
To summarise, I think simulators can be very useful tools for the issues they are designed to address, but they do not replace building real circuits.
Ok, got it me think. I'll inverstigate some hours in simulators and will then switch to a dev board I hope it could be adequate.
In addition, the 'components' of a simulation may be zero cost, but the time taken to build a useful simulation can be extensive, and by implication, expensive.
For the hobby you must not count hours, otherwise it's not worth it.
Best wishes and good luck. Dave
TY -- I hope I will have finished this project within a year or so. If that's unfeasible I'll give up.
2026-09-04 11:24 pm
Hi @amphitryonoff,
Thanks for your kind reply.
I hadn't really considered whether I was considering an emulator or simulator. In practice, whilst it is possible to point to specific examples of either, I have seen the words interchanged on similar systems... not as precise synonyms, but more in context of what the author thought they wanted to achieve at the time.
At the time of writing my message, I was imagining a system to simulate a circuit, like an Arduino or similar development board, connected to sensors and/or actuators. I regarded it as a simulation, because I would only expect it to be a 'pictoral' representation of a system that would need to be built with 'real' hardware, to have a 'useful' implementation of the overall system function.
I would suggest that at least some emulations, are basically aiming to be an alternative implementation of a given system function, which has been created for some convenience. For example, providing the facility to run a given computer programme, on a different type of processor (with a different instruction set) , because a processor of the original type is no longer available. In some cases, emulation may enable a 'poor' person to have a similar experience to that of a user of a large expensive machine, but that is not the only reason.
For example, it is common for digital chip designers to build an emulation of a new chip design, using FPGAs (Field Programmable Gate Array), to produce a circuit that emulates the required functionality, before committing to manufacturing the first batch of chips. In this case, the cost of the emulator will probably be much greater than the final chip version, but of course, the non recurrent tooling cost of that first batch will be greater still, and maybe 'wasted', if the design has a flaw. And in this case, the chip design will probably have been extensively simulated, before attempting the FPGA based emulation.
Note that emulating an instruction set of processor A, on processor B with a different instruction set, is often a fairly simple translation/interpretation process, assuming processor B is of similar or greater capability to processor A, due to similarity in digital processor concepts over the last 70 or so years.
However, if you consider systems with more 'analogue' functions, the scope widens enormously. Including a simple operational amplifier in a microcontroller presents considerable emulation challenges to someone wanting to emulate it with a different processor that does not have an equivalent capability.
-------
You may reasonably think of a hobby as not being 'time cost driven', but in reality, it still is, albeit the hourly rate can vary enormously. When using external tools, like the simulators and emulators you mention, all will have required a large amount of effort by someone. Similarly, there will be a practical limit, be it patience, other pressures and responsibilities, etc. for even the most dedicated hobbyist.
I hope my discussion will prove useful to you. Best wishes, Dave
Topic starter
2026-09-06 12:06 am
Hi @davee !
I hope my discussion will prove useful to you.
We exchage arguments what made me lean back and rethink my proceeding once more and again. But, "There are experiences which I want to have myself" once said a school friend of my daughter. Obviously I do have to pass through this (for me) virgin soil full of dead ends and pitfalls.
Next hurdle reached. An interim report.
On a site of seeedstudio.com I found Wokwi referenced with the hint "World's most advanced ESP32 Simulator." So if I try this one I don't need to test any other. This is what I achieved so far:
I modified an existing example, the LEDs and the resistor are its remnants.
The display I added is rather a stopgap than the final choice I'd prefer. Alas, it turns out to be a beta version, so there is no description nor documentation, the only hint how to wire it are the balloon messages shown when hoovering the cursor over the contacts. I surmise 'VCC' means 5V which are only available while attached to USB-C to load the battery. Running on battery ther are no 5V on that XIAO connector. Wokwi offers no battery to attach, consequently the simulation is not apt to detect this malfunction.
I postponed the display issue and started to setup the keyboard with 39 buttons. The keycodes observed in the role model imply a wiring with five colums and eight rows. I have a two-layer keyboard shield in mind with some 6x6mm tactile switches (through-hole soldered) in the hope this would be less error prone than wiring the buttons using wires on a breadboard (but a bit more expensive I guess).
Alas, the big hurdle is, there is no dedicated "keyboard chip" in the catalogue of Wokwi. I want my keyboard to act as an I2C input peripheral. Is that illusory? Another option could be, give the keybord a XIAO of its own and link to the mainboard via BLE. Option rejected -- too much additional troubles.
So far the present situation. Conclusion, I got a bloody nose, virtually, but using a simulation I failed much faster than using a real dev board me think. At the moment I see two options, i) check the same using another simulator (and fail once more), or ii) dig deeper in Wokwi to find a solution. I can't see an advantage in shifting to a real dev board, not yet.
I hadn't really considered whether I was considering an emulator or simulator. In practice, whilst it is possible to point to specific examples of either, I have seen the words interchanged on similar systems... not as precise synonyms, but more in context of what the author thought they wanted to achieve at the time.
To be perfectly clear, emulator or simulation are distinct disparate gizmos, and therefore can not be synonyms. Full stop. So far the theory, pure teachings, those with know-why grasp it. Alas, in daily practice, those with know-how only are not so accurate and don't mind the facts. In addition, "emulator" sound really sophisticated, much better than underdone simulation only.
Simple example. To run ancient calculators there are two radical different approaches, i) either recreate precisely its behaviour, or ii) recreate precisely its CPU and run with it the f/w of the role model. Which one is an emulator and which is a simulation only? -- Both are simulations, since in case ii) the CPU is not emulated, in no respect are the timing, corner cases, other aspects of the original emulated. Notwithstanding this it's common to call case ii) "emulators" just to distinguish it from case i). But there was a wakening call recently to come down to earth. All (!) in public known, wrongly called "emulators" failed to run an example which is described since long for the role model. Even the root cause, a corner case of the CPU, was known and documented for a long time, but not one of the programmers implemented it in his simulation of the CPU. The majority still trade their simulation under "emulator".
So far for today.
2026-09-06 9:46 pm
Hi @amphitryonoff,
I wish you luck with you search for suitable hardware simulator. My experience, mainly in the more distant past, is that a specific simulation to dig into a particular question, can be invaluable. In general, this was looking for incite into 'fundamental' characteristics, often using generic components.
Finding a simulator that provided models for all of the components I would actually put on a useful board, seemed less probable than finding pirate treasure buried in the garden. Time has moved on since then, so maybe I am just out-of-date - I'll leave you to provide updates on your findings.
I suggest that you personally review each simulation you attempt, and ask yourself the question "Did this teach or reveal anything I didn't already know and realise?"
=======
As for emulator vs simulator distinction, I am not aware of the specific teachings you are referring to. However, "in no respect are the timing, corner cases, other aspects of the original emulated" feels like a very demanding requirement.
In production, even the smallest changes may change the corner cases, and sometimes with unexpected, but very expensive or disasterous consequences. Manufacturers are typically very nervous of even the smallest changes, such as moving to a second supplier of a simple, basic components, which are claimed to meet the same specification, and even variation from one batch to the next, from the same source may provoke considerable concern, resulting in extra work to mitigate the possible pain of delivering an inadequate product.
So how someone can produce an emulation of a product, that preserves all of the corner cases, without it being an identical copy, I find hard to imagine. Of course, if only a small set of specific corner cases is required to stay constant, then this is a different situation, but this makes the border a very 'flexible' definition. Personally, I don't think the difference between emulation and simulation definitions is important. The important thing is to understand the specific details and consequences of whatever you are using.
Best wishes, Dave
Topic starter
2026-09-07 4:01 am
Hi @davee !
First things first: I'm here because with my project I'm stepping into terra incognita where all is new for me. Hence I appreciate every expedient hint that helps to reach my goal.
I wish you luck with you search for suitable hardware simulator. My experience, mainly in the more distant past, is that a specific simulation to dig into a particular question, can be invaluable.
TY. So you made some "priceless" experience in the past. Let's see if I may replicate that today.
Finding a simulator that provided models for all of the components I would actually put on a useful board, seemed less probable than finding pirate treasure buried in the garden.
LOL! The real treasurs are in foreign gardens, e. g. Venezuela 😉 -- No, silly joke, back to the subject. Up to now I only used one simulator (Wokwi) and maybe it would be unfair to gauge its usability already after few hours I used it (or tried to use it). But in short time I found some "unexpected features", or should I say serious flaws? One is, first I wired the buttons of the keyboard totally wrong so it made no difference if the button was pressed or not -- 39 buttons and not a single warning from Wokwi. An amazing experience.
I suggest that you personally review each simulation you attempt, and ask yourself the question "Did this teach or reveal anything I didn't already know and realise?"
Counterquestions: How would you proceed in defining this 10 x 4 keyboard w/o a simulator? What is the canonical way? How would you look for the keypad scanner I was eagerly seeking within Wokwi's predefined components catalogue? (I found it by chance within the parts list of a cyberdeck presented in the internet.) One more question, how may I find alternatives to this keypad scanner?
As mentioned afore, I'm here to learn how to advance in this IoT/toys/tinkerer world. So please, show me your "electronics" compass.
As for emulator vs simulator distinction, I am not aware of the specific teachings you are referring to. However, "in no respect are the timing, corner cases, other aspects of the original emulated" feels like a very demanding requirement.
You got it. Again: a software-defined emulator behaves like another system or computer, while a simulation imitates the operation of a real-world process only. That is why an emulator is much more elaborate compared to a "simple" simulation.
Best,
M.
2026-09-07 4:08 pm
The 5×8 matrix looks perfect for this experiment.That gives 40 positions for 39 keys. It's better to test the matrix itself first .Then add the I2C keypad controller. The TCA8418 looks particularly suitable here. It supports matrix scanning through an I²C interface.It also handles debouncing and key events. The RT TCA8418 expansion board may help. It uses the TCA8418 for keypad expansion.
This post was modified 1 month ago by girlindrone
Topic starter
2026-09-08 2:54 am
Hi @girlindrone !
TY for taking a look at the details and confirming the TCA8418 would be suitable for my project. That gives me some confidence to continue my striving. (LOL! Reminds me Goethe: "Wer stetig strebend sich bemüht, den können wir erlösen." About: 'Those who strive constantly, we can liberate them.' An unfounded promise me think.)
Back to the subject: Highly likely I'll end my "ESP32 Simulator Adventure" quite soon for several reasons.
- Wokwi offers the option to define components missing in its catalogue. I tried that with the TCA8418 keypad scanner what worked partially pretty well so I have a graphic depiction (but naming is only possible with lower case letters) showing all connections with tags -- but to simulate its behaviour I should do some C programming and, sorry, I'm overstrained with that task. Thus I may use "my tca8418" only for wiring, w/o any functionality.
- Wokwi shows no warnings for mistakes. Simple example, I may short-circuit a switch so its shift position makes no difference -- Wokwi stays quitet. Thus my wiring is not checked and constructing according the nifty design will fail. In my view "Simulator" is a promise -- "Wokwi, World's most advanced ESP32 Simulator" -- that is why I'm disenchanted.
- I changed the display to an LCD which comes with description and examples. (But I did not achieve to turn it to portrait view.) I wired it as shown, I copied the example code to my program and hit 'Start the simulation.' Result: I got a message about an overburdened server and two alternatives, i) pay for privileged treatment, or ii) run the compiling localy which after some time requires a licence (no pricing indicated). -- I am unwilling to pay for something w/o a distinct gain. Even for free I'm struggling to find it useful.
Present situation:
The idea was to do the keyboard wiring same as the role model. But due to the TCA8418 there is no benefit from doing so. I'd rather disentangle the wiring, just because I'll need for sure a list which button corresponds to which keycode of the simulated calculator.
Next hurdles in sight, not related to simulations, the TCA8418 comes as a 4 x 4 mm package with 6 contacts to each side -- clearly an SMD chip, alas SMD soldering is far beyond my ability. In addition, TI offers this chip only on reels of 3000 pieces. IDK where to find smaller quantities and who may solder it.
Then, TCA8418 does a debouncing of 50 μs. Is that much or just enough? I do have to find buttons which will have for sure stable contact within this time.
It's better to test the matrix itself first.
How may I execute such a test? I surmise using real h/w, not a simulator.
The RT TCA8418 expansion board may help. It uses the TCA8418 for keypad expansion.
For testing in haptic reality I had this Adafruit TCA8418 Keypad Matrix in mind. But, frankly, I have no idea what is preferable.
In short, I'm looking now for a way to proceed w/o simulator. But as I'm not the first newbie I just have to find the handy guidance 😉
Topic starter
2026-09-08 8:24 am
The Velxio simulator was advertised in a video as one of the three best simulators. So I gave it a try. I opened in it the blinking LED example driven by an ESP32-C6.
Its pinout does not comply with the specification from seeed studio and thus my interest ended instantly.
2026-09-09 4:12 pm
Hi @amphitryonoff,
I have no practical experience of the chip, but the Adafruit TCA8418 reference you provide looks a reasonable start, and reasonably priced, assuming delivery and taxes don't hammer you.
The photo on Adafruit board looks similar to boards adverised on AliExpress, and other AliExpress vendors claim to offer the raw chip in small quantities for a few UK pounds (or presumably a few US $). Of course, buying from AliExpress can be a bit of a lottery, which you do at your own risk.
You would probably need a PCB manufactured, for your 'final' packaged solution, and some PCB houses will also solder chips on, for a price of course. I would start with the Adafruit or similar board, as a prototyping aid, and worry about the final version, when you have the bench model working.
50 microseconds sounds rather short for debounce ... In the past, I would probably aim for more like 100 milliseconds for a first try ... but the data sheet seems confused!
Looking at https://www.ti.com/lit/ds/symlink/tca8418.pdf
Front page says "Integrated Debounce Time of 50 μs"
Page 7 includes:
I hope page 7 is the correct answer, as 60 milliseconds seems much more reasonable!
Good luck, Dave
Topic starter
2026-09-09 11:25 pm
Hi @davee !
I have no practical experience
That is the best requisite to step unencumbered into adventures of any kind 😉
the Adafruit TCA8418 reference you provide looks a reasonable start, and reasonably priced, assuming delivery and taxes don't hammer you.
Few weeks ago Switzerland has reconditioned the free trade agreement with China. (No supplementary comment.)
Back to the subject:
... buying from AliExpress can be a bit of a lottery, which you do at your own risk.
I'm repelled from AliExpress since unequivocal specifications of the products in question is pretty obscure, for me at least.
You would probably need a PCB manufactured
Sure, highly likely I'll need it even for concept testing. As of yet I have no idea how to detect a tap&hold gesture (which is part of the UI either to show additional information or prolong the pause to display it). Two keys same time is NP because all work from off state togehter with the ON key. I'll do that with "sticky keys" while the simulated calculator is in "deep sleep" mode. In this way no same-time push of keys is necessary.
some PCB houses will also solder chips on
A friend mentioned recently, "good job done at JLCPCB". A major share of this results probably from a perfect input, Meindert made his living on designing PCPs. At the moment I have no idea how to define a PCB in a suitable way/manner/format.
50 microseconds sounds rather short for debounce
The two first diagrams in paragraph "8.6.2.15 Debounce Disable Registers, ..." (p. 33) in the spec you referenced show, the 50 microseconds is the pause (or delay) between "key press or release is stable" and triggering the interrupt signal, it's not the total duration of debouncing.
Front page says "Integrated Debounce Time of 50 μs"
I'm not a native speaker, so the term 'integrated' might be correct but misleading, IDK.
Leafing through the a. m. spec leads to more questions: pullup resistors. They are required for the I2C bus, for unused rows and/or columns, for RESET and INT if unused. My current wiring looks like this (I still use or misuse Wokwi to sketch it):
I added two pullup resistors to the I2C bus even so I'm not sure about the correct resistance value. For the unused COL5..9 and INT and RESET I use only one resistor, IDK if this works or every pin must have its own resistor.
But do the unused COL contacts really require an external resistor? Paragraph "8.6.2.16 GPIO pull-up Disable Register,..." (p. 34 of a. m. spec) shows (if I comprehend correctly) internal pullup resistors may be activated. It's puzzling.
If possible I hope to avoid the use of INT. That will save an extra line from the keyboard to the ESP32. Besides that I will not play ego shooter on my device, for a pocket calculator it's enough to query the keyboard buffer five times a second me think.
About the apt use of RESET I do have to reread the spec once more.
2026-09-12 2:48 pm
Hi @amphitryonoff,
Regarding AliExpress generally, "unequivocal specifications of the products in question is pretty obscure", seems a fair description. For me, AliExpress has provided a considerable number of parts for personal experiments at a tiny fraction of the price I would have needed to pay to more 'professional' sources. As my income is limited, and I can accept that a small proportion of my orders will be a "disappointment", I use AliExpress for low cost items.
If I was intending to market or distribute a resulting object, I would definitely look elsewhere.
So, I sometimes mention AliExpress, but only as a suggestion, NOT a recommendation.
I often see Amazon mentioned, with quicker delivery, but note that many items from 'Amazon marketplace sellars', look very similar to those on AliExpress at a lower price, suggesting they might be simple imports from AliExpress, Alibaba, etc. I leave everyone to make their own choices.
-------------
I haven't used JLCPCB yet, but they clearly have a useful operation to consider. I think they offer free versions of their own PCB design software, as well as open source software, like Kicad, being readily available. Of course, these tools all require learning how to use them ... at least until AI gets smart enough to do it for you.
-------
I did see the notes on debounce time ... albeit I didn't see a very clear explanation, and putting 'integrated' and '50 microsconds' in the front page summary seemed a bizarre choice, assuming I have interpreted the overall chip's process correctly. Personally, I would start by assuming the real debounce time is 60ms, build that part of the system in hardware, and see whether it works.
In principle, you could simulate it instead, but that implies you can find a simulation which precisely models that part of the chip's behaviour.
---------
Normally a reset line should be held in the 'active' reset during power up, and then released to 'passive' state, when the power lines have had enough time to settle throughout the system, including inside of the chips.
Typically, reset will be be 'active' when low. Then a suitable capacitor connected between the reset pin and ground (0V), will hold the pin low for a period of time at power up. A suitable resistor between the input pin and Vcc, will then gradually charge the capacitor, and reach the 'passive' level some time after the power is applied. The value of resistor and capacitor must be chosen to provide sufficient, but not excessive, delay.
--------
GPIO pins on microcontrollers often provide a software selectable internal pull resistor. The 'Do I need an external resistor as well? ', is a continual discussion point, partly because it is another 'It depends' case.
The internal resistor is usually provided for the case that the GPIO pin is not required for the final system, but the pin must be held at a fixed logic level, to prevent very undesirable effects within the chip. The assumption is that the pin will only be connected to a single pad, so the total 'wire length' will be less than about 2mm, and fairly immune to stray electrical and magnetic pick up problems. In this circumstance, the internal resistor may be a fairly high, and imprecise value, perhaps around 100 kOhms, merely required to pull and hold the pin high.
If the pin is connected to more than a local pad, and even more critically, if it is connected to a switch or other circuit which sometimes intentionally pulls the voltage to zero, then the value of the internal pull up may be too high to securely and rapidly pull the input signal back to Vcc, when the switch or equivalent is opened. In this case, an external resistor is required, which must be chosen to meet the local circuit's requrements.
------
For lines which are actively used, and must be pulled up, each separate line will require a separate pull up resistor. If there are two or more pins which are never driven to low/zero, then a single resistor is sufficient for them.
As a 'warning', a common problem is that a designer thinks that the design is 'finished', and connects all of the unused pins together. Sometime later, the design needs to be 'upgraded', and one or more of the unused pins is assigned an active role. Physically 'releasing' one or more pins for its new role can be a challenge, depending upon the actual physical implementation.
----
Note that, for minaturisation of a final product, multiple resistors in a multileg package are available. This does not change the circuit, just the physical space required.
---------
The TCA8418 provides internal pull up resistors on its keyboard inputs. In principle, the same checks need to be made for this case, but I would 'hope' that suitable internal resistors have been provided, as these chip pin inputs have been specially designed for this usage, whilst the microcontroller GPIO pins are completely general purpose, and unnecessarily low values would probably increase current demand, which would be a disadvantage with systems powered by small batteries.
For the Col and Row unused inputs, my interpretation is that the internal pull ups should be sufficient, assuming they are always enabled.
------
I2C should normally have external pull up for each line, but in most cases, only one may be needed ... if say 4 chips are linked on the same bus, one resistor will often be sufficient. If more than one sensor/actuator board is connected, it is easy to acidentally have resistors on each board.
-------
Interrupts do increase complexity. I don't know whether you are writing the software yourself, or adopting software from others. These decisions may indirectly determine whether or not it will be interrupt based.
Intuitively, I suspect interrupts can be avoided, but you wil need to ensure that there are no routines which will 'hog' the processor for a long time, causing it to miss events, like a keyboard press or release.
I haven't read enough to understand the details and implications, but you might choose to implement the hardware to enable interrupts to be deployed, even if your software never enables it to be active. Adding the hardware connections later may be painful! Just remember to configure the software to mask (disable) interrupts until the support for them is implemented, which may never happen.
Best wishes, Dave
Topic starter
2026-09-14 1:09 am
Hi @davee !
As my income is limited, and I can accept that a small proportion of my orders will be a "disappointment"
My income is significantly limited (I'm retiree) I can not afford ordering w/ obscurities. Thus I never purchased from AliExp. Since several month I observe also cases at Amazon with AI generatged descriptions every now and then contradictions within the same offer. In addition their prices ar too high me think. I buy preferably where I can see the merchandise. Alas -- my project is to use an Altoids tin as housing -- I found none, not in France (looked only in one supermarket) nor in Germany (also only one supermarket) nor in Switzerland (several kiosks, several big stores). I ended with three tins, one too flat to hold a battery with all the rest, one too small for a 4 rows by 10 colums keyboard, and one w/o hinges and too big to be an EDC. Thus in this case for this special Altoids tin case I'm forced to order online.
So, I sometimes mention AliExpress, but only as a suggestion, NOT a recommendation.
Up to now I ordered once at Banggood.com and it worked flawlessly. I only receive much more spam since then.
I leave everyone to make their own choices.
Phew!
In principle, you could simulate it [debounce] instead, but that implies you can find a simulation which precisely models that part of the chip's behaviour.
The virtual buttons used in Wokwi simulate bouncing I was told, what I find surprising. Either way I regard debouncing as solved by using this TCA8418 chip (if I get it in a reasonable small amount).
Normally a reset line should be held in the 'active' reset during power up, and then released to 'passive' state, when the power lines have had enough time to settle throughout the system, including inside of the chips.
I must read the TCA8418 chip's spec. Maybe it shows some options that could be useful for my project.
GPIO pins on microcontrollers often provide a software selectable internal pull resistor. The 'Do I need an external resistor as well? ', is a continual discussion point, partly because it is another 'It depends' case.
TY for explaining the two cases. As first go I planned to do the keyboard matrix the same as the role model, where the key codes implicate 8 rows by 5 colums. On Wokwi's Discord someone suggested a wiring of 8 rows by 10 colums but could not give a reason. I changed it now to 4 rows by 10 columns (also for no reason).
For the Col and Row unused inputs, my interpretation is that the internal pull ups should be sufficient, assuming they are always enabled.
I still can't see a reason to use all row and col lines. But maybe this is one of the points which might be tested with real h/w instead of a simulator.
Interrupts do increase complexity. I don't know whether you are writing the software yourself, or adopting software from others. These decisions may indirectly determine whether or not it will be interrupt based.
I hope I can write the s/w myself, up to now I did it twice, once in FORTRAN (under VM/CMS) and later again using ooRexx. I don't plan to use the TCA8418's interrupt since I will not play egoshooter on my device. To run an ancient pocket calculator it will be enough to query the chips buffer for changes five times a second. At least I do so on the PC.
Currently I copy all the apt suggestions I got on Wokwi's Discord to my simulation.
/M.
Page 1 / 2
Next