Crazy idea? Making a PWM controller without a microcontroller? Possible?

[Smokey]

Go analog. 

Generate a triangle wave. 
Generate an analog voltage as the PWM duty command.
User a comparator to compare the duty cycle command voltage with the triangle wave voltage. 
Output of the comparator is PWM. 

This is how servo drives controlled motors before microcontrollers with PWM peripherals. 

[gnuarm]

years ago I implemented a "digital resistor" device with a latch and a network of resitors.
with one/two digital resistors you can modify the dutycycle of a NE555 PWM circuit.

Code: [Select]

.                         ______________
.                        |   dutycycle  |
.                    ____|___        ___|____
.                   |        |      |        |
.8bit --- latch ----| digital|      | NE555  |
./ce -------x       |resistor|      |        -------- PWM
.                   |________|      |________|
.                        |______________|
.

some problems:
- NE555 needs thermal compensation to avoid frequency drift
- the best I was able to obtain was dutycycle from 1% to 99%
- there are glitches when send a new value to the latch and it changes the configuration of the R-network
- it takes a lot or resitors, which may be 1-5% of tollerance, so ... expensive
- the capacitor of the "RC" cell must be low tollerance and very low ESR
- the R-network is never perfectly balanced, so the resistence seen by NE555 is never exactly linear/8bit set

This approach might work better with a digital resistor based on a switched capacitor.  There used to be chips, with all the details to implement tunable filters using switches and capacitors.  The capacitors act like charge pumps, conveying current across a connection.  The amount of charge in each switching action was pretty much fixed, and the faster the switching, the higher the current (so the lower the effective resistance). 

The frequency of the switching is easier to control continuously than a bank of discrete resistors.  (or is it discreet?  I can never remember, and the resistors are too discreet to tell me). 

[gnuarm]

Which leads me to: why not implement the 68000 architecture as a soft-core on an FPGA?

the 68000 is a very complex CISC CPU and takes a lot of LE when you try to implement it on FPGAs.
Modern FPGAs have enough resources nowadays, but the complexity is very high.

I wouldn't reccomend it.

There are many CPUs that are very adequate and can be implemented easily on a small FPGA.  One is called the J1, using around 500 LUT4s in its basic state.

[SiliconWizard]

Which leads me to: why not implement the 68000 architecture as a soft-core on an FPGA?

the 68000 is a very complex CISC CPU and takes a lot of LE when you try to implement it on FPGAs.
Modern FPGAs have enough resources nowadays, but the complexity is very high.

I wouldn't reccomend it.

There are many CPUs that are very adequate and can be implemented easily on a small FPGA.  One is called the J1, using around 500 LUT4s in its basic state.

Yes, but the OP specifically wants to design around the 68000. So using something else doesn't even make sense here IMO - if he were open to that, he would just use a MCU to begin with.

That said, I have evaluated a 68K soft core a few years ago, so anyone interested could have a look and do some testing as well: https://github.com/TobiFlex/TG68K.C

I had tested it on a Spartan-6-45 and (just checked), the core was taking about 5500 LUTs (20% of the device LUTs). Definitely more than a simple soft core for a small FPGA, but still pretty manageable without having to resort to large FPGAs. Fmax was about 30 MHz. Certainly much lower than what you can achieve with RISC soft cores on the same kind of FPGA, but still perfectly usable as a 68K.
Note that, as they state in this project, this soft core is not cycle-accurate, so if this is a concern for your particular application, you can forget about it.

