toggle quoted messageShow quoted text
Yep, the resource depth of the Nano just isn't there for what I want to do. Also, the 2K SRAM limit is the most constricting limitation, and use can't accurately be judged at compile time. My experience is that things can go south after a 70% utilization rate is reached. The reason, of course, is because the stack ebbs and flows as functions are called during execution.
I tried the Nextion years ago, but didn't like it or having to page in new screens from the SD card. (I don't know if that's still the approach.) Also, at that time, their displays were overpriced. As to their OOP library, virtually any graphics library is now OOP. Even better, since they are Open Source, I can strip out what I need and manage that myself if I want to. I can't remember: Is the Nextion library Open Source?
My CAT stuff will all be Open Source when I'm done. I've just rewritten my Beginning C for Arduino book to Beginning C for Microcontrollers, which includes the Arduino family, but also the STM32, ESP32, and the Teensy. I'm just proofing it now, but want to get it done before I go back to the CAT project. This sidestep was necessary because I think Microchip is going to let the Atmel processors wither and die. Also, I see Hans moving to the STM32F4 and I think many other Arduino-based projects will do the same.
On Tuesday, August 4, 2020, 11:33:17 AM EDT, Dean Souleles <dsouleles@...> wrote:
I like your video - it gives me some good ideas for UI improvements. I also plan to implement a spectrum display. And for that reason and others its clear I need to move off of the Nano and start using a Teensy. I like using object oriented libraries like the one provided by Nextion - once you get over the initial learning curve, they make implementing the UI a snap. The downside is they take up memory which is a precious commodity on a Nano that I watch like a hawk every time I do a build. It reminds me of my imbedded systems days where every module got a RAM budget and a timing budget. Just including Nextion.h use over 1/2 of the Nano's available memory and each object (button, text, graph) that you need to manipulate from the sketch consumes 20-30 bytes or RAM. I'm sitting at about 80% of Nano's variable memory which is about the limit where things begin to fail due to stack or heap problems. I've gone through and optimized globals, moves strings to flash and so on, but I've about reach the limit. That is only an issue because the Nano has only 2K of SRAM. For those of us who have become accustomed to fast processors and GBs of RAM that is quite daunting. Even with that limitation it is remarkable what you can do with a $3 MCU - as Farhan and the guys have repeatedly demonstrated. That said I have very little motivation to roll my own UI libraries or write my own protocol handler to try to shoehorn everything in to 2K. That is a losing proposition and I'd much rather work on the application. To me the difference between a $3 MCU and a $20 MCU is not enough justify the hours of programming grief!
Its funny what bothers us. I have the 2.8" Nextion in the my uBiitx V5 in and Amateurradiokits case and I haven't noticed the sliding issue or haven't thought about it. It is entirely possible that I am compensating by using two hands without even knowing it. I'll check it out when I get home, I haven't permanently mounted the Nextion in the homebrew rig yet so I don't know how that will work..