Yep, and very often, sadly they can be quite hard to spot until it's too late. I've been bitten so much over the years, that I now try to source direct from the manufacturers, even if it does cost more.

Power consumption might be important, but I find more important the durability as a long term storage. HDDs are better than SSDs on that by far, specially if the media is switched off the most of the time. M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

:) "A little time, a little trouble, your better day" Badfinger

This really depends on what it needs the FLASH storage for, frequency of access, storage size, board space, complexity, etc. Knowing what wifi chip you're considering would help but I would probably just stick a small SPI flash chip on there - or at least a footprint for it on a first prototype.

Embedded tools can be hard to set up, but are usually very reliable once they are. Is there any support for the RTOS or some example bootstrapping code or standard development boards? They might help you get to the point where there is only one thing being fixed rather than the hardware and software at the same time. As an alternative I wondered whether it would be possible to move over slowly, beginning with creating a board that runs a 40 pin display by being sent commands over whatever common bus will work, but keeping the main code where it is. The display board could then be fairly dumb and possibly just hardware rather than any software. The idea effectively being applying the strangler pattern to the current hardware. That might be easier than moving everything in one step in order to enable what is a small fraction of the current functionality, as there will only be a single thing to get working. This idea probably doesn't work for 100 reasons I haven't thought of but hopefully it is harmless to suggest it :).

Ah, brings back fond memories of spelunking the depths of CP/M, and its many undocumented features! Especially fun was discovering the ability to write a hidden track, between the standard tracks, to conceal data in plain sight. Loved that FDC 765! Have fun; you know you will! Will Rogers never met me.

Embedded programming is antithetical to pretty much every programming trend of the last 20 years. Note: If you are programming on a board that runs Linux or Android then this discussion is not really aimed at you. Deeply embedded systems are often built on severely resource constrained hardware. The typical embedded system uses only the memory built into the processor which can be a lot less than you expect. Cortex M0 processers for example come in variants with as little as 32KB FLASH and 2 KB RAM. Note the K vs M. The primary embedded programming languages is C (not C++ even though your compiler will claim to be C/C++). You will also need assembly code if you do board support packages. If you are not a proficient C coder, then get a good book and teach yourself. Book recommendations: All of these are older than dirt, but they are classics for a reason and will help you develop the mindset of an effective embedded programmer. Some of these are available as free downloads. * "Practical C Programming" by Steve Oualline for learning C coding in general. * "The Art of Embedded Systems" by Jack Gansslle for the general philosophy of embedded programming. * "Math Toolkit for Real-Time Programming" by Jack Crenshaw for complicated math. * "Insiders Guide to the Phillips ARM7 based Microcontrollers" by Trevor Martin for using processor resources. Martin's book on Philips ARM7 is the very best hardware tutorial book I have ever read. Hitex did a great thing for embedded programmers when they released this book as a free download (I think Philips paid for this book). I wish they had done the same thing for Cortex M processors, but life happens and money is not infinite. https://perswww.kuleuven.be/~u0068190/ARM7/lpc-ARM-book\_srn.pdf Embedded systems can go years between reboots and memory usage management is up to the programmer. Automatic memory allocation (malloc, new, etc.), or anything object oriented can be dangerous. Be wary of any library code that uses these kinds of things. This is one of the reasons why I want the source code for all libraries I use. Ring buffers are your friend. If properly implemented, buffer overflow exploits just became a thing of the past. You will need to be able to deal with missing data. I use packetized messages with error detection and missing message detection built into the communication protocol (I have been using my own processor to processor packetized protocol that I have used and extended over the last 2 decades). Every embedded product needs a r

Gary Wheeler wrote: I call those my "everything sucks and we're all gonna die" days :sigh: . Disclaimer: Not affiliated to them in any way. A fried just sent me the link today because they are in sales and I bought some t-shirts there. It is just that I remember two that fit perfectly with your message... One apple a day...[^] Watermelon wisdom[^] M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

Until last year was like changing Pest for Cholera... New boss of my boss came in 3 weeks before my return of parental leave, I kind of got a good connection with him and since I he named me (and a colleague) System Architect it has been a really good time. Way more busy than before, but I have recover the fun and the interest on what I have to do M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

I didn't reach something like that, but a salesman of Siemens made the statement that in the new version of TIA, there would not be any programm assertion / blocked execution more. When I said that he was wrong, he bet a starter kit... I won 3 of them and some time later an email from someone of the dev department saying "thanks" because they hadn't thought of that. M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

Yeah. But I got this. *cracks knuckles* Check out my IoT graphics library here: https://honeythecodewitch.com/gfx

Back in my younger days we had these same pin's on the underside of the BBC Micro, and the sockets, slots variations on devices etc. The standard they where known by, along with the ribbon cables that attached them where "IDC Connectors" Sometimes single row, sometimes double, some where male, some where female, some where 10 pins long, others where 20 pins or more, then there was the flat ribbon cables and the square plugs that went on the end, we just called all of them by the same name. These days, I have a crimping tool and pins/sockets rows, double blocks, 1x2 2x1, 2x2, 4x2 and so on... Those wires and connectors (According to my crimp tool manual) are called "Dupont Connectors" Dunno if that's the info your looking for. Shawty

Is not something similar a methode for brain washing? Why shouldn't work similar for AI? The question is... why the :elephant:? As it would not be bad enough training it with real internet data... M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

I saw this on Facebook the other day. In other news, Mom's cat "Fuzz" puked up a furball this morning. It was not uncommon for unattended DOS systems to run for a year or more. Three months is not news. When WIndows became more popular so did rebooting. I think the only thing that was a native problem with a DOS system sitting idle was if it didn't make a system call. The internal calender date would not advance until a system call was made so the calendar would stop if sitting at a DOS prompt. It would not know if the clock passed a second midnight. But most systems were doing something if they were left on, so it wasn't really an issue.

Jeff Healy? If so +50 to you, he was awesome, gone way too soon. "the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

Generally RFI (Radio Frequency Interferance), Track can act as antenna's for radio siginals. Could be the board layout, had that issue with MSP430's in the past. We switched to a cheaper alternative supplier (who didn't know how to layout multilayer circuits boards) kept getting rejections our our kit, looked at the controller board antenna central. Went back to TI boards (double the price) but no issues. I am glad I'm out of that so many ways to get sued!