Chuck,
I agree with you that well written and commented C is the way to go.
The advantage to an IDE comes with debugging and easy access symbols and
variables.
I worked for Software Development Systems working on their Freeform
(text based) and Single Step (windows based) debuggers. Which gave me
an up close experience with both types of interfaces.
Over the years I have used printf and blinking LEDs for debugging but
the ability to put breakpoints and watchpoints in code is immeasurable.
I have used GCC/GDB and command line debuggers and yes typing "bp
0x1234 -r 6 -h" works quite well, however, double clicking on a line
also works quite well and can be a little faster/easier to use. Hover
over a variable to get it's value is also very convenient.
This is similar to the model editor (Vi) vs non-modal editor (emacs,
brief) debate. It comes down to personal preference.
I have been programing since 1972 and have worked on all types of
systems, compilers, assemblers, editors, IDE's, emulators, etc. And,
over the years, I have found what works best for me (for example, I
have been using the brief editor keyboard layout for over 30 years) and
that works best for me. However, I have gone from simple assemblers
without any debugging at all to full IDE's and TBH, for me, I find the
IDE easier to use than command line debugging tools.
The auto make generation that comes with IDE's is quite nice also.
I will admit to using gcc/gdb for simple C code development without
leaving the slickedit environment.
Mike
On 5/25/2023 9:55 AM, Chuck Guzis via cctalk wrote:
On 5/25/23 04:52, Tony Duell via cctalk wrote:
USB interfacing is hard, but SD cards are a lot
simpler. So use a card
reader thing to transfer the files to an SD card and design an
interface for that to ISA bus.
That's my approach with my own setups. 32GB SD
cards are very
inexpensive and quite fast. So, rather than depend on a USB interface
to transfer data real-time to a PC, I use the SD card as intermediate
storage, later transferring the data off using either a card reader or
YModem-1K via serial port or USB. The side benefit is that the SD card
is large enough that I'll have a hard time filling it with things like
floppy images over the next few years--so I've got an automatic backup.
USB (or serial) is used mostly for commands and status (TTY emulator)
and can be run from a cheap tablet. The MCU I use does have ethernet
support, but I've found that to be unnecessary--the data volume isn't
that great.
For the programming language, I stick with C, not C++, not Python and
plain old makefiles--that's what the support libraries are written in.
I don't use an IDE, lest I become reliant on one--a text editor will do.
I document the heck out of code. Over the 50 or so years that I've been
cranking out gibberish, it's nice to go back to code that I wrote 30 or
40 years ago and still be able to read it.
I'm all too aware of the changing trends in the industry--and how
quickly they can change. I remember when there was a push in embedded
coding not long ago to use Ada--where is that today?
It's not that I resist technological change--I can and have written C++
and Python (what version?). On my desk sits a MicroPy board. I look
forward to advances in technology, but I'm also aware of how "bleeding
edge" trends can wither and get lost almost overnight. How many of you
program in Zig?
I imagine that in about 5 years, the main conversation will be about
using an AI to write code. Of course, there will be a new language to
instruct the AI...
--Chuck