Is it worth it to learn 8051 architecture now?

[technix]

Despite my primary choice of microcontrollers being something between AVR8, PIC8 and ARM, is it worth it to revisit the 8051 architecture now? Being in China, STC makes some ridiculously cheap 8051 MCUs on the low end. And universities still teach those. I do own a few 8051 chips though, a STC15L2K60S2, two STC89C51RC and two AT89C51RC.

I don't use those 8051 in my own projects though as I currently have no way debugging it. I have equipment to debug all my commonly used architectures, being AVR8 (Atmel ICE, a recent purchase,) PIC8 (PICkit 3) or ARM (J-link clone, also a recent purchase.) I do consider debugging somewhat important as I am a software perfectionist (I am professionally trained in software engineer after all, as that is my bachelor degree instead of electronics engineering) and I have a long history of battling heisenbugs that cannot be found by inserting printf's using debuggers.

[wraper]

Is it worth it to learn 8051 architecture now?

Yes

two STC89C51RC and two AT89C51RC

Don't bother with old chips. Use modern MCUs with modern 8051 instruction set compatible but order of magnitude faster core, Like EFM8 from Silicon labs which have good IDE and easy to program and debug. There are 8051 chips which are faster and more advanced than any AVR or 8 bit PIC, and much cheaper at the same time.

[technix]

Is it worth it to learn 8051 architecture now?

Yes

Thanks.

two STC89C51RC and two AT89C51RC

Don't bother with old chips. Use modern MCUs with modern 8051 instruction set compatible but order of magnitude faster core, Like EFM8 from Silicon labs which have good IDE and easy to program and debug. There are 8051 chips which are faster and more advanced than any AVR or 8 bit PIC, and much cheaper at the same time.

That STC15L2K60S2 implements such a new core. Older chips are cheaper though as I can buy decades-old NOS (I have tools to scrape the oxide off the pins very quickly.)

[nctnico]

Whether it is usefull to learnt the 8051 core depends on whether you are into high volume consumer products or might be involved in supporting legacy products. For the latter I wouldn't pay too much attentions because work will get less over time. 8051 may be interesting for consumer products but the archaic core will require much more development effort than a 16 bit (MSP430) or 32 bit (ARM) MCU. There are a lot of things in C (let alone C++) which don't work well on the 8051 core and need a compiler which can emulate these in software.

[wraper]

That STC15L2K60S2 implements such a new core. Older chips are cheaper though as I can buy decades-old NOS (I have tools to scrape the oxide off the pins very quickly.)

That's why I didn't quote it. When talking about cheap, you can buy Silicon Labs MCU with 17 kB flash, 2 kB RAM, decent 12 bit ADC, built in USB which do not require any crystal, internal 3.3V vreg which can supply up to 100mA and power external circuit, for less than 1 EUR at quantity of 1. And this is from Farnell, not some Chinese shithole (no offense). 8 kB version is even cheaper.

[ataradov]

Why not learn ARM? And once you are really comfortable with that, it takes like a day to figure out 8051, in case you actually need it.

[technix]

Whether it is usefull to learnt the 8051 core depends on whether you are into high volume consumer products or might be involved in supporting legacy products. For the latter I wouldn't pay too much attentions because work will get less over time. 8051 may be interesting for consumer products but the archaic core will require much more development effort than a 16 bit (MSP430) or 32 bit (ARM) MCU. There are a lot of things in C (let alone C++) which don't work well on the 8051 core and need a compiler which can emulate these in software.

Even among the 8-bit cores 8051 is more problematic than PIC18 from a C programmer's perspective (I always try to minimize assembler) and AVR8 is the simplest to code.

That STC15L2K60S2 implements such a new core. Older chips are cheaper though as I can buy decades-old NOS (I have tools to scrape the oxide off the pins very quickly.)

That's why I didn't quote it. When talking about cheap, you can buy Silicon Labs MCU with 17 kB flash, 2 kB RAM, decent 12 bit ADC, built in USB which do not require any crystal, internal 3.3V vreg which can supply up to 100mA and power external circuit, for less than 1 EUR at quantity of 1. And this is from Farnell, not some Chinese shithole (no offense). 8 kB version is even cheaper.

STC15L2K60S2 costs less than 0.1 EUR at quantity of 1, and no STC don't sell parts to distributors, they distribute parts themselves directly. By the way, I am from China and the STC company have an office in my city right where I usually shop for parts (and the company itself is 4 hours' drive north of my city, while the silicon itself is manufactured and packaged in TSMC facility right in the city.)

Why not learn ARM? And once you are really comfortable with that, it takes like a day to figure out 8051, in case you actually need it.

