#avr | Logs for 2012-01-29

Back
[00:09:55] <theBear> probly not, what about them ?
[00:11:53] <composite> ferdna, lets start on
[00:11:54] <composite> one
[00:12:02] <composite> there are lots of message boards already
[00:40:41] <ferdna> composite, that would be awesome
[00:42:12] <composite> i want to do BLDC motor control for RC airplanes
[00:42:22] <composite> one of these days
[00:44:41] <inflex> composite: no shortage of free/open designs to start from with those
[00:44:56] * inflex even has one that he never finished up (decided I'd prefer to do it with 4-layers
[00:46:08] <composite> ah good
[00:46:25] <composite> inflex, have any links?
[00:46:37] <inflex> lemme get for you
[00:46:58] <inflex> http://www.rcgroups.com/forums/showthread.php?t=742595
[00:47:44] <composite> thanks
[00:48:56] <inflex> http://www.rcgroups.com/forums/showthread.php?t=140454 <=- a better page, 7 designs!
[01:08:21] <skorket> timemage, sorry for the delay, thanks for that link. Weird that it's just kind of snuck in there without being mentioned in the other datasheet
[05:00:46] <amee2k> if the specs for an IRF520 n-ch mosfet says threshold voltage Vgs(th) max. 4.0V, does it mean that i can switch it straight from a (strong) 5V logic output
[05:32:59] <CapnKernel1> amee2k: Look at the graph called "Output characteristics"
[05:55:03] <amee2k> CapnKernel1: hmm i see
[05:55:35] <amee2k> in that case, not really. at 25°C and 4.5V the curve levels out at around an amp. thats no good
[05:56:17] <amee2k> shit, i hate being just a volt or two short >_<
[05:57:39] <amee2k> and i'm fresh out of high current logic level FETs >_<
[06:18:54] <eruif> not just that, but the gate has to be at +4V which means the output of your IRF520 will be at +1V
[06:19:57] <amee2k> well, the voltage has to be at more like 6-7V to safely allow a few amps safely
[06:20:10] <amee2k> but whats the output voltage got to do with that?
[06:20:23] <eruif> your load will see only 1V is that ok ?
[06:20:40] <amee2k> well, firstly it doesn't, it sees 12V
[06:21:37] <amee2k> and the load is a DC motor and that wouldn't even start at 1V. just sit there and draw a bit of current
[06:22:41] <amee2k> why would i only get 1V out of it?
[06:23:31] <amee2k> or rather out of what?
[06:25:02] <amee2k> 13:11 < amee2k> well, firstly it doesn't, it sees 12V
[06:25:02] <amee2k> 13:12 < amee2k> and the load is a DC motor and that wouldn't even start at 1V. just sit there and draw a bit of current
[06:25:05] <amee2k> 13:13 < amee2k> why would i only get 1V out of it?
[06:25:07] <amee2k> 13:14 < amee2k> or rather out of what?
[06:27:47] <eruif_> ignore what I said. somehow I thought you had a common drain configuration
[06:27:56] <amee2k> oh, okay
[06:27:57] <amee2k> lol
[06:51:14] <OndraSter> hmm those "IDE-like" cables are only from 3x2...
[06:51:16] <OndraSter> no 2x2 :(
[06:52:26] <amee2k> "ide-like cable"?
[06:52:32] <OndraSter> flat
[06:52:33] <amee2k> you mean ribbon cable?
[06:52:36] <OndraSter> ye
[06:52:39] <OndraSter> wasn't sure if it is ribbon
[06:53:18] <amee2k> thats what i call them all the time and people don't seem to be more confused than normally >_>
[06:53:52] <OndraSter> yeah
[06:53:54] <OndraSter> those are ribbons
[06:55:01] <amee2k> and yeah, i haven't seen any smaller than 6 conductors either
[06:55:15] <amee2k> what do you want them for, if i may ask?
[06:55:20] <OndraSter> SPI
[06:55:34] <OndraSter> power goes through another wires
[06:55:36] <OndraSter> so I need only 4 wires
[06:55:51] <amee2k> phone cable is quite flexible and easy to use and has 4 conductors, but it won't work with IDC connectors
[06:55:52] <OndraSter> (IN, OUT, CLK, RCK)
[06:56:02] <amee2k> "rck"?
[06:56:12] <OndraSter> it sends the internal shift register to the output latches
[06:56:20] <amee2k> mmh, whats the expected range?
[06:56:27] <OndraSter> range of?
[06:56:33] <amee2k> of the cable
[06:56:36] <OndraSter> oh
[06:56:38] <OndraSter> few cm
[06:56:43] <OndraSter> like 5cm :)
[06:56:46] <amee2k> i'd recommend running a ground wire or two parallel to the bus
[06:56:48] <amee2k> oh, i see.
[06:56:56] <OndraSter> there won't be high clocks
[06:57:07] <amee2k> then just use the 6-pin one and make two of the wires grounds
[06:57:19] <OndraSter> the problem is, it doesn't fit on the board anymore with 6 pin :P
[06:57:20] <OndraSter> too big
[06:57:37] <amee2k> you can put the grounds between the signal lines, like IN, GND, OUT, GND, CLK, RCK
[06:57:48] <amee2k> o.O
[06:57:54] <OndraSter> I am down to few mm :)
[06:58:40] <amee2k> how about a 1x4 header?
[06:58:48] <OndraSter> thought about that
[06:59:02] <OndraSter> I will go for 2x2 normal pins
[06:59:18] <OndraSter> it is not like it can blow or short out if I connect it the other way
[06:59:24] <amee2k> it is kinda rare but they make .1" ribbon cable too that would match a single row header
[06:59:50] <amee2k> well, depends. two strong logic outputs trying to drive against each other can cause damage
[07:00:01] <OndraSter> all of them are input (except the OUT)
[07:00:07] <OndraSter> we'll see
[07:00:16] <OndraSter> it is not that crucial, just noob safety measure
[07:00:19] <OndraSter> but noobs shouldn't play with it
[07:00:23] <OndraSter> or at least take it apart
[07:00:33] <amee2k> but you've got inputs and outputs on both sides
[07:01:11] <amee2k> with three signals going one way and one the other way, you'll always have two drivers connected together if you plug it in the wrong way
[07:01:22] <amee2k> (or at least i think so)
[07:01:57] <dpy> -sigh- I don't get it...
[07:02:07] <amee2k> you could get 8-pin ribbon cable and split it down the middle
[07:02:21] <amee2k> it is easy to separate between the individual conductors
[07:02:37] <amee2k> or just violate an old IDE cable, depending on how many you need >_>
[07:02:52] <amee2k> but i think 2x2 IDC connectors will be hard to find, and not very space efficient
[07:03:30] <amee2k> they need clearance of at least 0.1" towards the two sides perpendicular to the cable direction
[07:03:32] <dpy> Is it possible with an AVR @16MHz to blink a led in softpwm in such a short interval, that it actually appears to be off for the human eye?
[07:04:01] <OndraSter> dpy, yes, why it shouldn't?
[07:04:02] <amee2k> this prevents you from accidentially plugging a smaller IDC connector into a larger header... the pins would interfere with the connector body
[07:04:25] <OndraSter> amee2k, like I said, screw noobs... noobs should only write software for it, not take it apart :P
[07:04:33] <OndraSter> I will connect it, give it to them and leave it
[07:04:36] <OndraSter> some docs
[07:04:38] <OndraSter> and that's it :P
[07:05:18] <amee2k> dpy: in soft pwm pretty much everything is possible. as for hardware pwm thats gonna get tricky
[07:05:37] <dpy> then I must be doing something wrong here, because even if I turn off the led when my soft counter reaches 0, and turn it on when my soft counter reaches MAX-1, I can still see the LED being turned on (very dimly, but `on' nonetheless)
[07:06:04] <amee2k> 16MHz / 1024 / 2**16 = 0.23Hz... that is definitely visible i'd say
[07:06:44] <amee2k> err... you mean implement soft-pwm in a way that allows true 0% duty?
[07:06:59] <dpy> amee2k: I want my t44 to do 2 things: softpwm and IR receiving. Now working on part 1 (and yes, I've tried all available stuff, not enough resolution)
[07:07:16] <amee2k> i think ondra and i understood that you meant pwm it slow enough that the LED flickers visibly
[07:07:45] <dpy> no, I want it to have a duty cycle that is small enough to appear off
[07:07:53] <amee2k> i see
[07:08:24] <dpy> that way I have a high resolution control over the fading
[07:08:37] <dpy> I want really slow fading
[07:08:46] <amee2k> that'll strongly depend on the environment conditions... the human eye is quite sensitive in a dim or dark room, and modern LEDs are very efficient
[07:09:09] <dpy> all stuff I've seen sofar do 'smooth fading' by fading rather swiftly (to mask the step size in the dimmer regions)
[07:09:27] <amee2k> a LED with 1uA running through it will appear off in bright daylight, but in a dim room it'll show readily visible glow
[07:10:09] <amee2k> is there a specific reason why you need PWM to be implemented in software?
[07:10:10] <dpy> amee2k: so you're saying, the better the LED, the harder it becomes for the AVR to achieve this?
[07:11:00] <dpy> amee2k: yes, the t44 only has 2 channels of 16bit PWM, I need three. Moreover, I want my AVR to do nothing but simple very slow fading
[07:11:01] <amee2k> not harder for the AVR, but you need to make sure the duty cycle can actually go to zero... straight forward soft-pwm implementations sometimes don't allow for true 100% duty or 0% duty settings
[07:11:42] <dpy> amee2k: no, for true off, I'll just disable the counter and write a low to the pin
[07:11:58] <amee2k> okay
[07:12:32] <amee2k> then i'm not entirely sure what you mean. if you force the pin low, duty is 0% so the LED should stay off
[07:12:48] <dpy> amee2k: I'm using the 'appear to be off' as a metaphore for having a really high resolution on the PWM (if 1 appears to be off, and 5 appears to be on, I have high resolution, especially usefull in the dimmer regions)
[07:13:35] <dpy> which means I can really slooooowwly fade, and you wouldn't see any steps in the dimmer regions
[07:14:17] <amee2k> 16 bit would be high enough resolution to make the fade stepless for most purposes
[07:14:33] <dpy> kind of like: shadows of the sun on a bright day move constantly, but try to watch it move in real-time and you'll fail
[07:15:12] <dpy> I want to be able to look at the led and not noticing that it makes a step in brightness
[07:16:04] <amee2k> with 16 bit you shouldn't notice. at least unless you watch for it specifically and very closely
[07:16:26] <dpy> amee2k: 1) t44 only has 2 16-bit channels; 2) with a very efficient LED, even if I put the PWM on 1, won't it still be visible?
[07:17:08] <amee2k> what is the LED current during the on-time?
[07:17:26] <theBear> 16bit is cool so long as you avoid silly gradients (haven't read up many lines)
[07:18:18] <amee2k> 20mA on-current at a setting of 1 and 16 bit PWM yields an average current of 300nA. even with a high efficiency LED that is going to be a stretch to see unless the room is pitch black
[07:18:30] <dpy> I have no idea about the current (it's not a standalone led, but a string, powered by 12V PSU)
[07:19:02] <amee2k> you built the LED driver too, no?
[07:19:12] <dpy> amee2k: yeah I did
[07:19:45] <amee2k> so what target current did you use for calculating the resistors or other current limiter?
[07:20:03] <amee2k> i.e. the current that will flow while the PWM pin is active
[07:20:05] <dpy> the LED string comes with built-in resistors
[07:20:11] <dpy> I just supply 12V
[07:20:16] <amee2k> okay
[07:20:27] <amee2k> can you measure the current, or otherwise estimate it?
[07:20:51] <amee2k> from LEDs that i
[07:21:31] <amee2k> 've seen, i'd say everything under 2-3uA average current will be invisible for practical purposes. you'd only see it in a dark room if you looked straight at the LED at point blank range
[07:23:08] * amee2k points out that average current for PWM is Iavg = Ion * x / (2^n-1); where x is the PWM setting and n is the number of PWM bits
[07:24:20] <dpy> ok, we can, measure the current through the LED and calculate whether we would see it. On the other hand, we can also not measure and not calculate and simply write the fastest on/of sequence and try it out (which is the route I'm taking here, because I have a firmware coding set up here, and not a hardware debugging setup)...
[07:25:06] <amee2k> i see
[07:25:30] <dpy> you see, I hacked togehter the driver some time ago
[07:25:40] <amee2k> can't you at least talk to the hardware people to put the LED strip on a power supply and tell you how much current is acceptable to be considered off?
[07:45:39] <dpy> amee2k: okay, I've disabled all timers and wrote it in the main loop: tick++; if(tick == MAX){tick = 0; LED_ON; nop(); LED_OFF;}
[07:46:29] <dpy> I think it's safe to say that this is the fastest on-off cycle that the AVR can produce (without nop the LED appears to stay off)
[07:47:28] <amee2k> do you have a scope to measure the actual duty cycle that the MCU is generating?
[07:47:35] <dpy> MAX determines the max resolution, but it also affects the 'dimmest' possible value
[07:47:58] <dpy> amee2k: nope, I am very low on the equipment part, sorry
[07:48:14] <amee2k> soft PWM in a busy-waiting loop like that is fairly tricky to get right, especially if you do it in C
[07:48:52] <dpy> Making MAX larger doesn't make the LED every dimmer, at some point it starts flickering
[07:49:21] <amee2k> because it relies on the exact execution time, and C makes no statements about that, much less any guarantees
[07:49:43] <dpy> amee2k: this is turning out to be some sort of experimenting with the limits of what can and can't be done as well
[07:49:50] <amee2k> so i strongly suggest for you either use a hardware PWM channel for experimenting with the duty cycles, or get a scope to measure the duty cycle
[07:50:31] <dpy> amee2k: I can see it jittering before it starts flickering as well, so I think it's safe to say that we are reaching the limits of this LED string in combination with the AVR
[07:51:54] <amee2k> if the LED is flickering, then your PWM frequency is too low. which you can't measure without a scope
[07:52:04] <dpy> amee2k: this busy wait PWM is just for testing the limits, I won't use it in practice... I'll just have to live with the fact that there is going to be a step between off and dimmest possible value
[07:53:58] <amee2k> to appear flicker-free you'll want a PWM frequency of at least 100Hz or so. anything above 400-500Hz should be essentially invisible to the human eye for most purposes
[07:56:25] <amee2k> thats why i strongly recommend using a hardware timer for experimenting and figuring out the values. and then go looking for an existing soft-pwm library for the production version
[07:56:53] <dpy> I understand what you are saying, but I'm also beginning to understand PWM a lot more...
[07:57:37] <amee2k> since PWM my definition works in discrete steps, you won't get completely step-free operation either. but with 16 bit you'll have high enough resolution so people won't notice unless they specifically look for it
[07:58:07] <dpy> in particular: the relation between the clock frequency, the resolution of the PWM and frequency of the output signal of the PWM
[07:58:34] <amee2k> :)
[07:59:04] <dpy> for a fixed clock frequency, the resolution of the PWM directly influences the output signal of the PWM and there is a point where `dimmer' becomes `flickering'
[07:59:18] <dpy> which can only be solved by 'faster CPU'
[07:59:39] <dpy> (for a fixed LED string like this)
[08:00:10] <dpy> you could of course cheat and have a bigger resistor, but that will influence the max brightness
[08:00:55] <amee2k> for fixed MCU clock frequency, the resolution influences the PWM frequency, right. but flickering has nothing to do with how dim it is. higher resolution means lower frequency
[08:02:02] <amee2k> 1kHz PWM will always appear flicker-free no matter what brightness setting. 20Hz PWM will appear to flicker over almost the entire range of brightness settings
[08:03:05] <amee2k> 1MHz timer clock at 8 bit PWM is ~4kHz PWM. that is flicker free. 1MHz timer clock with 16 bit PWM yields 15Hz PWM. that is going to flicker
[08:04:01] <dpy> er... but it has (as I've just figured out): the higher the resolution, the smaller the duty cycle (e.g. 1/255 versus 1/65535); now 1/65535 may appear to flicker because for the given fixed clock frequency, it takes too long before the led is turned on again...
[08:04:31] <amee2k> mmh, not really
[08:05:03] <amee2k> for time periods shorter than a few milliseconds, the human eye is a very good integrator
[08:05:46] <amee2k> so as long as your PWM frequency is high enough that a single PWM cycle is significantly shorter than that integration window, you won't see that it is PWM
[08:05:54] <dpy> yes, but if the clock freq. is too low, the full duty cycle of 65535 ticks may become bigger than a few milliseconds, thus human eye integration fails: flickering appears
[08:06:24] <amee2k> true, but your clock frequency (and hence the PWM frequency!) is constant
[08:06:59] <dpy> yes, but I was discussing changing the MAX value
[08:07:35] <amee2k> the max value has nothing to do with that
[08:08:04] <amee2k> for example, 1kHz PWM yields 1ms PWM cycle time. now all you do is change how much of that 1ms is being spent with the LED turned on, and how much with the LED turned off
[08:08:35] <amee2k> e.g. 200us on, 800us off. thats 20% duty
[08:08:59] <dpy> yes, but changing the MAX value will change the PWM cycle time (the CPU won't count any faster)
[08:09:37] <amee2k> yes, thats why you need to make sure your frequency is high enough. but once you can manage that, the frequency won't change with the exact brightness setting
[08:09:39] <dpy> so changing the MAX value to 100 times, the PWM cycle time becomes 100ms
[08:09:47] <dpy> which will appear flickering
[08:10:34] <dpy> changing the MAX to 10 times it previous value, the PWM cycle becomes 10ms, but the LED will appear to be dimmer (for the 1/MAX duty cycle)
[08:10:48] <amee2k> o.O
[08:10:55] <dpy> its duty cycle went from 1/MAX to 1/(10*MAX)
[08:11:00] <dpy> let's stop yes
[08:11:00] <amee2k> define what you understand as "MAX" please
[08:11:01] <dpy> :D
[08:11:41] <dpy> I believe the AVR docs call it TOP
[08:11:46] <CapnKernel1> dpy: Put a cap across the LED string.
[08:11:47] <amee2k> ok
[08:11:54] <amee2k> what?
[08:11:54] <CapnKernel1> It will smooth the on time
[08:12:07] <amee2k> no, don't. CapnKernel1 is smoking chinese weed again >_<
[08:12:22] <CapnKernel1> amee2k: And why not?
[08:12:28] <CapnKernel1> A cap that is, not the wacky
[08:12:31] <amee2k> because it messes up the PWM waveform?
[08:12:52] <CapnKernel1> He doesn't care about the waveform, it's a continuously variable dimmed LED string.
[08:13:09] <amee2k> PWM exactly works because there is *no* smoothing
[08:13:24] <amee2k> so duty cycle is directly related to average current
[08:13:27] <CapnKernel1> You have it around the wrong way
[08:13:43] <CapnKernel1> PWM means you don't have to generate a varying voltage, in order to generate different brightness levels.
[08:14:07] <amee2k> with a strongly nonlinear load like a LED the current waveform would get all screwed up if you put a cap across it
[08:14:14] <CapnKernel1> By varying a signal between all on and all off, the average will be equivalent to an analog voltage.
[08:14:20] <CapnKernel1> To our eyes.
[08:14:35] <CapnKernel1> But there's *no reason* you can't take that PWM signal and convert it back into DC.
[08:14:39] <CapnKernel1> A varying voltage.
[08:15:15] <amee2k> then you'd need an LC filter and a halfbridge driver since you need a two-quadrant output to drive the filter
[08:15:33] <CapnKernel1> If by persistence of vision your eye is seeing a bright flash 1% of the time, why not smooth it?
[08:15:43] <CapnKernel1> Naah. The LED will discharge the cap quite nicely
[08:15:51] <amee2k> if you use just a cap, any linearity you had will go down the toilet
[08:15:57] <CapnKernel1> Add a diode and maybe a charge limit resisitor
[08:17:05] <CapnKernel1> I once had a board where I needed to get an idea of how busy the CPU was. I put a GPIO toggle either side of the sleep.
[08:17:22] <CapnKernel1> Connected the GPIO to a cap via a diode, and put a resistor across the cap.
[08:17:29] <CapnKernel1> Then put an analog meter across the cap.
[08:17:43] <amee2k> dpy: i see. but you're never changing your MAX / TOP, right?
[08:18:02] <CapnKernel1> The meter indicated how busy the processor was, and matched the figure I was calculating in software.
[08:18:08] <CapnKernel1> What I'm suggesting is no different.
[08:18:55] <amee2k> so once you have worked out a counter clock frequency and MAX value that yields sufficient resolution at acceptable frequency, you're done and it can never flicker
[08:19:47] <Bushman> ave
[08:20:01] <dpy> amee2k: agreed
[08:20:05] <amee2k> well, try it and see. but don't blame me if you're getting wonky results with the LED string then
[08:21:04] <dpy> amee2k: for starters I just wanted to see if I could get the led string to appear off, but as it turned out, I can't
[08:21:21] <dpy> amee2k: or maybe with the CapnKernel1 trick
[08:21:44] <dpy> amee2k: now that I know this, I can investigate how to make it smooth
[08:21:53] <CapnKernel1> You have nothing to lose either way.
[08:21:56] <amee2k> i'd also recommend you either get rid of the busy waiting loop, or arrange the loop in such a way that there are no conditionals in it.
[08:22:27] <amee2k> the counter clock depends on the execution time of one loop iteration of your busy waiting loop
[08:22:38] <amee2k> so you want that execution time to be constant
[08:23:18] <CapnKernel1> Busy waiting is for Arduino users.
[08:23:27] <amee2k> you can do soft-pwm by using the overflow interrupt of an 8 bit timer
[08:23:32] <CapnKernel1> And DOS.
[08:25:26] <CapnKernel1> Here's how I drove an IR LED at 38KHz to generate an IR command: http://pastebin.com/sHzAkShe
[08:26:51] <CapnKernel1> Counts up to 210 and restarts. OCR1B sets when the PWM toggles, so by fiddling with OCR1B, you can change the duty cycle.
[08:27:18] <CapnKernel1> That's for an ATtiny85
[08:27:51] <CapnKernel1> I seem to remember bsdfox helped me work it out. Thanks bsdfox.
[08:32:33] <CapnKernel1> skorket: You still there?
[08:32:59] <CapnKernel1> dpy: Going back to your initial requirement: "Is it possible with an AVR @16MHz to blink a led in softpwm in such a short interval, that it actually appears to be off for the human eye?"
[08:33:10] <CapnKernel1> Can "such a short interval" include actually being off?
[08:33:29] <dpy> apparently the answer is: no
[08:33:34] <CapnKernel1> Or are you looking for something which appears to be off, but is actually on for a tiny fraction of a second?
[08:33:51] <dpy> CapnKernel1: that was the idea, the experiment
[08:34:00] <CapnKernel1> I'm not talking about what the hardware can or cannot do, I'm talking about the requirement that comes from your problem domain.
[08:34:50] <CapnKernel1> In the case where the LED has to "appear off", why do you also have the requirement for it to be electrically on for some of the time?
[08:35:01] <CapnKernel1> Why can't it be electrically off 100% of the time?
[08:35:06] <dpy> CapnKernel1: but with this particular LED string, I think you'll need a 1/(16bit+) duty cycle, for which you'll probably also need higher clock frequency
[08:35:18] <CapnKernel1> You haven't answered the question.
[08:35:37] <dpy> say: perhaps: 200MHz and 24-bit PWM
[08:35:39] <CapnKernel1> Why does it need to be always on?
[08:35:48] <CapnKernel1> Where "always on" means "on for at least some of the time"
[08:35:54] <CapnKernel1> Why not just turn it completely off?
[08:36:22] <dpy> CapnKernel1: I already answered the question some time ago: I use the appear to be off as a metaphore
[08:36:39] <CapnKernel1> I can think of valid reasons why you still might want a PWM signal for some of the time, even though it appears to be off. For example, you may have circuitry to detect whether a LED string has failed.
[08:36:57] <CapnKernel1> I'll go back and re-read.
[08:37:01] <dpy> CapnKernel1: what I actually mean is: have a high enough resolution, that smallest duty cycle and the second-to-smallest duty cycle become indistinguishable by the human eye
[08:37:50] <dpy> and the answer to that (at least for this LED string) is: no, an AVR cannot do that
[08:40:14] <keenerd> Nothing can do that if you eyes are dark adjusted. You can easily pick out sub-microsecond pulses of light.
[08:40:21] <CapnKernel1> How to do the really dim end without flickering?
[08:40:33] <Kevin`> dpy: don't turn on the pwm every time the timer resets
[08:40:56] <CapnKernel1> The eye is amazingly sensitive. It can register with just 7 photons.
[08:40:59] <dpy> smallest and second-to-smallest being: 0/TOP and 1/TOP (with TOP, MAX being the highest value the counter has, i.e. the resolution of the PWM)
[08:41:31] <CapnKernel1> I'm with keenerd
[08:41:39] <dpy> ok
[08:41:59] <CapnKernel1> You could still try a cap, if you don't need lightning fast response.
[08:42:04] <dpy> 7 photons? That's like 7 electrons for an LED
[08:42:18] <CapnKernel1> I read it in a paper once.
[08:42:29] <Kevin`> wouldn't a series inductor be better than a cap?
[08:42:44] <Kevin`> and eliminate the resistors, if you have one, too, from that
[08:43:42] <keenerd> Just LED+cap would be better than LED+inductor.
[08:44:20] <keenerd> No resistor needed, the chip can only source so much.
[08:44:52] <Kevin`> inductor will try to maintain constant current across the leds
[08:45:04] <CapnKernel1> Folu
[08:45:11] <CapnKernel1> Found it
[08:45:18] <CapnKernel1> Hecht's experiment of 1942: http://en.wikipedia.org/wiki/Absolute_threshold#Vision
[08:46:43] <CapnKernel1> Also: http://books.google.com.au/books?id=2tW91BWeNq4C&pg=PA49 fig 3.9
[08:46:53] <skorket> CapnKernel1, what's up?
[08:47:08] <CapnKernel1> Re redefining symbols in assembler
[08:47:29] <CapnKernel1> Are you calling "as" directly?
[08:47:35] <skorket> ah, 'avr-as' yes
[08:47:59] <CapnKernel1> If you call "gcc-as", and your file has a .S extension (not .s), gcc will feed it through the C preprocessor
[08:48:03] <CapnKernel1> And then you can do #define
[08:48:14] <CapnKernel1> Oh sorry, "avr-gcc"
[08:49:21] <CapnKernel1> If you are on Windows, try giving the file the extension of ".sx".
[08:49:23] <skorket> ok. I'm still a little iffy on all the other pseudo-ops and directives... '.global' vs. '.data' etc.
[08:49:26] <skorket> I'm on linux
[08:49:32] <skorket> Ubuntu 10.10...
[08:49:46] <CapnKernel1> My point is, that's a standard way of doing textual substitution in an assembler file.
[08:49:56] <skorket> ok, thanks
[08:49:58] <CapnKernel1> And that was the question you had.
[08:50:00] <CapnKernel1> You're welcome.
[08:50:30] <CapnKernel1> Try "man gcc" and search using "/" for "Options Controlling the Kind of Output"
[08:51:13] <CapnKernel1> Or: http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Overall-Options.html#Overall-Options
[08:53:48] <abcminiuser> !seen Tom_itx
[08:54:31] <CapnKernel1> !seen tobbor!!!!!
[09:05:07] <abcminiuser> *Sigh*
[09:05:18] <abcminiuser> Tobber and Tom must have done a murder-suicide
[09:06:52] <amee2k> tobbor's mom had a quickie with postfix
[09:10:54] <carp3> is it ok to use crystal wihtout capacitor ? ( i don't have right capacitor right now )
[09:12:52] <amee2k> depends. i haven't had problems without loading caps on my solderless board
[09:13:34] <amee2k> apparently the contact capacitance alone provides enough loading. some AVRs also have built in loading caps that can be enabled with a fuse or register flag
[09:39:22] <_abc_> amee2k: and that is wrong for some atmega8a s. There is an errata
[09:39:34] <_abc_> If you use wrong value load caps the frequency will be way off
[09:39:44] <_abc_> Especially noticeable with 32kHz watch xtals
[09:41:12] <amee2k> thats why i said *some* have it, not all of them ;)
[09:44:59] <atmega> amee2k: you have buy some ATmega8A at the bay?
[09:45:26] <amee2k> what?
[09:47:54] <amee2k> why would i have to buy a mega8?
[09:48:38] <atmega> you talk about the errata for ATmega8A
[09:48:58] <amee2k> no, abc did
[09:50:34] <amee2k> carp3: either way, if you're ordering boards and can afford the board area, put cap footprints on the xtal. if you can't get it working without caps you can always put some on the board later
[09:51:19] <carp3> i'm using breadboard.
[09:52:29] <amee2k> then chances are it'll work with a full swing crystal without caps. not sure about watch crystals, the parasitic capacitance may not be enough for loading them
[09:56:42] <carp3> well, i'm changing fuse bits CKSEL = 1111 SUT 00
[09:56:57] <carp3> it works!
[10:00:48] <_abc_> watch xtals need 6 to 13pF load
[10:01:09] <_abc_> Be sure to use the value required by the xtal and never buy generic xtals with unspecified load cap
[10:01:32] <_abc_> Your reward will be a clock that runs up to a minute fast per 3 days or so, if you do
[10:01:34] <CapnKernel1> carp3: http://www.fairchildsemi.com/an/AN/AN-340.pdf
[10:03:26] <amee2k> _abc_: are you sure about that?
[10:03:45] <amee2k> iirc thats less than half of what is recommended for a full-swing xtal
[10:08:57] <atmega> _abc_: To use a 32.768 kHz watch crystal as the clock source for the device, the Low-frequency Crystal Oscillator must be selected by setting the CKSEL Fuses to “1001”.
[10:10:10] <atmega> The internal capacitors have a nominal value of 36 pF.
[10:29:59] <_abc_> atmega: look up 32kHz crystal specs, they give the capacitance
[10:30:04] <_abc_> * amee2k
[10:30:37] <_abc_> also in the atmega datasheet you will find the details of the capacitance connected by the atmega in parallel to the xtal pins for 32khz xtal operation
[10:34:13] <_abc_> http://www.atmel.com/dyn/resources/prod_documents/doc8333.pdf
[10:51:56] <dpy> amee2k: Okay, I settled for 12-bit soft-pwm using an 8-bit timer in CTC
[10:52:31] <dpy> amee2k: unfortunately, somehow sometimes it glitches (the leds stay off a blink of an eye)...
[10:56:00] <dpy> maybe someone sees some obvious error: http://pastebin.com/MbduZ1YW
[10:58:27] <rue_bed> hmmm
[10:58:49] <rue_bed> whats your goal pwm freq?
[10:59:49] <dpy> I don't care, as long as I don't think it flickers
[11:00:15] <dpy> I believe it's now somehwere around 16ms each cycle
[11:00:26] <dpy> I had it at 8 ms per cycle
[11:00:50] <rue_bed> pretty surprised if yu can do 12 bits without flicker
[11:00:54] <dpy> but that doesn't solve the occassional glitch where it stays off for fraction
[11:01:04] <rue_bed> its not pwm'ing I presume?
[11:01:38] <dpy> it feels that it skips a cycle or something
[11:02:04] <dpy> turns off the leds, then one full cycles doesn't turn them on, then the next cycle it recovers
[11:02:08] <rue_bed> hmm
[11:02:27] <rue_bed> I'd suggest my code if you hadn't done it so different
[11:04:01] <dpy> I've looked at several implementations before
[11:04:21] <dpy> they all make too large brightness steps in the dimmer regions
[11:04:30] <dpy> that's why I want 12-bits here
[11:04:58] <dpy> nobody wrote a 12-bit soft-pwm and published the code
[11:05:16] <dpy> but I frankly don't see what's causing the glitch
[11:05:28] <dpy> there's not a whole lot that's going on in this code
[11:05:34] <rue_bed> thats cause software pwm cant do high pwm freq's
[11:06:06] <rue_bed> whats pwm_log()
[11:06:18] * amee2k idly reminds rue_bed about the motor driver code from yesterday :)
[11:06:21] <dpy> a linear->log function
[11:06:28] <dpy> from 8-bit linear to 16-bit log scale
[11:06:36] <amee2k> gamma correction?
[11:06:41] <dpy> yeah
[11:06:45] <rue_bed> in an interrupt...
[11:06:56] <dpy> it's look up
[11:07:01] <dpy> can't be done there?
[11:07:03] <rue_bed> even on an avr that lookup takes a while
[11:07:18] <dpy> okay, maybe that causes the glitch
[11:07:47] <dpy> I can do a linear counter to see if that helps with the glitching
[11:10:16] <rue_bed> hmm I have to be looking at an avr timer datasheet to follow that properly
[11:11:36] <dpy> nope, even withouth the PWM_LOG there's a glitch
[11:12:25] <dpy> http://pastebin.com/AWDCVN0f
[11:12:39] <dpy> brb, oven is ready
[11:18:18] <dpy> so, nobody sees something obviously wrong there? (apart from writing to the output ports from within an ISR)
[11:22:14] <atmega> I can not find a definition for TOP
[11:27:00] <amee2k> how would i go about identifying the pinout of a known HD44780 compatible display with a funny connector? (2x7 block 0.1" header... resources online are conflicting over the pinout and the silkscreen pin numbering appears to be mirrored across the long axis)
[11:27:21] <amee2k> the module is 2x16 characters and the ICs are epoxy blobs
[11:27:54] <rue_bed> oh, dpy do you mean the 0 or 100% glitch?
[11:29:04] <dpy> unfortunately, no. It's random and somewhere between 0 and 100%
[11:29:40] <rue_bed> yea I'd need to sit down and draw waveforms of the two timers
[11:29:44] <dpy> I overflow from 0 to 100% so I wouldn't normally see that as a glitch, just a hard edge from 100 to 0
[11:30:17] <dpy> rue_bed: are those timers interfering with eachother then?
[11:30:41] <rue_bed> well you have two timed interrupts, at some point they will cross
[11:30:44] <dpy> I can turn off the second ISR and do the color update in the main loop if that makes any difference
[11:31:12] <dpy> I'll just watch the compare flag of the second timer
[11:31:24] <rue_bed> your using the compare match to increment r yes?
[11:31:34] <dpy> yes
[11:31:36] <amee2k> rue_bed: are you ignoring me? :P
[11:31:42] <rue_bed> amee2k, no...
[11:31:46] <amee2k> >_>
[11:31:50] <amee2k> just checking :)
[11:31:53] <rue_bed> oh 44780
[11:31:57] <rue_bed> sr
[11:32:22] <rue_bed> can you trace it back to the chip pins?
[11:32:27] <amee2k> well, that. and you said yesterday i should ask you for the motor drievr code again
[11:32:50] <amee2k> i can trace the connections to some degree, but not to the pins. the chips are epoxy blobs
[11:32:50] <rue_bed> *blink* motor driver code?
[11:32:59] <rue_bed> for what kinda motor?
[11:33:05] <rue_bed> ah, hmm
[11:33:07] <amee2k> yes, the coil winder. you said you had a servo motor code
[11:33:16] <rue_bed> what layout are the connections?
[11:33:20] <rue_bed> oh ok
[11:33:26] <rue_bed> servo32
[11:33:31] <amee2k> 2x7 header block
[11:33:43] <rue_bed> ok, thats one of the std ones,
[11:34:07] <amee2k> http://www.aeontekasia.com/pdf/DV-16235.pdf << this is the datasheet, but i have reason to believe the pinouts may be inaccurate
[11:34:13] <rue_bed> there are two std pinouts for 447880 dispays, an inline and a dual row
[11:34:26] <rue_bed> I cant open that on this
[11:34:47] <rue_bed> barely enough free ram for a desktop image
[11:34:53] <amee2k> there is a thread on mikrocontroller.net where people are debating the pinout, but all the links in the thread are dead
[11:35:07] <amee2k> so i don't know which ones they have identified as correct and which ones as incorrect
[11:35:11] <rue_bed> I can find mine
[11:35:20] <rue_bed> !assist avr
[11:35:26] <rue_bed> !time
[11:35:29] <rue_bed> ugh
[11:36:16] <amee2k> the silkscreen numbering is the same as shown on the drawing on page 2 (assuming the drawing is seen from the top), but the silkscreen and the header are both on the bottom of the board
[11:36:32] <amee2k> so the pin numbering would be mirrored with respect to ribbon cable IDC connector conventions
[11:36:34] <rue_bed> amee2k, can you tell where ground is?
[11:36:55] <rue_bed> 1 3 5 7 9 11
[11:37:02] <rue_bed> 2 4 6 8 10
[11:37:59] <amee2k> following the silkscreened pin numbering, pin #2 is connected to the front cover of the LCD. i'd say that says it is ground, right?
[11:39:05] <rue_bed> ok
[11:39:15] <rue_bed> we should be able to work out from that
[11:39:22] <rue_bed> did they say that was ground?
[11:39:35] <amee2k> datasheet says pin 2 is ground, yes
[11:40:42] <rue_bed> if you apply power to the 5v, and 'severly bounce the power' can you get it to partially initialize the lcd drivers (you see the elements change shade just a tiny bit)
[11:40:48] <amee2k> attaching a ribbon cable with IDC connector to the header would leave that pin on wire #1 though, and the mikrokontroller.net thread says power pins are swapped compared to the pinout their datasheet had. hence the confusion
[11:41:14] <amee2k> "severely bounce the power"??
[11:41:32] <rue_bed> scratch it agaisnt a 5V line
[11:41:56] <rue_bed> so it glitches up
[11:42:30] <rue_bed> +- the lcd drive voltage, that should give you a clue about the power
[11:42:53] <rue_bed> I'v seen some that need a -ve drive voltge too, -3V
[11:43:09] <rue_bed> most are ok with about 0-1V
[11:43:53] <rue_bed> !time
[11:43:54] <tobbor> My watch says its 09:39 Sun Jan 29 2012
[11:44:38] <amee2k> rue_bed: the drawing on the bottom of the first DS page shows the lcd drive pin connected to a poti across Vdd-Vss so i don't think it needs negative drive
[11:44:47] <rue_bed> k
[11:45:02] <rue_bed> only come up on 2/30 displays for me
[11:46:06] <amee2k> i scratched the teeth of a croco clip against the V+ wire but no reaction from the display
[11:46:34] <rue_bed> hmmm
[11:46:37] <amee2k> using pin 2 for ground, and grounding the lcd drive (pin 3 as identified by the silkscreen)
[11:46:40] <rue_bed> with bias at 0?
[11:47:06] <amee2k> too bad it doesn't have the backlight on the header too. that would be dead easy and safe to identify
[11:47:29] <rue_bed> hmm
[11:48:37] <amee2k> putting V+ on the case doesn't make any sense so pin 2 has to be ground, no?
[11:54:50] <rue_bed> yup
[11:55:00] <rue_bed> unless its fg
[11:55:07] <amee2k> "fg"?
[11:56:21] <rue_bed> frame ground
[11:56:46] <rue_bed> how many lines have thick traces?
[11:56:48] <rue_bed> 4?
[11:57:02] <amee2k> modules can have separate pins for the frame? o.O
[11:57:40] <amee2k> pin 1 has a pretty thick plane on the top layer
[11:58:15] <amee2k> pin 2 has a short, thin trace going into a moderately large plane that connects to the frame
[11:58:54] <amee2k> the pin 2 plane is on the bottom and has vias that i can't trace because they're under the display
[11:58:56] <rue_bed> oh pin 1 sounds like the logic ground
[11:59:07] <rue_bed> hmm
[11:59:42] * rue_bed climbs out of bed
[12:00:26] <amee2k> there is also a bunch of resistor footprints on the bottom. the only ones populated are a single SMT 0R resistor and a 6-pin SIL network
[12:00:50] <amee2k> i'll make a pic of the bottom of the module
[12:04:33] <amee2k> 2048x796 jpeg is ok?
[12:04:46] <amee2k> or should i scale it down?
[12:06:07] <dpy> well.. I've moved the LOG_PWM to the main loop: http://pastebin.com/MDZHFKTa
[12:06:13] <dpy> but it still glitches..
[12:06:34] <amee2k> rue_bed: http://ompldr.org/vY2lwcw/lcd-module-2.jpg
[12:07:45] <rue_mohr> uh, where are the rest of the resistors
[12:08:23] <OndraSter> selector for some voltage I presume
[12:08:25] <rue_mohr> there should be about 5 resistors in a row
[12:08:26] <OndraSter> probably backlight?
[12:08:26] <rue_mohr> no
[12:08:39] <rue_mohr> there should be 5 resistors in a row that do the bias division
[12:08:48] <rue_mohr> oh their using the sip
[12:08:49] <rue_mohr> sorry
[12:09:43] <rue_mohr> you have the contrast set to vss or vdd?
[12:10:40] <amee2k> all the connections on the SIP thing are on the top layer and obscured by the display, except for SIP pin #6, which is connected to the trace going from R8 to R7 and R6 around the top
[12:11:04] <rue_mohr> if you meter it, one of them is prolly connected to the Vee pin
[12:11:08] <amee2k> rue_bed: Vss
[12:11:11] <rue_mohr> one of the sip pins
[12:11:50] <amee2k> Vee == the lcd drive pin?
[12:12:03] <rue_mohr> everything looks normal, they seem to be using the logic ground for frame ground, ok
[12:12:07] <rue_mohr> yes
[12:12:13] <rue_mohr> you want to ground Vee
[12:12:19] <rue_mohr> lower = more contrast
[12:12:29] <rue_mohr> how are you trying to drive the pcd?
[12:12:35] <rue_mohr> lcd
[12:14:34] <amee2k> yeah, SIP pin #6 appears to be connected to header pin #3
[12:14:50] <rue_mohr> how are you operating the lcd?
[12:15:59] <amee2k> from the Vee pin, the other SIP pins measure in order from 5-1: 6.8k, 13.6k, 13.6k, 20.4k, 26.6k
[12:16:13] <amee2k> rue_bed: i'm not operating it. i want to identify the pinout so i can use it
[12:17:44] <amee2k> this is supposed to become the display for the coil winder :)
[12:18:23] <OndraSter> I wasn't here for the beginning
[12:18:27] <OndraSter> but is this regular HD44870
[12:18:31] <OndraSter> that costs $2?
[12:18:57] <amee2k> its from my junk box, but i don't remember where i got it from
[12:19:39] <amee2k> i have a datasheet for it and it looks like it is HD44870 compatible. thats what a thread on mikrokontroller.net about it indicates as well
[12:19:47] <rue_mohr> well everything looks good to me, wire 'er up and go!
[12:19:56] <rue_mohr> they almost always work
[12:20:29] <rue_mohr> the only thing I ever seen is a mirrored pinout cause the connector was on the wrong side of the board
[12:20:37] <amee2k> OndraSter: but the thread also indicates that the pinout is non-standard and not consistent with the datasheet pinout. unfortunately their datasheet link is dead so i don't know which pinouts (that they are refering to) are accurate and which are not
[12:20:48] <rue_mohr> the ground is given away by that frame connection
[12:21:32] <amee2k> rue_bed: so header pin 2 is ground, and the pinout in my datasheet are accurate?
[12:22:26] <amee2k> my datasheet says header pins are in order from 1 to 14: V+, ground, lcd drive, RS, RW, E, DB0..DB7
[12:24:55] <OndraSter> oh
[12:24:59] <OndraSter> bummer
[12:25:57] <amee2k> well, i've got a total of 6 different modules or so. chances are i can ID one of them before i kill it by tying >_>
[12:44:29] <amee2k> ooh eeek! my voltage regulator is boiling over 0.0
[12:50:18] <amee2k> rue_bed: ooh, i just pushed the display into the wired up header while the power was turned on and i'm seeing glitches when i push it in
[12:50:48] <amee2k> pixels turning on for a split second, grouped by line or by character but more or less at random
[12:50:58] <amee2k> does that sound like the glitching you expect?
[12:51:04] <amee2k> i can make a video if that helps
[12:53:52] <Big-Al> amee2k pin 2 and 3 have the pot on em ...
[12:54:12] <Big-Al> usually it will not pop the lcd hardware with 5v
[12:54:19] <amee2k> i don't think there is any weed on my bench, no.
[12:54:32] <Big-Al> the trim pot for contrast
[12:54:50] <Big-Al> so u use the gnd and pin 3 with the wiper of the pot
[12:54:51] <amee2k> >_>
[12:54:56] <Steffanx> amee2k, so where do you store/grow your weed?
[12:55:11] * Big-Al reports amee2k to the fbi
[12:55:11] <amee2k> nowhere
[12:55:15] <amee2k> lol
[12:55:55] <amee2k> i think i'm slightly outside their jurisdiction, by maybe a few... thousand... kilometers...
[12:56:05] <amee2k> but not missed by far
[12:56:08] <Big-Al> just put 5 volts on the top of the pot ... the wiper to pin3 and gnd to the other tripot lead and to pin2 of lcd
[12:56:16] <amee2k> lol
[12:56:32] <amee2k> i already have that wired up. connecting the control bus now
[12:56:51] <Big-Al> ah so u know the pinout now ?
[12:56:59] <amee2k> i think so
[12:57:11] <Big-Al> well the pot will change the lcd color
[12:57:26] <Big-Al> so ur sure its wired right cause u know pin 2 and 3 then
[12:57:27] <amee2k> from what rue_bed told me its probably just that the pinout is mirrored because they screwed up the silkscreen and put the header on the wrong side
[12:57:39] <amee2k> i think you're thinking lsd now...
[12:57:53] <Big-Al> where do you keep your lsd ?
[12:58:00] <amee2k> under your bed
[12:58:07] * Steffanx calls the FBI
[12:58:12] <amee2k> :P
[12:58:15] <rue_mohr> whos' question was I answering?
[12:58:22] <amee2k> mine
[12:58:49] <rue_mohr> what was the natore of the question?
[12:59:22] <amee2k> rue_mohr: that glitching i was describing up there sound like you expected when you told me to bounce the supply?
[12:59:59] <amee2k> like what*
[12:59:59] <rue_mohr> yea, if you scratch the power just right, it shoudl initialise all or part of the screen enough that you can see the segments
[13:00:04] <rue_mohr> at an angle
[13:00:27] <amee2k> doesn't need an angle for that, the pixels flash pitch black for a moment
[13:00:33] <rue_mohr> take two wires and rub them a bit, no disconnections longer than about 5ms
[13:00:36] <amee2k> right when i push it into the header on the board
[13:00:56] <rue_mohr> thats different
[13:01:04] <rue_mohr> well
[13:01:06] <rue_mohr> maybe not
[13:01:12] * rue_mohr tries to recall
[13:01:17] <amee2k> o.O
[13:01:35] <rue_mohr> most of the displays I'v seen will initialize half the screen, and you can tell the controller is running
[13:02:14] <amee2k> you said to scratch the wires but the display didn't show anything. so now i wired up a header on the board according to the datasheet pinout which i believe to be accurate
[13:02:36] <amee2k> and when pushing the module into the board header with power turned on, it glitches like that
[13:02:46] <rue_mohr> ok
[13:02:58] <rue_mohr> wire it up to a controller I suspect it works
[13:03:34] <rue_mohr> remember that you have to have a long delay after powerup before initializing the screen, they use an RC oscillator and take a while to get ready
[13:03:50] <rue_mohr> !assist avr
[13:03:51] <tobbor> Possibly http://eds.dyndns.org/~ircjunk/avr
[13:04:38] <rue_mohr> hmmm
[13:05:55] <rue_mohr> encoder or potentiometer?
[13:06:06] <amee2k> the servo? encoder
[13:06:22] <rue_mohr> http://eds.dyndns.org/~ircjunk/robots/buddy_III/servo32/encoder_lcd/
[13:06:23] <rue_mohr> hmmm
[13:06:57] <amee2k> http://ompldr.org/vY2lyOQ/glitch.png << this is in the middle of a glitch. sometimes it flashes one or more lines, sometimes the left half of the display at once or a bunch of characters on the left half
[13:08:15] <impulze> isn't it great when you need some schemantics/datasheets and the only two provides of said documents are either not responding or malfunctioning?
[13:08:35] <impulze> judging by that luck i should probably not cross streets today
[13:11:10] <rue_mohr> yup those are power then
[13:11:19] <rue_mohr> amee2k, you good, connect to a microcontroller and have fun
[13:11:35] <rue_mohr> impulze, for what chip?
[13:11:36] <amee2k> :)
[13:11:44] <impulze> rue_bed: no chip, an adapter and a board
[13:11:52] <rue_mohr> ah
[13:12:37] <rue_mohr> amee2k, whats higher potential gnd or vcc?
[13:14:31] <nevdull> rue_mohr: electrons flow from higher potential to lower, so Vcc is higher and gnd is lower
[13:14:36] <rue_mohr> SO WHY IS YOUR POSITIVE RAIL ON THE BOTTOM!?
[13:16:02] <impulze> :D
[13:16:05] <nevdull> you have to keep the positive rail on the bottom otherwise when you turn your PCB over all the electrons would fall out of the top
[13:16:15] <impulze> rofl
[13:16:35] <rue_mohr> :)
[13:16:44] <nevdull> hehe
[13:18:05] <nevdull> rue: so have you started brushing back up on your good ol' asm?
[13:18:21] <rue_mohr> its not just the asm
[13:18:44] <rue_mohr> if I'm gonna use those thigns I need to write the header files that define the io addresses and all the bits for things at those addresses
[13:18:58] <rue_mohr> then I need to write libraries to do all the really basic things
[13:19:17] <dpy> ok
[13:19:21] <dpy> I fixed the glitch
[13:19:32] <rue_mohr> oh yea
[13:19:32] <dpy> I just do the PWM_LOG update from the same ISR
[13:19:34] <nevdull> depends on your platform and toolchain i suppose. with avr and gavrasm/avrasm, the .inc files are written for you
[13:19:49] <nevdull> and with avr-as you mostly just include <avr/io.h>
[13:19:54] <rue_mohr> oh I thought you meant with the 8035 and 8085 stuff
[13:20:02] <rue_mohr> eek! I'm in Avr.... oops
[13:20:08] <rue_mohr> pretend I didn't say that
[13:20:13] <nevdull> oh i didn't know you were into 8035/8085
[13:20:23] <rue_mohr> me? no, AVRS RULE
[13:20:29] * rue_mohr glances around...
[13:20:55] <nevdull> i just briefly touched on 8051 programming after silicon labs sent me a complementary C8051F700 devel board
[13:21:25] <rue_mohr> ssh, I'm playing with an 8051
[13:21:39] <rue_mohr> the serial programmable one that nxp just EOL'd
[13:21:58] <rue_mohr> straight up serial, no software req'd
[13:22:04] <rue_mohr> takes ihex files
[13:22:31] <nevdull> rue: it's a venerated instruction set, for sure. ubiquitous and widely used/available, but doesn't have the instructions-per-clock-cycle capabilities of the AVR
[13:23:00] <nevdull> ah interesting, i didn't know that
[13:23:01] <rue_mohr> but, it does have one speed advantage, parallel bus
[13:23:39] <rue_mohr> so I can affix 300 direct output ports to it and push data at them faster than I could an avr bit banging a parallel bus
[13:24:13] <rue_mohr> also faster than an avr can clock out serial to an io expander
[13:24:17] <OndraSter> to which layer should I put some silkscreen text in Eagle? I am putting them into tNames/bNames
[13:24:27] <OndraSter> as they are exported on the silkscreen
[13:24:28] <OndraSter> these layers
[13:24:36] <OndraSter> but isn't there something made for it specially?
[13:24:39] <OndraSter> like Document?
[13:24:41] <nevdull> but it's still a cisc cpu (and i turn my nose down at von neuman architectures ;)
[13:24:43] <rue_mohr> OndraSter, I thinkit depends who your sending the file to
[13:24:55] <OndraSter> rue_mohr, exporting them to GERBER anyway
[13:25:05] <rue_mohr> nevdull, the new ones are only 6 cycles/instruction, at 40 or 60Mhz...
[13:25:15] <rue_mohr> OndraSter, then I really dont know
[13:25:22] <OndraSter> I think it doesn't matter
[13:25:26] <OndraSter> as long as it is exported to the gerber
[13:25:46] <rue_mohr> OndraSter, play with the exporter
[13:26:22] <Kevin`> rue_mohr: there are avr chips with an external memory controller
[13:26:43] <rue_mohr> I know
[13:26:45] <OndraSter> WOOT, I re-run the board with iteadstudio's DRC rather default eagle
[13:26:50] <OndraSter> and exactly 0 errors
[13:27:04] <nevdull> i think there's a _tsilk and a _bsilk although i've always used tPlace i think
[13:27:27] <OndraSter> Kevin`, but you can't use it for application... the reason why I don't like harvard :( :(
[13:27:40] <nevdull> OndraSter: have you ordered from them yet/before? i just discovered iteastudio the other month and was wowed by their pcb package deals
[13:27:50] <OndraSter> nevdull, nope
[13:27:57] <OndraSter> I made only two "real" PCBs so far
[13:27:58] <OndraSter> both at home
[13:28:04] <OndraSter> now I need both layers with vias
[13:28:35] <rue_mohr> Kevin`, I have a project comming up I want to be able to run software out of ram
[13:28:41] <Kevin`> OndraSter: I was talking more about the high speed parallel io aspect
[13:28:46] <OndraSter> ah
[13:28:55] <rue_mohr> I dont think even the avrs with the memory interface can do that
[13:29:07] <OndraSter> rue_mohr, the only way how to do that with AVR was (actually two options) was that it would set some "file id" into eeprom
[13:29:10] <OndraSter> reboot, flash it
[13:29:17] <OndraSter> and reboot again to the application
[13:29:20] <OndraSter> = wearing out flash
[13:29:26] <nevdull> the xmega have a really neat dma and event routing system that offloads peripheral comms from the core
[13:29:27] <OndraSter> or, the other option, running AVR VM... on AVR!
[13:29:27] <OndraSter> lol
[13:29:36] <Kevin`> rue_mohr: yeah, better to use something like avr there (why go through the pain of anything else)
[13:29:44] <Kevin`> rue_mohr: erm, arm, not avr
[13:29:49] <OndraSter> ARM rox
[13:29:56] <rue_mohr> I dont need arm
[13:30:13] <rue_mohr> I have a simple process with a huge io set
[13:30:14] <Kevin`> rue_mohr: need? no, but there are chips that are cheap enough that it hardly matters
[13:30:16] <nevdull> arm does rox0r
[13:30:35] <OndraSter> STM32 are quite cheap and good
[13:30:49] <OndraSter> then we have atmel's at91 series, but they are not cheap
[13:30:50] <rue_mohr> and there are no DIP arms I'm aware of
[13:30:52] <OndraSter> (not sure why)
[13:30:54] <OndraSter> nope
[13:30:58] <nevdull> hell you can get an entire system (think stm32discovery) ARM7TDM for ~$10
[13:31:08] <nevdull> cortex-m3
[13:31:08] <OndraSter> yeah discovery is supercheap
[13:31:18] <rue_mohr> with a parallel bus I can connect 200 io lines to?
[13:31:22] <OndraSter> and it has built in debugger over USB... or just flashing?
[13:31:36] <Kevin`> rue_mohr: um, you want a 200 pin dip chip?
[13:31:41] <nevdull> rue: that's what logic buffer ICs are for :)
[13:31:41] <rue_mohr> no
[13:31:47] <rue_mohr> parallel bus
[13:31:52] <rue_mohr> address, data bus
[13:32:05] <rue_mohr> with a large array of io chips
[13:32:11] <Kevin`> rue_mohr: a lot of them have that. even avr has that, except for running software from it
[13:32:13] <rue_mohr> low low latency io
[13:32:36] <nevdull> the avr benefits from having a distinct data and addr bus that isn't multiplexed
[13:33:01] <rue_mohr> avrs are also awesome for 'all-in-one' applications
[13:33:08] <rue_mohr> throw one chip at it
[13:33:35] <rue_mohr> this is just a project where my requirements are different
[13:33:55] <rue_mohr> besides, sofar I cant compile for the arm I have
[13:33:57] <nevdull> yah and with 128KB on a PDIP40 or 256KB on a TQFP-48/64 it has lots of program space
[13:34:05] <nevdull> why not rue?
[13:34:21] <rue_mohr> cant find a cross compiler package for linux
[13:34:30] <nevdull> what arm core?
[13:34:32] <rue_mohr> and I dont have the io definition files
[13:34:39] <rue_mohr> hmm, its a hammer board
[13:34:50] <rue_mohr> cuttently has linux on it
[13:34:58] <nevdull> i use codesourcery lite arm for linux targeted at gnu/linux and arm eabi
[13:35:14] <nevdull> free download
[13:35:17] <nevdull> mentor.com
[13:35:45] <rue_mohr> devnull, I'll ask ya about it later
[13:35:51] <nevdull> sure thing
[13:36:04] <rue_mohr> it would be fun to get it flashing an led
[13:36:20] <nevdull> blinky.c is the quintessential arm hello_world
[13:36:31] <Kevin`> arm cross compilers aren't exactly a hard thing to find
[13:36:43] <rue_mohr> it wasn't happening for me
[13:36:51] <karlp> summon arm toolchain?
[13:36:54] <rue_mohr> besides, I think an arm is too much overkill
[13:37:03] <rue_mohr> and I cant made arm pcb's
[13:37:17] <rue_mohr> I can only go down to .05" pitch
[13:37:31] <karlp> that's fine.
[13:37:46] <nevdull> my highest pin count soldering capability is a TQFP-64
[13:37:59] <karlp> plenty of arms in tqfp 48
[13:38:05] <rue_mohr> oh
[13:38:06] <karlp> though often at 0.5mm, not 0.8mm
[13:38:18] <karlp> nxp has announced some in pdip,
[13:38:27] <karlp> there's a few in soic,
[13:38:43] <rue_mohr> I can do 1.27mm min
[13:38:45] <nevdull> yeah i saw an lpc* in pdip28 or something the other day and was shocked
[13:39:35] <karlp> 1.27mm minimum is goign to limit you in many things, not just tqfp
[13:39:47] <karlp> lots of sensors and goodies are smaller than taht.
[13:40:22] <OndraSter> http://dl.dropbox.com/u/3936936/boards2/powerbrd.png
[13:40:24] <OndraSter> my board
[13:40:26] <OndraSter> any comments? :)
[13:40:30] <OndraSter> 'tis power board
[13:40:37] <OndraSter> 5 - 18V in, 3.3V out
[13:41:22] <nevdull> OndraSter: that's a nicely laid out board
[13:41:27] <OndraSter> thanks
[13:41:47] <OndraSter> it is pretty much just reference layout
[13:41:48] <OndraSter> the power
[13:41:58] <OndraSter> the MOSFETs on the right and bottom are switching output to different lines
[13:43:06] <OndraSter> wondering how much will the MOSFET heat
[13:43:11] <OndraSter> considering that it will be doing 5A output
[13:43:19] <OndraSter> or when it will start limiting :P
[13:43:23] <OndraSter> err
[13:43:24] <OndraSter> not MOSFET
[13:43:29] <OndraSter> the controller
[13:44:51] <nevdull> what's the max watt/power?
[13:44:58] <atmega> OndraSter: the vias are very smal
[13:45:08] <OndraSter> yeah
[13:45:22] <OndraSter> that's bad? :)
[13:45:52] <atmega> I can not drill it with hand
[13:45:58] <OndraSter> neither can I
[13:46:01] <OndraSter> but iteadstudio can
[13:46:03] <OndraSter> with machine
[13:46:07] <nevdull> is it constant current?
[13:46:11] <OndraSter> nah
[13:46:17] <OndraSter> but I will be draining probably as much as possible LOL
[13:46:22] <OndraSter> it is made for 5A
[13:46:27] <OndraSter> I think there is internal limiter for 5A
[13:46:28] <nevdull> @ 3.3v?
[13:46:33] <OndraSter> yap
[13:46:46] <nevdull> that's 3.3 * 5 = watts
[13:47:01] <OndraSter> well but 3.3*5 won't be lost on the chip
[13:47:19] <OndraSter> neither the power mosfets
[13:47:44] <nevdull> is it a pwm/switching regulator?
[13:48:02] <OndraSter> ye
[13:48:15] <nevdull> that's good..at least it won't be evolving heat just for regulation
[13:48:19] <OndraSter> yap
[13:48:22] <OndraSter> TPS54527
[13:48:25] <OndraSter> TSP54527?
[13:48:28] <OndraSter> one of those names
[13:48:38] <OndraSter> from TI
[13:48:43] <OndraSter> they are quite expensive
[13:48:50] <nevdull> yah i got a TPS5420 as a sample the other day from ti
[13:48:58] <OndraSter> I got them as samples too :P
[13:49:02] <OndraSter> 5 pieces, nothing else
[13:49:04] <nevdull> gotta love ti
[13:49:05] <OndraSter> I even filled out "student"
[13:49:12] <OndraSter> it came with FedEx
[13:49:17] <OndraSter> 36 hours after "ordering" the samples
[13:49:22] <OndraSter> to the other side of the world :o)
[13:49:26] <OndraSter> gotta love TI :)
[13:49:41] <nevdull> yeah, i fill my sample cart up with the max 5 items @ 5/ea/item about every 2-3 weeks from ti ;)
[13:50:07] <OndraSter> wow
[13:50:23] <OndraSter> I didn't want to look like somebody who wants to sell it...
[13:50:27] <OndraSter> so I grabbed just one chip :)
[13:50:37] <nevdull> i was even able to get several nice MSP430 MCUs from them
[13:50:43] <OndraSter> yeah
[13:50:45] <OndraSter> they sample 430s
[13:51:04] <OndraSter> I might actually do next sample order at Analog Devices
[13:51:10] <OndraSter> already sampled from there like year ago
[13:51:11] <OndraSter> some ADCs
[13:51:17] <OndraSter> now I want DDS and opamp :)
[13:51:18] <nevdull> i just got a sample order from maxim yesterday
[13:51:19] <OndraSter> and digital pots
[13:51:26] <OndraSter> yeah, I got from Maxim about 2 months ago
[13:51:39] <OndraSter> 5x DS18B20 and 3x 20Kb EEPROM 1wire
[13:52:06] <OndraSter> afk 20 mins
[13:52:49] <nevdull> i like maxim's to-92 package silicon serial number ds2401
[13:53:01] <rue_mohr> ok I fixed the phone, but if it bursts into flame I didn't touch it
[13:54:06] * nevdull makes a mental note not to send an SMS message to rue's phone
[13:55:39] <rue_mohr> its a land line, that would be an interesting asterisk trick
[13:56:06] <nevdull> SMS-via-carrier-pidgeon
[13:56:09] <rue_mohr> I suppose call display information can happen anytime on hook
[13:56:24] <rue_mohr> I have a jammer, two cats
[13:56:42] <nevdull> haha
[14:01:58] <_abc_> rue_mohr: umm call display is supposed to happen between 1st and 2nd ring
[14:05:18] <rue_mohr> oops
[14:18:56] <OndraSter> baack
[14:19:04] <OndraSter> now, let's see if I can drop some pins from the other board
[14:20:12] <OndraSter> it is hard math
[14:20:13] <OndraSter> :P
[14:20:27] <amee2k> rue_mohr: Vcc is +5V, why?
[14:20:47] <amee2k> rue_mohr: i'd say positive ground in a digital circuit would be mildly unusual, no?
[14:21:08] <OndraSter> http://dl.dropbox.com/u/3936936/boards2/ledbrd.png
[14:21:12] <OndraSter> 'tis my LED board
[14:22:16] <OndraSter> now, if I have there 48 outputs and I have 4 boards in total, that is 192 wires (duh)
[14:22:39] <OndraSter> now, if each LED driver board has 48 bits and I have 4 boards, that makes only 1 output per one bit @ driver
[14:22:40] <OndraSter> oka
[14:24:31] <amee2k> OndraSter: what is that board for?
[14:24:43] <amee2k> ledbrd.png
[14:24:43] <OndraSter> this is holder for 3x2 LED matrices
[14:24:58] <OndraSter> with connected together column and row lines
[14:25:22] <amee2k> "3x2"?
[14:25:30] <OndraSter> yes
[14:25:34] <amee2k> that looks like a fairly large board for only 6 LEDs
[14:25:41] <OndraSter> 6 LED matrices*
[14:25:54] <OndraSter> each matrix is 3x3cm
[14:26:13] <amee2k> maybe i'm too dumb but.... where are the leds on that??
[14:26:32] <atmega> OndraSter: 3 x 3 x 3 LED Board = 27 LEDs
[14:26:42] <OndraSter> http://www.ebay.com/itm/25-LED-Dot-Matrix-24pin-8x8-3mm-Red-Green-Common-Anode-/250953666745?pt=LH_DefaultDomain_0&hash=item3a6e0110b9
[14:26:44] <OndraSter> here are the LEDs
[14:26:56] <amee2k> no, i mean where on the board
[14:27:00] <amee2k> all i can see are traces
[14:27:01] <OndraSter> uh?
[14:27:09] <OndraSter> yes
[14:27:12] <amee2k> ooh
[14:27:14] <OndraSter> and there are 12 rows
[14:27:15] <OndraSter> of pins
[14:27:20] <amee2k> now i see it
[14:27:20] <OndraSter> and into those I will pop these suckers
[14:27:23] <amee2k> >_>
[14:27:25] <OndraSter> :)
[14:28:01] <atmega> good price
[14:28:08] <OndraSter> yeah
[14:28:10] <OndraSter> awesome price
[14:28:13] <OndraSter> wish they were RGB
[14:28:17] <OndraSter> but RGB = 10 times more :(
[14:28:19] <OndraSter> oruce
[14:28:43] <atmega> you need 3 times more lines
[14:28:50] <atmega> for rgb
[14:29:06] <OndraSter> yes
[14:29:08] <amee2k> not really
[14:29:20] <OndraSter> you actually need 1/3rd more columns
[14:29:30] <OndraSter> (1/2 of current number of columns)
[14:29:33] <amee2k> you need 50% more
[14:29:54] <amee2k> and that doesn't include the ground traces so actually less than 50%
[14:30:07] <atmega> no yes ... this is a rg- (without b) LED
[14:30:36] <amee2k> yeah
[14:30:45] <atmega> it's cool too
[14:30:53] <amee2k> the - traces as well as the R and G stay the same though
[14:31:15] <amee2k> so only <50% more for adding B
[14:31:18] <OndraSter> there will be also third columnt per pixel
[14:31:23] <OndraSter> exactly 50% more
[14:31:30] <OndraSter> before 2 columns, now 3 columns
[14:31:33] <OndraSter> but the common row would stay
[14:31:38] <OndraSter> depends on how do you count it
[14:31:42] <OndraSter> if just columns or whole board
[14:31:48] <amee2k> well, 50% more columns, but ground traces are still shared
[14:31:56] <OndraSter> yes
[14:31:59] <OndraSter> then it is <50%
[14:32:29] <amee2k> >_>
[14:44:10] <lidenbrock> hi. What would be a less expensive GSM Modem I could interface with any avr microcontroller?
[14:45:55] <_abc_> lidenbrock: still on that page?
[14:46:01] <_abc_> lidenbrock: search a little
[14:47:25] <OndraSter> I had hard times finding "cheap" and usable SPI/UART/... GSM modem
[14:47:52] <_abc_> heh
[14:48:27] <lidenbrock> OndraSter: any recommendation?
[14:48:40] <OndraSter> like I said, I haven't found anything usable :D
[14:48:52] <lidenbrock> hum
[14:48:52] <lidenbrock> k
[14:49:04] <lidenbrock> _abc_: I'm going to buy an nokia3310
[14:49:23] <lidenbrock> but I want to use something newer XD
[14:49:34] <lidenbrock> and I didn't find anything
[14:50:17] <lidenbrock> _abc_: is it possible to use a 3G modem?
[14:51:27] <_abc_> You mean a usb 3G modem?!
[14:52:12] <lidenbrock> yeah
[14:52:14] <lidenbrock> LOL
[14:52:33] <lidenbrock> by the way you reacted, the answer is NO!
[14:53:52] <_abc_> lidenbrock: what do you call 'cheap'?
[14:54:17] <_abc_> Cheapest I can see is dual band for about 80 Euro
[14:54:48] <_abc_> http://www.farnell.com/datasheets/650990.pdf this is the datasheet
[14:54:53] <_abc_> How cheap do you want?!
[14:55:09] <_abc_> If you buy quantity from China it is cheaper, down to $20-40
[14:55:31] <lidenbrock> that's cheap for me
[14:55:40] <lidenbrock> $50-80
[14:57:05] <amee2k> okay, this doesn't make any sense >_<
[14:57:24] <amee2k> dinner first
[14:57:26] <_abc_> lidenbrock: So look at Farnell in Europe and at Mouser and say Digikey and Newark in USA
[14:57:29] <_abc_> lidenbrock: Where are you?
[14:57:33] <amee2k> and then i'm gonna have a circuit analysis question
[14:58:00] <_abc_> aiee Brazil
[14:58:14] <_abc_> lidenbrock: Sounds like you're at the wrong end of a very long supply line?
[15:01:05] <_abc_> http://eu.mouser.com/Embedded-Solutions/RF-Wireless-Modules/_/N-6f8ws?Keyword=gsm+gprs&FS=True&Ns=Pricing|0 lidenbrock cheapest is 55€ or so
[15:01:14] <lidenbrock> yeah
[15:01:15] <lidenbrock> :P
[15:02:07] <_abc_> Be sure to get the kind that works in your country. Multibands are expensive, so you will get a dual band, and it must fit your country's gsm allocation scheme.
[15:02:46] <lidenbrock> k
[15:02:55] <lidenbrock> thanks, _abc_
[15:04:00] <amee2k> isn't everything these days triband except for the 5$ handys they sell for 50$ at the superstore?
[15:05:38] <_abc_> http://institutosabin.org.br/site/wp-admin/css/arduino-gsm-projects ah he left
[15:05:56] <_abc_> amee2k: not quite but close enough
[15:08:00] <amee2k> >_>
[15:08:33] <_abc_> One reason for the 'tri' is the crappy microwave filter which is unable to separate 1800 from 1900 MHz
[15:08:43] <_abc_> So you get 'tri' band for free, quasi
[15:09:06] <_abc_> What you don't get is built in operation for the required digital modes, and that is sometimes just a software thing.
[15:09:12] <amee2k> i don't think thats what she said >_<
[15:45:49] <amee2k> okay, lemme make a drawing then here goes my circuit analysis question!
[16:04:46] <amee2k> http://ompldr.org/vY2l1eQ/divider.png << this is a voltage divider with indicated labels. what i want to calculate is Vout, given Uin, R1, R2 and Iout (where I is significant compared to Iin and Ignd, so i can't cut corners assuming it is zero)
[16:06:00] <amee2k> i've analysed the divider with three different approaches. all three results agree, and they are accurate for Iout=0A, but they're consistently 10% over the results of this spice simulation
[16:07:47] <amee2k> the results i've got are a) Vout = (Vin/R2 - Iout) / (1/R1 + 1/R2) b) Vout = (Vin/R2 - Iout) * R1 / (R1/R2 + 1) c) Vout = Vin*r2/(R1+R2) + R1*R2/(R1+R2) * Iout
[16:08:31] <amee2k> the last one is the result of calculating the thevenin equivalent circuit by assuming the two terminals are Vout and ground
[16:08:55] <nevdull> Vout = Vin(R2/R1+R2)
[16:09:21] <amee2k> the first two are derieved from a bunch of basic formulas, namely the two resistor currents given Uin and Uout and the sum of all three currents
[16:09:58] <amee2k> nevdull: where is Iout in that formula?
[16:11:01] <amee2k> well, the obvious question is how do i go about analysing that circuit? and where do i keep going wrong?
[16:11:45] <nevdull> well, that's really a derivation of: V1 = IR1 = (Vin/R1+R2)*R1 and V2 = IR2 = (Vin/R1+R2)*R2 when I is negligible
[16:12:23] <amee2k> then why did i say in my first line that i'm assuming Iout is not neglegible?
[16:12:40] <nevdull> it doesn't take into consideration bleeder current either
[16:12:53] <Kevin`> amee2k: why not add a buffer and make iout negligable?
[16:13:32] <amee2k> Kevin`: because i'm assuming that it isn't for the purpose of the analysis
[16:14:01] <atmega> this two german guys: negligible
[16:14:16] <Kevin`> engineers are masochists.
[16:14:31] <amee2k> twss
[16:14:31] <nevdull> the bleeder current is such that you select R2 so that I2 is 10% of the desiered load current or Iout for you
[16:14:56] <amee2k> o.O
[16:15:05] <nevdull> i wonder if that 10% bleeder current factors into what you're losing in your analysis
[16:15:26] <amee2k> did i ask for a guideline on how to select resistor values based on quiescent current?
[16:15:40] <nevdull> you're an irritable fellow
[16:16:02] <amee2k> you're missing the point of my question by several lightyears :P
[16:16:33] <nevdull> then my apologies
[16:17:55] <amee2k> i want to analyse the circuit given the assumption that the output current is not neglegible. i do not want to select resistor values or buffer circuits for a concrete application of a voltage divider
[16:21:59] <amee2k> now, any ideas about the question?
[16:22:48] <atmega> you want to calculate the outputvoltage in relation to the output current?
[16:23:44] <amee2k> yes!
[16:27:45] <amee2k> http://ompldr.org/vY2l2ag/CIMG8924c.jpeg << this is my analysis from last night... results a) and b) are on the left page next to the (X), the thevenin equivalent calculation is on the bottom right... (ignore the power analyser board draft ont he right, it has nothing to do with the voltage divider!!!)
[16:31:42] <nevdull> since the voltage divider is a series circuit, the currents thru each resistor are equal to the total current, so if i understand what you're asking for, you can calculate the voltage drops across each resistor separately as (using your nomenclature) V1 = Iin * R2 and V2 = Ignd * R1 and V2 should be your Vout?
[16:32:51] <amee2k> nevdull: that assumes that my Iout is zero, or at least can be approximated as zero. which contradicts the initial assumption i've made
[16:33:57] <amee2k> I(R1) = Ignd and I(R2) = Iin are not equal. Iin = Ignd + Iout holds
[16:38:15] <nevdull> do you know your load resistance?
[16:38:51] <amee2k> no
[16:39:05] <amee2k> only that it will draw a given current
[16:39:35] <amee2k> i'm making no other assumptions
[16:39:55] <atmega> the current on i_1 is negativ :)
[16:40:16] <nevdull> wouldn't you need to know Rload for Iin(R2) = Ign(R1) + Iout(Rload)?
[16:40:40] <amee2k> i don't think so
[16:41:10] <amee2k> i know the potentials of all three terminals of the divider, and the currents entering each terminal
[16:41:34] <amee2k> (well, in variables. Uout is not known by value of course)
[16:42:28] <amee2k> i shouldn't have to make any assumptions about the load, same as i don't need to make any about where the input voltage comes from
[16:43:10] <atmega> I out is known?
[16:43:19] <amee2k> yes
[16:43:53] <amee2k> known are: Uin, R1, R2, Iout. ground potential is 0V
[16:44:32] <amee2k> nevdull: you can do Rload = Uout/Iout if that helps with the calculation, but the value won't be known. you'd have to substitute it at some point and resolve to Uout
[16:47:39] <nevdull> would't changes in Rload change Vout (assuming no constant voltage by tweaking Iout with fluctuations in Rload)?
[16:48:04] * rue_mohr whispers "ground on the bottom..."
[16:48:40] <amee2k> Iout is constant. it is just an operating point analysis (any other kind wouldn't make much sense anyway i think)
[16:49:02] <amee2k> with all variables being constant, the result should be constant too
[16:52:40] <nevdull> i see, so does Iout = Vout/Rload (for whatever value of Rload you've given it)?
[16:53:17] <amee2k> well, since Rload is defined in terms of Iout and Vout, yes
[18:32:04] <jadew> any idea what's the cheappest LCD's I can find? I need to display 3 digits on them and I need 4
[18:32:40] <jadew> so buying 4 x $5+ for such a simple thing doesn't sound good
[18:35:51] <rue_bed> jadew, has to be new?
[18:36:08] <jadew> no
[18:36:38] <jadew> is there a second hand store around?
[18:41:39] <rue_bed> do you mind driving your own 7 segment displays?
[18:42:12] <jadew> yeah, was trying to avoid that since it would kind of defeat the purpose in terms of price
[18:43:42] <jadew> tbh, what I really need (but it seems there's no such thing available) is a bunch of LCDs like the ones used in old wrist watches (the crappy ones)
[18:44:19] <rue_bed> do you have a lcoal dollar store?
[18:44:27] <rue_bed> calculators are ~$1
[18:44:45] <rue_bed> I dont think thats hard to drive
[18:44:55] <rue_bed> esp just 3 digits
[18:45:51] <jadew> true, I'll have to find some that are already connected to a PCB tho
[18:45:57] <Landon> /win 2
[18:46:00] <Landon> whoops
[18:46:01] <rue_bed> no
[18:46:16] <rue_bed> you can use the zebra strip to your own pcb
[18:46:29] <jadew> ah, that's right
[18:46:51] <rue_bed> the crystals go about 60hz ac to keep them dark
[18:47:00] <jadew> hmm, just realized I took appart a stereo a few weeks ago, from my old car
[18:47:10] <rue_bed> its like normal scanning, but you reverse the polaity every 1/60th of a second
[18:47:15] <jadew> it had a nice long graphic LCD, I could use that, since it's really long
[18:47:27] <jadew> but I'm not sure I can drive it
[18:47:32] <grummund> amee2k: Vout = (R1 x (Vin - (R2 x Iout))) / (R1 + R2)
[18:47:46] <rue_bed> jadew, hmm
[18:48:06] <rue_bed> I'm trying to think if I have a display around I can do a tutorial for you with
[18:49:13] * grummund sleep, afk.
[18:49:28] <atmega> grummund: U_out = R_1 * (U_1 / (R_1 + R_2)) - ((R1*R2)/(R1+R2))*I_out
[18:49:43] <jadew> rue_bed, that would be neat, thank you
[18:51:25] <jadew> you don't have to go trough the trouble tho
[18:51:55] <jadew> (too much of an electronics noob to be worth it)
[18:53:04] <grummund> i prefer my way.
[18:53:47] <rue_mohr> jadew, you drive it right off the avr
[18:53:57] <rue_mohr> you need 7 lines for segments and 3 lines for rows
[18:54:07] <jadew> so 10 pins
[18:54:19] <rue_mohr> Do you wish to continue? (Y/n):
[18:54:22] <jadew> Y
[18:54:26] <rue_mohr> heh
[18:54:29] <jadew> :D
[18:54:45] <rue_mohr> ok, do you have a display from a calculator or clock to use?
[18:54:54] <jadew> most likely
[18:55:02] <rue_mohr> pls confirm
[18:55:23] <jadew> I can take one appart if I don't, but IIRC I have a bag full of old watches
[18:55:31] <jadew> (small bag)
[18:55:51] <rue_mohr> ok say when ready
[18:56:04] <jadew> oh, you want me to grab one
[18:56:06] <jadew> hold on
[18:56:37] <atmega> if you use a normal LCD (without driver chip) then you must be carefull
[18:57:05] <Kevin`> if you just stick some capacitors in series with the segments it'll become kind of hard to damage
[18:57:18] <jadew> it's gonna take a while so before I go digging, I'll tell you what I know, to save some time and eventually the digging part
[18:57:32] <rue_mohr> I'll wait
[18:57:49] <jadew> I know that if you put some current on y row and x column the dot will light up and I understand the scanning concept
[18:58:01] <jadew> you don't want to light up other cells as well
[18:58:15] <jadew> so you light them up one at a time
[18:58:40] <jadew> correct?
[18:59:01] <atmega> we talkk about liquid crystal displays ?
[18:59:06] <jadew> yeah
[18:59:39] <atmega> then the integral of the voltage at the pins must be zero
[19:00:34] <jadew> like... to prevent them from lighting up randomly?
[19:01:19] <jadew> (my technical vocabulary sucks when it comes to english)
[19:01:44] <Kevin`> jadew: to prevent damage. don't apply dc bias to them
[19:02:03] <atmega> there is a black fluid between two metal platet glas panes ...
[19:02:15] <jadew> rue_bed, do you still want me to look for a LCD? I didn't want you to waste time on that issue
[19:02:52] <rue_shop> what?
[19:03:14] <rue_shop> I thought I had some lcd's in the VFD drawr...
[19:03:25] <rue_shop> none in the led display drawr...
[19:05:06] <atmega> the little pieces in the fluid are moving in a special direction, you can create the +1V / +1V with a capacitor, then you only must create 0V -> 2V -> 0V and you get -1 -> 1 -> -1 ...
[19:05:16] <rue_shop> aha, I have some lonley panels in the lcd box...
[19:05:32] <Tom_itx> i have a couple 1 x 8
[19:05:48] <rue_shop> atmega, pff, you square wave 5V across them and they will close
[19:06:12] <Roklobsta> lcds have a balck fluid? are you sure?
[19:06:14] <atmega> close?
[19:06:49] <Roklobsta> not even
[19:06:50] <atmega> you can say color filter
[19:06:59] <rue_shop> the liquid crystals act like a light polarizer when you put AC across them, they works with the other two built in polarizers to block the light
[19:07:23] <jadew> rue_shop, my real question about driving LCDs would be: can you drive them using less pins than (rows + cols) or do not?
[19:07:43] <Roklobsta> if you want to see the polarisation effect wear a pair of polarised sunglasses and rotate your head around to see the LCD image disappear and reappear
[19:07:56] <Tom_itx> like magic
[19:08:05] <rue_shop> its just rows + columns
[19:08:20] <Roklobsta> it's a quick way to tell if a TV is plasma or lcd
[19:08:36] <Roklobsta> plasma doesn't get affected by polariused sunglasses
[19:08:51] <rue_shop> I found what appears to be a calculator display, mine happens to have wires crimped to it, tell me when you have something to work with
[19:08:58] <jadew> I had a LCD when I was a kid (probably still do) on which I actually was able to see the cells turn white (once I removed the polarized plastic
[19:09:46] <jadew> rue_shop, hold on, you probably lost part of what I said, I'm gonna paste in private to avoid spam
[19:09:54] <Roklobsta> yeah if you turn the filter around you can invert the polarisation effect.
[19:11:25] <jadew> rue_shop, so, does that save me from digging up for LCDs?
[19:13:24] <atmega> jadew: can you use a normal HD44780 16 x 2 LC-Display ?
[19:13:59] <jadew> atmega, I want to keep this ones as cheap as possible and 16x2 is too big for my needs
[19:14:03] <amee2k> grummund: oooh, thanks! that cleared up at least one thing. its the same result as my thevenin equivalent circuit, except that i confused the resistors and have R2 in place of your first R1 :)
[19:14:27] <jadew> I want to build a power source and display the current consumption above each plug
[19:14:55] <jadew> so 3/4 chars should be enough, anything bigger and it wouldn't fit
[19:15:31] <atmega> okay ...
[19:15:42] <amee2k> grummund: i know the first (other) analysis i made looks kinda confusing, but do you have any educated guesses where i could have gone wrong?
[19:16:17] <Posterdati> hi
[19:16:27] <atmega> hi
[19:16:27] <tobbor> atmega! like, totally tell us about the project!
[19:16:56] <CapnKernel1> !seen tobbor
[19:16:56] <tobbor> tobbor is here
[19:17:03] <CapnKernel1> Yay, tobbor is here!
[19:17:20] <amee2k> tobbor \o/
[19:17:25] <amee2k> the little son of a 555
[19:19:44] <rue_shop> jadew, hmm, mine has a problem it takes almost 15V to trigger
[19:19:49] <rue_shop> :/
[19:20:07] <rue_shop> the small calc ones usually trigger on much lower voltages
[19:20:18] <rue_shop> jadew, did you find a display?
[19:20:41] <jadew> no, didn't go trough the boxes, did you read what I posted on private?
[19:20:57] <rue_shop> yea
[19:21:06] <rue_shop> lcd's are really slow
[19:21:12] <jadew> I don't think I can search for it right now to be honest, there are lots of dusty boxes and I don't know exactly where it is
[19:21:13] <rue_shop> scanning them is no big deal
[19:21:28] <jadew> can you explain the rest with out having a lcd in front of me?
[19:21:32] <jadew> I have a good imagination
[19:21:36] <rue_shop> jadew, ok, find one this week and get back to me
[19:21:41] <jadew> ok
[19:21:52] <jadew> thank you
[19:22:17] <rue_shop> ok, if you make a avr do ~30 to 60Hz square wave, two wires, and go thru all the pins, work out what the segment and column connections are
[19:23:07] <rue_shop> the trick to running them is to produce AC across just the segments you want blacked out
[19:23:41] <rue_shop> which I suppose does get a bit trickey when you have more than 1 set of segments to operate
[19:24:00] <rue_shop> which is prolly why they use tri-state on the official drivers
[19:24:05] <rue_shop> you can do it with an avr tho
[19:24:19] <rue_shop> do 1 digit for now
[19:24:44] <jadew> I'm not sure I understand why I need the square wave
[19:25:08] <jadew> won't I connect an individual pin of the avr to an individual pin of the lcd?
[19:25:32] <rue_shop> basically, flip the column back and forth at about 30 to 60hz, and have the segments you want always in the opposite state of the column output, the segments you dont want triggered the same polarity as the column wire
[19:25:42] <rue_shop> because the segments black out when you put AC across them
[19:26:18] <rue_shop> you have to flip them about 30 to 60 times/sec to keep them black
[19:26:30] <rue_shop> otherwise they just flash black
[19:26:31] <jadew> I see
[19:26:54] <atmega> if one pin is on high for a long time you damage the segment and the fluid ... it is like electrolysis
[19:27:04] <rue_shop> pff
[19:27:08] <jadew> makes sense
[19:27:14] <rue_shop> yea the screen prolly wont last 20 yrs
[19:27:57] <rue_shop> but it'll work and you can bragg that you did it
[19:28:02] <nevdull> jadew: newhaven makes a really clear 1x8 LCD: NHD-0108CZ-RN-GBW @ $7.55
[19:28:15] <rue_shop> he wait even $5 per screen was too much
[19:28:19] <atmega> @ amee2k today I am on your ignore-list ?
[19:28:20] <rue_shop> ?
[19:28:26] <rue_shop> he said even $5 per screen was too much
[19:28:31] <nevdull> oh gotcha
[19:28:36] <jadew> and that's too big
[19:28:50] <amee2k> atmega: hu?
[19:29:00] <jadew> I will use a bigger screen too, but I don't want to display all the data on that one, it's counter intuitive
[19:29:03] <amee2k> not really
[19:29:07] <amee2k> did i miss something?
[19:29:33] <atmega> I want to show you the TFT - Video?
[19:29:39] <amee2k> ok
[19:29:48] <amee2k> :)
[19:32:42] <rue_shop> jadew, to drive more than one digit, you may need to use 3 voltage levels, but you can still do that with an avr, the trick is to put a voltage divider on each pin to the lcd that defaults the lcd pin to 2.5V, I can tell you more later
[19:32:53] <CapnKernel1> jadew: Some ATmegas have LCD controllers inbuilt. I think the ATmega169 is one of them.
[19:33:11] <rue_shop> jadew, if I dont hear from you I'll try to ask on about wednesday if you found a screen
[19:33:23] <rue_shop> I can go to the dollar store and get a calculator
[19:33:39] <amee2k> did i miss the link? i didn't see it yet
[19:33:47] <amee2k> (to the tft video, i mean)
[19:33:52] <jadew> rue_shop, I'll be around, I'll look for one tomorrow, after work
[19:34:00] <rue_shop> cool
[19:34:14] <nevdull> jadew: ebay sometimes sells some monochrome grey screen lcds from nokia phones on the cheap
[19:34:24] <jadew> CapnKernel1, will look into it
[19:34:33] <rue_shop> I'm the only person I know to do my own VFD driver, it would be cool to help you be the first to drive your own lcd panel
[19:34:37] <atmega> here is the option "send file" in my irc-app
[19:36:07] <amee2k> o.O
[19:36:53] <jadew> I'm off to bed for now
[19:36:56] <jadew> thank you for the info
[19:37:12] * Valen wants to make a vfd
[19:37:29] <Valen> oh hang on you mean vacuume flourescent display
[19:37:35] <Valen> or variable frequency drive
[19:37:53] * CapnKernel1 is sick of fireworks
[19:38:36] <CapnKernel1> A week after Chinese New Year and everyone's *still* letting 'em off. 9am is just too early for fireworks!
[19:42:14] <rue_shop> this screen is completely stupid
[19:42:18] <rue_shop> they use 4 segments
[19:42:38] <rue_shop> 7 with an underscore
[19:42:45] <rue_shop> and the other 4 segments
[19:43:04] <rue_shop> so each 7 segment is really 2 columns
[19:43:10] <rue_shop> thats just stupid
[19:44:18] <rue_shop> so the display is 16 digit, as 32x4
[19:45:33] <rue_shop> thats as stupid as the 447880 I have where the first 8 and the last 8 characters are "on different lines"
[19:46:26] <Tom_itx> so rue_shop, what did you finish while i was afk?
[19:47:26] <Valen> I want to make a VFD to run ceiling fans without them humming
[19:47:56] <Tom_itx> that would be cool in more than one respect
[20:02:34] <Valen> rather
[20:04:04] <Valen> kinda scary though
[20:04:09] <Valen> and scary scary maths
[20:04:33] <izua> hm.
[20:04:36] <izua> this is odd.
[20:04:43] <izua> so i had a m644 lying around
[20:05:06] <izua> decided to see what's wrong with it, wrote a led flasher, it can download just fine, but nothing happens, regardless of the pin/port
[20:05:17] <Valen> clock running?
[20:05:26] <izua> could it be programmed otherwise?
[20:05:36] <Valen> clock fuses set?
[20:05:42] <izua> could it be programmed otherwise?
[20:05:57] <izua> it seems that a port is always stuck on 0xFF
[20:06:05] <izua> and everything else on 0x00
[20:07:25] <izua> if you don't have a clock - with all that it implies, right fuses, signal or crystal present - you can't download a program over spi
[20:07:40] <Valen> spi provides its own clock
[20:07:52] <Valen> often you can program without xtal
[20:08:06] <izua> yeah
[20:08:14] <izua> but that clock doesn't clock the flash
[20:08:29] <izua> try removing the crystal and see what signature you'll get from the chip
[20:47:54] <inflex> morn all
[20:47:56] <inflex> well, afternoon
[21:16:41] <Tom_itx> lo inflex
[21:22:06] <inflex> how's things Tom_itx ?
[21:28:17] <Tom_itx> just back from a trip
[21:28:21] <Tom_itx> kinda tired
[22:45:53] <inflex> ah okay - hope the trip was productive
[22:46:44] <Tom_itx> relaxing
[22:46:49] <Tom_itx> except the drive
[22:48:15] <Tom_itx> supposedly my boards are here
[22:48:21] <Tom_itx> i was gone so i didn't get em
[22:48:27] <inflex> oh good - always nice to have presents waiting :)
[22:48:57] <Tom_itx> hope they don't send em back before i can check