I didn't test it extensively, but from the few tests I did back then, it appeared to work properly.
(I didn't end up using this solution though, at the time, we had to choose between a pure software emulation of the 68K and a soft core on FPGA. In the end, the software emulation won for reasons not directly linked to the performance of this soft core.)

[Siwastaja]

Analog motor controller. These were commonplace back in the days. Some kind of opamp integrator triangle or sawtooth wave generator, followed by a comparator. Also remember current sense, need that for motor control, analog or digital, unless the motors are very small. That's one comparator more plus maybe a flipflop which keeps the output off until the next PWM cycle.

[DiTBho]

Analog motor controller. These were commonplace back in the days. Some kind of opamp integrator triangle or sawtooth wave generator, followed by a comparator. Also remember current sense, need that for motor control, analog or digital, unless the motors are very small. That's one comparator more plus maybe a flipflop which keeps the output off until the next PWM cycle.

yup.

Code: [Select]

.
.              /|ramp
.             / |
.         ___/__|___ trigger
.           /   |
.  ________/____|_____________________________________ time
.
.       __    __
.      |  |  |  |
.      |  |  |  |
. ___---__|---__|_____________________________________ time


Code: [Select]

.           ______
.          |      |
.          | ramp |
.          | gen  | __________|\
.          |______|           | \ voltage compare
.           ______            |  \__________________ PWM
.          |      |           |  /
.8bit ____ | DAC  | __________| /
.          |______|           |/
.

analog parts: ramp wave generator, and OA as voltage comprator
digital: latch + DAC

[DiTBho]

J1

I know it, it's used on Gameduino v1 as kind of "VGA blitter", but frankly I wouldn't reccomend it as it only works with Forth programming.

OT, anyway, a minimal RISC-V multicycle core is what I would reccomend.

[gnuarm]

J1

I know it, it's used on Gameduino v1 as kind of "VGA blitter", but frankly I wouldn't reccomend it as it only works with Forth programming.

OT, anyway, a minimal RISC-V multicycle core is what I would reccomend.

Huh?  How does any processor only work with a specific language???  You mean there's no C compiler written for it? 

[tggzzz]

In my never ending quest to make retro computer stuff, I'm designing a simple robotics platform with a MC68000 processor (yes, I'm obsessed with this part!). I need two PWM signals to the motor controllers and common sense tells me to integrate a small microcontroller for this purpose. However, when I say "retro", I really want to mean retro, i.e., any component available pre-1990's. This led me down a rabbit hole of how to design a PWM controller without a microcontroller. Unfortunately for me, I'm at a loss here, so I'll be going the microcontroller route.

Why stick at 1990? Why not use the DAC technique invented by Claude Shannon[1] in 1948?

Much faster than PWM. Much simpler than PWM - one bit serial output (e.g. a UART), one resistor, one capacitor, and a sample-and-hold (i.e. a switch plus capacitor). If the bit period is T, then RC = ^T/_ln(2)
https://www.radiolocman.com/review/article.html?di=656991



[1] Yup, that's Shannon as in "useless machine", maze running mouse - and information theory.

[DiTBho]

Huh?  How does any processor only work with a specific language???  You mean there's no C compiler written for it?

Writing an HL compiler like C is always feasable in theory but not practically a good idea for j1 as the generated assembly code the compiler outputs is so inefficient and freak that you'd better program directly in assembly, or in Forth to have a sort of built-in debugging.

[tggzzz]

Huh?  How does any processor only work with a specific language???  You mean there's no C compiler written for it?

C presumes a flat byte-addressable memory space. Hence there are many computers for which there is no C compiler, or at least only a heavily bastardised C vaguely-looks-like-C  subset+superset.

I'm very out of touch with the C standards; fortunately I no longer have to waste my life understanding all the subtle meanings and omissions. Do they (still) have "near" and "far" keywords as needed for that abortion, the 80286?

[gnuarm]

Huh?  How does any processor only work with a specific language???  You mean there's no C compiler written for it?

Writing an HL compiler like C is always feasable in theory but not practically a good idea for j1 as the generated assembly code the compiler outputs is so inefficient and freak that you'd better program directly in assembly, or in Forth to have a sort of built-in debugging.

C compilers have been written for stack processors, and run well.  Trouble is, people who use stack processors, typically understand that C is a crappy language for smaller programs and small targets.  The C stack alone can use all the RAM in a small CPU.  So why burden a project with such overhead? 

No need for assembly language, just a good language that is designed for small targets. 

[jonpaul]

The PWM SMPS (analog) controller have been around since at least 1970s, simple PWM ICs.

i believe one of the first regulating PWM controllers was the  Silicon General SG  1524.

I visited the factory and met the designer   Stan Dendinger in 1976! Used in my first HID/HMI arc lamp electronic ballast.

https://www.electronicdesign.com/technologies/power/article/21188405/pwm-from-a-single-chip-to-a-giant-industry


These analog ICs  proceeded digital controller by about 15..25 years.

Jon

[Nominal Animal]

The PWM SMPS (analog) controller have been around since at least 1970s, simple PWM ICs. See Silicon General SG  1524.
https://www.electronicdesign.com/technologies/power/article/21188405/pwm-from-a-single-chip-to-a-giant-industry

They proceeded digital controller by about 15..25 years.

MC6840 was introduced in 1978 (in "Motorola Semiconductor Products Inc., Specification DS9802 Programmable Timer Module MC6840, 1978."), and is an 16-bit digital programmable timer module with three-channels, capable of PWM outputs but much more besides, running at up to 1/1.5/2 MHz.

[DiTBho]

C compilers have been written for stack processors, and run well

"run well" ...

for example, the machine code produced by gcc C/89 for hc11 in "expanded mode" (the CPU can fully address  64Kbyte) is an order of magnitude suboptimal than manual assembly programming. Hc11 has two index registers and only one accumulator, and it continuously needs push/pop in order to compute expresssion, doing IO stuff, and functions calls, so to follow the C machine layer model, from how to evaluate an expression (reverse polish notation is the best match here, all stack based) to how to handle calls of function (arguments pushed onto stack, response popped off stack), it always ends with much opcodes and stack space is wasted on machine-level glue code, which, being all stack-based, heavily uses asynchronous ram, which is several orders of magnitude slower than CPU registers.

