Recently I studied the 8080 / Z80, looked at most 8 bit kinds so I'm able to make a gist out of their machine model and pecularities.

When I started with PIC32 I considered it quite pointless even to begin with asssembler at all. you'd need to study 1000 pages with quite amount of detail, and there are many SFRs with cryptic names.

 

I can understand the need for socketable DIP packages or even PLCC. However, in order to meet the requirements listed and to stay current you almost have to abandon low-pin count DIP and move on to SMD components.

I would bite the bullet and move up to an ARM processor. With superior computing power, more memory, more hardware and features, the sacrifice for moving to SMD and C is worth it. ST has very affordable low power chips and accompanying development kits.

 

I've been using and programming 8051 controllers for decades now, and although they're still being updated by some manufacturers (to the point of making them single-cycle devices, and with in-system programming and other features), and can still handle a lot of complicated tasks, I'm giving serious consideration to learning how to use a recent model that is not constrained to an 8-bit architecture. This is mainly because of maximum code size, the lack of higher than 8-bit functions and registers, and the speed at which they run, which is a bit limited compared to newer technologies. The model that I'm most familiar with is the AT89LP4052, although I've used other atmel 32 pin devices before.

I'm not attracted to arduino nor raspberry, since (although they seem powerful) I consider those devices to be too high end for what I intend to use them for.
I've been programming in assembly all my life, and I'm no big fan of C. This is because most of my applications are time-critical, and I have to know exactly what instruction is being performed at the MCU at all times.
So far I'm considering ARM and AVR as possible substitutes for the 8051. What do you think? Which device that you are familiar with would you recommend for me to start learning, considering that I intend to program it using assembly? Also, it must have at least one UART port. And USB capability would be nice, but not essential.

I'd recommend the baseline PICs too or the new extended midrange.
You can use them for time critical tasks / with cycle control required, in assembler, contain it as much as possible, then use them as serial slave MCUs.

Its not difficult after a while. Then you can use as master any device you like, maybe 10msec resolution.

Mixing C / Assembler results in a mishmash (often) that few people will really dig into + reuse.

USB + assembler is almost effervescent complicated.

If you just look the C sources for STM8 which are supplied, they are worlds apart from the constructs of some programmers which think of themselves as highly acclaimed experts.

Almost unthinkable to do it in assembler.

 

USB + assembler is almost effervescent complicated.

My assembler USB stack for MSP430 is more clear, less complicated, faster and liter then original TI USB stack written in C. Last revision is so small, that cutomized BSL (CDC + AES Decrypt + Loader) is 2 KByte in total size.

 

My assembler USB stack for MSP430 is more clear, less complicated, faster and liter then original TI USB stack written in C. Last revision is so small, that cutomized BSL (CDC + AES Decrypt + Loader) is 2 KByte in total size.

I know nothing about the MSP430. I was trying to have it done with PICs but the sole real example I got was the one posted in the Microchip forum, years ago.

Did you write it yourself? If so, based on actually what? Kind of flow diagram or just what the protocol asks?

Very interested.

 

I know nothing about the MSP430. I was trying to have it done with PICs but the sole real example I got was the one posted in the Microchip forum, years ago.

Did you write it yourself? If so, based on actually what? Kind of flow diagram or just what the protocol asks?

Very interested.

I put logs to PC over 1 Mbps Uart all over the original TI USB Stack, and analyze it until everything was completely clear. Start with writing in assembler from zero. Target was minimal code size with high speed (1 MByte/s) transfer and lite CPU load, CDC and Bulk (not HID).