<muurkha>
well, keep in mind that most discrete transistors cost more than the Padauk PMS150C or even the reported price for this new CH32V003, so it's quite easy for an analog circuit to involve more parts from the point of view of a circuit board and be more expensive
EchelonX has quit [Quit: Leaving]
<muurkha>
I mean, at the point that your analog circuit involves an op-amp or signal transistor, it has become more expensive than a microcontroller
<muurkha>
generally I find it easier to design software than analog filters, though not always, and there are up-front costs like getting a toolchain running that I don't have to worry about with, like, an RC filter
wingsorc__ has quit [Quit: Leaving]
<muurkha>
but in terms of reliability, well, it's true that a microcontroller program can have crashing bugs (or worse) that are hard to find, and the microcontroller might get wedged in a surprising state by cosmic rays or something, or do something that's supposed to be impossible, and tends to be kind of sensitive to EMI
<muurkha>
but most of the time microcontroller circuits are enormously more reliable than analog circuits
wingsorc has joined #riscv
<muurkha>
analog circuits are plagued with issues of linearity, tolerances, temperature sensitivity, and surprising behavior at out-of-spec supply voltages that *mostly* disappear with microcontroller systems
<dh`>
I guess
<muurkha>
when you add, subtract, or multiply quantities in analog circuitry, you're subject to linearity errors that are typically on the order of 0.1%, like 8-bit arithmetic. it's easy for the corresponding operations in a microcontroller to have rounding errors on the order of 0.0000005%, and those errors don't vary with temperature
<dh`>
I mean, you can tell I'm a software person, I'll tell everyone to avoid software
<muurkha>
PWM is extremely linear, and the error of a single cycle of PWM is commonly about 0.04% (from rounding, assuming an 8-bit counter) but averaged over 100 cycles it's more like 0.004%
<muurkha>
and, again, that doesn't depend on temperature
<muurkha>
or supply voltage, or even clock speed, as long as the clock speed doesn't change too much during a single cycle
<muurkha>
also you can simulate microcontroller behavior *perfectly* as part of an automated test suite; with analog circuits the best you can do is a Monte Carlo simulation
<muurkha>
oh also aging. have I mentioned aging? all these analog errors change over time as your components age
<muurkha>
believe me, I have a profound appreciation for how much software sucks, but I think you may not appreciate how good we have it in software-land
<muurkha>
another thing is that anything nonlinear is even harder to do precisely in analog-land. you're using a temperature sensor made out of tungsten, whose temperature coefficient of resistivity goes through a couple of phase changes over its useful temperature range? good luck converting that into a linear analog temperature signal using opamps, capacitors, and resistors. not that it can't be done, but it
<muurkha>
requires a totally different level of ingenuity from a couple of if statements
freakazoid332 has joined #riscv
<muurkha>
that 2.7¢ Padauk PMS150C isn't much as microcontrollers go: 64 bytes of RAM and 1Kiword of program memory, enough for 1024 instructions. but consider that if you use it to simulate an analog system, it can simulate a system with something like 64 analog state variables (capacitors, say) connected through about 1024 components, many of which would have to be carefully trimmed at manufacturing time to
<muurkha>
achieve the required precision
<muurkha>
this is analog circuitry of roughly the same complexity as a VCR or something — although in a VCR many of the components would have to run at speeds the PMS150C can't dream of
frkzoid has quit [Ping timeout: 250 seconds]
<muurkha>
and of course things like the motors require switching more current than a microcontroller can handle
<muurkha>
so that's the situation where people use analog designs these days: for the parts of their system that have to go really, really fast, or to interface a microcontroller to things it can't drive directly
<muurkha>
or measure directly
<muurkha>
or things that have to never crash, where restarting after a watchdog timer isn't good enough
<muurkha>
because generally using microcontrollers is simpler, cheaper, and far more reliable, precisely contrary to what you would intuitively expect
<muurkha>
oh I realize I forgot to mention microphonics: another source of error in analog circuits, on top of the temperature, component variation, and aging causes I mentioned, is vibration, which changes the inductance of inductors, the capacitance (and sometimes directly the voltage) of capacitors, and the resistance of resistors. this does not happen to multiply subroutines
Trifton_ has quit [Read error: Connection reset by peer]
mz___ has joined #riscv
<solrize>
yeah i haven't heard of anyone using a 555 timer in like forever. it's simpler and cheaper and way more precise to use an mcu
rafael_bento has quit [Quit: ERC (IRC client for Emacs 27.2)]
<dh`>
hmm
Trifton has quit [Quit: Error: no route to host]
<GreaseMonkey>
...10c for a RISC-V core with ADCs?! that's worth evaluating
<dh`>
on the other hand, operating a motor for a drone seems like a case where watchdog timer and restart isn't good enough
<dh`>
well, maybe.
<dh`>
I guess one of the reasons quadcopters are popular is you can lose one motor temporarily without automatically entering an upset
<muurkha>
GreaseMonkey: yeah, it's exciting! how's your Chinese?
<GreaseMonkey>
uhh, it's second on my list of languages to learn that i'm not actively learning right now
<GreaseMonkey>
(first is Korean, currently actively learning Japanese which may make things better or worse not sure)
<muurkha>
solrize: apparently the 555 is still popular enough that not only does Digi-Key have a huge number in stock, but JLCPCB included a 555 among their 689 "basic" parts that are free to stuff your board with
<muurkha>
that is, they charge you 7.58¢ for the 555, plus 0.15¢ per pin to solder it, but they don't charge you an extra fee to load a reel of "extended" parts into their pick-and-place machine
<muurkha>
GreaseMonkey: I'm sure learning kanji will help a lot with Chinese characters
<dh`>
yes and no
<dh`>
learning the forms of them so they don't all look the same absolutely helps
<muurkha>
yeah. and a lot of Japanese technical vocabulary is Chinese loanwords, though with an archaic pronunciation
<dh`>
but the overlap in characters is not as large as you might think, lots of the meanings have diverged, and sometimes they don't even have the same stroke order any more
<muurkha>
oh, I hadn't run into cases where the stroke order differs
<muurkha>
that must be a huge pain
<dh`>
i know nothing specific, just remember my officemates discussing it
<GreaseMonkey>
there is also the caveat that several characters are different, and unicode absolutely botched up stuff like 直 which will render differently depending on your font settings and what language you've set your fonts to - if there's a line to the left it's ja/ko, if there isn't and it's fused to the bottom it's zh
<muurkha>
ah
<muurkha>
heh
<dh`>
...or it will render as " "
<GreaseMonkey>
anyway, manuals written in Chinese. would be a challenge, but i can probably kludge some understanding together
<muurkha>
IIRC Naomi Wu said Chinese is the command line of the 21st century
<dh`>
I keep trying to get unicode irc to work and it keeps not
GenTooMan has quit [Remote host closed the connection]
<dh`>
the problem here is xterm's font handling and I think ultimately it's xterm being broken and I'm going to have to fix it
GenTooMan has joined #riscv
<muurkha>
oh, possibly, I'm using libvte, unfortunately
<muurkha>
it wouldn't be extremely surprising for xterm to be broken with respect to Unicode fallbacks
<GreaseMonkey>
...oh right it's also got DMA, heck yeah
<dh`>
I have a terminal font I like, but it's a legacy bitmap font and while xterm ought to be able to take glyphs from a fallback font it doesn't seem to actually be able to
<dh`>
and font handling on unix is a disgrace so it's a ... cluster
<dh`>
one of the things I keep meaning to do sometime is wade into that problem and figure out a real solution
<dh`>
fontconfig does not appear to be the right answer
<muurkha>
GreaseMonkey: I'm a little uncertain about how useful the DMA is going to be with 2048 bytes of RAM
<muurkha>
does fontconfig do bitmap fonts at all? I thought it was TrueType-only or something?
<GreaseMonkey>
it only has one UART, so it's probably enough space
<GreaseMonkey>
...i do like MCUs with lots of UARTs on them though :/
<dh`>
fontconfig indexes everything, I think
<dh`>
but maybe not
<muurkha>
maybe you can bitbang a second UART
<GreaseMonkey>
but realistically 2 or 3 is what's "needed"
<GreaseMonkey>
yeah that'd be a thing
<dh`>
like I said it's a disgrace, layer upon layer of broken stuff
<muurkha>
or press the SPI peripheral into service for that
<muurkha>
dh`: I guess that's why freedesktop.org has gone off into the Wayland clouds
<GreaseMonkey>
ah yes... maybe even use it for SPI
<dh`>
I think that's ultimately just more layers of broken stuff
<dh`>
but idk
<GreaseMonkey>
how many times have i used an SPI peripheral for things which aren't SPI, hmm...
<muurkha>
probably yeah
<muurkha>
GreaseMonkey: that sounds like an exciting list, do tell
<dh`>
freedesktop.org doesn't exactly have, let's say, a record of good engineering decisions, either
<GreaseMonkey>
some of it pertains to work so i'd have to make it ambiguous, but in one case we used it to drive a shift register chain, and in another case we actually used it 4x oversampled for a balanced line-coding scheme
<muurkha>
dh`: "Cascade of Attention-Deficite Teenagers developmnt model"?
<muurkha>
GreaseMonkey: hey, isn't SPI just driving a shift register chain when you're using it "properly"?
<dh`>
something like that
<muurkha>
dh`: in their favor they're *making* engineering decisions, even if they are kind of shitty sometimes
<muurkha>
so for example cut and paste on X-Windows finally works in the last five years
<dh`>
it's always worked
<dh`>
until recently, when sometimes you can't paste into or out of firefox
<muurkha>
it's been a mess of incompatible clipboard and selection mechanisms since I started using X-Windows in 01993
<muurkha>
cut buffers and selections and clipboards
<muurkha>
I think the firefox thing is just a firefox bug where sometimes its internal clipboard handling gets broken in a window
<muurkha>
I don't think it's X's fault
<dh`>
idk
<GreaseMonkey>
ok, i'm going to be honest, this chip does look like it's "heavily inspired" by the STM32
<dh`>
although actually come to think of it pasting between firefox and xterm was a problem for a long time (~2000s) but that was fixed long ago and whatever's broken recently is different
<muurkha>
GreaseMonkey: that's great! that should make it easy to use
jacklsw has joined #riscv
<GreaseMonkey>
it also appears to have an ARM version... but still, 10c is way less than what ST would offer
<muurkha>
yeah, I'm not sure if xterm ever got updated to use whatever the current cut-and-paste fashion is
<GreaseMonkey>
and i do like me some RISC-V... i can dig ARM if it's either traditional or Thumb-2, but Thumb-1 is pretty meh and GCC refuses to optimise it properly
<muurkha>
I think it's still using the selection mechanism that came after CUT_BUFFER0
<muurkha>
GreaseMonkey: does WCH have an STM32 clone like the GD32 and CKS32 lines?
<GreaseMonkey>
possibly, the CH32V003 uses a V to denote RISC-V and an F to denote ARM
<muurkha>
because I think those are absolute drop-in replacements for corresponding STM32 parts, with the same pinouts and registers (except that the GD32 is a lot faster)
<muurkha>
that's what the datasheet says, yes
<muurkha>
I don't think there's an STM32F003, is there? just STM32F103
<muurkha>
that manual has an introduction to RISC-V programming in general in it, including U-, S-, and M-modes
<muurkha>
it seems to actually have the introduction to trap handling I was complaining was missing from the Privileged Mode spec, integrated with an explanation of how the interrupt controller on their chips work
<muurkha>
too bad (for me) it's only in Chinese
<muurkha>
oh and apparently they decided to implement an internal hardware stack that bank-switches (?) most of the x1-x32 registers for fast nested interrupt handling!
epony has quit [Ping timeout: 252 seconds]
epony has joined #riscv
vagrantc has quit [Quit: leaving]
BootLayer has joined #riscv
davidlt_ has joined #riscv
bjdooks has quit [Quit: No Ping reply in 180 seconds.]
bjdooks has joined #riscv
dor has joined #riscv
paulk has quit [Ping timeout: 264 seconds]
paulk has joined #riscv
erg_ has joined #riscv
dor has quit [Ping timeout: 260 seconds]
erg_ has quit [Remote host closed the connection]
qwer has quit [Ping timeout: 260 seconds]
qwer has joined #riscv
qwer has quit [Remote host closed the connection]
qwer has joined #riscv
eroux has quit [Ping timeout: 260 seconds]
qwer has quit [Remote host closed the connection]
eroux has joined #riscv
pecastro has joined #riscv
<nelnire>
4
pecastro has quit [Ping timeout: 260 seconds]
pecastro has joined #riscv
qwer has joined #riscv
wingsorc has quit [Ping timeout: 276 seconds]
qwer has quit [Ping timeout: 276 seconds]
qwer has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #riscv
davidlt_ has quit [Ping timeout: 260 seconds]
BootLayer has quit [Quit: Leaving]
Andre_H has joined #riscv
<bjdooks>
this weeks' pain looks like pcie and asmedia
dor has joined #riscv
erg_ has joined #riscv
dor has quit [Ping timeout: 250 seconds]
Andre_H has quit [Quit: Leaving.]
erg_ has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 272 seconds]
dor has joined #riscv
davidlt_ has joined #riscv
dor has quit [Ping timeout: 260 seconds]
wingsorc has joined #riscv
Ballerburg9005 has joined #riscv
pecastro has quit [Quit: Lost terminal]
Ballerburg9005 has quit [Ping timeout: 276 seconds]
qwer has quit [Read error: Connection reset by peer]
pedja has joined #riscv
rneese has joined #riscv
<conchuod>
prabhakarlad: I've been hoping that mmind00 would chime in about the alternatives stuff
<conchuod>
Thanks Heiko :)
prabhakarlad has quit [Quit: Client closed]
qwer has joined #riscv
qwer has quit [Read error: Connection reset by peer]
qwer has joined #riscv
dor has joined #riscv
qwer has quit [Remote host closed the connection]
qwer has joined #riscv
prabhakarlad has joined #riscv
Andre_H has joined #riscv
Starfoxxes has quit [Ping timeout: 252 seconds]
Starfoxxes has joined #riscv
BootLayer has joined #riscv
aerkiaga has joined #riscv
<prabhakarlad>
mmind00, conchuod: thanks for the pointer. I still need to understand the asm code for the zicbo.
rsalveti has joined #riscv
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #riscv
aburgess_ is now known as aburgess
jacklsw has joined #riscv
motherfsck has quit [Ping timeout: 276 seconds]
<conchuod>
bjoto: nice
rneese has quit []
<conchuod>
I'd swear half the comments I leave on things are a ^C + p of checkpatch so having that automagically will be great :)
<bjdooks>
yeah, I once wrote a git commit plugin that would stop you commiting if it failed checkpatc
cronos has joined #riscv
<bjoto>
conchuod: Exactly! :P
<conchuod>
bjdooks: unfortunately, it is not possible to inflict that on others!
eroux has quit [Ping timeout: 250 seconds]
eroux has joined #riscv
eroux has quit [Ping timeout: 276 seconds]
wriggs has quit [Quit: Bridge terminating on SIGTERM]
patersonc[m] has quit [Quit: Bridge terminating on SIGTERM]
qrqrtty[m] has quit [Quit: Bridge terminating on SIGTERM]
acharles has quit [Quit: Bridge terminating on SIGTERM]
DanielakaCyReVol has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
jim-wilson[m] has quit [Quit: Bridge terminating on SIGTERM]
Esmil[m] has quit [Quit: Bridge terminating on SIGTERM]
atishp[m] has quit [Quit: Bridge terminating on SIGTERM]
psydroid has quit [Quit: Bridge terminating on SIGTERM]
wingsorc has quit [Quit: Leaving]
wriggs has joined #riscv
eroux has joined #riscv
jacklsw has quit [Quit: Back to the real life]
qrqrtty[m] has joined #riscv
psydroid has joined #riscv
jim-wilson[m] has joined #riscv
khem has joined #riscv
Esmil[m] has joined #riscv
acharles has joined #riscv
patersonc[m] has joined #riscv
DanielakaCyReVol has joined #riscv
atishp[m] has joined #riscv
aerkiaga has quit [Remote host closed the connection]
Narrat has joined #riscv
<solrize>
muurkha, if that bank switching thing makes sense it would be good if it were part of the standard. i had been thinking a vax-style register save instruction could slam all the registers into a temporary register file and then save them to memory in the background while the rest of the function/interrupt handler ran
<solrize>
where "memory" would usually be L1 cache
<solrize>
maybe register windows should come back, now that transistors are so cheap
GenTooMan has quit [Ping timeout: 272 seconds]
aerkiaga has joined #riscv
elastic_dog is now known as Guest3315
Guest3315 has quit [Killed (silver.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
guerby_ is now known as guerby
davidlt_ has quit [Read error: Connection reset by peer]
davidlt has joined #riscv
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #riscv
frkzoid has joined #riscv
dor has quit [Remote host closed the connection]
frkazoid333 has quit [Ping timeout: 250 seconds]
vagrantc has joined #riscv
<muurkha>
solrize: I think the mechanism kind of is register windows, but only for interrupts
prabhakarlad has quit [Ping timeout: 244 seconds]
BootLayer has quit [Quit: Leaving]
jljusten has quit [Quit: WeeChat 3.6]
jljusten has joined #riscv
jmdaemon has joined #riscv
zjason` has joined #riscv
zjason has quit [Ping timeout: 260 seconds]
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
davidlt has quit [Ping timeout: 250 seconds]
m5zs7k has quit [*.net *.split]
rah has quit [*.net *.split]
jn has quit [*.net *.split]
jimbzy has quit [*.net *.split]
rektide has quit [*.net *.split]
hl has quit [*.net *.split]
djdelorie has quit [*.net *.split]
conchuod has quit [*.net *.split]
palmer has quit [*.net *.split]
panzeroceania_ has quit [*.net *.split]
j0rd has quit [*.net *.split]
rah has joined #riscv
jn has joined #riscv
palmer has joined #riscv
jimbzy has joined #riscv
ConorDooley has joined #riscv
rektide has joined #riscv
panzeroceania_ has joined #riscv
jn has joined #riscv
jn has quit [Changing host]
j0rd has joined #riscv
hl has joined #riscv
m5zs7k has joined #riscv
djdelorie has joined #riscv
loggervicky has joined #riscv
GenTooMan has joined #riscv
loggervicky has quit [Quit: loggervicky]
vagrantc has quit [Quit: leaving]
<solrize>
so does jlpcb offer any super cheap mcu's in its no-setup plan like the 555?
<muurkha>
at the time the answer was "no, but it ought to be possible to send them a CPU design they can fabricate from CMOS SSI random logic chips for under US$100, if you debug it first"
<muurkha>
this was before I knew about SeRV though so my estimate was that it would be on the order of 200 SSI chips
<muurkha>
a CPU spread across about 10 small circuit boards
<muurkha>
rektide, Sofia, ZipCPU, pabs3, leah2, what do you think?
<solrize>
muurkha, nah i just meant plop down a padauk 3 cent chip or whatever
<solrize>
or what is the setup fee if you want to use something like that? if they can get them, that is
<solrize>
any prices for those other wch.cn risc-v parts?
<muurkha>
maybe LCSC has other wch.cn CH32V* parts?
<muurkha>
as I understand it the setup fee was US$2, plus US$3 per non-"basic" component (such as, AFAIK, any microcontroller) and the rest of the cost is entirely per-component or per-area cost, proportional to the number of boards you have them fab
<muurkha>
I haven't actually ordered from them, though, and watching youtube videos from product shills does not make me an EE
<ZipCPU>
At its smallest configuration, the ZipCPU requires 3500 NANDs. That will give you a CPU alone, and nothing else: no interconnect, no memory controller(s), no serial port, etc.
<ZipCPU>
In other words, I think your numbers are kind of low ... ;)
<muurkha>
ZipCPU: does it help if you have SSI parts like a 74HC595, a 74HC138, or a CD4051?
<solrize>
$3 per component = not bad if you're making 100+ boards
<muurkha>
right, that's 3¢ per board
<muurkha>
they don't have NANDs in the basic parts list but they do have ANDs and NOTs
<muurkha>
or didn't when I checked a year and a half ago
<solrize>
idea is to do stuff cheap, not purely avoid the setup cost at the expense of using lots more oparts
<muurkha>
are the Padauk parts back in stock at LCSC? they were all out last time I checked
<muurkha>
but maybe the supply chain crisis has eased since then
<ZipCPU>
Did you ever see pepijndevos[m] 's work using 74xx chips?
<ZipCPU>
He modified Yosys so that it would synthesize a design into 74xx chips
<ZipCPU>
Then he ran his own CPU through it
<ZipCPU>
At the time I saw his presentation, he hadn't yet built his CPU though
<muurkha>
the breather?
<muurkha>
Wolf also successfully synthesized PicoRV32 to 74xx chips with yosys IIRC
<ZipCPU>
The PicoRV has been synthesized into more than just 74xx chips. ASIC(s) have been made of it.
<muurkha>
it required 4846 74xx chips, but that was using only DFFs and bare gates
<muurkha>
nothing even as fancy as a 74HC595
<muurkha>
I didn't know about the PicoRV32 ASICs! who made them and how well did they work?
<ZipCPU>
Not sure what I'd do with a 3-state output register
<ZipCPU>
Not sure how much I can say about the PicoRV32 ASICs either. Industry disclosure rules, etc.
<muurkha>
oh :(
<ZipCPU>
:(
<ZipCPU>
There's a gentleman nearby who has been trying to get me interested in 64-level logic.
<muurkha>
well, as you of course know, tristate output registers are handy for driving buses
<ZipCPU>
Not sure what to make of it.
<ZipCPU>
Each wire could then carry 6-bits of information. Is that better? Worse? I'm not sure.
<ZipCPU>
What I do know, and told him, was that ... you need the synthesis tool in order to make use of it.
<muurkha>
it might be better or worse; for mechanical logic I've been thinking 4-16 states might be convenient
<muurkha>
but you can run binary logic pretty fast before waveform distortion gets the best of you
<muurkha>
(and noise)
<muurkha>
you'd have to run multilevel logic a lot slower
<ZipCPU>
I just know it would be a challenge to map my nicely verified designs to non-traditional logic elements ;)
<muurkha>
3500 2-input NANDs in CMOS is 14000 MOSFETs. that's about twice the size of a PDP-8 or 6502
<muurkha>
which are, in turn, about twice the size of a PDP-8/S or RCA 1801
<ZipCPU>
Well, the ZipCPU is a 32-bit machine ...
<muurkha>
I did design a PDP-8/S like machine, 12-bit bit-serial with a less convenient (but more regular) instruction set, in about 700 NANDs. but it isn't nicely verified!
<muurkha>
SeRV is 32-bit as well, but that matters less for bit-serial designs
<ZipCPU>
Heh, yeah
<ZipCPU>
So let me add one more: the ZipCPU was designed to handle one instruction per clock cycle--although the 3500 NAND version can't handle that speed.
<ZipCPU>
You'll need about 10k NANDs to hit that speed, and won't likely get that close either without a cache. Once you add the cache into the system, my numbers start going wild because the RAM usage within the cache gets added to the NAND count.
<muurkha>
normally you wouldn't build a cache out of NANDs though
<ZipCPU>
Exactly. But ... those are the measurements I maintain.
<muurkha>
makes sense, the alternative is something like "mm² in TSMC's 55 nm process"
<muurkha>
if you want a concrete scalar metric to minimize
<ZipCPU>
As I make changes, I try to keep track of how these statistics are impacted.
<muurkha>
1112 4-LUTs is pretty small
<ZipCPU>
Today, I just rebuilt my DMA, so I've been rebuilding the usage table to include the cost of this updated DMA
<ZipCPU>
Yep, pretty small. Not that useful either, but pretty small. It's primarily there for bragging rights.
<muurkha>
you can build a 3-LUT out of a 74HC164 and a CD4051
<ZipCPU>
That configuration offers no multiply support, no divide support, no support for shift instructions, no pipeline support, no debug port, no user mode, no compressed instructions, etc. ... but it is a valid configuration.
<ZipCPU>
(Without user mode, trap instructions won't work, so you can't even trap the missing instructions.)
<muurkha>
and you can build a 4-LUT out of two of those if you have one of your inputs in complemented form because the CD4051 has an "inhibit" or "chip enable" input
<ZipCPU>
Don't forget, NOT functions come for free in LUTs, so getting a complemented input is really easy.
<muurkha>
it doesn't support traps at all? that does seem like it would limit its usefulness; does it have any interrupt mechanism at all?
<ZipCPU>
The ZipCPU does, that configuration does not
<muurkha>
I mean you need one of the inputs in both positive and complemented form, like you get out of a conventional R-S flip-flop
<ZipCPU>
You have to go for the trap configuration to get interrupt support. That will then give you access to your shift instructions, bus lock instructions, and the full interrupt capability -- still no hardware support for multiply or divide though.
<muurkha>
you wire inputs A, B, and C to the A, B, and C inputs of both CD4051s, and then wire D to the INH input of one and /D to the other
<muurkha>
a barrel shifter sounds like a high price to pay for interrupts
<ZipCPU>
Well ... you can make an implementation like that, the CPU is configurable enough, I just don't track the logic usage of it.
<ZipCPU>
The minimum configuration shown there, called "ASM", is so named because you really need to program it in assembly. If you don't, the compiler might try to use instructions the CPU (in that configuration) doesn't support.
<ZipCPU>
The "TRAP" configuration is supposed to be the minimum configuration you could have where you trap unimplemented instructions--so you could at least get compiler support for user mode.
<ZipCPU>
The MIN configuration is the smallest configuration I have that supports all of the CPU's instructions, together with an external debug access port. It's also the minimum configuration I tend to work with.
<muurkha>
for a small CPU I don't think trapping unimplemented instructions is absolutely necessary
<muurkha>
I mean really all you need is for them not to hang the CPU unrecoverably or set it on fire
<ZipCPU>
At issue is the compiler. Will the compiler generate such instructions?
<muurkha>
you can fix the compiler to not generate them ;)
<ZipCPU>
If you don't mind not having all instructions, and not trapping on the ones you don't have, then the ASM configuration should work nicely for you as a minimum configuration
<ZipCPU>
I need to run for supper though. Chat later?
<muurkha>
but you really do need interrupts for most uses of a small CPU
* ZipCPU
steps away
<muurkha>
sure, enjoy!
ConorDooley is now known as conchuod
pedja has quit [Quit: Leaving]
Andre_H has quit [Ping timeout: 250 seconds]
qwer has quit [Ping timeout: 250 seconds]
qwer has joined #riscv
aerkiaga has quit [Remote host closed the connection]