The entire ASM language reference fit on one page that you had printed out next to the only monitor you had, a CRT next to the desktop. At least that's how I remember.
Did it tell you which bits were which in register #3?
That STM8... I gave it a try. You have to ask some French company in email a license to a free compiler that only works for one year. And then you have barely any examples. It was quite frustrating and gave up in the end. I rather pay a bit more to some much more polished development.
That would be Cosmic. I've never bothered with it; SDCC all the way. It does have some warts, but it works well enough. Actually, by now, it's probably the most polished and rounded compiler available for STM8, warts notwithstanding.
I've never had problems finding examples. Lots of various things on github, or in the nucleo/discovery board SDKs from STM. Code documentation is decent. If you set up an editor with code completion, it's pretty easy to just type something like 'spi' and scroll through the suggestions to find a register, struct, enum, macro or function you need. Its also pretty straightforward to develop bare metal style straight out of the RM.
I used to write assembly for AVR and PIC. Nowadays I don't have the patience to set up a toolchain. If it takes 20 minutes to do, the eval board and the company goes into the junk bin. I just want my usual libraries working out of the box.
I don't think there is any amount of money a company could pay me to do programming as a job anymore. Because your coworkers are all a*hats that will start a blood feud over the order of variables in a struct or how you name them. And management wants the most ridiculous features bolted on to an already finished product, then asks you to give an estimate on how long it will take, then report on it with 15 minutes accuracy.
The only reason I program something is that programming it myself in 15 minutes will cause less stress than talking to those people. Or I have a hobby project that I want to do myself for fun. Compilers are not fun.
But seriously, if I can put together a developer team, where you say: "I will use camel case to name my variables" - That's OK, It doesn't matter and we don't give a F" is the normal way of communication, then maybe I will.
Microchip PIC was THE microcontroller of choice way back, but now you hear practically nothing about them. Meanwhile, they still go into a zillion items.
It was only popular because equivalent small-scale Arm stuff didn't exist. Luckily that's now doing a good job of displacing the PIC architecture and that other abomination, MSP430.
I fully agree with 8 bit PICs (I never understood why PIC got so popular because it is so crappy both in terms of software development and the chip itself), but I don't see why MSP430 is bad. It has a flat memory architecture and the CPU has been designed to make it easy to write a C compiler for. I have done my fair share of MSP430 projects but never ran into problems. Besides the somewhat convoluted peripherals and average documentation, I don't see any real downsides to MSP430.
that other abomination, MSP430.
I rather liked the msp430, at least up until they added the warts for supporting more than 64k of address space. Very pdp11-like; much more so than any number of earlier chips that claimed to be pdp11-like! (Although, that makes it rather CISCy.)
Microchip PIC was THE microcontroller of choice way back, but now you hear practically nothing about them. Meanwhile, they still go into a zillion items.
It was only popular because equivalent small-scale Arm stuff didn't exist. Luckily that's now doing a good job of displacing the PIC architecture and that other abomination, MSP430.
Past tense for Arm. Now in embedded RISC-V is displacing both Arm (slowly) and everyone's proprietary ISAs and the remaining 8 bit. Only 8051 seems to be hanging on like a cockroach. -- tbh they're not bad for things that need no more than 256 bytes of RAM. Possibly AVR is better, but I've never heard or anyone licensing an AVR core to put inside their own ASIC, while 8051 is so old that clone designs are free.
Incidentally, you can always tell PIC and MSP430 programmers in a crowd, just look for anyone with many layers of healed-over bloody scabs on their foreheads, and possibly razor scars on their wrists.
Agreed on PIC, but what is supposed to be wrong with MSP430? The built in constants are a little bit funky -- but handy -- and ALU operation destinations being only
reg or
offset16(reg) is a very limited number of addressing modes for a CISC, but one more than RISC gives you. It's not a bad trade-off to encode a PDP-11 with 16 registers instead of 8.
I used to write assembly for AVR and PIC. Nowadays I don't have the patience to set up a toolchain. If it takes 20 minutes to do, the eval board and the company goes into the junk bin.
Agreed on PIC, but it doesn't take 20
seconds for AVR, MSP430, Arm, RISC-V, Coldfire.
bruce@i9:~$ time sudo apt install -y gcc-avr
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
gcc-doc avr-libc
The following NEW packages will be installed:
gcc-avr
0 upgraded, 1 newly installed, 0 to remove and 16 not upgraded.
Need to get 19.2 MB of archives.
After this operation, 77.4 MB of additional disk space will be used.
Get:1 http://au.archive.ubuntu.com/ubuntu noble/universe amd64 gcc-avr amd64 1:7.3.0+Atmel3.7.0-1 [19.2 MB]
Fetched 19.2 MB in 2s (11.1 MB/s)
Selecting previously unselected package gcc-avr.
(Reading database ... 349679 files and directories currently installed.)
Preparing to unpack .../gcc-avr_1%3a7.3.0+Atmel3.7.0-1_amd64.deb ...
Unpacking gcc-avr (1:7.3.0+Atmel3.7.0-1) ...
Setting up gcc-avr (1:7.3.0+Atmel3.7.0-1) ...
real 0m3.410s
user 0m0.001s
sys 0m0.004s
I for sure used it about 20 years ago,
...
According to Wikipedia it was introduced 2005.
Used, or using?
I am still using PICkit2, but not for PICs. Never liked PICs. Peripherals were not standard, too little RAM, and page swapping was a nightmare. However, I've used the PICkit 2 to program ATMEL AVR microcontrollers
(with some software bridge).
Meanwhile, since about 10 years ago or so, PICkit 2 was added as a supported hardware programmer by AVRdude, so PICkit 2 can now program AVR chips with zero software fuss. And can program PIC chips too.
The PICkit2 programmer can also be used as a 4 bits logic probe, to generate or to visualize logic pulses.
As for less used microcontrollers, Propeller 1 from Parallax was an interesting one. Very unusual. Its architecture and HDL code was open sourced some years ago. There is a Propeller 2 followup.
https://www.parallax.com/propeller-2/
Microchip PIC was THE microcontroller of choice way back, but now you hear practically nothing about them. Meanwhile, they still go into a zillion items.
It was only popular because equivalent small-scale Arm stuff didn't exist. Luckily that's now doing a good job of displacing the PIC architecture and that other abomination, MSP430.
I fully agree with 8 bit PICs (I never understood why PIC got so popular because it is so crappy both in terms of software development and the chip itself), but I don't see why MSP430 is bad.
PIC's got so popular because they were the first microcontroller with re-programmable EEPROM program memory, this was a game changer. The first mover advantage.
And back then most people only needed a microcontroller to do fairly simple jobs, so the architecture didn't really matter much. And excellent C compilers like the HiTech C compiler existed.
The entire ASM language reference fit on one page that you had printed out next to the only monitor you had, a CRT next to the desktop. At least that's how I remember.
With the 6502, the entire asm reference fit in your head, no need for a cheat sheet.
Of course you were also quite a bit younger than, and better at memorising lists of mnemonics.
General reply for the MSP430, possibly just a bad first impression from looking into something that involved one, not helped by the fact that they were trying to cram an Arm's worth of workload into a PDP11's worth of CPU.
The entire ASM language reference fit on one page that you had printed out next to the only monitor you had, a CRT next to the desktop. At least that's how I remember.
With the 6502, the entire asm reference fit in your head, no need for a cheat sheet.
Of course you were also quite a bit younger than, and better at memorising lists of mnemonics.
Mate. Mnemonics, sure, no problem. And registers, of course.
Which addressing modes are available, and which flags are affected ... that's another thing entirely.
Why do
LDY abs,X and
LDX abs,Y exist but not
STY abs,X and
STX abs,Y ??
Which instruction has only ZP and abs and nothing else, no indexing at all? And which flags does it set?
Which instruction has ZP, abs, and imm and nothing else?
The 6800 is almost always a much slower CPU, but my goodness it's much easier to memorise. All the accumulator instructions have imm, zp, abs, and off8,X while all the single operand RMW instructions have A, B, imm, and off8,X.
Microchip PIC was THE microcontroller of choice way back, but now you hear practically nothing about them. Meanwhile, they still go into a zillion items.
It was only popular because equivalent small-scale Arm stuff didn't exist. Luckily that's now doing a good job of displacing the PIC architecture and that other abomination, MSP430.
I fully agree with 8 bit PICs (I never understood why PIC got so popular because it is so crappy both in terms of software development and the chip itself), but I don't see why MSP430 is bad.
PIC's got so popular because they were...
...the go to chip (PIC16C54) for every pirate CATV decoders since running them with a 20MHz crystal made them just the right speed to lock onto a north-american NTSC video signal. For a time, this was the largest use case for the PIC16C54 and helped increase Microchip's profits high enough to improve both their own and third party compilers and programmers.
Hmmm, Wikipedia and google search has the wrong release date for the PIC16C54.
They have a release date of 1993 for the PIC16C84, but 1998 for the PIC16C54, this sounds backwards.
I remember using the first RS232-PICSTART programmer with a DOS Picasm compiler in 93. I wrote my own picstart programmer burning code to over-burn the 4MHz XT variants to run at the 20MHz HS speed. Basically, burn the Eprom 5 times in a row, then a protect burn. Worked flawlessly saving me thousands in using XT variants instead of the HS variants.
The 6800 is almost always a much slower CPU, but my goodness it's much easier to memorise. All the accumulator instructions have imm, zp, abs, and off8,X while all the single operand RMW instructions have A, B, imm, and off8,X.
Yup.
Never did get my head around all the 6502 addressing modes, and their limitations forced contorted thinking/code.
Basically, burn the Eprom 5 times in a row, then a protect burn. Worked flawlessly saving me thousands in using XT variants instead of the HS variants.
what sorcery is this? i never heard of it.. and i should have had as in high school our electronics teacher knew, used and discovered many such tricks
Hmmm, Wikipedia and google search has the wrong release date for the PIC16C54.
They have a release date of 1993 for the PIC16C84, but 1998 for the PIC16C54, this sounds backwards.
I think the PIC16C54 is around 1989 vintage. It's one of Microchips first range of chips after splitting away from General Instruments.
I fully agree with 8 bit PICs (I never understood why PIC got so popular because it is so crappy both in terms of software development and the chip itself),
The PIC got popular because it was the first single-chip MCU that was affordable and accessible. The low cost and size also pushed into areas where MCUs would have been unaffordable or too big. Architecture was way down the list of priorities
Microchip were the first to push OTP as a solution for production - previously the only real options were maskrom, or an external EPROM on an 8051 type device. There were a few other EPROM/OTP devices around at the time, but most were viewed as development devices for maskrom. One exception was the Philips 87C51 range which included a 28 pin (also 20 maybe?) part when almost everything else was 40 pin DIP/PLC44
The chips and tools were also easy to buy - back then many MCUs were only available via more specialist distributor.
Compared to the 8051, the assembler was simple and easy to learn.
Microchip also ran many free seminars to help users get going.
PIC's got so popular because they were the first microcontroller with re-programmable EEPROM program memory, this was a game changer. The first mover advantage.
And back then most people only needed a microcontroller to do fairly simple jobs, so the architecture didn't really matter much. And excellent C compilers like the HiTech C compiler existed.
Before that, it was the OTP PIC16C5x series that really kicked things off. The reprogrammable parts just made life a bit easier.
One advantage of the architecture at the time was that the assembler was really easy to learn due to the small instruction set- compilers were fairly expensive back then.
I did PIC assembler for many years (including 8K of very packed code on a soldered-down PLCC device) before moving to C.
Basically, burn the Eprom 5 times in a row, then a protect burn. Worked flawlessly saving me thousands in using XT variants instead of the HS variants.
what sorcery is this? i never heard of it.. and i should have had as in high school our electronics teacher knew, used and discovered many such tricks
Yup. Though you could fuse program the oscillator fuse of 20MHz HS variants to anything (HS, XT, LP, RC), even though the 4MHz XT ones were stuck as an XT, they would crash at 20MHz or only work for a day at 20MHz before becoming corrupt. Burning the eprom multiple times with the same software improved the on-chip eprom enough to function up to 25MHz. The HS variants fed at 40MHz by a TTL oscillator using my multiple burn trick would also function fine. (The XT would oscillate fine at 20MHz with the right caps and a good 5v supply.)
Note I believe that the picstart programmer was not intended to be a production grade programmer.
Hmmm, Wikipedia and google search has the wrong release date for the PIC16C54.
They have a release date of 1993 for the PIC16C84, but 1998 for the PIC16C54, this sounds backwards.
I think the PIC16C54 is around 1989 vintage. It's one of Microchips first range of chips after splitting away from General Instruments.
I started using the PIC16C54 a few months after purchasing my Commodore Amiga A3000 (one of the first in Montreal), so my earlier date of 1993 was wrong. I started using the PIC at the end of 1990, not 93.
Basically, burn the Eprom 5 times in a row, then a protect burn. Worked flawlessly saving me thousands in using XT variants instead of the HS variants.
what sorcery is this? i never heard of it.. and i should have had as in high school our electronics teacher knew, used and discovered many such tricks
Yup. Though you could fuse program the oscillator fuse of 20MHz HS variants to anything (HS, XT, LP, RC), even though the 4MHz XT ones were stuck as an XT, they would crash at 20MHz or only work for a day at 20MHz before becoming corrupt. Burning the eprom multiple times with the same software improved the on-chip eprom enough to function up to 25MHz. The HS variants fed at 40MHz by a TTL oscillator using my multiple burn trick would also function fine. (The XT would oscillate fine at 20MHz with the right caps and a good 5v supply.)
Crazy.
When are you doing DDR4? 
Yup, got my software DDR3 controller working on altera's Cyclone IV & Max10 at 1gtps while altera claimed a maximum of 600mtps for software DDR3 controller only on Max10 or Cyclone V.
If I had time, I would attempt a DDR4 controller, but, Xilinx has their own and Altera/Intel FPGAs are done.
If I had time, I would attempt a DDR4 controller, but, Xilinx has their own and Altera/Intel FPGAs are done.
What about Lattice though?
Another less common are the FPGA specific soft-core processors, for example Microblaze from Xilinx, or Nios from Altera.
If I had time, I would attempt a DDR4 controller, but, Xilinx has their own and Altera/Intel FPGAs are done.
What about Lattice though?
If someone would donate a dev board with a DDR3/DDR4 ram chip on it and a DVI/or/HDMI video output port, I would do it. It would give me an excuse to try another clocking trick I worked out last year allowing for only a single clock domain plus 1 phase tunable clock for the ready data block alone. (My Altera one used 3 clock phases with 3 domains and a complex .sdc file. This would improve fitting/routing for FPGAs with simpler PLLs like those in Lattice and Effinix, Gowin.)
Note that I heard that DDR4 is being discontinued and now everyone needs to move to DDR5.
Another less common are the FPGA specific soft-core processors, for example Microblaze from Xilinx, or Nios from Altera.
Every FPGA vendor is dumping or at least deprecating their proprietary FPGA cores ... now you have MicroBlaze V and Nios V, which run the same ISA.