As a hobby type person maybe I'm not qualified to respond, but I have found that since many newer PICs will still run at 5V it has simplified a few things with my own projects. I am slowly migrating to 3.3V when possible, but there are times where I still find 5V has advantages and makes things simpler.

The 18F24Q10 and 18F45Q10 are about the lowest priced they offer in the 18F variety and are quite capable. Really a lot of the 'Q' variety cost less than many of the older offerings and are much more capable. The 18F45Q10 has some built in logic cells that operate independent of the instruction clock and have proved useful in a home made logic analyzer board I built. The logic cells routed clock signals between binary counters used for RAM address bits, flip flops, and RAM clock signals faster than I could do in program and independent of the program.

I don't know about other manufacturers, but there are a few PICs with built in USB that make interfacing to a PC a little more interesting. I haven't tried any of the newer ones, but I did have a 18F2550 working quite well at one time. I found due to the price and for what I was using it for they weren't worth really using. There are some newer less costly ones, but I still don't really have the need for USB for most of my projects.

Anything that the Arduino IDE supports would probably be good to learn and it offers some form of portability at the expense of gaining an intimate knowledge of the microcontroller you are programming. I have been able to sort through a couple libraries and learn how a few things work for custom ESP8266 programming using the Espressif IDF. It may be beneficial for people to be able to both use the Arduino IDE and the perspective controller's native tools for programming such as the Espressif IDF for the ESP offerings or the AVR tool chain for Atmel products.

I would like to figure out how to use the STM32's run program from RAM feature to be able to load custom programs on the fly. It would be cool to have just a basic board I can use as a testing / tinkering platform and be able to keep a basic program or two in flash without having to reflash it every time for something new. I had planned on using the PICs external memory bus feature on some 80 pin chips, but the STM32 appears to make it much easier.

The MSP430 looks interesting and maybe something to look in to one day.

 

Going back to the question.. The ESP32 is the go to for wireless.. The Arduino platform is free. I recently installed the Pico W on the Arduino platform. these are from £3.60 each. You can use C++ Python or basic and the software for all three is free.

Is there any good offline simulator for ESP32 except wokwi.Because most of students excuses for no internet or slow internet connectivity.Is there any possibility to use ESP32 on Proteus?

 

Proteus will only do several 32bit micro's. Its a pity the Pic24 / 33 didn't do as well as the pic32 as they are supported in Proteus.

When I write for the pic32, I have a pic24 footprint in Proteus and I test in stages.
The ST32 Cortex M3 is modeled.. But I don't have the license for it so I cannot comment.

Nothing will simulate wireless any way. I just use rs232 and hope the radio part will do its job.

 

...so that students dont hjave to complain of no IDE.

You're teaching fundamentals of embedded engineering. IDE's don't teach you the fundamentals.

Start with asm, then c, then c++ and/or some dumb IDE. Teach them makefiles and linkers and header files. If you want to add in BLE or WiFi - get modules for one of those and have them develop a driver for it. It's a good time to also teach about drivers. Although - if you're driving an LED module you've also made a driver for it - so I don't see much value.

 

You're teaching fundamentals of embedded engineering. IDE's don't teach you the fundamentals.

Start with asm, then c, then c++ and/or some dumb IDE. Teach them makefiles and linkers and header files. If you want to add in BLE or WiFi - get modules for one of those and have them develop a driver for it. It's a good time to also teach about drivers. Although - if you're driving an LED module you've also made a driver for it - so I don't see much value.

In an ideal learning environment this might be true. Engineers today learn differently, especially with tools available. They need to see the end results in order to appreciate the building blocks and stay motivated. They want to get from A to Z as quickly and efficiently as possible. Having been there, done that, seen it, then they are more likely to be absorbed in the nitty gritty of the detailed steps.

 

In an ideal learning environment this might be true. Engineers today learn differently, especially with tools available. They need to see the end results in order to appreciate the building blocks and stay motivated. They want to get from A to Z as quickly and efficiently as possible. Having been there, done that, seen it, then they are more likely to be absorbed in the nitty gritty of the detailed steps.

I agree with this wholeheartedly. I have no doubt that the idea of expecting a student to learn fundamentals before the things that will get them results is a mistake. While their are a small percentage of students who find fascination in the fundamentals in and of themselves, the overwhelming majority will learn the fundamentals for the benefits they can bring.

In my teaching (primarily operating systems, programming, and networks) I used this to entrain the students along the path that included key fundamental topics—after they’d been able to accomplish higher level goals with my help.

Presented with a novel problem of the same type, it was much easier for them to understand the need for the fundamentals, and find motivation to climb the sometimes difficult learning curve, or to withstand the apparently abstract or impractical nature of some materials.