I am trying to. I am still trying to get the USART driver not to throw out Usage Errors when called through stdio though. It is no more different from AVR8 or PIC8 really, although the clock system always get on my nerves

[Kalvin]

You do not really need a debugger. If you can get the chip programmed and running, you can use a lightweight printf() for the debugging purposes. For really hard problems, use an oscilloscope and make some I/O-pins wiggle. That's the way it was done 20 - 25 years ago.

[technix]

You do not really need a debugger. If you can get the chip programmed and running, you can use a lightweight printf() for the debugging purposes. For really hard problems, use an oscilloscope and make some I/O-pins wiggle. That's the way it was done 20 - 25 years ago.

I have run into occasions where printf() gives me more issue than benefit (remember that I mentioned above that on my ARM board the printf function crashes the processor?) and it can throw off timing and cause heisenbugs (I have tracked down more than 20 such timing-caused race condition bugs on microcontrollers and computers alike before. Those bugs are hard to catch as it roots in timing and even a single nop instruction can throw the timing off enough to cause the bug to manifest differently)

[ataradov]

I have run into occasions where printf() gives me more issue than benefit (remember that I mentioned above that on my ARM board the printf function crashes the processor?) and it can throw off timing and cause heisenbugs.

Debuggers can be intrusive as well. You always need to think what is best for a specific case anyway.

printf() should not crash anything, and since you are learning, it is a great learning opportunity to figure out what is wrong and fix it.

[technix]

I have run into occasions where printf() gives me more issue than benefit (remember that I mentioned above that on my ARM board the printf function crashes the processor?) and it can throw off timing and cause heisenbugs.

Debuggers can be intrusive as well. You always need to think what is best for a specific case anyway.

printf() should not crash anything, and since you are learning, it is a great learning opportunity to figure out what is wrong and fix it.

Depend on what kind of debugger you are talking about. However unlike a good debugger that does not intrude too much to throw off timings to the point that I cannot even find the bugs in question, printf() almost always guarantees timings being thrown off.

I tracked the printf() buf on my ARM board to some code supplied by AC6 (in binary form)so that is a no-go for me.

[Kalvin]

You should be able to write a simple printf() yourself. Take a look at this as a starting point, and modify it for your purposes:

http://www.sparetimelabs.com/printfrevisited/printfrevisited.php
http://www.sparetimelabs.com/tinyprintf/tinyprintf.php

[rstofer]

I have run into occasions where printf() gives me more issue than benefit (remember that I mentioned above that on my ARM board the printf function crashes the processor?) and it can throw off timing and cause heisenbugs.

Debuggers can be intrusive as well. You always need to think what is best for a specific case anyway.

printf() should not crash anything, and since you are learning, it is a great learning opportunity to figure out what is wrong and fix it.

I am pretty down on implementations of printf() and anything in the strings library that use the heap.  I write my own little USART send/receive code and a few conversion routines from "The C Programming Language" (Kernighan & Ritchey) to get around these issues.  In any event, I would still have to write the putc() routine even if I did use a library version of printf().

But printf() will always be my favorite way to debug just about anything.  Single stepping code is a monumental waste of time!

[tggzzz]

You should never learn any single device's architecture, unless someone is paying you to do it as part of a job.

Instead you should learn common architectural principles that will (1) last a lifetime, and (2) enable you to pick up any single device's architecture within a day or so.

Example: what I learned in the 70s about 8080/6802/1802/etc was instantly relevant when I started programming Arduino-class machines. I was surprised and disappointed that so little had changed in 35 years (except cost and size, of course).

[nctnico]

You do not really need a debugger. If you can get the chip programmed and running, you can use a lightweight printf() for the debugging purposes. For really hard problems, use an oscilloscope and make some I/O-pins wiggle. That's the way it was done 20 - 25 years ago.

I have run into occasions where printf() gives me more issue than benefit (remember that I mentioned above that on my ARM board the printf function crashes the processor?) and it can throw off timing and cause heisenbugs (I have tracked down more than 20 such timing-caused race condition bugs on microcontrollers and computers alike before. Those bugs are hard to catch as it roots in timing and even a single nop instruction can throw the timing off enough to cause the bug to manifest differently)

If you have these kind of timing problems then you should seriously revise your programming and design methods!

[ebclr]

8051 is used in several applications, and also the last generation of 8051 have incredibile performance take a look on Silabs site.

Several  IOT and GSM modules use 8051 architecture, same for a lot of usb interface chips like Cypress, It's totally worth the time. But this must be complemented with Arm . Today Arm is HOT 8051 is usefull legacy. And PIC is shit expensive legacy

[wraper]

