|
ANIME AKBAR posted:I found a couple dozen results on digikey. Anything from panasonic or nichicon should be good. Here's one from nichicon's HE series: Thanks for the help, I tried looking through their site earlier and just couldn't seem to find those.
|
#
?
Apr 20, 2009 03:03
|
|
|
|
| # ? May 8, 2024 18:11 |
|
|
I've been designing a simple PCB that is pretty much a breakout for 8 CMOS4066 chips and I've run into a few little issues. Firstly, battery power. If I have dual supply 4066 ICs can I pass the positive and negative leads from a CR2032 or 2 AAs to power them? Will -3V on the enable lines be logic low? I haven't had a chance to test this since I don't have any dual supply 4066 ICs lying around. I don't really have 0V on my board, I can get it from elsewhere but it would be nice if I could just use the negative terminal from the battery. Next, how can I calculate how long I expect the battery to last if the battery is just feeding these 4066ICs? The enable lines will be pulled down to -3V with 10k resistors 99% of the time, I don't know if that changes anything. On most of the datasheets I look at I can only find the leakage current and quiescent current (not really sure what that is) and they are usually around 1uA for a 3V supply. To calculate battery life in hours should I just do battery capacity / (2uA (for good measure) * 8)? I don't want to put in a power switch and I just want this thing to last a long time like a remote control. My last issue is with finding connectors. For each set of 4 ICs I have two 16 pin headers (16x2), what better options do I have for connected wires other than soldering them directly or hot gluing them into a female header? I found this on digikey http://search.digikey.com/scripts/DkSearch/dksus.dll?FullDetail&name=A28757-ND#usewithchildren but I have no idea how to use it. I suppose I need a crimper and plugs for inside? I'm also wondering if putting two of these right on top of each other will be a space issue since they are keyed.
|
|
#
?
Apr 25, 2009 17:20
|
|
|
I know next to nothing about battery power so I'd be interested in some information on that as well. I am under the impression that you generally want to use a boost convertor like the MAX756 because batteries don't provide a consistent voltage over the course of their life. I guess that doesn't really matter if your ICs have a wide supply range, though.
|
|
#
?
Apr 25, 2009 17:31
|
|
|
The ICs I'm looking at have a range of +- 2-12V. If the batteries last long enough, the voltage drop from the battery running out over time should be negligible. I guess what I'm trying to say is that I want to be a cheap rear end and not use a DC-DC converter at all.
|
|
#
?
Apr 25, 2009 18:35
|
|
|
Scarboy posted:I've been designing a simple PCB that is pretty much a breakout for 8 CMOS4066 chips and I've run into a few little issues. Is there such a thing as a dual supply 4066? Got a datasheet link? But if so, what you're proposing should work. Actually, a schematic might be helpful here. Do you need or have a virtual ground? Quiescent current is how much current the chip draws when it's not switching. The switching current (at least in the 4066 datasheet I'm looking at) is calculated as part of the total supply current, and is dependent on the switching frequency. If you're not going to be switching very fast or very often, it won't matter. It's microamps per kilohertz. Are you already stuck with this 2x16 pin header design? You should be able to get a 2x16 header and ribbon cable although I'm having trouble finding one on digikey.
|
|
#
?
Apr 26, 2009 00:03
|
|
|
Mill Town posted:Is there such a thing as a dual supply 4066? Got a datasheet link? But if so, what you're proposing should work. Actually, a schematic might be helpful here. Do you need or have a virtual ground? This was the dual supply 4066 I was looking at http://www.onsemi.com/pub_link/Collateral/MC74HC4066A-D.PDF Right now I don't have a virtual ground, and if the IC works how I think it does, I don't think I need it. Nothing is stuck for now, I'm still working on the design. I was looking through digikey/mouser for those ribbon cables and header and man is it confusing. Sometimes I think I'm looking at what I need and I have no idea what I'm getting.
|
|
#
?
Apr 26, 2009 00:21
|
|
|
I have an electrical question, and this looks like the best place to ask it, so here it goes. This is part of a power supply that was assigned for my class to work on and I've got it down to this. I need to find the voltage going into the voltage regulator from the emitter, but I don't know how to continue. I'm pretty sure the voltage across the resistor is 27.4 V and the zener diode clamps the voltage at B as 22, but I don't know what to do now. The transistor's data sheet: http://www.datasheetcatalog.org/datasheet/mospec/TIP115.pdf The voltage regulator's (not really important): http://www.datasheetarchive.com/pdf-datasheets/Datasheets-21/DSA-413025.pdf
|
|
#
?
Apr 26, 2009 02:53
|
|
|
Sammus posted:I have an electrical question, and this looks like the best place to ask it, so here it goes. The easiest way to answer this is to simply assume the transistor is on, and then look at the datasheet:  You are right about the zener - it sets the base to 22V. The Vbe is approximately 2.8 V according to the datasheet, meaning that Ve should be 22 - 2.8 or about 19.2 V.
|
|
#
?
Apr 26, 2009 04:35
|
|
|
yeah i posted a similar circuit a few pages back, and someone was dumb enough to actually build it, you can have a look at that one
Bush Ant fucked around with this message at 12:17 on Apr 26, 2009 |
|
#
?
Apr 26, 2009 11:57
|
|
|
Bush Ant posted:yeah i posted a similar circuit a few pages back, and someone was dumb enough to actually build it, you can have a look at that one If I had built a circuit like that (god help me), I would have used a weaker input voltage divider, and tolerated a higher capacitor voltage ripple, as it's more efficient to maintain a lower quiescent current and even it out with a linear regulator. If I was feeling particularly generous towards the power system, I'd put in a full bridge rectifier as well...
|
|
#
?
Apr 26, 2009 12:56
|
|
|
Bush Ant posted:yeah i posted a similar circuit a few pages back, and someone was dumb enough to actually build it, you can have a look at that one How embarrassing for you, I'm standing right here...
|
|
#
?
Apr 26, 2009 14:36
|
|
|
Bush Ant posted:yeah i posted a similar circuit a few pages back, and someone was Fixed.
|
|
#
?
Apr 27, 2009 16:51
|
|
|
This may be a bit of a long shot, but do any of you know how gamma correction is done on a TFT/LCD at at very low hardware level? I know what gamma correction is for, but not quite how it's implemented in hardware. I have a raw LCD panel that needs 14 gamma voltage levels between GND and AVDD, all set by a big chain of resistors. I'm pretty sure the resistors are set by trial and error to iron out the idiosyncrasies in the gamma correction of that particular panel model, but I haven't been able to find any references as to how these voltages are used by the panel. I hope that makes sense.
|
|
#
?
Apr 27, 2009 21:14
|
|
|
Those voltages will be used by a gamma buffer, a multi-channel controllable output voltage buffer. I think that level goes to set the total output in each section in combination with the RGB control. If it's just a chain of 14 levels, does that make it an older LCD? I think newer/flasher ones use a digital gamma map.
|
|
#
?
Apr 27, 2009 22:21
|
|
|
It's not a full size LCD, it's a 800x480 7" display.
|
|
#
?
Apr 27, 2009 22:33
|
|
|
I'm finally doing some real professional consulting/design so I'm finally learning to program AVRs in C using AVR GCC. it's loving waaayy harder than I thought. Sucks when example source code doesn't even work. Does anyone here know their way around AVR GCC?
|
|
#
?
Apr 28, 2009 07:36
|
|
|
Yes. Mostly. edit: what's your setup? cygwin, linux? catbread.jpg fucked around with this message at 09:27 on Apr 28, 2009 |
|
#
?
Apr 28, 2009 09:24
|
|
|
Only worked with it for a little while, but I find it generally easy to work with. A bunch of annoyances with non-standardized #defines, but nothing major.
|
|
#
?
Apr 28, 2009 16:05
|
|
|
I'm using AVRstudio (or winavr I suppose), since I already have experience with it and most tutorials I'm finding use it as an example. So far I'm running into two things. First, changes to variables done in interrupt routines are not being kept upon returning to the main control, even though the variables are declared outside the interrupt routine. Second, in a lot of the code examples I'm messing with, the code just operates in an infinite for or while loop with maybe one instruction in it (most of the functions are interrupt driven). However, when I go to simulate it, the simulator will never actually step into the code inside the for loop, but rather only step into the interrupt routines. here's some example code where both of these issues occur: code:
|
|
#
?
Apr 28, 2009 19:47
|
|
|
The first issue I know the solution to. The compiler does not know about the interrupt handler, and just sees led as a loop invariant that can be optimized away. You want to declare it as volatile uint8_t which makes any optimizing away access to it forbidden (or compile without optimization, but that is just a workaround).
|
|
#
?
Apr 28, 2009 20:24
|
|
|
Yep, it just needs a volatile declaration. Standard for anything that gets changed in an ISR. This is also where you might want to start thinking about atomic operations, for example multi-cycle instructions on larger integers. cli() + sei() are your friends. The other issue is probably caused by the simulation of the timer. Once the first problem is fixed, try going 'run to' for a line in the main loop. Step through and look at the simulated timer register value. You could insert some dummy operations on dummy variables if you want to pad it out a little.
|
|
#
?
Apr 28, 2009 21:54
|
|
|
The volatile keyword is also handy for memory-mapped I/O which can get messed up by optimization as well. I don't think that will come up very often with AVRs, though, but I have had to use it for USB RAM on PICs.
|
|
#
?
Apr 28, 2009 23:32
|
|
|
yeah I was assuming it had to do with how I was declaring the variable... but is volatile really what I want? I had assumed volatile meant that the value is not kept between routines (based on what the definition of the word volatile actually is). Are volatile variables the same as global variables? As for the thing with the for loops, I did try putting dummy code in there but it still didn't step into it. I'm pretty sure the code gets executed, but it won't let me see it. And putting breakpoints inside should work, but when I go to run it, the simulator tells me that that "the break point can not be set."
|
|
#
?
Apr 28, 2009 23:37
|
|
|
You're thinking of local variables which are declared in functions, allocated onto the stack when the function is called, and deallocated when the function returns. Global variables are declared outside of functions and should retain their value throughout the program's execution. The variable led in your program is global whether you make it volatile or not. Volatile has nothing to do with scope, just with the way the compiler optimizes your program. You usually want it for things that can change outside the regular flow of your program such as during interrupt routines or if you're using memory-mapped I/O. Let's say you have something like this that reads two bytes from a serial port or something: code:Your case is fairly similar. The compiler sees led initialized to 0 but then it never changes later in the function, so to optimize the code it just assumes that led will always be 0. It has no way of knowing that an interrupt routine will increment led at regular intervals, so you need to declare it as volatile to tell the compiler that it may be different every time it loops. Edited for a tiny bit of clarity BattleMaster fucked around with this message at 02:14 on Apr 29, 2009 |
|
#
?
Apr 28, 2009 23:49
|
|
|
Declaring the variable as volatile did the trick, though I still can't really understand why.BattleMaster posted:You're thinking of local variables which are declared in functions, allocated onto the stack when the function is called, and deallocated when the function returns. Global variables are declared outside of functions and should retain their value throughout the program's execution. The variable led in your program is global whether you make it volatile or not. Now that I think about it, I really don't know if I'm observing its value correctly. I've been looking at the memory space and I've seen that when it's incremented in the subroutine, it happens in a working register, but after that, it could be storing it in SRAM (perhaps the stack?). Is there a way to keep track of variables the way the compiler keeps track of them, or do I just have to track it down in the memory space? quote:Volatile has nothing to do with scope, just with the way the compiler optimizes your program. You usually want it for things that can change outside the regular flow of your program such as during interrupt routines or if you're using memory-mapped I/O. Let's say you have something like this that reads two bytes from a serial port or something: quote:Your case is fairly similar. The compiler sees led initialized to 0 but then it never changes later in the function, so to optimize the code it just assumes that led will always be 0. It has no way of knowing that an interrupt routine will increment led at regular intervals, so you need to declare it as volatile to tell the compiler that it may be different every time it loops. Now on to something else. A lot of people told me I was underestimating C compilers when I assumed that I could always write assembly to be more efficient (in terms of execution time). Now I'm convinced more than ever that I was correct. I'm looking at my cycle counter and seeing things requiring 15 cycles that I could do in two or three. Later on I'm going to have to code my own asynchronous serial interface which will require a lot of bit banging. I'm afraid that if I write it in C, its execution time will be huge. Is there any way I can make it so my compiler biases itself more towards optimizing execution speed instead of program memory? Thanks for the help so far, I don't know what I would have done if you guys hadn't pointed out the volatility thing. ANIME AKBAR fucked around with this message at 16:14 on Apr 29, 2009 |
|
#
?
Apr 29, 2009 16:08
|
|
|
ANIME AKBAR posted:Now that I think about it, I really don't know if I'm observing its value correctly. I've been looking at the memory space and I've seen that when it's incremented in the subroutine, it happens in a working register, but after that, it could be storing it in SRAM (perhaps the stack?). Is there a way to keep track of variables the way the compiler keeps track of them, or do I just have to track it down in the memory space? Remember, the idea of a "stack" is just a logical construct made out of memory. ANIME AKBAR posted:So in the case that it's not volatile, it sees those two lines of code and turns it into temp1=temp2=rx, which is somehow more efficient? But for your example, volatility doesn't ultimately change the result of the code (just perhaps how fast it executes). The volatile keyword doesn't mean "don't optimize", although that is its effect. What it means is that the memory/register where that variable is "stored" could be changed by some other process or action at any time, and the compiler would have no idea. Thus it could change between accesses. This is often true in cases when you aren't pointing to memory, but to an I/O port. In the example, rx might be returning a byte from a serial port. Each "read" from rx would return the next byte that has been received, so setting temp1=temp2 would be wrong!
|
|
#
?
Apr 29, 2009 17:51
|
|
|
ANIME AKBAR posted:Declaring the variable as volatile did the trick, though I still can't really understand why. Let's take a look at your code: code:code:The lesson is that if you use variables in both interrupts and main code, they need to be volatile or they will likely not work correctly. quote:Right, so if led is global then why is its value not being conserved between functions? Calling/returning from functions shouldn't affect the value of led becuase globals don't care about that. Only locals are affected by that. They pop into existence when the function is called and disappear when it returns. The Wikipedia article on call stacks actually does a good job of explaining how that works. Global variables are stored in constant RAM locations that are fixed at compile time. I have little experience with AVR development tools but you should be able to find out where the variable led is being kept if you look at the disassembly for the line led = 0x00;. Maybe there's an easier way? quote:So in the case that it's not volatile, it sees those two lines of code and turns it into temp1=temp2=rx, which is somehow more efficient? But for your example, volatility doesn't ultimately change the result of the code (just perhaps how fast it executes). Sorry if I confused you with that example, I thought it was a good example but it's something that probably won't come up a whole lot. The variable rx was supposed to show the usefulness of volatile in memory mapped I/O. That is, rx doesn't point to RAM but rather a hardware-based buffer for a serial port or somesuch that gives you the next value in the buffer every time you read it. SnoPuppy did a great job of explaining why you want it to be volatile! quote:Now on to something else. A lot of people told me I was underestimating C compilers when I assumed that I could always write assembly to be more efficient (in terms of execution time). Now I'm convinced more than ever that I was correct. I'm looking at my cycle counter and seeing things requiring 15 cycles that I could do in two or three. Later on I'm going to have to code my own asynchronous serial interface which will require a lot of bit banging. I'm afraid that if I write it in C, its execution time will be huge. Is there any way I can make it so my compiler biases itself more towards optimizing execution speed instead of program memory? C compilers are good enough at optimization that it's almost never worth your time to hand-optimize something. And that's coming from someone who learns assembly languages for fun! There are a few things to watch out for, though. Depending on the architecture used, function calls with arguments and local variables can be more inefficient than you'd like. Read about call stacks to find out why - accessing local variables and arguments requires calculating offsets because the dynamic nature of function calling makes it impossible to use an absolute address. You probably don't want to be using that outp() function for time-sensitive bit banging. If the compiler gives you access to I/O ports as if they were variables (no clue about AVRs, but everything else I've ever used lets you) then the results shouldn't be much different than if you had written it in assembly. BattleMaster fucked around with this message at 19:24 on Apr 29, 2009 |
|
#
?
Apr 29, 2009 19:09
|
|
|
Hello again guys. Well, you'll be glad to hear that I'm still broke and bored. This time my 1st gen 2gb ipod nano seems to have died on me. Since its fairly old I figure its the common problem with these things, the battery finally gave up. I opened it up and I'm ready to change it. Thing is, I don't have an actual replacement battery. They don't sell them in my country. Some technicians fix them but they're assholes and won't sell me the battery alone (presumably so they can charge me exhorbitant fees for their godlike labour).  I do have a ton of cellphone batteries though.  These are the specs for the original ipod battery according to this site. quote:# Capacity: 330mAh This is my candidate battery: quote:# Capacity: 670mAh So my questions are probably obvious at this point. First of all, will the battery work? And second, whats this charge up voltage thing? I can't find the "charge up voltage" for the ipod battery. I need to know if and what kind of problems that will cause when I plug the thing into the USB cable. More info on ipod battery specs. Thanks for any help you can provide
|
|
#
?
Apr 29, 2009 20:24
|
|
|
Yeah, it'll work.
|
|
#
?
Apr 29, 2009 20:33
|
|
|
Crossposted from wiring thread: I have a few low voltage questions: For 14v AC @ 1amp - what size wire can I get away with for a run of 30' without a drop in power? I'm familiar with AWG, but my supplier uses a format of 24/0.2 , 7/0.2, 1/0.6 - as far as I can tell this translates to 24 strands at 0.2mm each. Is there a chart on how these compare with AWG figures?
|
|
#
?
Apr 29, 2009 22:20
|
|
|
Jagtpanther posted:Crossposted from wiring thread: Infinite  How much drop is too much?
|
|
#
?
Apr 29, 2009 22:40
|
|
|
Didn't work. I soldered the cellphone battery (BL-6C model from nokia) onto the ipod. It lit up when I plugged the USB cable into it but its giving me a "very low battery, please wait" message and its not being recognized by the PC. I'm guessing this is because they're both smart batteries, right? They both have 3 pins and I'm not exactly sure which one is the data pin, if someone could help me find out I'd really appreciate it. I've done a fair bit of googling but maybe I'm just not looking in the right places. Also, do the two smart batteries even speak the same language? or is the ipod simply dumping me into a default error message because it doesn't know if the battery is charged? And if so, is there a way around it? Here's what I did:  It should be noted that I removed the thing and plugged the ipod in without any battery and I got the same message so maybe I just got the pins wrong? (Also, I was getting no message at all when it had the original (presumably faulty) battery in place) Halp?
|
|
#
?
Apr 30, 2009 05:40
|
|
|
CptAJ posted:Didn't work. I soldered the cellphone battery (BL-6C model from nokia) onto the ipod. It lit up when I plugged the USB cable into it but its giving me a "very low battery, please wait" message and its not being recognized by the PC. I'm guessing this is because they're both smart batteries, right? They both have 3 pins and I'm not exactly sure which one is the data pin, if someone could help me find out I'd really appreciate it. I've done a fair bit of googling but maybe I'm just not looking in the right places. Can you take a better picture of the ipod battery? It looks like a run of the mill (as I call it) flatpack lithium ion polymer battery, which is most probably not a smart battery. If that is the case, there is a chance that the extra wire is a thermister or something. http://www.stagarms.com/product_info.php?cPath=13_22&products_id=209
|
|
#
?
Apr 30, 2009 05:49
|
|
|
 Maybe you're right? If so, then I must've gotten the pins wrong? Suggestions? (I'm guessing switch white and red)
|
|
#
?
Apr 30, 2009 05:56
|
|
|
I've got one tip with optimising bit operations: Where possible, do all operations as native n-bit integers. For example, use a whole byte to represent each bit of a bitfield when you're doing operations on it, then reconvert to a bitfield at the end. Same thing goes for boolean flags, bytes for everything.
|
|
#
?
Apr 30, 2009 06:00
|
|
|
CptAJ posted:
it would appear the circuitry on the left turns it into a smart battery. If I were you, I would try and find a replacement li-ion cell, and just unsolder the smart battery circuitry (carefully) and resolder it on the new cell. I don't THINK that will hurt anything, at least - I think battery controllers keep cell health info, but it should gradually change to match the new cell, I would think. Keep in mind what I would do is less of an expert's opinion and more of a hobbyist's inklings.
|
|
#
?
Apr 30, 2009 08:06
|
|
|
catbread.jpg posted:I've got one tip with optimising bit operations: Are you seriously recommending something like this: code:
|
|
#
?
Apr 30, 2009 20:16
|
|
|
No, I'm saying if you have seperate data bits originally (serial input or similar), AND you want to do bit operations on them before the final output, save the conversion to the bitfield till the end.
|
|
#
?
Apr 30, 2009 21:44
|
|
|
Quote is not edit!
|
|
#
?
Apr 30, 2009 21:44
|
|
|
|
| # ? May 8, 2024 18:11 |
|
|
That second algorithm is doing unnecessary operations if bitfield is initialised to zero. Either: code:code:I won't comment on the first algorithm because there should be no need to do that.
|
|
#
?
Apr 30, 2009 21:56
|
|