Back
[00:55:48] <Triplell> Anyone here familiar with FTDI?
[00:56:41] <ziph> Those are the chips people use when they don't know about LUFA, right? :)
[00:58:29] <Triplell> Likely...as I don't know about LUFA
[00:58:53] <ziph> http://www.fourwalledcubicle.com/LUFA.php
[00:59:39] <ziph> But go ahead and ask your actual question.
[00:59:56] <Casper> I don't know lufa, but I would probably use an FTDI over LUFA
[01:00:30] <Triplell> Does LUFA interface well with the Atmega328?
[01:00:40] <ziph> It requires a USB AVR.
[01:00:51] <Triplell> Well I guess that is not an option :)
[01:01:31] <Casper> ah lufa is the usb enabled avr... I tought it was the bitbang... but well, I'ld probably use an ftdi still :D
[01:01:58] <Triplell> Anyway, I am required to use an USB application for on of my projects. It's stupid, because there really is no need for USB in my application, but whatever...more busy work I guess.
[01:02:15] <Casper> nite
[01:04:16] <Triplell> Anyway, i am interfacing with the FTDI via FT232RL. From the documentation and sample schematics I found, it seems that CTS and RTS are often left floating (on the FT232RL device). It seems to if RTS floats to high, then the device will not accept any more data on the RX pin
[01:04:25] <Triplell> However all the example projects I saw left it floating
[01:06:19] <ziph> That seems odd, but in any case you should be able to tell it to ignore flow control if you aren't using it.
[01:06:58] <Triplell> Is flow control set using the D- and D+? or is it likely a single pin input?
[01:07:17] <Triplell> I know you can set the USB mode using D- and D+, but I am unsure about flow control
[01:07:54] <ziph> Flow control is an RS232 thing, it doesn't relate to the physical layer of USB.
[01:08:12] <Triplell> Ah, that makes sense
[01:08:46] <Triplell> Would flow control be controlled by DTR?
[01:10:32] <ziph> No.
[01:11:12] <Triplell> I'm just concerned that the device will not accept anymore data if RTS would float
[01:11:19] <inflex> wtf... hey ziph , Tom_itx , Casper .... and whom ever
[01:11:53] <Triplell> If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.
[01:13:38] <ziph> Triplell: It means the device on the other end shouldn't send any, not that the FTDI will drop it. (Although it may if the FIFO is full)
[01:14:16] <ziph> Triplell: The flow control input of a device may stop it from sending, but it won't stop it from receiving.
[01:15:29] <ziph> inflex: Howdy.
[01:17:34] <Triplell> ziph, thanks for your help
[01:20:51] <Triplell> One last questions: I plan to power my board externally. The USB supplies 5v power. Should I make sure that the VCC(for the mega328 and other components) is seperate from the 5v supplied from the USB
[01:23:20] <ziph> If you want it to work when USB isn't plugged in, yes.
[01:24:02] <ziph> Have a look at the FTDI datasheet for externally powered set ups though, the FTDI might want to still sense the USB VBUS 5V (through a 10k resistor or something).
[01:26:51] <Triplell> My thought was that I would only want to power the FT232 while the USB is connected, so I'll just make use of two seperate 5v lines
[01:28:08] <ziph> Make sure you have pull ups/pull downs on any control lines you run out of the FT232 then, so that they don't float while it is off.
[01:28:59] <ziph> s/control/output
[01:30:58] <ziph> And you most likely won't be able to apply any voltage to any of the input pins of the FT232 while it is off.
[01:33:20] <ziph> Which could mean you have to switch connected peripherals in the AVR back to GPIO so that you can make sure they put out 0V or High-Z while you aren't connected to USB.
[02:54:29] <sh00p> So i'm trying to set up a serial communication link between my atmega and my pc
[02:54:31] <sh00p> f��f�怘���f��f�怘
[02:54:34] <sh00p> thats the output i'm getting
[02:54:39] <sh00p> anybody seen this before?
[02:54:52] <sh00p> I want the atmega to print "hello" every so so milliseconds
[02:56:41] <Triplell> looks like the output I get when my baud rates are set up correctly
[03:06:41] <lifeeth> *not
[03:06:53] <TwisteR> sh00p, your baudrate settings is wrong either in your terminal application or in your firmware (UBRR register value)
[03:07:05] <lifeeth> sh00p, check the baudrates and maybe check if the baund you set is right for your clock speed
[03:08:16] <TwisteR> I like to use macros provided by <util/setbaud.h> for this purpose (in case you use avr-libc)
[03:10:53] <dehuman> ditto that
[03:15:52] <sh00p> thanks guys, I'll check that out
[03:16:07] <sh00p> util/setbaud, check
[03:18:12] <TwisteR> sh00p,
http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html
[03:19:05] <TwisteR> only if you are using avr-gcc/wingcc
[03:21:03] <TwisteR> s/wingcc/WinAVR/
[03:35:50] <Triplell> Why would pb0 of the Atmega328 be pulled high?
[03:39:18] <Triplell> Timer/Counter Input Capture Input:...I do not know what that is, and the data sheet is confusing me
[03:40:35] <TwisteR> maybe internal pull-up is active?
[03:41:31] <Triplell> I know that timers are used so that you don't have to rely on the software to produce real time signals
[03:45:17] <Triplell> Basically, I don't understand what a high value on PB0 does as an input
[03:49:12] <TwisteR> if the pin is configured as input, then it has very high impedance and measuring its voltage is incorrect
[03:50:54] <Triplell> Is it reccomended that you regulate the supply voltage? I need 3.3v and 5v for this board. Should I have a regulator for both?
[03:51:23] <TwisteR> does it behave correctly in firmware? does the value of the bit 0 in PORTC changes on logical level change of the pc0?
[03:51:55] <TwisteR> sure, you need two voltage regulators
[03:54:02] <Triplell> Series, parralel, or does it matter?
[03:54:12] <Triplell> As long as I always step down?
[03:54:38] <TwisteR> yes, you can power 3.3v regulator from 5v regulator
[03:54:58] <TwisteR> with proper decoupling caps, of course
[03:55:46] <TwisteR> if we are talking about linear voltage regulators like 1117 or 7805
[03:56:58] <Triplell> Do you see any problems with this?
http://i39.tinypic.com/ruyxjc.png
[03:57:07] <Triplell> first regulator is 5v, next is 3.3v
[03:59:01] <TwisteR> no problems, but I prefer to power LEDs from 5v, because I'm using very low power 3.3v LDO's
[03:59:40] <TwisteR> and 0.1 uF ceramic caps together with 10 uF tantalum on outputs
[04:01:40] <Triplell> I'm using a lm7805 and a ld117v33
[04:02:40] <Triplell> Also I'm using polarized caps
[04:03:07] <Triplell> electrolytic*
[04:12:48] <Triplell> Also I've been wondering if I should buy a 9v wall wort, or a 5v. I've noticed with the previous 5v ones I used, I ussually only get 4.5-4.8v outputs
[04:20:51] <inflex> ugh, that's fun, when you over run your regs
[04:21:18] * inflex has that problem on one of his latest projects... want to run a buzzer, but the damned thing wants 80mA for maximum output, but my poor little SOT23 reg isn't going to do better than 100mA
[04:24:14] * inflex ponders doing an R-2R ladder for a DAC... or getting an actual DAC :
[04:24:27] <TwisteR> Triplell, you should *allways* use input voltage higher (minimum for 1-2 volts) than your regulator's output
[04:25:39] <TwisteR> so buy 9v immediately
[04:27:29] <theBear> an expensive regulator can often go a little below a volt, but "normal" ones like 78/9xx need from memory 2-2.5volts to be happy, and remember the fact that you are regulating suggests your supply will wobble a bit, so you want a little headroom
[04:28:19] <TwisteR> in regulators datasheet you can see very important value -- dropout voltage. Thus, input voltage should be minimum Vout + Vdrop
[04:32:06] <karlp> theBear: they don't need to be expensive at all.
[04:32:34] <inflex> datasheets tell all
[04:32:39] <karlp> in fact, 7805s are more expensive, and have vastly higher quiescent current, and higher drop out
[04:33:03] <inflex> Anyhow, trying to decide if I should use a DFN6x2 package... or boring SOIC
[04:43:52] <karlp> always use the new and sexy!
[04:44:00] <karlp> even if it has no apparent advantages!
[04:46:35] <Valen> dfn seem harder to use for us at least ;->
[04:47:40] <theBear> karlp, i shoulda said fancy, not expensive
[04:55:04] <karlp> :)
[05:32:19] <Triplell> How much heat is regulating from 9v to 5v going to produce, and how much power consumption?
[05:33:15] <theBear> depends on load
[05:33:53] <theBear> it's gonna be 4/5ths the consumption of the load (simple ratio/percentages) and heat, well there's some maths to turn the previous answer into heat i'm sure
[05:34:33] <theBear> if you have a given heatsink with a given thermal resistance, assuming adequate airflow you can know how hot the outside of the heatsink and the regulator will be
[06:32:30] <Tom_itx> inflex?
[06:35:48] <inflex> hi Tom_itx
[06:36:02] <Tom_itx> <inflex> wtf... hey ziph , Tom_itx , Casper .... and whom ever
[06:36:05] <Tom_itx> ??
[06:36:16] <inflex> oh, not sure, I think I was just saying "hi"
[06:36:30] <Tom_itx> oh
[06:36:34] <Tom_itx> hi
[06:39:17] <Casper> Triplell: 78xx regulator waste all of the extra voltage as heat. you will waste exactly: W=(Vin-Vout)*Iout
[06:41:02] <h4x0r`> hi
[07:07:01] <TwisteR> [avr-libc] Is there some way to properly organize my work with two UARTs, both represented as IO streams?
[07:07:11] <TwisteR> For example, I need to continuously read some data from the remote device via first UART using fgets()
[07:07:20] <TwisteR> in the same time I need to accept commands through the second UART, but I can't do that since fgets() is still waiting for remote device's data
[07:07:37] <h4x0r`> hrm
[07:08:04] <h4x0r`> you want to feed everything back to the 1 terminal session/window? right?
[07:08:44] <TwisteR> I prefer to stay with stdio.h functions and not to switch to the low-level interrupt-driven custom library
[07:08:57] <h4x0r`> my sourcecode isnt on this deck, but yea FILE file; and use conout
[07:09:11] <h4x0r`> not sure tho
[07:10:33] <TwisteR> no, I don't want to feed everything back to one terminal -- separate commands for the remote device via first uart, separate user interface via second uart
[07:13:01] <TwisteR> according to man page:
[07:13:02] <TwisteR> gets() and fgets() return s on success, and NULL on error or when end of file occurs while
[07:13:02] <TwisteR> no characters have been read.
[07:13:26] <h4x0r`> hmm not sure, i built an interpreter, like a little avrOS that is triggered by commands sent to the uart by the ic
[07:13:45] <h4x0r`> heh
[07:14:06] <TwisteR> does this means, that if there is no new data and buffers are empty, I need to return EOF char in my lowlevel uart_getc() function?
[07:14:35] <h4x0r`> lf perhaps
[07:15:06] <h4x0r`> i iterate buffers to determine contents
[07:15:17] <h4x0r`> fgets and stuff never turned me on much
[07:16:07] <TwisteR> I'm trying to figure out how to work with that stuff in correct way :)
[07:25:50] <inflex> urrrrh
[07:25:52] <inflex> choices choices
[07:26:25] <inflex> trying to work out if I should put the whole DAC/ADC/control stuff on a single board and AVR... or if I should control all the daughter boards from a single central AVR
[07:26:45] * inflex is erring towards an AVR per daughter board
[07:27:34] <inflex> in which case I can probably drop the need for the DAC, instead just use 10 bits on the AVR
[07:28:30] <inflex> Anyone worked with DFN2x6 packages?
[07:37:24] <orated> Hi! Could anyone explain me about fuses in AVRs? What do they represent and to set them?
[07:39:57] <TwisteR> they are like switches -- you can tell AVR to proceed in different modes and tweak some internal settings by means of fuses
[07:40:30] <TwisteR> how to set them depends on software tools you are using
[07:40:57] <TwisteR> there may be a window with checkboxes or command-line interface
[07:41:34] <h4x0r`> good info there ^
[07:41:34] <orated> Setting them in avrdude using write hfuse etc. But I want to know on what basis you decide the fuses should be as per requirement?
[07:41:45] <h4x0r`> but be careful of fuses, particulalry the clocksel fuse.
[07:41:56] <h4x0r`> dont mess with them at all until you read up on them.
[07:42:26] <TwisteR> avrdude is really cool, using it too :-)
[07:43:56] <TwisteR> all info on fuses for particular part has an comprehensive description in the datasheet for that part
[07:44:56] <TwisteR> there are several tables in Memory programming / Fuses section
[07:45:09] <TwisteR> of the datasheet
[07:47:07] <TwisteR> every fuse bit, described there, has a reference to the page with details on that particular fuse
[07:50:40] <orated> I have not set anything. I could get to an online tool which allow to select parameter and get fuses values. I lost the link nor was I able to use it properly. I didn't get what lfuse and hfuse denotes..? Yes, I'm reading the datasheet
[07:52:34] <TwisteR> hfuse and lfuse does not denote anything by itself, it just serves as a "container" for fuse bits
[07:53:11] <TwisteR> some bits may reside in high fuse byte, other -- in low fuse byte
[07:53:20] <orated> So they are not high and low fuse?
[07:53:27] <orated> ah-ok
[07:53:38] <TwisteR> there are even parts with extended -- third -- fuse byte
[07:53:50] <TwisteR> efuse in avrdude notation
[07:53:57] <orated> lock?
[07:54:00] <TwisteR> no
[07:54:20] <TwisteR> they *are* high and low fuses
[07:54:30] <h4x0r`> high fuse/low fuse
[07:54:36] <TwisteR> yes
[07:54:57] <TwisteR> hfuse is High fuse byte
[07:55:02] <h4x0r`> 0/1.. on/off
[07:55:03] <TwisteR> lfuse is Low fuse byte
[07:55:06] <h4x0r`> high/low
[07:55:13] <h4x0r`> 0 being low
[07:55:16] <h4x0r`> 1 being high
[07:55:18] <TwisteR> efuse is Extended fuse byte
[07:55:22] <h4x0r`> yup
[07:55:47] <TwisteR> lock is lock fuse byte
[07:56:09] <TwisteR> ^ all in avrdude notation
[07:56:52] <orated> Could you link me to an online resource for the same or AVR application notes? And also the tools which help to set the fuses as per parameter selected?
[07:57:28] <TwisteR> orated, you can get the list of possible memory types and some other info by typing "part" in the interactive mode of the avrdude
[08:00:03] <orated> Ok, thanks TwisteR h4x0r`
[08:00:42] <TwisteR> I'm usually calculate fuse values with python in interactive mode :)
[08:00:59] <TwisteR> hex(0b10010101)
[08:01:07] <TwisteR> voila :-)
[08:03:04] <h4x0r`> TwisteR, u rock a telit gsm unit?
[08:03:10] <h4x0r`> they run python
[08:03:24] <TwisteR> filling zeroes and ones as an argument to hex() using table for appropriate fuse byte as reference
[08:03:58] <TwisteR> h4x0r`, no, I'm using system python interpreter
[08:04:25] <TwisteR> one can use calculator in hex mode or whatever
[08:06:20] <TwisteR> it is handy to have several files with fuse bits definitions for different MCUs
[08:07:57] <karlp> just use this:
http://www.engbedded.com/fusecalc/
[08:08:10] <karlp> it even generates the avrdude command line segments for you
[08:08:25] <karlp> and you can type in fuses to see what they decode as, or choose settings and have it generate fuse bytes
[08:10:34] <TwisteR> I can't get why avrdude developers still does not provide similar functionality with their program
[08:13:15] <TwisteR> lol, poor orated is not patient enough to get url he was looking for :D
[08:16:37] <karlp> TwisteR: not really their focus I guess.
[08:16:42] <karlp> also, it's done, it exists :)
[08:19:51] <TwisteR> any ideas about my problem with several uarts?
[08:20:26] <karlp> I can'ðt think of anyway of doing it without using the avr interrupts
[08:20:38] <karlp> or, using an operating system that provides something like select()
[08:20:44] <TwisteR> basically, I need something like select() for streams multiplexing, but that function is not the part of the avr-libc....
[08:20:53] <karlp> yeah, exactly :)
[08:20:54] <TwisteR> :D
[08:21:47] <karlp> I think you're going to have to have two rx buffers, and use either interuppts or polling to fill them up until you get enough to do something
[08:21:57] <karlp> how long a string were you trying to fgets()?
[08:23:49] <TwisteR> not longer than 16 chars (all buffers are 32 bytes long)
[08:35:21] <Travler1> ^^
[08:56:39] <_abc_> Erm. Where does one get avrdude for windows?
[08:57:05] <_abc_> Is the avrdude-gui a complete avrdude? I mean is it compiled into it?
[08:58:49] <TwisteR> it should be, I suppose
[08:59:24] <TwisteR> that is windows-way to do things like that :)
[09:03:39] <_abc_> No, it is not. The avrdude must be gotten from savannah and it is camouflaged as *-PatchXXX-*.zip
[09:04:10] <_abc_> Please check your facts when answering, you may lead small children astray :)
[09:05:03] <TwisteR> my bad, sorry :)
[09:05:53] <_abc_> I found an instruction page on how to install ghostview on Windows which contains the golden phrase 'If you have Windows 3.1 you are in luck'. I think that someone should a) put dates on webpages and b) sometimes reboot University servers which were left on since the early 90s
[09:05:57] <_abc_> Damn Unix.
[09:06:15] <_abc_> kidding
[09:48:11] <maurijn> hi.
[09:48:36] <maurijn> does one get to ask questions here?
[09:48:51] <mrfrenzy> try it
[09:50:11] <maurijn> on a mega48, is it possible to activate both CTC timer channels (A&B) simultaneously?
[09:51:02] <mrfrenzy> you can wait until someone who was used both timers on a mega48 comes online, or you can look up the relevant page in the datasheet
[09:51:03] <maurijn> datasheet says: "two independent output compare units"
[09:51:23] <mrfrenzy> good on ya, you had already checked ;)
[09:51:28] <maurijn> I took that to mean yes
[09:51:28] <mrfrenzy> if they are independent: yes
[09:51:45] <maurijn> well yeah, I didn't want to be the new guy asking idiot timer questions ;)
[09:52:04] <maurijn> now I'm just the new guy asking idiot timer questions while having done a little research
[09:52:11] <maurijn> oh, good
[09:52:13] <mrfrenzy> which is very unusual ;)
[09:52:20] <mrfrenzy> most guys have not done any research
[09:52:21] <maurijn> oh, yay :p
[09:52:27] <mrfrenzy> welcome to irc
[09:52:48] <maurijn> situation: I have the COMPA interrupt up and running, but the COMPB won't fire
[09:53:16] <mrfrenzy> can you get COMPB working if you disable COMPA?
[09:53:19] <maurijn> I thought I'd just have to set the OCR0B value (compare match) and OCIE0B flag to activate the channel
[09:53:33] <maurijn> I tried setting the OCIE0A to 0 to disable it and then nothing happens ;)
[09:53:47] <maurijn> is there a flag I'm missing or something?
[09:54:24] <mrfrenzy> most likely, I'm not the most experienced person to help though, put your example code on pastebin, and wait for someone to come around that wants to have a look
[09:55:12] <maurijn> I'll go mess around myself a little first and then if I can't work it out I'll do that
[09:55:17] <maurijn> thanks for your help so far :)
[10:03:18] <maurijn> ah, figured it out: CTC can only have one channel, which is understandable come to think of it
[11:59:17] <Triplell> Has anyone here ever used the HD44780 LCD chipset?
[11:59:32] <Steffanx> Ofcourse
[11:59:49] <Triplell> There is two pins, 15 and 16, which I assume is for the backlight
[12:00:44] <Triplell> Do I need to current limit the A pin(pin 15) to 120mA>?
[12:01:08] <Tom_itx> it varies depending on what type of backlight it has
[12:01:18] <Triplell> http://www.sparkfun.com/products/709
[12:01:24] <Tom_itx> some are flourescent and some are led
[12:01:28] <Triplell> LED
[12:01:29] <Tom_itx> you need to test it to see
[12:01:41] <Tom_itx> and i wouldn't drive it to full spec anyway
[12:01:50] <Triplell> 120mA is typical
[12:01:59] <Tom_itx> yes you need a resistor
[12:02:23] <Triplell> and a forward voltage of at least 4.2v I take it?
[12:02:35] <Tom_itx> that varies too
[12:02:40] <Tom_itx> i've had some that were 12v
[12:02:51] <Tom_itx> graphic displays though
[12:03:26] <Triplell> Let assume the datasheet is correct, does that mean I can drive it directly with a 5v supply?
[12:03:38] <Tom_itx> probably
[12:03:45] <Tom_itx> put a resistor on it though
[12:04:47] <Triplell> I've also seen a fet placed on the kathode
[12:04:57] <Triplell> is this required?
[12:05:02] <Tom_itx> no
[12:05:10] <Tom_itx> they probably used it to pwm the brightness
[12:05:33] <Triplell> Pulse Width Modulation, correct?
[12:05:40] <Tom_itx> uh huh
[12:09:47] <Triplell> If I assumed I needed 4.2v at the anode, and I wanted to limit the current to 120mA, I would need a 7 ohm resistor (if my math is correct)...why so small?
[12:12:21] <Tom_itx> cause that's the math
[12:12:44] <Triplell> so I should use that small of value?
[12:12:52] <Tom_itx> 10
[12:12:55] <Triplell> right
[12:13:41] <Steffanx> left
[12:17:56] <Triplell> using 10ohm resistor would drop the voltage at the anode to 3.8v, which is below the forward voltage of the LEDs
[12:20:14] <Triplell> Assuming typical leds have .7v drop, I assume this would mean that the backlight would not light up completely
[12:34:15] <TwisteR> Triplell: but it's life will be much longer ;)
[15:32:15] <impulse32> i'm using this makefile to try to compile my project:
http://sprunge.us/fQPD
[15:32:37] <impulse32> when i do make it says: /usr/libexec/gcc/avr/ld: cannot find crtm1280.o: No such file or directory
[15:33:10] <impulse32> crtm1280.o is in /usr/avr/lib/avr5 on my system which i tried to add to the library search path with -L
[15:33:18] <impulse32> but i still get that error
[15:33:27] <impulse32> anyone know how to fix this?
[15:56:02] <TwisteR> impulse32: I've fixed this ugly — just by symlinking /usr/avr/lib/avr5/crtm1280.o to /usr/avr/lib/
[15:56:22] <impulse32> TwisteR: thanks
[15:56:37] <impulse32> i'm rebuilding my toolchain now, i'll give that a try
[15:57:14] <TwisteR> the error i s well known across the Internet, but I did not find any correct way to fix it
[15:57:22] <TwisteR> is*
[15:58:24] <TwisteR> impulse32: crossdev user @ gentoo, right?
[15:58:45] <impulse32> yep
[15:58:51] <impulse32> that worked thanks
[15:58:55] <TwisteR> welcome to the club of strange errors :D
[15:59:00] <impulse32> just found it on the wiki too
[15:59:26] <impulse32> i still have a much stranger one
[15:59:43] <TwisteR> there are #gentoo-embedded channel here at freenode, you can ask there about reasons of this error
[16:00:18] <impulse32> check out this error:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=96055
[16:00:44] <impulse32> ^ the reason i gave up on embedded programming a few months ago
[16:01:54] <impulse32> strange how -L didn't fix it
[18:41:25] <Tom_itx> inflex et all:
http://www.proto-advantage.com/store/
[18:44:23] <Tom_itx> abcminiuser
[18:44:25] <Tom_itx> you in?
[18:44:35] <abcminiuser> Yup
[18:44:40] <Tom_itx> remember the talk about a standalone programmer and lufa?
[18:44:58] <Tom_itx> i forgot what capability lufa had toward that end
[18:46:17] <impulse32> can anyone help me with this issue:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=96055 ?
[18:46:59] <abcminiuser> Tom_itx, I started one a long while back, never finished it
[18:47:12] <abcminiuser> I should get back to it though, transplate my old ButtLoad code into it
[18:47:21] <Tom_itx> usb or standalone?
[18:47:43] <abcminiuser> ButtLoad is standalone with a butterfly board
[18:48:06] <abcminiuser> I want to make a LUFA powered one that either acts as a flash drive, or allows you to insert flash drives containing HEX files
[18:48:12] <abcminiuser> impulse32, JULY?
[18:48:21] <impulse32> yes sir
[18:48:27] <impulse32> still holding me back
[18:48:44] <abcminiuser> Ok, gimme a sec to refresh my memory of the thread...
[18:49:15] <impulse32> thanks
[18:49:59] <abcminiuser> Hrm, why the call to the delay func in the transmit?
[18:50:10] <abcminiuser> It'll work fine without it, since you busy-wait right after it
[18:50:20] <impulse32> i thought it might help
[18:50:23] <impulse32> but didn't
[18:50:32] <impulse32> i think someone suggested it
[18:51:06] <JanneP> speaking of stand alone programmers, i've been working on an usbasp with on board storage
[18:51:16] <JanneP> provided by 24lcxxxx's
[18:51:45] <JanneP> started working on that before i head anything about butt load, for my own needs. but now i'¨m too close to stop =)
[18:52:17] <abcminiuser> impulse32, hrmph
[18:52:33] <abcminiuser> Given the loop test someone asked you to perform worked, your code should also
[18:52:51] <impulse32> abcminiuser: how can i see the image that's being loaded?
[18:53:21] <impulse32> abcminiuser: i'm on a new host machine with a freshly built toolchain now
[18:53:29] <abcminiuser> See it how?
[18:53:31] <impulse32> maybe now after a year i have better luck?
[18:53:40] <abcminiuser> Once you build, the .LSS file will contain the C and resulting ASM code
[18:53:53] <impulse32> what about the data?
[18:53:58] <impulse32> also in the .lss/
[18:54:18] <abcminiuser> Frankly I'd suspec the makefile - have you tested with the WinAVR template?
[18:54:40] <abcminiuser> If that wasn't copying constant data into SRAM on startup correctly, you'd see your problem
[18:55:16] <abcminiuser> Actually, stack corruption could do it too
[18:55:26] <abcminiuser> Tell you what, I'll rebuild it here for you and you can test it on your HW
[18:55:42] <impulse32> cool thanks
[18:56:36] <abcminiuser> What crystal speed?
[18:58:10] <impulse32> 16MHz
[18:58:33] <abcminiuser> http://pastebin.com/HwZXiUzw
[18:58:43] <abcminiuser> Copy-paste into a .HEX file, program it in
[19:03:36] <impulse32> ok i found the board
[19:03:47] <impulse32> now i just need to find a usb cable
[19:04:46] * abcminiuser showertime
[19:12:17] <impulse32> ok found the cable
[19:12:53] <impulse32> usb
[20:02:55] <abcminiuser> ...and?
[20:09:13] <inflex> ugh, feel trashed
[20:10:50] <Casper> inflex: what bus would you suggest to use if I only have access to 2 wires without any change... 4 wires could be doable however. star network, multi-master.
[20:12:14] <Casper> the one that is the closest seems to be canbus, but the wire is the problem, unless I take the protocol and kinda make it 1 wire...
[20:12:51] <inflex> I'd be tempted to try 1-wire
[20:13:17] <inflex> but it depends, do all the devices have a common ground still?
[20:13:47] <Casper> all devices will be independant, and multi-ground point
[20:13:52] <Casper> which cause even more problems
[20:14:10] <Casper> 1 wire as it is single master, I need multi-master
[20:14:14] <inflex> I'm not really strong on the whole set of options to be honest... I'm just chewing over 1-wire atm as well interestingly, trying to find a way of embedding an EEPROM into a battery and using modulated high-frequency on the power lines to talk to it
[20:14:25] <inflex> urrrrugh, right
[20:14:40] <inflex> sounds like you've got a helluva task
[20:14:47] <inflex> brb, getting coffee #1 for the day
[20:14:55] <Casper> yeah... can't figure out this one
[20:15:04] <Tom_itx> inflex et all:
http://www.proto-advantage.com/store/
[20:17:12] <Casper> basically, I'm planning on making some clocks. I have an old gps that is half broken but still have serial communication, so was thinking to make it broadcast the time. then I want to add a "pit flusher" project, which is 3 circuits... I'ld like to be able to control each parts. 2 would be transmitter... that make 3 master... then I want to connect the pc to it, so 4th master...
[20:20:05] <Casper> the problem is I don't want to reinvent the wheel... there HAVE to be an on the shelf solution that do not require rewiring the house
[20:28:36] <inflex> Tom_itx: yeah, saw that
[21:44:26] <Tom_itx> abcminiuser what if 2 interrupts fire at the same time? which one gets serviced and what happens to the other one?
[21:44:53] <Tom_itx> ie, adc and timer overflow
[21:45:10] <abcminiuser> The higher prority one (i.e. the one with the lower ISR vector address/number in the datasheet)
[21:45:12] <Casper> Tom_itx: on avr, timer get executed in a priority manner, based on the vector table
[21:45:29] <Tom_itx> i thought so, but rue disagreed with me
[21:45:34] <abcminiuser> The lower priority ISR will have the interrupt flag set, and will execute one cycle after the higher priority one comples
[21:45:36] <abcminiuser> *completes
[21:45:38] <Casper> both get the interrupt set, lower number execute first
[21:46:03] <Tom_itx> the adc seems to be throwing off the pwm pulsetrain though
[21:46:10] <abcminiuser> Note that the "queue" this produces is only one entry deep for each interrupt source -- i.e. if you receive two USART characters while another ISR is running, you only get one USART RX interrupt
[21:46:42] <Tom_itx> so it's possible to miss a timer if the adc is taking a reading?
[21:47:20] <Casper> no
[21:47:56] <rue_shop> there are lies in here for me?
[21:48:16] <Casper> the only way to miss an interrupt is if one flag is set and the same interrupt happend again
[21:48:17] <rue_shop> yea, so its drops interrupts
[21:48:23] <rue_shop> it dosn't latch the interrupt flags
[21:51:50] <abcminiuser> It does latch them in most cases
[21:51:58] <abcminiuser> But you've only got one flag per interrupt source
[21:52:12] <abcminiuser> So if you get two events for the one interrupt source before you process it, you lose one
[21:52:52] <Tom_itx> adc seems to be interferring with timer overflow
[21:53:02] <Tom_itx> vectors 4 and 16
[21:53:13] <Tom_itx> 4 being the timer
[22:14:52] <abcminiuser> Hrmph
[22:15:10] <abcminiuser> Well, if the ADC interrupt was slow, it would delay the timer interrupt
[22:15:41] <abcminiuser> So even though it's picked second, it might introduce enough latency into the timer ISR which has to wait for it to finish for the next ISR that it breaks the system
[22:16:31] <Tom_itx> <rue_shop> timer does like _-_-_-_-_ with no adc
[22:16:31] <Tom_itx> <rue_shop> with adc its _-_-___-_-___-_-___-_-_____
[22:17:53] <rue_shop> it fits what abc said exactly
[22:18:06] <rue_shop> its ok, I'm moving the adc read to the main loop
[22:19:44] <rue_shop> int getAVal( int channel) {
[22:19:44] <rue_shop> ADMUX = channel & 7; // select channel
[22:19:44] <rue_shop>
[22:19:44] <rue_shop> NOP();
[22:19:44] <rue_shop> NOP();
[22:19:45] <rue_shop> ADCSRA = 1 << ADEN |
[22:19:46] <rue_shop> 1 << ADSC | /* start a converstion, irq will take from here */
[22:19:48] <rue_shop> 0 << ADATE |
[22:19:50] <rue_shop> 0 << ADIF |
[22:19:52] <rue_shop> 0 << ADIE | /* enable interrupt */
[22:19:54] <rue_shop> 1 << ADPS2 |
[22:19:56] <rue_shop> 0 << ADPS1 |
[22:19:58] <rue_shop> 0 << ADPS0 ;
[22:20:00] <rue_shop>
[22:20:04] <rue_shop> while(IsLow(ADIF, ADCSRA));
[22:20:06] <rue_shop>
[22:20:08] <rue_shop> return ADC;
[22:20:10] <rue_shop>
[22:20:12] <rue_shop>
[22:20:14] <rue_shop> }
[22:20:16] <rue_shop> oversights?
[22:20:38] <rue_shop> I think reading the value clears the flag
[22:21:17] <rue_shop> ugh, or do I wait for ADSC to go low again, I fergot
[22:28:29] <impulse32> abcminiuser: it seems my problem went away with the newer toolchain
[22:28:33] <impulse32> thanks for your help