Thank goodness, the hc11/E chip comes with half 1kbyte of internal (on-chip) static ram, and I can make better use of it by turning it into "virtual registers" to have more CPU registers, say 32 registers, like RISC. Yes, again "memory-based" operations instead of "pure register operations", and the code size only benedict a 2% off, which is nothing, but the speed up is 40%!!!

The commercial Avoget C/11 has a flag to use soft-registers, other commercial C compilers for hc11 don't have this trick, and with gcc ... you have to hack the old v3.3.6.

The point is that it's still suboptimal vs assembly programming, where you cleverly use resources and avoid repeated patterns ... here C has problems because "optimizing" the machine code produced by the HL is a very difficult task on stack-machines, and, in any case, it's the best trick you can do when you have 512byte of internal ram at your disposal.

So you say "run well" , I say "mumble" 

[MK14]

Hc11 has two index registers and only one accumulator,

It (68HC11) seems to have two accumulators, A and B, which can be combined as one 16 bit accumulator (D).

https://en.wikipedia.org/wiki/Motorola_68HC11

It makes a big difference, which is why I pointed it out.

[gnuarm]

The point is that it's still suboptimal vs assembly programming, ...

So you say "run well" , I say "mumble" 

So, which small processor runs C programs as well as assembly programming???

[DiTBho]

It (68HC11) seems to have two accumulators, A and B, which can be combined as one 16 bit accumulator (D).
It makes a big difference, which is why I pointed it out.

A and B makes no difference in practice as a lot of instructions are not able to access B, only D, and you have to swap(A,B) or use D.

Also, the point was: stack-oriented, instead of regs!

[MK14]

It (68HC11) seems to have two accumulators, A and B, which can be combined as one 16 bit accumulator (D).
It makes a big difference, which is why I pointed it out.

A and B makes no difference in practice as a lot of instructions are not able to access B, only D, and you have to swap(A,B) or use D.

Also, the point was: stack-oriented, instead of regs!

But the point also is, that an assembly language program can usefully use both 8 bit accumulators.  Contributing to the potentially higher program execution time efficiency.

8 bits is big enough for many things, if you want to scrape the last ounce of performance out of a relatively slow, low end 8 bit microcontroller or microprocessor.

[DiTBho]

So, which small processor runs C programs as well as assembly programming???

only RISC ones(1), I am afraid none in the stack-oriented class.
(1) I think the tiny-AVR8 is a good example here.

[Siwastaja]

The point is that it's still suboptimal vs assembly programming, ...

So you say "run well" , I say "mumble" 

So, which small processor runs C programs as well as assembly programming???

AVR architecture (with whopping 32 registers) comes close. Of course, hand-crafted assembly by someone who knows exactly what they are doing always wins (or becomes a tie), but that is true for small and large processors, equally. C on small AVRs is definitely not any worse than C on large targets, and is definitely good enough for nearly all jobs, and as a result, it's rare to see anyone writing AVR programs in anything else than C.

[madmac]

74HC393 dual 4 bit counter wired as 8 bit counter and clocked to generate a digital ramp count. For each motor connect counter to one side of 74HC684 comparitor the other side to an eight bit latch. Use the > output as a PWM. Load latch for PWM value.
To make a bit neater use a two input nand to combine '>' and '=' outputs of the comparitor.
Two 20pin parts per motor with a common 14 pin counter........needs a clock from somewhere
madmac

[Siwastaja]

Nah, digital PWM controller out of discrete logic seems too simple; basically a copy of the block diagram in microcontroller timer/PWM module (minus unnecessary stuff like input capture). In essence, counter and comparator.

Why not complicate things a bit and forget brushed DC motors? Do a FOC controller, BLDC (easier) or AC induction motors. I'm pretty sure some of the first, original FOC controllers were built in such discrete logic.

[RoV]

Many years ago I used a TL1451AC to convert analog signals to PWM. It was in 1999, I am surprised to see that the chip is still available e.g. on Mouser. This is an option if you can add an 8 bit DAC.

[DiTBho]

74HC393 dual 4 bit counter wired as 8 bit counter and clocked to generate a digital ramp count. For each motor connect counter to one side of 74HC684 comparitor the other side to an eight bit latch. Use the > output as a PWM. Load latch for PWM value.
To make a bit neater use a two input nand to combine '>' and '=' outputs of the comparitor.
Two 20pin parts per motor with a common 14 pin counter........needs a clock from somewhere
madmac

I like this idea! It's simple and elegant.