My most successful courses were ones that started from high- to low-level concepts, tying them together in the students mind and offering a reason to pursue, what otherwise might seem arcane and of little use, on their own even after class was over.

Demos, then principles, then practices, then labs—shift and repeat—is the basic drill.

 

In today's world, engineers are well accustomed to using simulators.

Long before anyone gets to college, they all learn to fly a Cessna 152 or a Boeing 747 in real time, without having to know how or why an airplane flies.

Engineers are exposed to simulators, finite element analysis, in fluid dynamics, heat, mechanical stress, and electrical analysis, without ever having to enter a laboratory. I am not saying that learning the fundamentals is not important. It is how educators approach and revise the pedagogy is important.

 

In today's world, engineers are well accustomed to using simulators.

Long before anyone gets to college, they all learn to fly a Cessna 152 or a Boeing 747 in real time, without having to know how or why an airplane flies.

Engineers are exposed to simulators, finite element analysis, in fluid dynamics, heat, mechanical stress, and electrical analysis, without ever having to enter a laboratory. I am not saying that learning the fundamentals is not important. It is how educators approach and revise the pedagogy is important.

Precisely. The solid knowledge of fundamentals makes everything else better.

 

In today's world, engineers are well accustomed to using simulators.

Long before anyone gets to college, they all learn to fly a Cessna 152 or a Boeing 747 in real time, without having to know how or why an airplane flies.

Engineers are exposed to simulators, finite element analysis, in fluid dynamics, heat, mechanical stress, and electrical analysis, without ever having to enter a laboratory. I am not saying that learning the fundamentals is not important. It is how educators approach and revise the pedagogy is important.

I agree that students today are more insistent on wanting the end results handed to them upfront without the bother of learning the fundamentals. As you can probably tell, I'm far from convinced that this is a good thing.

They might THINK they have learned to fly a plane because of their time spent with a game console -- but put them in a real airplane and, if anything, they do worse than someone with no such background. Been there, seen it -- more than once.

The same with simulators. In my experience, students whose electronics experience involves only simulators are, if anything, less prepared to do good lab work. As always, there are exceptions. But most students learn the wrong things and then have to spend time unlearning them. Simulators are a good supplement to hands-on experience, not a substitute for it.

 

In an ideal learning environment this might be true. Engineers today learn differently, especially with tools available. They need to see the end results in order to appreciate the building blocks and stay motivated. They want to get from A to Z as quickly and efficiently as possible. Having been there, done that, seen it, then they are more likely to be absorbed in the nitty gritty of the detailed steps.

The University of Colorado - Boulder has arguably one of the best embedded software programs in the world. I've taken their intro to embedded class. Guess what? *.asm, C, hardware, switch debouncing, wirewrap (which I could have done without), LED lights, LCD drivers, etc. Follow-on courses introduce you to embedded architectures, C++, RTOS, ring buffers, vision learning. They have embraced fundamentals in their intro courses. One thing with their program is that there are generally no pre-req's... choose the course you want to take and either sink or swim.

I get that it's a bottoms-up vs. top-down approach. I personally think you start with the bottom stuff first and work your way up.

I would advocate for an optional 2-3 week summer course to get students excited - using an Arduino and a simple IDE to get them interested. Do some wireless stuff. Abstract the details away to have the students understand the power of the system quickly.

 

Perhaps you were a student of @WBahn.

 

I get that it's a bottoms-up vs. top-down approach. I personally think you start with the bottom stuff first and work your way up.

We still use the bottom-up approach with a top-down view.

We tell the students at the first lecture that they are going to build XYZ, for example, a PID temperature controller, or an inverted pendulum. Then we introduce them to the steps required to accomplish their goal.

They begin with analog components and circuit design, followed by boolean algebra and digital circuits.
They move on to microcontrollers, ASM programming, HW-SW interface, before getting into C and MATLAB.

 

I would advocate for an optional 2-3 week summer course to get students excited - using an Arduino and a simple IDE to get them interested. Do some wireless stuff. Abstract the details away to have the students understand the power of the system quickly.

The latest release of the Arduino - Arduino Uno R4 - has WiFi onboard. So it also becomes sn option that has a popular supported IDE.

 

Perhaps you were a student of @WBahn.

I know Bill, personally, but not through the school - through this forum. We're both members of the oldest computer club in the world.

 

We still use the bottom-up approach with a top-down view.

We tell the students at the first lecture that they are going to build XYZ, for example, a PID temperature controller, or an inverted pendulum. Then we introduce them to the steps require to accomplish their goal.

They begin with analog components and circuit design, followed by boolean algebra and digital circuits.
They move on to microcontrollers, ASM programming, HW-SW interface, before getting into C and MATLAB.

I think we're advocating for the same approach. Just coming from different angles.