Back
[02:43:04] <juri_> bad avr-ld.
[02:43:16] <juri_> loading my strings into ram doesn't do my program any good.
[02:45:39] <juri_> ok, putting it in my interrupt table REALLY won't help...
[03:19:57] <joh__> Could anyone tell me what's up with the first example code on Atmel TWI?
http://asf.atmel.com/docs/3.0.1/sam4s/html/twi_quickstart.html
[03:20:25] <joh__> namely, twi_master_setup(&TWIM0, &opt); doesnt work. TWIM0 is #defined as some unsigned value.
[03:22:23] <joh__> I could just send it in as a value I guess. since twim0 should be an address to a TWI master interface, and if I just send it in as the value it will typecast to a pointer anyway
[03:22:50] <joh__> not sure if this is correct to do though, anyone worked on atmel common interface twi?
[03:32:00] <Tom_itx> joh__, dallas RTC using TWI:
http://tom-itx.dyndns.org:81/~webpage/avr/Dallas%20RTC%20Code/
[05:01:51] <joh__> Tom_itx: Thanks! But seems like it's made using winavr, the project i joined uses the atmel toolkit and not winavr. doesn't seem like those libraries are supported in atmel's toolkit.
[05:02:24] <joh__> I started an implementation in that library you linked to until I noticed atmel didnt have that library
[06:26:42] <megal0maniac_afk> juri_: PROGMEM?
[06:26:55] <Roklobsta> any udev experts here?
[06:27:22] <megal0maniac_afk> Roklobsta: Just sudo :)
[06:27:39] <Roklobsta> no. program uses QT and complains about not seeing X
[06:27:47] <Roklobsta> if i sudo
[06:28:26] * megal0maniac_afk is referring to the udev.rules issues
[06:28:48] <megal0maniac_afk> And lots of other issues
[06:29:12] <megal0maniac_afk> But I'll shut up now because I'm not a udev expert by any stretch of the imagination
[06:29:59] <juri_> rokl: thats by design. welcome to shared cookies.
[06:30:50] <juri_> megal0maniac_afk: actually, setting the attribute for the interrupt vector table to be in the .vectors section did the trick.
[06:30:50] <megal0maniac_afk> And welcome to #avr ;)
[06:48:35] <Roklobsta> sorted. i fscking had to restart the udev service.
[07:28:26] <mdorenka> hi, is someone of you familiar with the attin84?
[07:28:46] <mdorenka> i have a problem with the following code:
[07:28:46] <mdorenka> https://gist.github.com/mdorenka/43f7bec0a603bbfcf941
[07:29:10] <mdorenka> it seems to crash from time to time, resulting in a reboot (re-execution of setup() which flashes an led) or in a freeze
[07:31:59] <twnqx> delay in an isr... daring
[07:32:21] <mdorenka> generally a bad idea? ;)
[07:34:41] <Tom_itx> always a bad idea
[07:35:57] <mdorenka> i removed it
[07:36:02] <mdorenka> still crashes.
[07:36:49] <Tom_itx> must have other bad ideas as well then
[07:36:57] <Tom_itx> no time to look here. i'm gone
[07:45:29] <Tom_itx> i would do the compares as >= and <= instead of > and <
[07:47:20] <Tom_itx> i would also initialize the var to an initial value
[07:48:06] <Tom_itx> ok, i see where you did that now
[07:50:43] <Tom_itx> i think i would move the if statement out of the interrupt as well and put it in main just to keep the int as short as possible
[07:50:46] <Tom_itx> but that's just me
[07:55:27] <zmo> hi!
[07:55:36] <mdorenka> hmm okay
[07:55:42] <mdorenka> what would happen if the int was too long?
[07:56:02] <zmo> I'm still struggling with my bootloader problem:
http://stackoverflow.com/questions/19518045/stk500v2-bootloader-only-loaded-on-power-on-reset-not-on-pin-wdt-resets
[07:56:47] <zmo> mdorenka - it takes as many bytes as the format tells it to take
[07:57:18] <juri_> zmo: you've checked GICR?
[07:58:43] <mdorenka> Tom_itx, even without the ifs in the interrupt but in the main loop it crashes
[07:58:46] <zmo> juri_ - I don't think so
[08:02:45] <zmo> juri_ - what do you think that I shall check in GICR?
[08:17:37] <zmo> actually, I do reset the MCUSR in the bootloader, though when I reset the AVR
[08:18:02] <zmo> the firmware app code gets the MCUSR still set
[08:53:13] <beaky> hello
[08:53:20] <beaky> why use _BV instead of 1<<
[08:54:17] <bss36504> No particular reason, they are equivalent. I personally find the (1<<SOME_BIT) a lot easier to read.
[08:55:48] <beaky> me too
[08:55:57] <blathijs> A lot less ugly, too :-)
[08:56:33] <bss36504> _BV is a classic example of when #define's are unnecessary.
[08:56:33] <beaky> i wish i could #define _ to be equivalent to (1<<n), would make code more cnsice
[08:57:07] <bss36504> what so you would have _6 to set bit 6?
[08:57:14] <beaky> e.g. EIMSK |= _(PCINT0) | _(PCINT1)
[08:57:21] <bss36504> That is ugly (IMO)
[08:57:26] <OndraSter> so say goodbye to functions foo_bar
[08:57:44] <beaky> but foo_bar is different token from _
[08:57:50] <beaky> so it wil slide :D
[08:57:52] <bss36504> I mean, it's nice at first glance, but sometimes verbose is better.
[09:17:31] <beaky> I love avr
[09:17:37] <beaky> it is the easiest miconcotrler to use
[09:18:04] <Guest42891> Especially with Arduino
[09:19:35] <Guest42891> :)
[09:20:28] <zmo> zen of python: "explicit is better than implicit", which, IMHO, has even more meaning when doing embedded C/C++
[09:23:46] <megal0maniac_afk> What the hell???
[09:24:03] <megal0maniac_afk> Busy configuring OpenWRT build. AVR32 is a target :/
[09:24:17] <megal0maniac_afk> As is AT91
[09:28:36] <megal0maniac> RikusW: Hey :)
[09:28:45] <RikusW> hi
[09:29:19] <RikusW> megal0maniac: Did you get the email ?
[09:29:37] <megal0maniac> I did, but laptop hasn't fetched email yet so it's on my phone still
[09:29:49] <megal0maniac> Might have to get one of those CPLDs soon :P
[09:30:14] <RikusW> I still have to properly test it
[09:30:24] <RikusW> I don't have any files to test programming yet...
[09:30:46] <megal0maniac> (A selection of useful .hex files for the U2S on the site would be pretty inviting for people looking at buying a U2S :)
[09:30:53] <RikusW> I might still optimize it a bit, like inlining a few functions
[09:30:57] <megal0maniac> RikusW: Blinky LED? :D
[09:31:32] <RikusW> still have to figure out exactly how to use quartus
[09:31:42] <RikusW> and verilog
[09:32:29] <RikusW> there was a blinky led on there before I erased it
[09:32:45] <megal0maniac> Can't you do it with VHDL?
[09:32:45] <RikusW> seems it got only 240 LEs ...
[09:32:57] <RikusW> don't know that well enough either...
[09:33:02] <megal0maniac> LEs?
[09:33:09] <RikusW> logic elements
[09:33:30] <RikusW> the basic unit in the MAX II and FPGA's like the cyclone
[09:33:47] <RikusW> cyclone got more like 8k to 50k etc
[09:33:55] <megal0maniac> Ah, okay. aka logic slices?
[09:34:08] <RikusW> probably
[09:34:16] <RikusW> each LE got a 4 input LUT
[09:34:43] <RikusW> I have the EPM240T100
[09:35:13] <megal0maniac> Yeah, same thing then
[09:35:41] <megal0maniac> The Xula has 4032
[09:36:04] <megal0maniac> Logic cells, that is
[09:36:15] <megal0maniac> 200K gates
[09:36:36] <RikusW> Xilinx ?
[09:36:48] <megal0maniac> Yip. XC3S200A
[09:37:16] <RikusW> it seems that quartus can program other devices given the IEEE 1532 BSDL file
[09:37:47] <RikusW> seems 1532 is a subset of VHDL
[09:39:40] <megal0maniac> Too many standards :)
[09:39:49] <RikusW> 1149 is jtag
[09:40:12] <RikusW> and its seemingly impossible to get it, unless you pay $100 per paper :(
[09:40:25] <RikusW> or are a member of ieee
[09:46:03] <bss36504> Xilinx ISE >> Quartus
[09:46:11] <megal0maniac> +1
[09:46:12] <bss36504> From personal experience with both
[09:55:54] <megal0maniac> RikusW: That's too bad
[09:58:47] <beaky> what is the cheapest avr
[09:58:54] <beaky> cheapest ATmega
[09:59:09] <beaky> that is not obsoleted by atmel
[09:59:26] <OndraSter> depends on where
[09:59:33] <OndraSter> just open your favourite distributor and click on SORT BY PRICE
[09:59:36] <OndraSter> ASC
[10:00:10] <beaky> ATmega48 seems cheapo
[10:00:23] <beaky> i love digikey they have everything cheap
[10:00:37] <megal0maniac> beaky: Didn't you already establish that the mega48 was the cheapest mega on digikey? Like 2 days ago?
[10:00:50] <beaky> maybe someone here knows better and that i am wrong
[10:01:03] <twnqx> yes, digikey is expensive :P
[10:01:06] <beaky> but seems atmega48 is still a dollar
[10:01:19] <beaky> it is? i thought they had good deals especially if you buy >5k components
[10:01:43] <twnqx> how often do you do that?
[10:02:00] <beaky> never. i am just a poor hobyist :( not a big company
[10:02:04] <twnqx> see.
[10:02:09] <OndraSter> then why are you looking at 5k+ pricing
[10:02:33] <beaky> i want to pretend i am a big company desining a product
[10:02:38] <OndraSter> well enjoy
[10:02:40] <OndraSter> gl
[10:02:41] <beaky> so i consider budgetary options
[10:02:51] <twnqx> and that's why local shops are often cheaper on small amounts
[10:02:54] <beaky> in real life i would just buy biggest avr for prototyping
[10:03:43] <beaky> local shops here charge $25 for an atmega328p
[10:03:58] <beaky> no wonder i think digikey is cheap :D
[10:04:31] <megal0maniac> beaky: You live on Antarctica?
[10:04:42] <beaky> nope
[10:04:47] <beaky> i live in united arba emierate
[10:05:03] <twnqx> 3.10€ for smd, 3.90€ for DIL
[10:05:57] <beaky> smd seems the way to go for budgetary design
[10:06:10] <twnqx> in single amount.
[10:06:31] <beaky> i wish i knew how to work with smd
[10:06:39] <beaky> not very perfboard friendly :(
[10:18:06] <OndraSter> SMD is simple, unless you are doing BGA
[10:18:30] <OndraSter> tbh through-hole power connectors in laptops are far worse to replace than some chips :D
[10:39:27] <RikusW> TH on PTH pcb is painful...
[10:41:02] <bss36504> only to take out
[10:41:12] <RikusW> indeed
[10:41:32] <RikusW> caps aren't that bad
[10:42:02] <RikusW> you can alternately pull the leads out bit by bit
[10:47:40] <bss36504> The worst is when you rip the plating out of a hole and tear the traces in the process..
[10:49:44] <RikusW> on multi layer it will be worse
[10:50:09] <bss36504> That it is.
[11:23:57] <nbrt> If you get stuck when writing because TWI_SR_TXRDY is never getting set for any byte, what could be a typical problem?
[11:26:45] <nbrt> For I2C that is
[11:51:56] <gillyh> I'm semi-new to digital stuff, have experience on coding but not on embedded where one actually has to give more than a single f**k about resources. Building an mp3 player, a mega32 reading a card and feeding that to a sta013. I'd also like to add in a simple lcd interface. Got one parallel 128x64 sitting there. I'm wondering, if the m32 @ 16 MHz is capable of handing all this without delays in audio output
[11:52:19] <gillyh> Moreover, I'm just kindly asking for some software pointers, and if anyone has a clue on whether I should invest in a sturdier chip for this
[11:52:57] <tzanger> if you're using a hardware decoder chip you need next to zero microcontroller resources
[11:53:07] <tzanger> it's just a data pump really and whatever frills you want to add
[11:53:55] <gillyh> Well, I'm guessing I need to buffer the reads out of the card...
[11:54:05] <tzanger> depending on how slick you want to do it you might be ablet o clock the data directly from the SD card to the decoder, but I'm pretty sure there's no buffer memory on the decoder chip so it won't work as well as it should
[11:54:11] <Casper> check the decoder IC datasheet first
[11:54:20] <Casper> I beleive some also take care of the sd card
[11:54:20] <gillyh> sta013 isn't documented all that well
[11:54:40] <tzanger> basically what I expect you will be doing is implementing a FAT32/VFAT filesystem driver to actually interpret the sector data coming out of the SD card
[11:54:43] <gillyh> however, studies suggest it pulls data amounting to one mp3 frame, and buffers a second one
[11:55:19] <tzanger> to access the SD card you'll want to write a little SPI driver, but between them woudl be a little thin layer which does the SD interaction
[11:55:19] <gillyh> and when it needs data, it asserts a pin
[11:55:43] <gillyh> I have a little spi driver, I could demo it right away
[11:55:46] <tzanger> how big is an MP3 frame?
[11:55:56] <gillyh> depends on the sample rate I think
[11:55:59] <tzanger> sure
[11:56:41] <tzanger> but that's the first questions you should be asking, since if the frame is > 512 bytes (your SD sector size) then you'll end up buffering since I think it would be more challenging to find the next sector to read quickly enough
[11:56:45] <tzanger> I coudl be wrong though
[11:57:00] <gillyh> what you can do is
[11:57:02] <tzanger> better to just have enough RAM in the micro to buffer a sane amount
[11:57:12] <gillyh> yeah well the card part is down
[11:57:33] <gillyh> when you search the fat
[11:57:34] <tzanger> then you have to "threads" (not really threads) which read sectors from the card which contain audio data and shuttle data out to the decoder as long as it can accept data
[11:57:46] <gillyh> you can simply write the clusters to a buffer in advance
[11:57:54] <gillyh> and then go through those sectors
[11:57:57] <gillyh> so that's not an issue
[11:57:57] <tzanger> yep
[11:58:03] <tzanger> so what is the issue?
[11:58:16] <gillyh> the issue is, the "threading part"
[11:58:24] <gillyh> I'm really lost with this :(
[11:58:27] <tzanger> oh that's not as difficult as you think it is
[11:58:35] <tzanger> you can do it the quick and dirty way first
[11:58:40] <tzanger> have a 1ms timer interrupt first
[11:58:59] <tzanger> you always need a timer itnerrupt because sooner or later, you'll have to do state machines.
[11:59:13] <tzanger> and besides, it's essential for blinkenlights, keypad decoding and a host of other things
[11:59:56] <gillyh> please continue, as stated i'm a bit more of a hardware type of engineer =D
[12:00:29] <tzanger> your main loop (quick and dirty) is something like this: while (decoder_wants_data) { write_data_to_decoder(); }; if (buffer_avail >= 512 bytes) { read_sector_from_card(); }
[12:00:55] <tzanger> that is the quick and dirty. it's not how you'd probably want to do it as a final design but that should get you audio
[12:01:31] <tzanger> the way I wrote that will drain the buffer as fast as possible (assuming again that the decoder does not take more than it neeeds to get through the frame and buffer the next) and then give the SD card an opportunity to fill the buffer by 512 bytes.
[12:01:52] <gillyh> i think you mean buffer_avail =< 512 b?
[12:01:58] <tzanger> the sd card access is more or less hard-limited by that one sector transfer, which may or may not be enough. again depends on how the decoder fifo levels work
[12:02:05] <gillyh> I mean buffer_avail <= 512?
[12:02:09] <tzanger> no
[12:02:16] <tzanger> if there isn't room in the buffer for a sector, don't transfer a sector
[12:02:26] <tzanger> that simplifies your code because you don't need to try to track partial sectors
[12:02:32] <tzanger> you just read a sector when you have room to store one
[12:02:48] <beaky> is it a good idea to ground input pins
[12:02:54] <beaky> what about output pins
[12:03:00] <gillyh> sure is
[12:03:14] <gillyh> gets you cooking real fast
[12:03:23] <tzanger> beaky: output pins can float since you're driving them. input pins shoudl be tied high or low through a 100-1000 ohm resistor (to prevent oopses when you inadverdently make it an output and drive it to the other rail)
[12:03:56] <beaky> but i always ground them since I use them to bink leds
[12:04:01] <tzanger> prototypes shoudl never tie a pin directly to a rail. You never know when you need that pin becaues of a design change/goof and if it's got a resistor there it's trivial to use the pin
[12:04:01] <beaky> or is that different
[12:04:13] <vsync_> yes. try is. Ground the output straight
[12:04:17] <vsync_> try it*
[12:04:25] <vsync_> see what happens
[12:04:31] <tzanger> don't tease the lad
[12:04:36] <vsync_> sorry
[12:05:00] <tzanger> obviously you don't want to tie an ouptut to a rail, even if you're driving it to the same rail. There's nothing useful to come of that
[12:05:28] <gillyh> tzanger: pardon my stupidity. I still don't get it. What's buffer_avail exactly?
[12:05:41] <tzanger> and similarly don't tie inputs directly to the rails because you never know when you might need it. use resistors, they're cheap, and even 0805 surface mount resistors are trivial to solder with tweezers and any iron
[12:05:58] <tzanger> gillyh: buffer_avail is the number of bytes available for writing into the buffer
[12:06:03] <tzanger> yes I can see now how that's confusing :-)
[12:06:09] <beaky> is there really a diference between using PORTX and PINX for i/o
[12:06:09] <tzanger> buffer_free might be a better name
[12:06:18] <tzanger> yep
[12:06:18] <beaky> or are they the same and just naming conventions for intent
[12:06:27] <tzanger> PORTx is the latch value... whqat you wnat it to be
[12:07:06] <beaky> in the libc source they are #defined similarly
[12:07:06] <tzanger> PINx is the actual state of the physical pin (actually the level seen by the input pad)
[12:07:08] <beaky> aha
[12:07:27] <tzanger> beaky: an example: set PORTx to 0 but have the pin tied to +V. reading PORTx will say the pin is low, but you will have a meter on it saying "no it's not, stupid AVR, who writes this garbage?"
[12:07:37] <gillyh> tzanger: So, you keep track of the remainer of the file with it?
[12:07:38] <tzanger> (that's assuming you don't blow out the driver by short circuiting it :-)
[12:07:50] <gillyh> remainder*
[12:07:50] <tzanger> gillyh: no, the buffer has no concept of file
[12:08:13] <tzanger> gillyh: the buffer is just the storage area for data going to the decoder, nothing more
[12:08:19] <gillyh> yes, got it
[12:08:46] <tzanger> obviously your logic would have to get a little more involved for end of file, since buffer_free will grow above 512 as the last frame(s) of the song play out and there is no more data to play
[12:09:02] <tzanger> so the loop gets a little more involved, but that loop should get you started and making noise
[12:09:44] <tzanger> (I find for myself it's always good to start simple, get a little bit of success behind me, then start adding on complexity/features)
[12:09:51] <gillyh> God i must be retarded. Still wondering where you pull the buffer_free from
[12:09:51] <tzanger> and commit your code to your lcoal git repository OFTEN
[12:10:25] <tzanger> because when you add a fewture and all hell breaks loose and you're pulling out your hair screaming "BUT I ONLY CHANGED ONE LINE" you can look at the commit logs and diffs and realize what actually changed. :-)
[12:10:33] <tzanger> Not that I'm speaking from experience or anything on that one... nooooo.
[12:11:11] <tzanger> buffer_free is just a variable that stores the number of bytes that can be written to the buffer
[12:11:34] <gillyh> Okay. the wording eludes me.
[12:11:44] <tzanger> write_data_to_decoder() increases the number in that variable by the number of bytes it takes out of the buffer when it writes them to the decoder
[12:12:07] <tzanger> read_sector_from_card() subtracts 512 from that variable every time it writes a sector itno the buffer
[12:12:32] <tzanger> a very quick and dirty implementation of write_data_to_decoder() might look like this:
[12:12:42] <gillyh> yeah okay that makes sense
[12:13:50] <gillyh> might have to tune that somewhat, according to the mp3 frame size or so
[12:14:02] <tzanger> write_data_to_decoder() { while (buffer_avail < BUFFER_MAX) { if (decoder_wants_data) { byte d = buffer[rp++]; xfer_data(d); buffer_avail--; } }; }
[12:14:40] <tzanger> (you will need to implement proper FIFO wrapping ofr the read pointer and buffer_avail < BUFFER_MAX has to be rewritten because I switched from a FIFO to a ring buffer halfway through writing that, but you get the idea
[12:15:37] <tzanger> How I would do it if it were me would be to have two "threads" -- one which fires from an interrupt when the decoder says it wants data, and one which fires periodically (say every 10ms) if the song is not done and there is room in the buffer
[12:15:52] <tzanger> that would keep the buffer as full as possible and dump data to the decoder as often as it can handle it
[12:16:22] <gillyh> now there's an idea!
[12:16:38] <beaky> how do I reduce the interference of pwm on the power signals
[12:16:43] <tzanger> like I said though... start simple. get noises. gain some success
[12:16:53] <tzanger> then start complicating it with asynchronous logic. :-)
[12:16:57] <gillyh> I think I read something along the lines of 320kbps/48kHz being ~24ms per frame or so
[12:17:11] <gillyh> so after the initial transfer you can time the interrupt
[12:17:33] <gillyh> tzanger: got time for one more? I'm very thankful though, this has helped a bunch already!
[12:17:34] * megal0maniac_afk hears the sweet sound of I2S
[12:17:43] <tzanger> I wouldn't care about the timing; I would just have to make sure that I can read data from the card fast enough to keep the buffer more full than the decoder can suck it out
[12:18:18] <gillyh> the spi bus, is the max freq at fsck/2?
[12:18:24] <gillyh> has to be i guess
[12:18:32] <tzanger> megal0maniac_afk: I've unfortunately heard the scratchy harmony of DTS audio played without being decoded. :-)
[12:19:11] <tzanger> gillyh: that'll be in the datasheet. I'm not sure offhand. It's usually ioclk if it's a master but that depends on the specific part
[12:20:04] <gillyh> yeah. just wondering about the xfer rate
[12:20:08] <gillyh> I guess it'll be 'nuf
[12:20:30] <gillyh> well thanks a bunch!
[12:20:35] <gillyh> cya and take care!
[12:23:11] <N1njAway> megal0maniac_afk: Isn't it nice when digital audio starts flowing through a circuit correctly? :D
[12:23:48] <tzanger> grr
[12:23:56] <tzanger> mavericks screwed up my iterm2 fonts
[12:24:23] <vsync_> beaky | is it a good idea to ground input pins'
[12:24:29] <vsync_> this should be in the topic tbh
[12:24:41] <vsync_> theBear: help us out please. to ground or not to ground?
[12:24:52] <N1njAway> Ground unused inputs, yes :)
[12:24:55] <vsync_> no ffs. that was for inputs
[12:25:04] <vsync_> godd
[12:25:15] <vsync_> w
[12:25:26] <vsync_> well the one i was after was the next one where he asked about output pins
[12:25:28] <vsync_> ...
[12:27:48] <N1njAway> vsync: I want to attach SATA directly to PORTB and bit-bang it. Do you think that will be fast enough?? :D
[12:28:42] <vsync_> hmm
[12:28:59] <vsync_> cannot think of a clever retort
[12:30:23] <tzanger> N1njAway: you could conceivably make a SATA-to-SPI bridge...
[12:30:59] <vsync_> what you should do
[12:31:00] <vsync_> issss
[12:31:44] <vsync_> run one data line to mux
[12:31:50] <vsync_> and bit bang the sata
[12:31:59] <vsync_> hard mode
[12:33:51] <N1njAway> Hi BSS!
[12:34:03] <bss36504> Hi N1njAway
[12:34:06] <bss36504> :D
[12:34:36] <N1njAway> vsync and I were just talking about wiring SATA directly to PORTB and bit-banging it. I think this is a super-great idea! What do you think? :D
[12:35:04] <N1njAway> An ATTINY might just have enough pins, too - one I/O for each SATA pin. Perfect plan.
[12:35:35] <bss36504> Oh jeez. that sounds like a swell plan
[12:35:42] <bss36504> It certainly wont be fast.
[12:35:46] <bss36504> but it might work.
[12:36:00] <GargantuaSauce> bitbanged sata on an attiny
[12:36:08] <GargantuaSauce> that is absolutely ridiculous
[12:36:09] <GargantuaSauce> i love it
[12:36:24] <bss36504> What did you want to do with the data once it's sata'd? SPI to another MCU?
[12:36:53] <vsync_> heya bss36504!
[12:37:16] <bss36504> wow, people know me here now :')Hey vsync_
[12:40:15] <bss36504> This sounds like a neat idea for shure
[12:40:27] <bss36504> wow, did I really just write "shure"
[12:40:32] <bss36504> kill me.
[12:40:52] <bss36504> that couldn't have been any more ronger.
[12:47:11] <tzanger> ronger lol
[12:47:33] <bss36504> ronger, Roger.
[12:47:55] <vsync_> shure makes pretty nice IEM's
[13:08:32] <N1njAway> Who calibrates the calibration?
[13:08:52] <vsync_> jesus
[13:12:26] <N1njAway> I mean, what if someone forgot to properly calibrate mathematics in the beginning, and that's why we can't divide by zero!
[13:15:13] <vsync_> s/someone/buddha
[13:15:42] <bss36504> blowing my mind right now N1njAway
[13:16:18] <bss36504> http://i.imgur.com/GTdVD4o.gif
[13:21:20] <N1njAway> What if my RULER has become uncalibrated.
[13:21:30] <N1njAway> I'm going to start a business, selling calibrated rulers, made out of Invar
[13:21:41] <N1njAway> JUST TO BE SURE
[13:22:24] <bss36504> good call
[13:23:04] <N1njAway> It should be usuable to measure things immersed in liquid helium just as accurately as things in a furnace.
[13:26:57] <vsync_> i'm going to start selling calibrated air
[13:27:31] <vsync_> air is pretty much what everyone sells today anyway
[13:31:37] <N1njAway> bss: GIF -- hate when that happens, because you have to call in HAZMAT to clean up, and those guys are expensive.
[13:33:11] <vsync_> you have to call samuel l. jackson cause he's the cleaner
[13:34:52] <N1njAway> "This IS one tasty burger!"
[13:38:19] <beaky> how do I limit current draw of avr
[13:40:39] <N1njAway> beaky: Install a 1/4 turn ball-valve on the VCC pin. That's what I do. :D
[13:40:43] <beaky> ah
[13:40:47] <beaky> what is that
[13:40:50] <beaky> i am new to electronics
[13:41:07] <beaky> all I know is ohms law
[13:41:10] <N1njAway> Your question is a bit general - we need specifics
[13:41:54] <beaky> nothing is physically stopping me from drunkenly coding my firmware to use 32 outputs on 32 leds and exceeding the current rating of the uC
[13:42:19] <beaky> so i want to add some hardware components to protect from that
[13:42:25] <beaky> its just good design(tm)
[13:42:39] <beaky> (to cover bad firmware design ^^)
[13:50:26] <N1njAway> beaky: The AVR will internally limit the current to the LEDs. As you turn more and more on with the port, you'll see the entire port getting dimmer.
[13:50:37] <beaky> ah
[13:50:41] <beaky> didnt know it was self regulating
[13:50:49] <beaky> i mean self current-limiting*
[13:52:23] <N1njAway> Better to run external LEDs with transistors if you need consistency.
[13:52:50] <N1njAway> Or a dedicated constant-current driver if you need precision
[13:53:07] <beaky> I love mosfets
[13:53:20] <vsync_> why exactly do you love them?
[13:53:29] <vsync_> You seem to love a lot of things. Such as PWM
[13:53:30] <beaky> mosfets let my arduino do more with less
[13:53:46] <vsync_> good description
[13:54:09] <vsync_> Here's an idea
[13:54:20] <N1njAway> Arduino lets my mosfets to less with more.
[13:54:23] <N1njAway> +do
[13:55:14] <vsync_> build an smps for your arduino, pwming a mosfet. PWM (= more with less) * MOSFET (=more with less) = more with less^2
[13:55:19] <N1njAway> Actually, Arduino sometimes depresses my mosfets, and my efficiency drops.
[13:55:53] <bss36504> amen N1njAway. If all you know is ohms law, then you are missing out on the true power and limitations of any transistor. Arduino is just canning low level operations and impeding your full understanding.
[13:56:07] <N1njAway> vsync: So it's more or less equal to more with less squared.
[13:56:20] <vsync_> MOSFET = MOre w/ lesS FEkkin tru
[13:56:40] <vsync_> tru has a capital T
[13:56:48] <N1njAway> bss: Canning it like a TO-39, even
[13:56:54] <beaky> i love ohms law because it is so simple
[13:57:01] <beaky> v = ri
[13:57:11] <vsync_> this is so funny
[13:57:15] <beaky> thats all there is to it, and you know 99% of electronics by working up from that
[13:57:15] <vsync_> it's beyond that
[13:57:28] <beaky> there is beyond ohms law?
[13:57:32] <theBear> mmm, generally in digital land the rule is to gnd ANY unused/floating inputs on EVERYTHING... tho in avr land you could alternatively turn on the internal pullup or just set the port to output, probly pullup is less intrusive/'nicer'
[13:57:37] <vsync_> this is beyond funny
[13:57:46] <theBear> beaky, have you been drinking today ?
[13:58:01] <vsync_> beaky: I think you should have revised ohm's law before smoking stuff with the shunt eh?
[13:58:11] <vsync_> or does that fall into the odd 5%
[13:58:12] <bss36504> you might say that, N1njAway :P beaky, you gotta start with ohms law, but there is a hell of a lot more to learn, especially with semiconductors. Just wait till you do some ultra high frequency analysis too. Those nice, linear resistors suddenly have inductance and capacitance.
[13:58:18] <N1njAway> Light emitting resistors
[13:58:25] <vsync_> N1njAway: :D
[13:58:33] <vsync_> oh my god, best of the evening
[13:58:33] <bss36504> N1njAway: that would make millions
[13:58:56] <N1njAway> bss: You HAVE made one before, right? They're generally one-time use.
[13:59:01] <vsync_> bss36504: not that hard. The photon emission just usually shows up as a quick burst :(
[13:59:05] <vsync_> rather than a constant beam
[13:59:08] <beaky> yeah i need to sleep
[13:59:18] <bss36504> right, when you pass too much current through
[13:59:20] <bss36504> :P
[13:59:28] <bss36504> beaky: maybe a good plan
[13:59:33] <bss36504> hey guys, I love lamp.
[13:59:35] <N1njAway> I also like smoke-emitting diodes, too.
[13:59:38] <vsync_> you can pretty much make light emitting anything
[13:59:46] <N1njAway> People don't realize they moonlight as fuses.
[13:59:55] <beaky> i smoked my arduino because I was too sleepy to notice my wrong connections
[14:00:02] <vsync_> :D
[14:00:03] <beaky> now im left with plain avr :(
[14:00:05] <bss36504> how did you manage that?!
[14:00:12] <bss36504> cant you fix it?
[14:00:14] <beaky> I reversed connected the +5V and GND
[14:00:23] <bss36504> they have a protection diode I thought...
[14:00:28] <vsync_> ohm's law doesn't have a chapter on that
[14:00:28] <beaky> arduino hates that, everything on it died
[14:00:30] * theBear looks at the rizzla packet and the lighter
[14:00:31] <bss36504> and a polyfuse
[14:00:32] <N1njAway> beaky: Yeah, most people don't realize that you can upgrade Arduino's like that.
[14:00:38] <theBear> damn, you'd need to be REAL sneaky to smoke an arduino
[14:00:42] <beaky> upgrade? heh
[14:00:47] <vsync_> yeah. Once you smoke them they actually become useful
[14:00:51] <bss36504> you have liberated that AVR. be free young 328, be free!
[14:00:54] <vsync_> you can get a few nice smd leds and stuff out of them
[14:01:02] <beaky> aren't those smoked
[14:01:05] <beaky> since i smoked the supply
[14:01:13] <N1njAway> Smokes salmon, smoked Arduino. Both avaliable in the freezer section of your local store these days, it seems.
[14:01:18] <N1njAway> +Smoked
[14:01:21] <theBear> bss36504, heh good call re: lamp ... even the name almost matches... "beaky, are you just looking around the room and saying you love things you see ?" "i love lamp" <grin>
[14:01:30] <vsync_> i love smoked arduino
[14:01:47] <N1njAway> Especially ones with extra SRAM seasoning
[14:02:03] <beaky> i will go shop for a new uno
[14:02:09] <vsync_> sure you will
[14:02:11] <bss36504> (in Forrest Gump style) Smoked arduion, fried arduino, boiled arduino, arduino with gravy...
[14:02:16] <vsync_> :DDD
[14:02:23] <beaky> ask my mom for credit card to order an arduino from sparkfun
[14:02:26] <vsync_> dear god i'm too tired
[14:02:28] <theBear> damn, i wonder how you accidentally put your arduino in a metal thing after preparing some nice slow smouldering fancy-wood-chips underneath and leave for several hours or even days without noticing :)
[14:02:41] <vsync_> beaky: you didn't just say that
[14:03:02] <N1njAway> I want a little tiny roast the size of a thimble, that I can place atop an ATMEGA2560 and cook at 12V for 5 hours.
[14:03:02] <bss36504> beaky: How is it THAT broken? Say what you will about the IDE and framework, but the hardware is pretty well designed. They have circuit protection.
[14:03:17] <beaky> well, i connected the power lines backward,
[14:03:35] <beaky> 12V to GND, and the other line of my battery to +5V
[14:03:35] <vsync_> just get a 328 and save your mom a dime
[14:03:40] <N1njAway> That's why you need to use AC mains - you can't connect them backwards :)
[14:03:58] <beaky> my fault for trying to build switching supply with arduino
[14:04:06] <vsync_> yep. i power my avr's straight from mains. Beaky, it's worth a shot. It might resurrect your avr
[14:04:21] <theBear> err, that's not backward, that's just crazy
[14:04:24] <beaky> yeah i might try building a proper power supply
[14:04:36] <beaky> once i am more careful :D
[14:04:46] <vsync_> you just need two wires...
[14:04:54] <vsync_> between the mains socket and the supply pins
[14:04:54] * theBear is slightly shocked by this fast moving sequence of near unbelievable statements
[14:04:56] <N1njAway> vsync: That would be an amusing one - figure out how to power an AVR directly from mains through a full-wave rectifier AND then take mains through a 1M resistor and clock the part at 50/60Hz
[14:05:09] <OndraSter> uhm
[14:05:11] <OndraSter> safety :D
[14:05:21] <vsync_> N1njAway: who said anything about rectifiers or resistors... at least not that big!
[14:05:36] <N1njAway> If there's one thing Mike Rowe from Dirty Jobs taught me, it's that safety comes third.
[14:05:54] <beaky> safety comes after low cost
[14:06:04] <bss36504> beaky: oh of course you probably connected to the VIN pin which has no protection, so yeah, it might be toast. Still, probably only the regulator
[14:06:05] <theBear> someone did a nice little pcb up months ago, got it locally somewhere... the something-shield, nice pcb layout/overlay cad with some nice text and the little shield connector or whatever the stupid things use at one side, and big fat solder pads in the shape of mains pins take up the rest of the board :)
[14:06:21] <beaky> hmm i thought the +5V pin is unregulated
[14:06:27] <beaky> so it will go through everthing
[14:06:38] <N1njAway> vsync: You wire up the AVR with the comparator with auto-sleep interrupt, so you just wake the AVR up and run it when the AC Mains voltage is between 1.8v and 5.5v, and then put it back to sleep.
[14:07:36] <theBear> N1njAway, hmm, now you mention, my coffee machine that is currently dead-micro waiting for me to fix things, definately sat off mains unisolated, single diode and zener after big resistors and series cap trick, and i can't actually remember seeing a crystal on there, or maybe i'm just tired :) not an avr, but similar genericey kinda small dip micro i had never heard of before
[14:07:37] <vsync_> the uno even has a linear reg doesn't it?
[14:07:49] <beaky> yes, but it works for USB and for the DC jack
[14:07:50] <bss36504> Wait, explain again which pins you connected where? You put +12V on gnd and 0V on the +5?
[14:07:56] <beaky> yes
[14:08:06] <bss36504> Thats a bad Idea. Use the vin pin
[14:08:07] <beaky> i reversed them and forgot the +5 is unreglated
[14:08:10] <bss36504> yeah
[14:08:21] <beaky> everything became very hot
[14:08:23] <theBear> that's what i was thinking, no doubt there's a nice little 2 pin power header ?
[14:08:35] <vsync_> beaky: will it work for a dc jack out of mains?
[14:08:37] * theBear proudly has almost zero knowledge of arduinos, and doesn't love them at all
[14:08:45] * theBear loves 8bit avrs :)
[14:08:54] <beaky> yes it works from mains since it has an onboard regulator
[14:08:59] <beaky> like the stk500
[14:09:04] * theBear giggles
[14:09:06] <vsync_> :D
[14:09:09] <bss36504> I would totally use an Arduino board as a dev platform, just not as an arduino.
[14:09:22] <theBear> and THAT kinda statement is exactly why i say you shouldn't be giving out advice in the electronics channel
[14:09:23] <vsync_> i would totally power arduino out of mains, cause it has a reg on board
[14:09:37] <beaky> well, mains through a DC supply
[14:09:39] <theBear> vsync_, oh it works, like you said, there IS a reg
[14:09:50] <bss36504> Why, the board is fairly solid and pretty adaptable, plus there is a host of shields that are all pretty well designed as well.
[14:10:07] <bss36504> Its nifty, but the software framework is sad
[14:10:09] <theBear> ooooh, my mobo has lots of regs on it, i could save 50 bucks buying a big fancy new supply, it'll run off mains :)
[14:10:10] <beaky> i wish I could make my own boards rather than just use arduino
[14:10:29] <beaky> but i dont know how to etch at home
[14:10:35] <theBear> first step to making your own boards is not using the word arduino =>1 times a sentence
[14:10:37] <bss36504> beaky: You can. Download EAGLE and find a board fab. I use OSHPark
[14:10:45] <bss36504> theBear: That too
[14:11:10] <beaky> yeah i see OSHPark advertised on electronics.stackexchange.com and they seem to have a good deal for hobbyist folks who want to make PCBs
[14:11:23] <vsync_> stackexchange is surely the place
[14:11:35] <bss36504> very good. $5/square inch and you get 3 boards for that price.
[14:11:47] <beaky> a square inch is the dimension of arduino?
[14:11:52] <vsync_> yeah
[14:11:58] <theBear> it is ?
[14:11:59] <bss36504> no, a square inch is a square inch.
[14:12:03] <vsync_> :DD
[14:12:03] <beaky> ah :(
[14:12:07] <bss36504> 1 inch by 1 inch.
[14:12:15] <bss36504> I'm in the USA, btw
[14:12:17] <vsync_> I think i'm gonna start using arduinos as my power supplies
[14:12:33] <theBear> i don't even know what avr is on an arduino, but seriously ? usb socket, 2nd chip for usb/serial translation, main avr and reg in 1inch square ?
[14:12:33] <bss36504> I dont know of hobbyist board fabs outside the US
[14:12:40] <vsync_> I can hook em up to a 12 v batt and then i can light up all of my led strips around here
[14:13:18] <vsync_> wait
[14:13:20] <vsync_> wth
[14:13:30] <vsync_> i meant hook it to mains
[14:13:50] <vsync_> theBear: yeah it's a true SoC
[14:14:19] <bss36504> true SoC....
[14:14:20] <bss36504> ok
[14:14:22] <theBear> is this original version or some newer version ?
[14:14:37] <vsync_> beaky: think of all the money saved, when you can get 3x 1"^2 boards for 5$? Instead of taxing on your mom's wallet with arduinos from sparkfun
[14:14:39] <bss36504> The "original" is way old
[14:15:09] <beaky> the upcoming arduino (forgot what its called) does have an arm soc
[14:15:15] <beaky> (or was it intel?)
[14:15:18] <N1njAway> Man I do love this newer Pace iron. Room temperature to 650F ready in 12 seconds XD
[14:15:26] <bss36504> theBear: check this out:
http://arduino.cc/en/Products.Compare
[14:15:33] <beaky> wow awesome iron mine takes half an hour to warm up
[14:15:46] <vsync_> N1njAway: f**k pace. Weller's where it's at
[14:15:47] <theBear> meh, it doesn't really matter, even if they made the most nicely laid out and feature perfect well built super awesome avr board in the world ever to end all others, i still wouldn't use them on principal :)
[14:15:58] <theBear> but i suppose i could click that link this one time
[14:16:07] <Tom_itx> dare ya
[14:16:21] <N1njAway> vsync: Pace is all USA made, and if anything goes wrong they send me replacement parts. :)
[14:16:27] <bss36504> vsync_: truth. My WESD51 has served me well
[14:16:37] <bss36504> Then again, I've never owned a Pace
[14:16:44] <beaky> maybe i should buy a weller instead of an arduino
[14:16:47] <theBear> damn they a lot of different models now ! and i suspect every single one is an avr that didn't exist the last time i bought some :)
[14:16:49] <beaky> i already have ATmega328ps
[14:16:49] <N1njAway> Everything here at the shop is Pace. I'll never buy otherwise. Some of the hot-air stations are 10+ years old and in perfect working condition.
[14:17:05] <Tom_itx> wtcpt ftw
[14:17:08] <vsync_> weller's german.
[14:17:12] <vsync_> nuff said
[14:17:23] <Tom_itx> weller is cooper tools
[14:17:39] <beaky> cooper tools?
[14:17:50] <N1njAway> bss: The WJS100s, the tip assembly is quick-change. Entire tip, heater, and thermometer is all integrated in to a single assembly that hot-swaps in and out. Total replacement cost is $10 for the entire active tip!
[14:17:58] * Tom_itx hears an echo in the channel
[14:18:31] <N1njAway> And since it throttles down to about 350F once it's idle for about a minute, the tips last forever, especially with lead-free
[14:18:42] <vsync_> actually yes
[14:18:58] <Tom_itx> i've replaced one tip since i had my iron
[14:19:07] <beaky> http://www.apexhandtools.com/brands/CF_Files/model_detail.cfm?upc=037103059963 this is what im use
[14:19:08] <Tom_itx> and that's because i misplaced it
[14:19:36] <vsync_> I haven't replaced mine in say five years. But now it's finally giving up
[14:19:52] <Tom_itx> mine's at least 15yrs old
[14:19:58] <bss36504> N1njAway: thats a nice iron, also double the cost of my WESD51. I like mine a lot, but that pace sure does look nice
[14:20:22] <bss36504> I haven't been alive long enough to own my own iron for 15 years, so there's that. ask me again in 10.
[14:20:49] <megal0maniac_afk> I bet nobody has the same one as me :)
http://www.magnumproducts.co.za/magnum_Soldering_Iron_1220.html
[14:21:09] <megal0maniac_afk> Except for Rikus. His is also Magnum, but a proper station. Locally made and pretty decent
[14:21:29] <vsync_> I know of a brand called magnum...
[14:21:38] <megal0maniac_afk> Rudimentary, but it gets mostly everything done with the right tip and enough patience
[14:21:48] <megal0maniac_afk> vsync_: Guns? Ice cream? :P
[14:21:51] <Tom_itx> i've got a magnum too
[14:21:56] <Tom_itx> but it's a 357
[14:22:06] <megal0maniac_afk> Tom_itx: Do you really, though?
[14:22:14] <Tom_itx> yep
[14:22:20] <Tom_itx> 6 shot magnum
[14:22:26] <megal0maniac_afk> That's a pocket rocket
[14:22:27] <vsync_> okay things just got real
[14:22:31] <bss36504> Was that unbelievable, megal0maniac_afk?
[14:22:35] <N1njAway> bss: It's definately nice. All of the stuff is Pace, so it's useful in having dozens of replacement tips around. Lead-free eats them up fairly fast on the non-throttling ones.
[14:22:47] <bss36504> hmm good to know.
[14:22:51] <megal0maniac_afk> bss36504: He's in the land of people with guns, as my stereotypes go, so no :)
[14:23:01] <Tom_itx> not quite pocket size
[14:23:04] <Tom_itx> 6" barrel
[14:23:08] <megal0maniac_afk> I have big pockets
[14:23:12] <vsync_> you and your inches...
[14:23:31] <bss36504> N1njAway: I just made the switch to lead free, so I probably have a good bit of lead in my body. More worried about that than tips.
[14:23:43] <bss36504> vsync_: 0_0
[14:23:48] <vsync_> i can't stand lead free
[14:23:53] <Tom_itx> that's just silly talk
[14:23:54] <vsync_> you need a ton of flux for it
[14:24:12] <Tom_itx> and a hotter tip
[14:24:19] <bss36504> megal0maniac_afk: oh, i guess I am too. I live in the sticks of the northeast US
[14:24:33] <Tom_itx> more chance of screwing up a trace or component
[14:24:40] <vsync_> yep
[14:25:11] <bss36504> I run at 650F (343C), how about you guys?
[14:25:13] <megal0maniac_afk> bss36504: I was talking US in general. I don't know it well enough to specify
[14:25:21] <megal0maniac_afk> 350C
[14:25:22] <vsync_> and well. tried a few different lead free's. I just think leaded flows better
[14:25:26] <bss36504> haha yeah, I guess we do have guns...in some placess
[14:26:04] <theBear> last few years i've crept up and up, i seldom go below 400c setting and often more like 450c if doing serious stuff (maybe soldering many-layer boards or recapping mobos)
[14:26:05] <vsync_> Wow you're hot. I think I'm like 37 C or so
[14:26:06] <megal0maniac_afk> vsync_: Leaded + 120mm extraction fan = Minimal health risk and much better soldering
[14:26:09] <theBear> heh
[14:26:27] <bss36504> vsync_: 37C?!
[14:26:27] <megal0maniac_afk> theBear: Maybe you're just impatient :)
[14:26:29] <theBear> vsync_, they do say if fever persists, i should see my doctor... maybe they were right
[14:26:42] * Tom_itx eats lead solder like licorice
[14:26:44] <megal0maniac_afk> bss36504 didn't get it... :P
[14:26:49] <bss36504> goddammit, just di.
[14:26:51] <bss36504> did*
[14:27:01] <vsync_> hah
[14:27:08] <vsync_> well theBear it's not bad... yet :)
[14:27:12] <bss36504> had to do the conversion, stupid Fahrenheit dependence
[14:27:19] <theBear> megal0maniac_afk, nah, this is a carefully measured, researched and practiced thing i've moved slowly towards over many many thousands of hours of soldering both for work and play, and have talked over with more than a few fulltime (mainly repair) techs over the years
[14:27:33] <vsync_> megal0maniac_afk: meh. the psu fan of my workshop computer is next to this table, so that works enough. Not really concerned about lead poisoning
[14:27:40] <vsync_> i do my soldering quick, no wanking around
[14:27:54] <N1njAway> I generally run 650-700F for most hand rework here. Everything else runs through the ovens :)
[14:28:07] <theBear> and my soldering IS good/solid, not only visually, but i've got 1000's of repairs across probably 1000's of customers travelling around the country, and my work never cracks/fails/goes bad
[14:28:22] <vsync_> confident are we
[14:28:35] <bss36504> Thats how I feel about temperature. I don't have an oven though, I do have a hot air station
[14:28:37] <theBear> quick isn't bad so long as you still 'follow the rules' re: temps on ALL metals/things involved in the joint, and cooling speeds etc etc
[14:29:09] <N1njAway> theBear: And assuming you don't have moisture-absorption issues to deal with :)
[14:29:10] <theBear> also flux runs out in a few seconds, anything many-layered with huge planes sucking yer heat is a huge hassle manually fluxing during heating
[14:29:13] <megal0maniac_afk> vsync_: Interestingly, at work the extractor fan is a gutted PC PSU with only the fan remaining :)
[14:29:29] <N1njAway> theBear: What kind of solder and flux do you use?
[14:29:30] <theBear> N1njAway, that's when you see bubbles and alter technique :)
[14:29:31] <megal0maniac_afk> The smoke magically disappears into the box
[14:30:02] <N1njAway> We run SAC305 for pretty much everything here, and either RMA, WaterSoluable, or NoClean, depending on the process and application.
[14:30:11] <theBear> damn i used to hate those bubbles when i was less experienced in this kinda thing, just when you think you've finally got it all out and made a nice joint one pops and 'freezes' like a crater at the last moment :)
[14:30:24] <N1njAway> Pastes are type 3/4 SOC305 NC and WS
[14:30:37] <N1njAway> SAC305
[14:31:22] <theBear> N1njAway, usually standard multicomp 1.6mm fluxed, for literally almost everything, recently my forced-retirement hobbies include soldering STUPIDLY small things with stuff like 1,6mm solder, i'm down to comfortably and reliably (and no wicking/messing about) doing .25mm pitch pins with that :)
[14:31:32] <theBear> oh sorry, 60/40, it's late
[14:31:42] <N1njAway> What kind of flux?
[14:32:55] <vsync_> okay armchair engineers here's something for you to ponder upon
[14:32:59] <theBear> umm, i can try to read the label, probly even got an unused(and unreadable label) roll somewhere, i think they call it 5-core or something, just the stock standard been around forever multicomp 60/40
[14:33:14] <vsync_> software engineers need not to answer
[14:33:22] <bss36504> alright
[14:33:30] <N1njAway> Here's some of my finer soldering. Wire-bonding by hand --
https://www.dropbox.com/s/u4rto36es3lbvsw/ledbond.jpg
[14:33:33] <theBear> i recently got a local-hobby-shop rebranded flux 'pen' with some generic no-clean stuff in it, but i seldom use it
[14:34:06] <N1njAway> That is a 100 micron LED die with a 75 micron pad, about half the size of a grain of table salt.
[14:34:25] <N1njAway> The picture in the lower right is in comparison to a US Dime :)
[14:34:27] <vsync_> so. There are these plastic covering pipes, used to protect fluorescent tubes in case they break, so the shattering glass stays inside
[14:34:31] <vsync_> you just slip it over it
[14:34:42] <bss36504> N1njAway: but with a wirebonding apparatus I'm guessing
[14:34:42] <vsync_> they are called, surprisingly, fluorescent tube covers
[14:35:01] <N1njAway> No, by hand with solder paste - about 3-4 balls :)
[14:35:09] <bss36504> vsync_: II'll bite...
[14:35:19] <theBear> N1njAway, heh, it ain't a challenge unless you use 1.6mm solder <grin>
[14:35:23] <vsync_> Now i need to make one into a pressure vessel. I already know how I will reinforce the tube itself, however I need a way to seal it
[14:35:31] <N1njAway> Though I'd like to get a wedge-bonder in here at some point :)
[14:35:33] <bss36504> N1njAway: Alright, I'm impressed
[14:35:50] <bss36504> vsync_: Duct tape
[14:35:58] <vsync_> to withstand 10+ bars, that's umm. ~150 PSI for you americans?
[14:36:11] <vsync_> or 160, 170, 180. You and your god damn units
[14:36:20] <N1njAway> bss: It's actually fun to solder the dies to pieces of 38 gauge magnet wire and hang them from the ceiling, since it results in these wierd ephemeral points of light that hang in space :D
[14:37:46] <bss36504> vsync_: Thats a pretty decent pressure vessel....
[14:37:51] <bss36504> (also thanks for the PSI)
[14:38:01] <vsync_> 150 is correct, checked
[14:38:16] <theBear> all this time on my hands and lack of money really is making me do 'silly' things sometimes, i hand rebuilt the voicecoil on a spotwelded/riveted/generally non-disassemblable dirt cheap crappy 15w hifi speaker last year for example :)
[14:38:19] <bss36504> N1njAway: What compelled you to buy led dies?
[14:38:43] <theBear> americans use psi ? maybe they aren't 100% crazy in their units :)
[14:39:03] <vsync_> bss36504: yup. Rokkits. I'm moving from bottle ones to those slimmer FTC ones :)
[14:39:07] <vsync_> theBear: say what?
[14:39:23] <vsync_> PSI is as american as it gets
[14:40:05] <theBear> really ? TIL <grin> that's my new acronym, i like it..
[14:40:15] <N1njAway> bss: R&D for some custom applications :)
[14:40:36] <bss36504> vsync_: That's gonna be tricky. Maybe some sch. 80 PVC with endcaps?
[14:40:40] <theBear> psi is used for 99% of things here, personally i find when i have meters/options to use either taht psi is just 'easier' 'cos of the resolution without decimals
[14:40:41] <bss36504> N1njAway: neat
[14:40:43] <vsync_> theBear: f you.
[14:40:55] <vsync_> oh, you weren't trolling
[14:40:58] <bss36504> theBear: where are you at?
[14:41:45] <vsync_> here, we pretty much use atm for pressure. Which is almost 1:1 with bars
[14:42:09] <theBear> err, no i wasn't, i must be missing something due to almost exlusive psi-usage-exposure
[14:42:58] <theBear> i got two turntables and a microphone... sorry, reflex reaction to any short sentence involving where and at.. west australia
[14:43:24] <vsync_> yeah. I actually knew they used psi in australia
[14:43:38] <theBear> that crazy beaky guy, the more he learns the more dangerous he becomes, and the way he asks us everything that crosses his mind instead of thinking or using a dictionary or i dunno, THE WHOLE INTERNET, he could at least say goodbye
[14:43:41] <vsync_> but one would wonder where it would originate since it's based on pounds and inches
[14:44:24] <vsync_> and correct me if i'm wrong but i think atm is SI
[14:44:44] <theBear> ahh, when you say it out loud like that, good point
[14:44:59] <theBear> people here just say "psi" not "pounds" when talking
[14:46:45] <vsync_> so far the sturdiest thing i've put together was a fiberglass reinforced bottle rocket withstanding ~12 bars
[14:47:04] <vsync_> that's something like 160 to 170 PSI I think
[14:47:59] <theBear> probly in the ballpark, i don't often do pressure or convert, but i'm always SHOCKED when i see numbers for those common plastic drinkbottles
[14:48:55] <vsync_> the PET bottles are bad. very thin, easily disformed
[14:48:57] <Tom_itx> i'd like to see that ballpark. there sure is alot of stuff that's 'in the ballpark'
[14:49:18] <vsync_> it's a bit over 174 PSI to be precise
[14:49:54] <vsync_> when i've tested those bottles, without reinforcing they seem to burst at around 140-150 psi
[14:50:41] <theBear> Tom_itx, heh, dealing in abstracts, i'm surpised woops, i mean impressed
[14:50:50] <theBear> i been watching yellow submarine and the point too much recently
[14:51:17] <theBear> "what ? just cos i'm a drummer ? i can deal in abstracts if i please <mumble grumble>" <grin>
[15:19:30] <vsync_> N1njAway | I generally run 650-700F for most hand rework here. Everything else runs through the ovens :)
[15:19:32] <vsync_> hmm, funny
[15:22:01] <vsync_> i think a certain adolf went by the same guidelines as you, N1njAway
[16:09:31] <hugogee> Can i run avrdude witha usb to serial adapter? it has a pl2303 chip inside.
[16:10:13] <megal0maniac_afk> hugogee: If the chip is programmed with a compatible bootloader, then sure
[16:11:13] <hugogee> mega10maniac_afk, is there a list somewhere?
[16:12:18] <megal0maniac_afk> hugogee: probably in the avrdude docs? Either way, I'd probably recommend optiboot. It's small and up to date and works
[16:12:48] <megal0maniac_afk> And with the right circuitry you can have the serial cable put the chip into bootloader mode
[16:12:54] <megal0maniac_afk> Without pressing any buttons
[16:13:33] <hugogee> mega10maniac_afk, kinda new to avr. that seems overwhelming to me.
[16:13:37] <hugogee> :D
[16:14:39] <megal0maniac_afk> hugogee: It really isn't
[16:14:43] <megal0maniac_afk> Can you solder?
[16:14:56] <hugogee> maga10maniac_afk, ya been soldering all morn & night.
[16:15:05] <hugogee> ugly but surely, hehe
[16:15:21] <megal0maniac> You need a capacitor and a resistor. That's it
[16:15:29] <megal0maniac> And access to the DTR line of the chip
[16:15:38] <hugogee> maga10maniac_afk, can you shoot me a link?
[16:15:53] <hugogee> DTR??
[16:17:06] <hugogee> i have both cap & res. what *size(s)? if thats even the correcct term-proly not.
[16:17:48] <megal0maniac> hugogee:
http://i.imgur.com/igvNd.jpg http://ariverpad.wordpress.com/2012/02/26/resetting-the-arduino-through-software-for-fun-and-profit/
[16:18:21] <megal0maniac> First link is my PL2303 cable which I gutted (minus power wires, but it's easier to see without them)
[16:18:36] <hugogee> ues i was just reading about it.
[16:19:21] <hugogee> wow that looks simple
[16:19:41] <hugogee> ha i just gutted my pl2303. it was fun!
[16:19:59] <megal0maniac> The optiboot bootloader runs for approx 1s after power on or a reset. The DTR line on the serial cable goes low (like pushing a button) when the serial port is opened on the computer, and the serial port is opened when you begin programming
[16:21:03] <megal0maniac> The cap allows the inital pulse through, but it goes high again once the cap is charged. It's long enough to trigger a reset
[16:21:18] <megal0maniac> http://i.imgur.com/VKKnb.png
[16:21:24] <hugogee> mega10maniac, sounds doable. btw which module would i use with avrdude for this?
[16:21:55] <megal0maniac> arduino I think
[16:22:00] <hugogee> kk
[16:22:03] <megal0maniac> Since it's their default
[16:22:25] <megal0maniac> Yip. Arduino
http://i.imgur.com/ts6P5.jpg
[16:22:30] <hugogee> maga10maniac, great. thank you for the help. i am going to see if i can get this done.
[16:22:32] * megal0maniac is glad he documents this stuff
[16:23:16] <hugogee> mega10maniac, yes i am starting to do the same thing.
[16:23:41] <hugogee> everything in its right place...
[16:24:12] <megal0maniac> Woah! -j is make's new best friend
[16:24:32] <megal0maniac> I need to stop using embedded systems to compile, and use my quad core desktop instead :P
[16:25:27] <hugogee> thats funny
[16:26:01] <megal0maniac> You laugh, but my Seagate Dockstar is a build client for Rockbox
[16:27:01] <megal0maniac> http://build.rockbox.org/data/78c060b-clients.html
[16:27:15] <hugogee> i guess you wont be running out of music anytime soon. sounds cool
[16:29:14] <hugogee> that is funny shit
[16:29:45] <hugogee> When you know what you are doing you are only limited by your imagination.
[16:30:32] <megal0maniac> I'm good at pretending
[16:30:39] <hugogee> hehe
[16:36:27] <megal0maniac> Goodnight!
[16:36:41] <hugogee> so your dockstar writes rockbox to anything you plug into it?
[16:37:09] <hugogee> good night mega10maniac_afk
[16:37:17] <hugogee> thank you for your help.
[16:37:57] <megal0maniac_afk> hugogee: No, my dockstar sits and waits for the build master (server) to request a new build. Then it compiles some stuff from the latest sources, and uploads it to the build client. Put a few machines together doing that, and compiling happens pretty quickly.
[16:38:44] <megal0maniac_afk> Which is how you have compiled versions of rockbox for every single target whenever any change is made to the source, within a few minutes. And my pleasure
[16:39:20] <hugogee> very convenient.
[16:39:40] <hugogee> lazy programmers, hmmpf
[16:39:50] <hugogee> ;P
[16:44:04] <juri_> efficient programmers. :)
[16:44:32] <megal0maniac_afk> juri_: Not with this build client, they aren't
[17:25:43] <qartis> I need a little conceptual help
[17:25:58] <qartis> trying to interface with an sd card while it's plugged into a digital camera
[17:26:17] <qartis> the camera has 50k pullups and 50k pulldowns on all the data lines
[17:26:49] <qartis> if I run my avr at 3.5V, then I can read files off the sd card
[17:27:13] <qartis> if I run my avr at 5V with level converters, then it never works
[17:27:40] <qartis> I think the camera's pullups/pulldowns interfere too much with my FET-based level converter
[17:28:08] <qartis> it's SPI, so 3 of the lines are 5V->3.5V which can be done with a resistor divider
[17:28:16] <twnqx> ugh
[17:28:36] <twnqx> did you ever see single-fet level shifter schematics for that purpose?
[17:28:39] <qartis> but MISO needs 3.5V -> 5V, and I can't think of a configuration that will overcome the stupid interference from the camera
[17:29:19] <qartis> twnqx: like the sparkfun level converter?
[17:29:33] <qartis> twnqx:
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/BreakoutBoards/Logic_Level_Converter.pdf
[17:30:52] <spec_> Yikes! You're messing with the card while the camera has it open?
[17:31:00] <twnqx> yes, nicely copied from the phillips appnote
[17:31:27] <qartis> spec_: camera's battery lines pass through a relay
[17:31:30] <twnqx> but yeah, SPI is not multi-master capable
[17:31:47] <qartis> so the camera is off when I'm using the card
[17:32:09] <twnqx> uhhh
[17:32:12] <twnqx> still
[17:32:17] <spec_> I would be inclined to mux the SPI lines to prevent a collision between masters.
[17:32:19] <qartis> and I turn the avr's SPI lines to HI-Z when the camera is on
[17:32:19] <twnqx> disconnect the camera's i2c
[17:32:20] <spec_> Ah
[17:32:27] <twnqx> even worse
[17:32:42] <twnqx> if there are pullups, your data lines drive the camera's vcc...
[17:33:02] <twnqx> with 25k, but still
[17:33:14] <qartis> yeah, but it's a cheap camera, I'm not worried about damage or lifetime
[17:33:27] <qartis> it's just an experiment to see how cheap I can make it
[17:33:49] <twnqx> why don't you just remove the camera from the equation completely, and only connect the card?
[17:34:11] <qartis> I've tried adding a mux outside of the camera, but the line capacitance killed the camera's (high speed) SD card access
[17:34:27] <twnqx> so.. take the card out from the camera? :S
[17:34:30] <qartis> so I think the only way I can mux the lines is if I can install the mux literally inside the camera
[17:34:36] <twnqx> yeah, likely
[17:34:40] <qartis> ideally looking for a solution that doesn't involve that
[17:34:46] <qartis> because I do have it working now, this way
[17:34:50] <qartis> but only at 5V
[17:35:27] <qartis> it works beautifully, except for the camera's PWR led glows slightly when the AVR is accessing the card.. haha
[17:35:39] <spec_> Hmmmm. Weird that they have both a pull-up *and* pull-down on each line.
[17:35:42] <qartis> but it does work, I'm just having trouble with the level conversion
[17:36:05] <spec_> Although the values are high enough I wouldn't expect interference with what you're doing
[17:36:20] <twnqx> 2.5V baseline for higher switching speed? :P
[17:36:22] <qartis> spec_: I agree
[17:36:31] <twnqx> or 1.75 or whatever
[17:36:41] <spec_> Are you sure the camera is using SPI and not the 4-bit interface?
[17:36:45] <qartis> the camera also drives the SD card at 3.5V
[17:36:47] <twnqx> i saw that on a can bus, looked funny
[17:36:52] <qartis> camera is using the 4-bit interface
[17:36:56] <twnqx> until i realized what it does
[17:37:52] <spec_> Are you resetting the card? Is it possible it's still in 4-bit mode when you try to access it?
[17:38:00] <qartis> definitely resetting it
[17:38:12] <spec_> Do you have a scope?
[17:38:20] <qartis> I use the same procedure whether the AVR is in 5V or 3.5V
[17:38:35] <qartis> the only difference is the system voltage and the presence of the level conversion
[17:38:45] <qartis> SD card is driven at 3.5V in both scenarios
[17:38:56] <qartis> no scope, only logic sniffer
[17:39:07] <spec_> Have you tried slowing the comms to the SD when you're at 3.5?
[17:39:57] <qartis> with the AVR at 3.5V (no level converter necessary) I'm able to go up to the AVR's highest spi speed
[17:39:59] <spec_> maybe that 1.5V difference is enough to make the slew rate mangle the signal
[17:40:19] <spec_> Try slowing it down and see if it'll communicate
[17:40:23] <qartis> with the AVR at 5V (with level converter), I'm not able to use even the slowest SPI speed
[17:40:36] <twnqx> what level converter do you use?
[17:41:01] <qartis> twnqx: a sparkfun one (the schematic I linked), and I've also tried a TI txb0108
[17:42:22] <twnqx> let me quote the data sheet
[17:42:23] <twnqx> The TXB0108 is designed to drive capacitive loads of up to 70 pF. The output drivers of the TXB0108 have low
[17:42:23] <twnqx> dc drive strength. If pullup or pulldown resistors are connected externally to the data I/Os, their values must be
[17:42:23] <twnqx> kept higher than 50 kΩ to ensure that they do not contend with the output drivers of the TXB0108.
[17:42:24] <twnqx> For the same reason, the TXB0108 should not be used in applications such as I2C or 1-Wire where an opendrain
[17:42:24] <twnqx> driver is connected on the bidirectional data I/O. For these applications, use a device from the TI TXS01xx
[17:42:26] <twnqx> series of level translators.
[17:42:26] <qartis> I've also ordered some 74LVC1G125 but they haven't arrived yet
[17:42:32] <twnqx> use TXS
[17:43:02] <qartis> twnqx: yeah.. I did see that
[17:43:16] <qartis> but I can't understand why the FET converter isn't working either
[17:43:41] <twnqx> i can tell you that (without a camera) i use txs0104 for SPI
[17:43:56] <twnqx> successfully :P
[17:44:07] <qartis> hehe
[17:44:14] <qartis> okay, well it looks like that's my best shot for now
[17:44:41] <qartis> twnqx spec_: thanks :D
[17:45:06] <spec_> Np. If I might ask, what camera are you hacking on?
[17:46:01] <qartis> secondhand powershot A540
[17:46:08] <qartis> incredibly robust little camera
[17:46:12] <spec_> Using CHDK?
[17:46:42] <qartis> spec_: I wanted to try that to reduce the camera's IO speed in software, but chdk can't be permanently installed
[17:46:58] <qartis> it needs to load from the SD card every bootup
[17:47:09] <spec_> Yes, but you can make it autoboot into CHDK
[17:47:12] <qartis> which means I still need low-capacitance SD card access
[17:47:33] <twnqx> just emulate the full SD card with AVR MITM
[17:47:35] <twnqx> :3
[17:47:46] <qartis> because the whole point was to slow down SD access so it would have higher tolerance to my meddling
[17:47:50] <spec_> I take it your're working on a solution to clean the card nightly.
[17:48:06] <qartis> spec_: nope, adding a camera to a robot
[17:48:16] <spec_> Hmmmm.....
[17:48:25] <spec_> Cool. Carry on then!
[17:48:29] <qartis> using the camera as a cheap JPEG source
[17:48:47] <qartis> I've also soldered up all of the buttons so the AVR is able to zoom, manual focus, etc
[17:49:07] <qartis> it's pretty neat to see it working
[17:49:12] <spec_> BTW: The CHDK in the German repo has the ability to pull live jpegs from the viewfinder over USB
[17:49:27] <qartis> haha wow
[17:49:29] <spec_> And you can controll the entire camera over USB
[17:49:48] <spec_> So you don't have to molest the hardware quite as much
[17:50:10] <qartis> although I'm not too eager to try working with USB
[17:50:19] <qartis> that would increase the software complexity quite a bit
[17:50:40] <spec_> yeah. I'm *just* starting to wrap my head around it myself
[17:51:59] <spec_> Ideally, I'd like to have a raspberry Pi start and stop CHDK, clean the card off to an attached USB hard drive, and start it again, so I can get months or years of timelapse
[17:52:55] <qartis> that's the beauty of the rpi eh
[17:53:33] <qartis> use all the nice linux features and write something like that in a few lines of python that runs usermode
[17:53:35] <spec_> Totally. Tiny, cheap Linux system you can afford to lose.
[17:54:44] <spec_> I don't know if this appeals to anyone else here, but it might be of interest:
http://www.anandtech.com/show/7387/intel-announces-galileo-quark-based-arduino-compatible-developer-board
[17:55:03] <spec_> Embedded x86
[17:55:15] <spec_> 600MHz, 512MB
[17:55:28] <spec_> Ethernet, SD
[17:55:57] <spec_> My bad, 400MHz
[17:56:19] <spec_> 1 mini PCIe
[17:56:29] <qartis> interesting that it's x86
[17:56:30] <spec_> Expected street price ~$60
[17:56:59] <qartis> I guess it's still in their best interests to push x86
[17:57:03] <spec_> There's already a stripped down Linux distro
[17:57:18] <spec_> Yep. Otherwise ARM is going to eat their lunch.
[17:57:25] <twnqx> lol
[17:57:36] <twnqx> as if arm would ever compete in the lucrative high end
[17:58:10] <spec_> But this isn't high end. it's targeted at the low end embedded space
[17:58:22] <spec_> Mid-end I guess
[17:58:49] <twnqx> i personally would start mid-end at a few ghz of i3 power...
[17:58:56] <spec_> ARM is making head way into the server market, so anything is possible.
[17:59:01] <twnqx> but yes, gallileo is arm competitor
[17:59:09] <qartis> spec_: andrew "bunnie" huang is also working on a bit beefier single-board computer with an integrated fpga
[17:59:36] <twnqx> fpgas aren't necessairly fast, or making things faster
[18:00:09] <qartis> but they're great at what they're meant for
[18:00:16] <spec_> Agreed. Not a CPU replacement.
[18:00:23] <twnqx> large glue logic?
[18:00:50] <qartis> the arduino-equivalent of a dsp
[18:00:57] <twnqx> um
[18:01:02] <twnqx> not really
[18:01:33] <qartis> how so?
[18:01:53] <twnqx> fpgas are plain simple look up tables, flip flops and routing logic
[18:02:04] <twnqx> the more of each you need, the slower they get
[18:02:35] <spec_> There are smaller PLDs for doing glue than FPGA
[18:02:53] <twnqx> well yes, glue with intelligence
[18:03:57] <spec_> A CPLD is more appropriate for doing glue
[18:05:05] <spec_> Or PALs/GALs if you want to get old school
[18:05:15] <twnqx> way too small
[18:05:29] <twnqx> barely address decoders :P
[18:06:00] <spec_> Still, better that it all be in one chip than five or six.
[18:07:56] <twnqx> anyway, bedtime
[18:07:57] <twnqx> nn
[18:08:27] <spec_> Later!
[18:08:40] <qartis> see ya, thanks for your help
[20:33:42] <Valen> lufa question, i'm using the virtual serial demo, is there any simple way to know if its connected or not?
[20:34:04] <Valen> so i know not to send data if the remote buffer is full or whathave you
[21:00:56] <hugogee> If i run an UNO with a usb-ttl cable using avrdude i would only be able to upload sketches,change fusebits, but not update the bootloader? is that correct?
[22:31:03] <Casper> hugogee: correct
[22:31:37] <Casper> actually, I don't know what you call sketches, but you can do everything that the bootloader do
[22:31:52] <Casper> I think the bootloader allow to change the fuses, but that isn't a certain thing
[22:32:16] <N1njAway> Sketches are the Ardunio term for a compiled application.
[22:32:41] <N1njAway> Fuse settings are pretty limited from inside of any bootloader - some you can change, some you can't.
[22:33:13] <N1njAway> I'll still take an ISP header and a $30 ISP-MK2 programmer anyday :)
[22:34:07] <N1njAway> I prefer bootloaders to be locked down quite tightly, so that you absolutely CANNOT brick up a device under any circumstances, in the field. Always a way to get it to force a new firmware accept :)
[22:34:11] <N1njAway> But that's just me.
[22:34:42] <Casper> actually, there is no reason to change the fusebits in the bootloader...
[22:35:01] <Casper> because, any change in the fusebits could result in a non-working bootloader
[22:35:10] <N1njAway> Exactly.
[22:35:58] <N1njAway> From a *development* standpoint, an ISP or JTAG programmer is a far better option, since you can always get to everything, unless you do something dumb like disable reset or the ISP/JTAG interfaces or select an invalid clock :(
[22:36:14] <Casper> actually, not really
[22:36:31] <Casper> set the fuses, flash the bootloader and that's it
[22:36:43] <N1njAway> I mean when developing.
[22:36:44] <Casper> once the bootloader is there, the fuses shouln't be touched anymore...
[22:36:48] <Tom_itx> until you clobber the bootloader
[22:37:05] <Casper> http://imgur.com/QBv44SN ← lie fail :D
[22:37:14] <N1njAway> Tom: The point is to lock the bootloader down once you deploy :)
[22:37:30] <Tom_itx> where's the adventure in that?
[22:37:44] <Casper> N1njAway: there is always ways to fuck up the bootloader...
[22:37:52] <N1njAway> Such as?
[22:37:54] <Casper> like application bug or bootloader bug
[22:38:10] <N1njAway> You are familiar with the AVR lockbits, yes?
[22:38:10] <Casper> the application can write in the flash, wrong address and it may kill the loader
[22:38:21] <N1njAway> No it can't if the bootloader flash sections are locked.
[22:38:29] <Casper> as the bootloader may not verify the flashing address and kill itself
[22:38:50] <Casper> there is also some weird hardware bugs, specially with unstable voltage
[22:39:02] <N1njAway> Which is why you set brownout detection.
[22:39:13] <hugogee> Casper, N1njAway: thanks for clearing that up for me.
[22:39:13] <N1njAway> All of these issues are addressed.
[22:39:32] <Casper> I've hear some that got corruption even with the BOD enabled at 4.5V
[22:40:11] <N1njAway> I have seen flash get corrupted/erased due to unstable voltages and brown-out detection, and Atmel opened several investigations for us. We ultimately determinted this was because the BOD was not set. Once it was set we have yet to have a problem in thousands of Atmels currentl deployed.
[22:40:13] <hugogee> If i wanted to debug a program from the terminal would i also need a programmer to do that?
[22:40:23] <Casper> from what I understand, the BOD is slightly too slow to react and miss some fast dips
[22:40:57] <Casper> hugogee: nope, a programmer can not debug, unless you use a jtag one
[22:40:58] <N1njAway> Casper: If your chip and power-supply is properly decoupled, that shouldn't happen.
[22:41:17] <Casper> N1njAway: that's the thing, proprelly decoupled... and proprelly designed
[22:41:29] <hugogee> Casper, so its not possible to interact with the program running on the avr?
[22:41:37] <N1njAway> hugogee: Depends on what you mean by debugging from terminal. Unless you write your own monitor or such, you'd probably want do use JTAG or DebugWire
[22:41:55] <Casper> hugogee: jtag / debugwire or use some output in your code like serial output or leds
[22:42:02] <N1njAway> Casper: Well that's not a fault of the bootloader or the AVR. That's PEBCAK.
[22:42:13] <Casper> so?
[22:42:17] <Casper> it can still happend
[22:42:22] <hugogee> hmm, sad i wasted so much time on this
[22:43:38] <hugogee> I was reading a thread on avrfreak re:fatfs and i thought i understood that serial debugging was taking place.
[22:43:46] <N1njAway> Casper: My point was the AVRs can be properly configured to lock the bootloader to prevent bricking in the field. They do in fact do this correctly. :)
[22:44:15] <Casper> N1njAway: in theory yes, who knows in practice :D but they generally know what they do
[22:44:22] <Casper> except that you can get weird stuff at time
[22:44:35] <N1njAway> hugogee: AVR doesn't have much built-in debug support unless you are using JTAG/DW, or have written your own "helper" debug routines, like dumping strings to the serial port like Casper suggested :)
[22:44:49] <Casper> like that "non-existant" bug where the device-ID get zeroed out
[22:45:44] <Casper> It hink atmel still hasn't acknowledged it
[22:45:45] <N1njAway> Casper: We ship a fair amount of mission-critical projects based on AVRs, so I speak from personal experience saying "Yes, bad things can happen. Yes, there are ways to prevent them from happening. Yes, there are ways to design things poorly than still make them happen." The point is to NOT do the former. :)
[22:46:00] <hugogee> guess i will just keep on keep'n on. thanks guys. -cheers
[22:46:09] <N1njAway> Good luck!
[22:46:19] <N1njAway> When in doubt, blink an LED on a spare pin!
[22:46:54] <Casper> it's crazy what a led can do
[22:47:10] <N1njAway> Like function as a simple random number seed. :)
[22:47:48] <Casper> and now that I have a DSO, a led can really be usefull... just "morse code" it and capture on the scope :D
[22:48:03] <N1njAway> Indeed!
[22:49:10] <hugogee> so imma go buy a programmer, any suggestions?
[22:49:21] <Casper> hugogee: why not tom's one?
[22:49:32] <N1njAway> Get one of Atmel's JTAGICE3's
[22:49:35] <hugogee> k, where can i find it
[22:49:37] <N1njAway> $100 USD
[22:49:50] <N1njAway> Does JTAG, DW, and ISP
[22:49:55] <hugogee> jtagice3 - sounds fierce
[22:50:09] * Casper would have went with tom's one...
[22:50:24] <hugogee> thats a good idea, i might be able to carry on with my idea
[22:50:36] <hugogee> Casper, why Toms?
[22:50:51] <N1njAway> hugogee: What OS do you develop under?
[22:50:57] <hugogee> linux
[22:51:13] <Casper> hugogee: me make some good one for not too much
[22:51:15] <N1njAway> I'm not sure what support the JTAGICE3 has under Linux.
[22:51:58] <hugogee> How much Casper?
[22:52:09] <Casper> ask him...
[22:52:14] <Casper> Tom_itx: ding dong
[22:52:22] <hugogee> Casper: Hey, you arent Tom by any chance?
[22:52:36] <hugogee> ;P
[22:52:37] <hjohnson> heh, forgot about this place...
[22:52:38] <Casper> hugogee: nope
[22:53:25] <Casper> hjohnson: bad bad bad...
[22:53:35] <hjohnson> hehe
[22:54:03] <hjohnson> trying to decide whether to go with one of the cheapie fleabay jtag-ice clones, or ponying up my $120 for a jtagice3
[22:55:52] <hjohnson> here is my nearly complete project. :)
http://i.imgur.com/NQJu07i.png
[22:56:28] <hjohnson> ... must stop the featureitice though...
[22:56:34] <Casper> oh you succeded to walk around that paint when you painted yourself in that corner? congrat!
[22:58:15] <hjohnson> yeah, moved the reset circuit to another area of free board space. :P
[22:59:23] <hjohnson> i'm trying to resist the temptation to come to one more level of featureitice
[22:59:54] <hjohnson> i found a nice I2C barometric sensor for $4.50
[23:25:26] <Casper> hehe
[23:25:33] <Casper> do it!
[23:48:24] <hjohnson> there's a reason why my BOM cost is now in excess of $200...
[23:48:28] <hjohnson> *sheepish grin*
[23:49:43] <Casper> but hjohnson... it's only 4.50$!
[23:49:58] <Casper> what does 4.50$ is compared to the 200+$? :D
[23:50:33] <hjohnson> shush you
[23:50:53] <hjohnson> heh, I will now effectively have a full weather station
[23:51:19] <hjohnson> wind speed/direction, temperature, water temperature, pressure...
[23:52:18] <hjohnson> and it will go out via satellite, which is wickedly cool. :)
[23:52:22] <Casper> hjohnson: don'T forget an accelerometer, gyro and a compass!
[23:52:30] <hjohnson> Casper: already have those
[23:52:44] <Casper> :)
[23:52:46] <hjohnson> (I scored a free honeywell HMR-3300 heading sensor... that thing is incredible)
[23:53:03] <Casper> :D
[23:53:22] <weilawei> So... I've got this bare-metal piece of code for an atmega32, built using avr-as, avr-ld, avr-objcopy... I try to add some code to use lpm to load values out of a table into r0, but it clearly isnt getting the addresses right... pm_lo8(mylabel) and pm_hi8(mylabel) give some really off values.. if i hexdump the final bin, count the right address, and hardcode it, it works..
[23:53:25] <hjohnson> (it's also worth $350+
[23:53:51] <hjohnson> the single most expensive thing I will be buying is the iridium module
[23:53:57] <hjohnson> (which I wasn't counting in the above BOM)
[23:54:48] <Casper> iridium.... that's the satellite module right?
[23:54:52] <hjohnson> yeah
[23:55:30] <hjohnson> https://www.globalsatellite.us/sites/default/files/IRIDIUM%209602.jpg this little cutie
[23:56:02] <Casper> 480... /me googles
[23:56:14] <weilawei> http://pastie.org/8425925 my problem is in lines 113-120... the pm_lo8 and pm_hi8 are commented out, the current values are hardcoded by trial and error...\
[23:56:20] <Casper> arizona...
[23:56:41] <weilawei> i dont get why avr-gcc has such serious problems with progmem when this is a piece of cake elsewhere...
[23:58:42] <Casper> weilawei: you'Re coding in C?
[23:58:46] <Casper> or in asm?
[23:58:51] <weilawei> Casper, no, if i was, this'd be easy
[23:58:54] <weilawei> straight asm
[23:59:06] <weilawei> its been working fine up until i decided to store values in flash
[23:59:38] <weilawei> i had to compile a test program and disassemble it just to figure out how to define a section i could put values in..
[23:59:54] <weilawei> and then edit the linker script so it didnt put it as the very first thing
