Sometimes yah's just gots tah try somethin', regardless of whether it'll become a full-fledged "project"...
Already have an account? Log In.
To make the experience fit your profile, pick a username and tell us what interests you.
Ridiculosities found here, thus far (See the logs):
Just found this groovy thing in my rarely-accessed analog-ICs bin.
http://www.pmerecords.com/Docs/Archer_SAD-1024_Tech_Data.pdf
I like the description: "an analog-sampled data device which lies between linear and digital"
I have yet to wrap my head around how it works... though I think it's similar to CCDs, which I also have yet to wrap my head around... (How on earth is the *entire* charge supposed to make it from one end to the other, wouldn't all the intermediate capacitors spread it out?).
Anyways, pretty cool looking.
-----------
I also located 3 LM3914's (and a LM3915)... And, I think I might have another 3914 in another parts-box... And unless I made a horrendous mistake in a move, I should already have a wired-up 20x20 LED matrix from nearly 20 years ago (Jeeze I'm old!). So there may be some messing around with Lissajous and LEDs in my future.
Thanks #LED Oscilloscope Mk. II and #RGB LED Oscilloscope for the distraction!
-----
UPDATE: Bah... I can't find the matrix, and soldering 400 LEDs is a daunting prospect. Maybe later.
UPDATE: Hah! It's even easier than that! See bottom...
----------------
Had no idea how easy it is to create a maze... This looks great on low-resolution.
@matseng has a brilliant looking one in only 64x32 pixels over at #Tjipp8 - A Chip-8 game console
Here it is in C... (not even remotely as efficiently-implemented!)
esot.eric
#include <stdio.h>
#include <inttypes.h>
#include <stdlib.h> //random
char bitmaps[2][4][5] = {{ "\\ " ,
" \\ " ,
" \\ " ,
" \\" },
{ " / " ,
" / " ,
"/ " ,
" /" }};
uint8_t lineBuffer[80/4];
int main(void)
{
uint8_t row, col;
for(row=0; row<24; row++)
{
for(col=0; col<80/4; col++)
{
if(row%4 == 0)
{
lineBuffer[col] = (rand() & 0x01);
}
printf("%s", bitmaps[lineBuffer[col]][row%4]);
}
printf("\n");
}
return 0;
}
--------------------
Apparently the original program was a "classic" one-liner in Basic, that somehow seemed to slip through my experience until now...
Reimplemented in C, it's essentially nothing more than:
while (1) { printf("%c", (rand()&0x1) ? '\\' : '/' ); }The earlier was coded-up from matseng's code-example which was designed for a system in graphics-mode, rather than character-mode. I guess what I've done, then, is re-implement the character-bitmaps with sub-characters... hahaha. Seriously, check out his log. There's a link to a *really short* code-routine in "Bit8" which looks a bit like assembly, and a link to a book that's all about that one liner. An interesting read, it would seem.
------------
As far as what I'd done, earlier... Reimplementing, essentially, a character with a block of characters, I guess it sorta "zooms in" on a line-drawing...
Here's the output from the one-liner:
UPDATE: Found some more sources, including one that explicitly mentions running HCT devices at 2V-6V. Sheesh. See the bottom.
-----------
I have no idea where, but somewhere in my projects' logs, I think, I wrote some thoughts regarding whether it would be within reason to expect 74xCT devices to run at 3.3V, like their 74xC counterparts...
Obviously, that's not within-spec (they're spec'd for 4.5-5.5V).
The point of xCT devices being to interface TTL devices' outputs to 74xC CMOS devices' inputs, when running at 5V. If you look at the input/output specs of the TTL and CMOS@5V, you'll note that:
74HC04@4.5V (why they don't specify at 5V boggles my mind):
Vih-min = 3.4V
Vil-max = 1.35V
whereas TTL:
Vih-min = 2.0V
Vil-max = 0.8V
-------
Why am I comparing Vih/Vil's rather than Vih/Vil to Voh/Vol...? Because the output-voltage parameters vary depending on the load... It's up to the designer to make sure the loading doesn't cause the output to "sag" out of range. If you designed your TTL circuit right, it's guaranteed to be able to drive a TTL input with Vih/Vil as-specified, above.
------
So, you can see, TTL's guaranteed output-voltages, when loaded, aren't in range of a 5V-CMOS input; TTL might just output 2.4V for a guaranteed high, but CMOS might just require 3.4V to be considered a guaranteed high.
-----
Alright, so they've invented the 'T' series (ACT, HCT, AHCT, whatnot, but NOT LVT, as I recall, that's different, so read them datasheets!)... They invented the 'T' series to interface TTL's outputs with CMOS's inputs (when running at 5V). The 'T' series is guaranteed to work with TTL-outputs connected to its inputs, while still being a CMOS part.
WEEE!
---------
Now, as a hacker, or maybe just "a hack," I'm looking for ways to make use of what I've got... And I've got... access to a lot more 'T'-series parts than 'C'-series... (and *significantly* more TTL/LS/A/S/F 5Volters, but that's another story).
And... now it's starting to get to the point where I'm actually using 3.3V in my experiments somewhat regularly.
----------
So, assuming the 'T' series only differs from the associated 'C' series in its *inputs*, it seems somewhat reasonable to assume they'd actually work *like* the 'C' series when run at 'C'-series voltages (except, of course, for their inputs). I can't really back up this theorizing, except to say that the 'C'-series and 'T'-series usually share the same datasheet with the only specified differences (I've noticed) being those of voltage-levels (and slightly increased propagation-delays for the T-series). So, my guess, is that they were developed pretty much alongside each other, probably using the same silicon processes, and internal circuitry, and the only difference is the input-circuitry.
--------------
Now, unlike the old old datasheets of yesteryear wherein they actually showed the BJT-equivalent circuits for TTL devices, I have yet to find MOSFET-level internal-circuits for 74-CMOS devices...
Until Now.
http://www.nxp.com/documents/user_manual/HCT_USER_GUIDE.pdf
Alright! I think we've got something to work with, here!
Definitely read the explanation in that user-guide.
But, basically, if I understand correctly, *really simplified* what they've done is insert an inverter at the input that runs at a slightly lower-voltage than the rest of the circuit... kinda like inserting a 74HC04 running at 3.3V between your TTL-output device and your 5V-CMOS device. (This is *really* simplified). Then they threw in P2 as, essentially, a pull-up resistor.
A little less-simplified, P1 allegedly is "cut out" of the circuit, entirely, when the input-voltage is greater than something like 2.7V, which is not guaranteed by TTL, but apparently is considered expectable. The main effect being a reduced current-draw, since N1 is on.
I'm not really seeing anything in this that suggests it wouldn't run at 3.3V... The input, then, would essentially be like a 74HC04 running at 2V (value pulled randomly out of the air). So, as long as the 3.3V CMOS output connected...
Read more »UPDATE IV: Adding an image of the differential-amplifier simulation.
UPDATE III: DEFINITELY a current-mirror. Check out the bottom.
UPDATE II: Throwing random images and notes up at https://github.com/esot-eric-test/transistorOddities
UPDATE: Isn't this a [single transistor] current-mirror? Gotta explore this in a bit more depth... Some notes at the bottom.
--------------
Split The Current, and switch it from one side.
So, imagine we have two 3V coin-cells with slightly different charges, or two solar-cells which may receive slightly different amounts of light, and want to draw darn-near twice their maximum-rated current.
Putting them directly in parallel isn't so smart, right? Especially when the system's powered-down.
So, with this circuit--using a PNP on the ground-side, or an NPN on the positive-side, with its emitter tied to ground/positive, respectively--roughly half the current comes through each coin-cell, and the on/off switch (or maybe another normally-wired transistor?) controls them both.
So, here I'm simulating two coin-cells; one's at 3V, and one's at 2.5V, when unloaded. But their internal series resistance is roughly 100 ohms (represented by the 100 ohm resistors on each branch).
In the middle we have a load (a circuit, LED, etc...) simulated by another 100 ohm resistor, getting about 1.5V.
The switch could be anything, maybe a "normally-wired" transistor controlled by a pushbutton and flip-flop as part of the load, etc.
Note the directions of the current entering/leaving the transistor... Current is *exitting* the PNP's emitter, and *enterring* its collector. That's why this guy's a weird setup that's been boggling my mind for weeks.
---------
Here's the original weird circuit:
And here's another, in a more logical topology.
Note that as long as the right-side "battery" is greater-than or equal to the right-side "battery's" voltage, the two branches carry the same current. Doesn't that make it a single-transistor current-mirror? Hmmm...
-----------
DEFINITELY a current-mirror. Have never heard of a single-transistor current-mirror, have you?
Not that we can trust simulations...
Here's a simulation of an attempt at a differential amplifier using this current mirror. It *sorta* works. Though I know little about diff-amps, these days...
-----------
If you haven't been following the saga, check out The mistake that started it all, and Some more rambling.
UPDATE V: Here's a demo using a TTL input as an example of my original "weird circuit" in use
Note that by varying the input-voltage to greater than about 3.65V, the circuit's very similar to mine, current flows from the base through the collector. And at nearly 5V, current flows into the NPN's emitter.
UPDATE IV: I FOUND A USE for the weird PNP mistake!
--------------
UPDATE III: Found a REALLY HANDY REAL-TIME-ish SIMULATOR
and more simulation-links at the bottom.
UPDATE II: New Interesting circuit, at the bottom.
UPDATE: ROTFL, it's just diodes... more at the bottom.
---------
Over at #Improbable Secret Project, (Log: https://hackaday.io/project/18868/log/50780-open-collector-fail-the-atx-power-switch-saga-continues) I accidentally discovered that the following circuit is possible:
The key-factors are:
So, what we have, here, is a *buffer*, rather than an inverter, as it would be with the NPN I'd intended to use.
It's sort of an emitter-follower, except using the "key-factor" this makes it more of a "collector-follower."
(BUT, allegedly that term is reserved for another purpose.)
Note that when the input voltage is greater than (V+ - 0.6V) (high, assuming VBC-on=0.6V), the transistor is *off*.
When the input is less than (V+ - 0.6V) the transistor is *on*, and the output-voltage follows the input voltage... So, a 0V input would result in a 0.6V output (which is lower than a TTL circuit's VIL-max of 0.8V, nice) so it will be Low.
Similarly, a TTL circuit's VIH-min is something like 2.0V, and obviously VOH-min must be greater than that. So, feeding 2.0V into the input, the transistor will be on, but its output-voltage will be 2.6V... High.
(Of course, these depend a little bit on the value of the base-resistor)
----------------
Well, here's an interesting result...
This is an AND gate, I think!
I'm calling it a [L]AND gate, because, without the pull-up resistor, it's an AND which only outputs the Low state, the "high" state is determined by the load (the pull-up resistor, in this case).
Similarly, if I've got my logic right, the opposite (using NPNs connected to V+), creates a [H]OR gate.
I'll stick to discussing the [L]AND gate...
When both inputs are the same, we have the same effect as with a single transistor... That takes care of the 00, and 11 states of an AND gate.
My THEORY (untested) is that the lower of the two inputs will be followed.
The reality may be significantly different... Since the current-gain is really low (like IC=2*IB), and since the high input would imply a higher current going into that transistor's base, that transistor (the one pulled high) will have a greater IC... and this is where I can't quite wrap my head around it... because a higher IC (through B) would create a greater current through C->E, which would cause it to pull even lower. Hmmm...
So, I think it's an AND gate, but I'm not certain.
------------
This came as a result of analyzing @Ted Yapo's circuit from #CBJT Logic:
Note the normally-biased PNPs Q9 and Q10 in that circuit form a NAND gate. Which seems a bit backwards, since they're in parallel. But if the other transistors were removed and replaced with a pull-down resistor (and if this were 5V logic), then we'd have essentially the exact opposite of the [L]AND gate... they'd be a [H]NAND gate.
Now, I find it a bit strange that two *parallel* transistors could create an AND (or NAND) gate... OR, sure. NOR, sure... So I took a bit to think about it and, here's my conclusion. NAND is actually the same as an OR which has its inputs inverted.
______
-|>o--\ \
| OR >---
-|>o--/_____/
=
______
-----| \
| NAND |o--
-----|______/Unfortunately, it doesn't seem [to me] too simple to interface a [L]AND and [H]NAND gate such that the series transistors (and pull-resistors) could be removed... but I could be mistaken....
Read more »The Class-AB (linear) audio-amp chips I'm currently using for my motor-driver have *4* channels... So, for low-enough-current motors this single chip could handle *4* separate DC-motors. (cool).
Update-Wise: it seems to be working quite well for several weeks now. It definitely gets warm, and maybe on a few occasions has been dropping-out (plausibly due to thermal protection-circuitry combined with the fact the heat-sink it's attached-to has a *channel* (for screws) right under the thermal-pad...). But actual overheating-protection seems few and far-between.
There is a more pressing problem that oddly seems to be related to the motor itself... when spinning in one direction it works fine, but in the other direction it acts a little strange, kinda stutters. This only seems to happen when driven at full-speed (when the amp's outputs are close to ground and V+).
Now there's a few oddities, here. Watching the negative output from the audio-amp, it's very clear that that output stutters *with* the motor's stuttering... When it's *just above* ground, it runs smoothly, but when it stutters, the output actually reaches ground. OK, maybe thermal protection...
But then, there's oddity 2. When the motor's *loaded*, it doesn't do this. The output doesn't go to ground. When it's *loaded*, the motor draws *more* current (right?) so then thermal-protection seems illogical.
OK, now there's oddity 3. As I recall, reversing the polarity of the motor's connection to the audio-amp/motor-driver doesn't do what I expected. I expected the motor to continue to "stutter" when the motor-driver is driven the same way (now, the reverse-direction), thinking the "motor-driver" might be a bit 'biased' toward one polarity over the other (maybe one of its channels has a slightly more-powerful low-side transistor than the other channel?).
In fact, what seems to be happening is that the motor itself is responsible, when powered with one polarity over the other. Is that plausible? I should measure its current-draw... But, again, loading it causes the stuttering to *stop*, so a differing amount of current-draw doesn't seem like the problem, right...?
The motor is from the 1980's, so it's likely had years of wear... maybe it was used in one particular direction more than the other, so its brushes aren't worn evenly, or something...? Is it possible that the sparking caused by the brushes' breaking-contact with the windings could be larger in one direction than the other, (again due to wearing) causing, maybe, over-voltage protection?
Again, the weirdest part about it is that when I actually apply a load to the motor's shaft, this problem isn't a problem. When I drive the audio-amp's input such that the outputs aren't *quite* at their limits, it's also not a problem. BUT it only seems to happen when the motor's powered/spinning in the same direction (but not the other), regardless of the polarity it's been wired to the driver-chip.
Oh, and, yes, I did (early-on) throw in freewheeling/flyback diodes, despite my experimentation-goals of seeing whether the Class-AB amp really needs them with its push-pull abilities.
------------
Now, onto the experimentation-TODO:
It was suggested, if I understand correctly, at https://hackaday.io/project/9919-powerful-portable-speaker/log/34102-talking-about-circuits that Class-AB amps might be paralleled?! OK, I've always thought this to be a bit risky, since it'd be hard to have two identical transistors/gains, etc... So then the loading on one output would be higher than the other... (and maybe worse in this particular case, since the gains are fixed, there's no [external] feedback-path, they might differ slightly). But, maybe it's actually possible... and something worthy of my looking into. Here's a good start: http://cds.linear.com/docs/en/design-note/dn126.pdf I found some other resources, as well, but one was about Tube-Amps, and the other was nothing more than SPICE simulations (which seem to me like they wouldn't take into account...
Read more »I've been fighting getting this Vacuum Fluorescent 16x2 text-display working...
It's supposedly compatible with standard character-LCD displays based on the Hitachi HD44780...
So, there's a datasheet for *the entire display*: Samsung 16T202DA1 but I found the HD44780's datasheet to be a bit more informative, so have been using it for timing-info...
Things were working fine until I started working with the "Busy Flag." Hardcoding excessively-long delays seemed to work fine, but reading that Busy Flag just resulted in all kindsa fail.
I thought maybe my port-direction stuff wasn't working quite right, since I hadn't done any other read-back from the display, prior. Maybe the data was floating too long, or something. This seemed somewhat corroborated by the fact that whatever *last* value was sent to it *seemed* to have an effect on whether it functioned or not... E.G. *for the most part*, if I sent a character that had bit 7 set to high, then the system would crash while waiting for the busy-flag (which is read-back on bit 7), but if I sent a value that had bit 7 set to low, then the system seemed to work fine. *For the most-part*. There were some other oddities that didn't *quite* align with this logic, but durn-close.
So then I implemented a simple test: I wrote a character to one position, then another character to another position, then read-back the character at the first position, and... it seemed *almost* to work, in some weird way... *almost* corroborating my theory that read-back wasn't quite implemented correctly...
And, eventually, the instructions seemed to get garbled.
I'm using this thing in 4-bit mode... so my thought was that the two-nibble reads were somehow getting misaligned, maybe one was missed here or there, or maybe there was too much noise on the line causing spurious "Strobes"... This could still be true, actually... Apparently the *chip* datasheet says the minimum High input-voltage on the *strobe* pin is *higher* than the data pins, 0.8VCC (4V) rather than 0.7VCC (3.5V). Yet the *module* datasheet says the minimum High input-voltage is the same for all pins, 0.7VCC... and I'm using a 3.6V processor, so... hmm...
But here's a more-glaring thing... The *chip* datasheet *explicitly states* (In *several* locations) that the Busy Flag ALWAYS RETURNS LOW.
The chip is marked: NEC D16314AGJ, the closest-match datasheet I can find is uPD16314... so it may be slightly different. BUT the ALWAYS LOW Busy-Flag definitely seems relevant...
This venture has led me in so many directions, I can't quite piece it all together. I'm certain I saw a recurring case where it seemed that the data read-back was read-back in 4-bit mode with the *same* data in both nibbles... matching almost-identically the last nibble sent. Then there was the case where it *almost* read back the actual data written to the previously-written character, except with one or two bits incorrect... This one worked fine for several seconds, then the instruction-garbling...
If I recall correctly, that was the last test, before I gave up and swapped out the VFD for a regular-ol' *actual* HD44780-based LCD display... which once plugged-in seemed to work *perfectly*... Prompting me to look up the NEC D16314's datasheet... and noticing the blaring statement that the Busy Flag is ALWAYS LOW.
(But how does this explain the *other* issues...? The 4-bit read-backs that seemed to be the last-nibble written, repeated twice...? And the fact that it eventually gets garbled instructions, even though *currently* I'm not actually *using* the busy-flag...? ... would seem I still have some friggin' work ahead of me.)
So, this is for my stupid [Audio-Amp] Motor-Driver Testing Experiments... The intention being to have easily-adjustable settings for things like minimum and maximum PWM values, to choose whether an output is locked-antiphase or direction/PWM, to vary the Proportional Constant (KP) for my positional-feedback-loop, and more...
HOW it's taken *literally* DAYS to get a stupid...
Read more »Update: EXCELLENT results briefly summarized at the bottom... (Update 2: and a couple more)
The "Groovy Circuit" of the last couple logs is now being tested with an abruptly-varying PWM signal...
0->3.3V PWM (20-80% duty cycle)
V+
^
|
\
R1 /
\
|
+--|>|----.
| |
| __|__|
| | / \ 3.3V
| /___\ Zener
| |
0->3.3V >---||--+--|<|----+-----> >----.
| | | Audio
\ === \ Amp
R2 / | / Input
\ V \ ~30k
| GND |
V V
GND GNDAgain, the point of this circuit is several-fold.
First, it attempts to linearize the PWM signal, so the motor will be driven by an *analog* value rather than directly by PWM.
Second, it relocates that now-linearized signal such that at 50% PWM the input to the audio-amp is 0V, but at 20% PWM duty-cycle, the input to the audio-amp is now *negative* (without a negative power-supply available).
Third, it attempts to adjust *quickly* to sudden changes in the PWM value... E.G. If the motor's running forward at full-power (somewhere around 80% PWM), and suddenly the system needs to bring the motor to full-stop, the next PWM duty-cycle will be 50% (stop). Ideally, this circuit will respond to that sudden change.
I guess, in a sense, this circuit's output is similar to that of a D-to-A converter of the Resistor-Ladder sort (Thanks @Yann Guidon / YGDES, I get your reference, now), where the DtoA has both positive and negative power supplies. As opposed to, say, the output of an R/C filter...
R/C Filter "Averaging" circuit
0->3.3V PWM >---/\/\--+-----> >----.
| |
=== \ Amp
| / Input
V \ ~30k
GND |
V
GNDAn R/C filter wouldn't accomplish near-immediate response to sudden changes in PWM values... e.g. a sudden change, say, from 80% 50% and back to 80% in three cycles would result in almost zero change on the output, whereas the "groovy circuit" I came up with seems to respond almost immediately:
The first trace is the PWM input, varying dramatically in duty-cycle from cycle to cycle.
The second trace is the output of the "groovy circuit." I'm not yet sure where the noise is coming from, this is a *very* early experiment.
Here, the upper trace shows the output of the AC-coupling capacitor, before feeding into the diodes. You can see that the peaks and valleys vary in value from cycle to cycle, this variance is what determines the output voltage... A sort of dual-retriggerable peak detector circuit that relies heavily on the fact that the input voltage is always switching from 0V to 3.3V during each cycle.
Does it work *exactly* as I'd hoped...? Not sure, haven't done the full gamut of experiments yet. It definitely seems to work well with slowly-varying changes (as would an R/C filter, if I didn't need a negative output signal) (not shown here). Though, it looks like the output is scaled down a bit during these sudden-changes... something to ponder in later experiments.
-----------
Update:
Excellent results after swapping capacitors and changing some pots... *excellent*.
Video, maybe, soon.
Interesting side-effect I vaguely foresaw, but hadn't quite pinpointed... This circuit *inverts* the signal... E.G. 80% PWM is 3.3V for 80% of a cycle and 0V for 20%... So, an average of 80% of 3.3V, yet results in a *lower* voltage-output from the circuit... This would make sense... The average being .8*3.3 would be the "DC-offset" which is *removed* by the AC-coupling capacitor. The circuit output follows the *negative peak* of the AC-coupled signal, and since the DC offset increases with the PWM duty-cycle, and that DC-offset is *removed* by the AC-coupler, the negative peak goes *lower* as the PWM duty-cycle *increases*. Easily compensated-for in software, but an interesting side-effect.
Oddly, that's hard to see in the images above... The output voltage shown above seems in many cases to *follow* the positive duty-cycle. There's a lot at play in there... Of course we'll see *some* increase with the positive half of the duty-cycle (when the zener is on). The output of that circuit (with the old capacitor and pot values) was *way*...
Read more »Here's an explanation for the circuit in my last log...
First:If you haven't seen it yet, check out this groovy circuit I came up with!
0->3.3V PWM (20-80% duty cycle)
V+
^
|
\
R1 /
\
| D2
+--|>|----.
| |
| __|__| D3
| | / \ 3.3V
| /___\ Zener
C1 | D1 |
0->3.3V >---||--+--|<|----+-----> >----.
| | |
\ === C2 \ Amp
R2 / | / Input
\ V \ ~30k
| GND |
V V
GND GND
OK, so I'm not 100% certain it does what I think it does... but it seems darn-close. Here's what I intended:
My audio-amp's input is biased at 0V... so a 0V input results in a 6V output. ~0.4V input results in 12V output. ~-0.4V results in a 0V output. Odd, yes... it is, in fact, a single-supply amplifier... Obviously, they were expecting AC-coupling.
This circuit serves several purposes. First: It converts PWM to a (roughly) linear voltage... kinda like an R/C filter / averaging-circuit. Second, and more importantly, it "shifts" that "average" down into a range for the input, such that e.g. 20% PWM Duty-Cycle results in -0.4V output to feed into the audio-amp's input so that its output will be 0V. Third, hopefully, the "linearizing" aspect is limited to a *single* PWM cycle, thus if the PWM duty-cycle changes dramatically suddenly, this should respond to that quickly, rather'n slowly rising to the change like would happen with an R/C filter.
Starting with the AC-Coupling capacitor C1...
0->3.3V >---||------> >----.
C1 |
\ Amp
/ Input
\ ~30k
|
V
GNDFeeding a high-enough-frequency PWM signal through the AC-coupling-capacitor results in basically the same waveform fed into the amp-input, except shifted to be "centered" around GND...
At 50% duty-cycle, it's perfectly centered...
50% duty-cycle AC-coupled:
3.3V .-----. .--- +1.65V .-----. .---
| | | | | |
| | | --> 0V - - | - - | - - | - -
| | | | | |
0V ' '-----' -1.65V ' '-----'
As the duty-cycle is varied, the DC-component of the input-signal varies, but that DC-component is removed by the AC-coupling capacitor C1. The result is that the *peaks* (both negative and positive) of the waveform shift up and down. The *average* is kept at 0V, so then, basically, the *area* of the upper portion of the waveform and the area of the lower portion of the waveform are kept equal...~10% duty-cycle AC-coupled:
3.3V .--. .--. 2.9V .--. .--.
| | | |A1| A2 |
| | | --> | | | |
| | | 0V - | -|- -v- - | - -
0V ' '--------' -0.4 V ' '--------'So, A1 ==A2, the waveform shifts up, but its amplitude is unchanged, 3.3V.Well, this alone is fine for my motor-driving-purposes... -0.4V is still low enough to cause a 0V output during the low portions of the PWM cycle. And the amp's input seems perfectly OK with 2.9V, which is >>0.4V input necessary to output 12V. So, we have, roughly, PWM on the audio-amp's output, to drive the motor. Awesome.
Except, this audio-amp has a very slow slew-rate for my needs... A square 50% duty-cycle input at my 32kHz PWM frequency results in an almost perfectly triangular output.
That's fine, I was kinda interested in experimenting with *linear* voltage control of the motor, rather'n PWM, in the first place... So, now how do I linearize my microcontroller's PWM output...? Typically, an R/C filter, right...? Except, I need its output to go *negative* from a 0-3.3V rectangular-wave... hmm... And I don't have a negative voltage-supply to feed into a voltage-divider, or whatnot... And, de-facto, If I find the *average* of the AC-coupled signal, it'll always be 0V.
Also, it'd be ideal if the "averaging"/linearization circuit doesn't introduce any noticeable delay... E.G. if the PWM signal changes from 50% to 80% in a single cycle, it'd be awesome if that change is fed to the motor almost immediately, rather than slowly rising, as an "averager" would do... (This part is the part I'm not certain my circuit accomplishes...)
OK, so the output of the AC-coupled signal has portion of the PWM cycle that *goes negative*... and somehow I'd like to "average" *that negative value* and not the *entire* value......
Read more »
Great info and ponderings, thanks!
I think you're spot-on with the A0 and A1 thing, I was just reading about that, in fact.
Yah almost got me with the BOFF method, but I think BOFF disables the address bus, as well, and if I understand correctly, that means it will stall while waiting for the next instruction, then resume wherever it left-off when BOFF is disabled. Though it's an interesting concept... maybe tying it to another bus-output pin to selectively disable the bus only for certain types of bus accesses... hmm...
Hah, now you got me wondering if it's *possible* to run the 486's program counter beyond the address-space... would think it'd just wrap around, but maybe not! Hmm... (I think A20Masking might prevent that, if used, but what if not-used?).
I think you're spot-on about AVRs, though, since they have inbuilt FLASH, no address-lines for it, (and a harvard-architecture), what would stop the program-counter from exceeding the amount of inbuilt flash, unless the PC was actually limited in bit-width to the amount of FLASH... It'd be funny as heck if you just discovered how to execute code from the AVR's RAM ;)
Woot! Glad someone thinks so, 'cause I get to spend a *lot* of time in there!
I feel like I saw a project a few years ago (maybe using a 486?) that was pretty much a hot pad for a cup of coffee using an ancient processor of some kind. Great application IMHO.
got it: #quad-386 coffee heater. Might be a good starting point?
Hah, I remember hearing of something like that, hadn't actually seen it though. Thanks for sharing! I see he used the "self-test" mode to get 'em actually chugging... was wondering, 'cause this 486 is running about 75% as fast as it's rated and isn't even hand-warm. Got me thinking about looking into this self-test mode... wonder whether it plays with the outputs... hmm...
--erm, nope, "the external bus isn't modified"-ish... but could plausibly be useful for something besides heating coffee... not that that's not cool as heck, but it's already been done ;)
Oh, and thanks for the follow!
mincepi
Christoph
I'm looking at The Indispensable PC Hardware Book 4 and they've got quite a lot of data on the 486. It's out of my league, but here are some things that may help:
- A0 & A1 are can be determined in some way by the states of BE0, BE1, BE2 & BE3.
- If these are floating in your circuit: pull AHOLD low, pull /EADS high, pull /FLUSH high
- Maybe pull /BOFF low to prevent it trying to drive the data bus? "The 486 will deactivate its bus with the next clock cycle."
Also, I wonder if the 486 just keeps happily executing nops, runs the program counter right out of the valid address space and starts executing undefined garbage. At least, on the AVR I'm sure you have to have a jmp somewhere to loop, not sure about x86. Would be one explanation for all the oddities you're observing.