STC15L2K60S2 costs less than 0.1 EUR at quantity of 1, and no STC don't sell parts to distributors, they distribute parts themselves directly. By the way, I am from China and the STC company have an office in my city right where I usually shop for parts (and the company itself is 4 hours' drive north of my city, while the silicon itself is manufactured and packaged in TSMC facility right in the city.

Dunno, STC has price list in their datasheet, price for STC15L2K60S2 is RMB 5.5 = $ 0.82 (for 200k units order if I understand it right). Page 16:
http://www.stcmicro.com/datasheet/STC15F2K60S2-cn.pdf

[nctnico]

IMHO the biggest mistake is to look at the price of a part unless you are into high volume products. Archaic architectures are a PITA to program need expensive tools and thus get a beginner nowhere. If you are well versed on ARM you can pick up 8051 easely. The other way around is just a waste of time.

[wraper]

IMHO the biggest mistake is to look at the price of a part unless you are into high volume products. Archaic architectures are a PITA to program need expensive tools and thus get a beginner nowhere. If you are well versed on ARM you can pick up 8051 easely. The other way around is just a waste of time.

Silabs eclipse based IDE (simplicity studio) is free, and comes with free full Keil compiler licence, has graphical HW configurator which is good for beginners. All you need is EUR 30 dev board with built in Segger J-link which can program/debug external devices too, including ARM MCUs. Or (original) standalone debugger/programmer which costs about the same EUR 30, or even cheaper toolstick. Then there are cheap Chinese clones too. The same IDE is used for ARM MCUs too.

The on-chip debugging interface (C2) allows non-intrusive (uses no on-chip resources), full speed, in-circuit
debugging using the production MCU installed in the final application. This debug logic supports inspection and modification of memory
and registers, setting breakpoints, single stepping, and run and halt commands. All analog and digital peripherals are fully functional
while debugging.

[amyk]

If you are well versed on ARM you can pick up 8051 easely. The other way around is just a waste of time.

I'd say it's the other way around. ARM and AVR are boring if you know 8051 or PIC. PIC and 8051 are frustrating if you started with ARM or AVR.

[Keicar]

Wandering off topic somewhat, but I do recall occasions when adding a printf() made a problem (apparently) go away entirely - best not to tell your manager lest they decide to "leave it in there & call it fixed"...

[technix]

Wandering off topic somewhat, but I do recall occasions when adding a printf() made a problem (apparently) go away entirely - best not to tell your manager lest they decide to "leave it in there & call it fixed"...

That is what I call heisenbug. That printf() fixed the timing.

[Jeroen3]

Is it worth it to learn 8051 architecture now?

Depends where you work.
If you're working to develop some consumer products for millions a year for cheap. Yes. (think, chip-on-board)
If you're working to develop some industrial controller board for a few thousand units a year for industrial price. No, you'll waste engineering resources.
If you're working to support some industrial controller board for a few thousand units a year for industrial price. Yes, it'll run some legacy almost EOL 8051 controller.

[nctnico]

I've used 12C 8051, 4C 8051, 1C 8051, AVR, AVR-XMEGA, CM0, CM3, CM4, CA7, CA8, CA9, ARM9, ARM11, Blackfin+, CFP51, MSP430, C2000 and X86 Atom, and my conclusion is unless you write RTOS for it, or try to do some really weird timing critical things, architecture really doesn't matter.

In that case you never did anything serious. On architectures like the 8051 it it very hard to use pointers because of the many memory types it has. You always end up with some weird usage of C (pragmas to put variables into a certain memory, all variables global for example) and the compiler needs to emulate a lot of things like a stack. Nowadays programming is all about re-using code.

[wraper]

I've used 12C 8051, 4C 8051, 1C 8051, AVR, AVR-XMEGA, CM0, CM3, CM4, CA7, CA8, CA9, ARM9, ARM11, Blackfin+, CFP51, MSP430, C2000 and X86 Atom, and my conclusion is unless you write RTOS for it, or try to do some really weird timing critical things, architecture really doesn't matter.

In that case you never did anything serious. On architectures like the 8051 it it very hard to use pointers because of the many memory types it has. You always end up with some weird usage of C (pragmas to put variables into a certain memory, all variables global for example) and the compiler needs to emulate a lot of things like a stack. Nowadays programming is all about re-using code.

Not so difficult http://www.keil.com/support/man/docs/c51/c51_le_memtypes.htm
http://www.keil.com/support/man/docs/c51/c51_le_ptrs.htm and generic pointers can be used as well (slower).

Code: [Select]

char data var1;
char code text[] = "ENTER PARAMETER:";
unsigned long xdata array[100];
float idata x,y,z;
unsigned int pdata dimension;
unsigned char xdata vector[10][4][4];
char bdata flags;