Back
[00:00:00] <theBear> <sob>
[00:00:38] <theBear> you can't imagine how intimately i know intel flash images, developer toolkits, memory layouts, boot and bios protocols and codes, intel dl site, etc etc right now
[00:00:43] <theBear> hey Casper :)
[00:01:04] <Casper> theBear: but, I want a stronger camera flash
[00:01:23] <Casper> one with a better zoom too :D
[00:01:30] <Casper> and yes, my flash have a zoom on it
[00:01:48] <langoliers> lol
[00:01:56] <langoliers> flash is magic
[00:01:57] <theBear> heh, few months ago i wouldn't have believed you, but i saw one like that recently... somewhereo r other
[00:02:28] <langoliers> Casper<= if i get it right, you are wrong. digital zoom is not zoom
[00:02:45] <Casper> langoliers: not digital
[00:03:05] <theBear> you can't have a digital zoom on a flash !
[00:03:19] <theBear> you need more than 1 'pixel' to have digital zoom
[00:03:38] <Casper> it have a motor in the head that move the bulb, causing it to flash on a wider or narrow angle
[00:04:22] <theBear> is it physically synced with the camera zoom ?
[00:04:35] <Casper> yup
[00:05:07] <Casper> from I think 28mm up to 105mm
[00:05:29] <theBear> few years back i was doing some led experiments, got a nice little bare-smd-led by osram designed for camera flash.... it looked like a normal one, but somehow magically outputted ONLY a rectangle of light without any spill or additional lenses or anything
[00:05:54] <theBear> amazingly bright for a single tiny led.. i think it was something odd like 2.4w or so
[00:06:37] <Casper> this flash unit... if you put your hand on the head and manually fire it at 100%... you can feel a burning hot light :D
[00:07:02] <langoliers> problem with led flashers is leds will not give kilowatts of peak power, just burn
[00:07:04] <theBear> wow, phone camera ?
[00:07:04] <Casper> seriously, I think that 4-5 times the length and it could cause some burn
[00:07:17] <Casper> no
[00:07:30] <Casper> theBear:
https://www.dropbox.com/s/28ctojwdxuta6ce/IMG_5968.JPG ← my camera
[00:07:59] <theBear> hehe, that's a good trick taking a pic of itself sideways :)
[00:08:08] <theBear> that's some fancy ass lens on there
[00:08:24] <Casper> there is a 2x doubler there
[00:08:30] <theBear> damn that's got some res ! you don't need that fancy giant lens and camera
[00:08:51] <Casper> the lens is a 70-200mm f/2.8 is III usm :D
[00:08:57] <Casper> with a 2x III extender
[00:09:07] <theBear> i believe you
[00:09:28] <Casper> with a canon t4i body, with a bg-e8 grip (the bottom part of the camera)
[00:09:33] <Casper> the grip hold 2 battery too :D
[00:09:47] <Casper> and come with a tray for 6xAA batts
[00:09:53] <Casper> usefull for emergency power
[00:10:19] <Casper> and theBear... that pic was only from my point and shot
[00:10:30] <theBear> huh ? you saying canon still haven't got the hang of battery-efficiency since their first digital cameras and super slow/power hungry mem cards ?
[00:10:52] <Casper> https://www.dropbox.com/s/zzbaw86eugjd57s/IMG_1008.JPG ← that's with my shitty lens (not on that pic)
[00:10:59] <theBear> or is that enough power for a 2month holiday ?
[00:11:16] <theBear> oooh, artistically focused, fancy
[00:11:45] <Casper> you can see there how shitty the lens is... full of chromatic aberation...
[00:11:53] <Casper> and it's not as sharp as it should have been
[00:12:42] <Casper> (the t4i is a 18 mpixels camera btw)
[00:14:05] <Casper> as for battery power...
[00:14:20] <Casper> it really depend on how much pic you take, which lens you have and all
[00:14:33] <Casper> I expect the lens I have to eat the batts
[00:14:43] <Casper> it weight 3.2lbs
[00:15:06] <Casper> have a motorised focus (USM, ultra sound motor)
[00:15:15] <Casper> and is IS... image stabilised
[00:15:27] <Casper> so it have a 2 axis giro and servos
[00:46:59] <xelion> tzanger: I need your help regarding that stupid ADC result we discussed the other day.. Are you busy at the moment?
[01:05:13] <OndraSter_> <langoliers> who does c++ on microcontrollers?
[01:05:13] <OndraSter_> I sometimes do :P
[01:05:13] <OndraSter_> <langoliers> OndraSter_<= electron mobility is faster than holes
[01:05:13] <OndraSter_> he?
[01:13:05] <langoliers> OndraSter_<=
http://en.wikipedia.org/wiki/Electron_mobility
[01:14:50] <OndraSter_> how does it relate to me?
[01:16:25] <langoliers> you asked why nfet better than pfet
[01:17:31] <langoliers> (i'm still a week late with my work btw)
[01:18:36] <OndraSter_> oh
[01:18:36] <OndraSter_> I did?
[01:18:36] <OndraSter_> I don't remember that
[01:21:49] <langoliers> you were probably not really interested in the answer
[01:28:10] <langoliers> [224550] <OndraSter_> langoliers, why are N better than P?
[01:28:30] <langoliers> cause'
[01:30:23] <OndraSter_> I see :D
[01:50:24] <microchip_sac> hello all, i have a question
[01:50:41] <microchip_sac> i want to communicate with my avr through usb
[01:51:08] <microchip_sac> like, between pc and avr
[01:51:32] <microchip_sac> so how do i do this?
[01:54:03] <langoliers> i'd use a micropchip usb ic
[01:55:01] <microchip_sac> like?
[01:55:08] <microchip_sac> and are they readily available?
[01:57:28] <OndraSter_> microchip_sac, what AVR, to be precise?
[01:58:12] <microchip_sac> well, i have an atmega8
[01:59:29] <OndraSter_> ok, then you have to use some USB - serial adapter, like the microchip's one (cheaper) or FTDI's FT232 (more expensive)
[02:00:01] <OndraSter_> or any other similar
[02:00:01] <OndraSter_> I remember Cypress doing some dual UART -> USB
[02:00:41] <microchip_sac> so a USB <-> UART adapter can be done in software (on the AVR)?
[02:13:06] <MrTrick> Okay, my C is rusty. Is there a simple expression for "If var FOO is non-zero, BAR, else 0". Does it have to be a ternary expression? Or will (FOO && BAR) work?
[02:15:16] <OndraSter_> it can, but it is very slow and takes most of the MCU time
[02:15:16] <OndraSter_> so just use hardware one
[02:15:51] <OndraSter_> eh?
[02:15:51] <OndraSter_> if(foo != 0) bar();
[02:15:52] <OndraSter_> or what do you mean?
[02:16:14] <MrTrick> no, the value of bar.
[02:17:03] <MrTrick> eg, (FOO ? BAR : 0) works. Just wondering if (like in javascript) (FOO && BAR) will return the value of BAR if FOO is non-zero, 0 otherwise.
[02:17:24] <OndraSter_> javascript is a clusterfuck of mess
[02:19:29] <microchip_sac> i read something about usb communication using v-usb and libusb?
[02:20:20] <OndraSter_> yeah
[02:20:20] <OndraSter_> but like I sai
[02:20:20] <OndraSter_> d
[02:20:27] <OndraSter_> it takes a lot of the MCU time
[02:21:01] <OndraSter_> and works really slow
[02:21:01] <OndraSter_> software USB is a pain
[02:21:01] <OndraSter_> aand I am gone
[02:22:33] <microchip_sac> speed doesnt matter... i just want usb communication
[02:25:42] <CapnKernel> microchip_sac: I have used V-USB
[02:25:57] <CapnKernel> As long as you understand the limitations, it works well
[02:26:29] <CapnKernel> OndraSter_ is wrong, it doesn't take a lot of CPU time. It takes ALL of the CPU time, at least while it's sending and receiving.
[02:29:44] <microchip_sac> thats fine, but does it work fine? easy enough to implement?
[02:30:51] <CapnKernel> Yes and yes
[02:31:43] <microchip_sac> v-usb on the device, but what on the other end?
[02:31:55] <microchip_sac> if libusb, how do you make it work?
[02:38:02] <CapnKernel> USB has a hardware side and a software side
[02:38:17] <CapnKernel> As long as you can make the hardware side work, then the software can do whatever you want
[02:38:51] <microchip_sac> so the h/w is the avr, and the s/w (libusb, etc.) is easy
[02:38:52] <CapnKernel> Your device can pretend to be (no, not pretend, *be*) almost any USB device you can think of
[02:39:06] <theBear> the hw is both ends of the cable, the sw is what is behind either of those ends
[02:39:07] <CapnKernel> You don't necessarily need to use libusb
[02:39:22] <CapnKernel> I'm not going to disagree with that :-)
[02:39:33] <CapnKernel> To the PC, it just sees a USB device
[02:39:49] <CapnKernel> If you've written your software to work like a keyboard, you can just plug it into a PC and it will work
[02:40:22] <microchip_sac> what if i want to *send* something *from* my pc *to* my avr?
[02:40:24] <CapnKernel> I made a device with a Nintendo touchscreen that uses V-USB. To the PC it looks like an absolute coordinate mouse
[02:40:37] <CapnKernel> There are two ways to do it
[02:41:00] <CapnKernel> The first is to look at all the USB devices out there, and pick one where you can piggyback this data over the existing protocol
[02:41:06] <theBear> remember yer osi model... it translates pretty well to usb... you got a usb bus, everything gets an address, the host (pc usually) end and any 'clients' that are physically connected have a virtual cable straight between each other, this virtual cable basically just transfers data in either direction
[02:41:30] <CapnKernel> For the sake of this exercise, I'm going to take you very literally: You want to send some data to the USB device. You haven't told me the speed, so a very slow rate is ok
[02:41:36] <microchip_sac> yes
[02:41:40] <CapnKernel> What the PC can do is toggle the caps lock and numlock
[02:41:49] <CapnKernel> This will be sent to USB keyboards to update the LEDs
[02:41:58] <CapnKernel> Your device can capture this data, and decode it
[02:42:02] <CapnKernel> That's an example of piggy-back
[02:42:03] <theBear> hehe, i was just musing about using a ps2 port as an avr programmer like that earlier :)
[02:42:13] <CapnKernel> It's very slow though
[02:42:37] <microchip_sac> the other method?
[02:42:42] <CapnKernel> Or, you can set up V-USB to be a custom USB device unlike anything else
[02:42:50] <CapnKernel> THEN you use libusb to talk to the device
[02:42:52] <theBear> i don't remember how usb-hid works at a protocol level.... if it's close enough to physical ps2/at keyboard in theory you can send a lot more 'codes' than just caps/num/scrllock
[02:43:49] <microchip_sac> and then libusb can send whatever i want to the device (if i specify it)?
[02:43:58] <theBear> you also MIGHT make v-usb look like a usb-serial chip of some kind (there are a bunch of variations on the generic standard) in which case the pc end would look just like a serial port, and the avr end would receive data just like a serial cable
[02:45:25] <CapnKernel> microchip_sac: There's a neat project that lets you put a USB bootloader on your AVR. The AVR flash is divided into bootloader and application areas. You can update the application area over USB, independent of the bootloader
[02:46:04] <CapnKernel> Bother, should have been using my hackvana account, like this:
[02:46:06] <hackvana> Yes you should have! Here I am.
[02:46:43] <hackvana> microchip_sac: I have written about this on my blog:
http://capnstech.blogspot.com/
[02:46:43] <microchip_sac> i need usb communication for a simple project im doing,
[02:46:53] <hackvana> Go read the V-USB website
[02:47:06] <theBear> every word !
[02:47:13] <microchip_sac> where i take in readings and send them to the pc
[02:47:16] <theBear> and not just the last ones
[02:47:18] <microchip_sac> and get results back
[02:57:32] <hackvana> microchip_sac: Go read the V-USB website, plus my blog. Read everything. THEN we can help you.
[04:36:02] <kdehl> Are there any I/O pins I can't use as general purpose I/O by default without disabling certain functionality first?
[04:36:08] <kdehl> I'm using a 1284p.
[04:36:26] <specing> yes, RESET
[04:36:44] <Valen> dunno about that chip, but jtag?
[04:37:39] <kdehl> Heh.
[04:37:44] <kdehl> I'm not using jtag.
[04:38:10] <kdehl> Hm. That's on port C, iirc, maybe that's my issue here..
[04:38:23] <kdehl> No.
[04:38:25] <kdehl> Wait.
[04:38:37] <kdehl> JTAG uses the same pins as SPI, no?
[04:38:43] <Valen> not always
[04:39:08] <Valen> bbs moving internets
[04:39:14] <Valen> DONT MOVE!
[04:40:29] <kdehl> Hm.
[04:40:35] <kdehl> I'm trying to get a 4x40 display to work...
[04:42:56] <twnqx> via spi?
[04:43:17] <twnqx> spi is a bit tricky since not all pins are overridden
[04:44:29] <twnqx> kdehl: did you manually define MOSI, SCL and /SS (if used) as outputs?
[04:44:35] <twnqx> SCK*
[04:45:31] <kdehl> twnqx: No, I haven't touched them at all.
[04:45:40] <twnqx> see
[04:45:44] <twnqx> that's your problem
[04:46:30] <kdehl> Heh. I just moved on to use pins 0-3 of port B instead. That shouldn't be a problem, should it?
[04:46:41] <twnqx> http://pastebin.com/f6DVcUWY (for the at90can, your port/pins may vary)
[04:48:17] <twnqx> (it happens to be portb, 0-3)
[04:49:14] <kdehl> Oh. Heh. I think we have a misunderstanding here. I'm not using SPI. :)
[04:49:20] <twnqx> oh
[04:49:22] <kdehl> Hehe.
[04:49:44] <kdehl> I just wondered if there are certain pins that I can't use as general I/O without disabling certain functionality first.
[04:49:56] <kdehl> But thanks anyway. :)
[04:49:59] <twnqx> except reset i don't know any
[04:50:23] <kdehl> Okay. Good.
[04:50:31] <twnqx> and if you blow that fuse i hope you a way of high voltage programming :P
[04:51:40] <twnqx> hm, aren't the spi pins used for ISP programming as well?
[04:52:20] <kdehl> Yes. But I think it is used when reset is pulled low, or maybe I made that up myself
[05:02:13] <twnqx> kdehl: yes
[05:05:47] <xelion> QUESTION: Anybody up for helping me on some AD conversion stuff? I need help figuring out how to manipulate the raw ADC value to something useful (i.e. voltage) and send it to an lcd in 8-bit mode. Device: ATmega8, ADC: FreeRun 10-bit mode (result NOT left aligned), LANGUAGE: ASM
[05:06:20] <xelion> any help would be appriciated!
[05:06:25] <xelion> greatly
[05:08:22] <xelion> I've stored the values of ADCH:ADCL in R17:R16 and done LSR R17, ROR R16, LSR R17, RSR R16 on the result
[05:10:31] <xelion> I'm just getting strange artifacts on my screen :( well, they correspond to some binary value anyway.. I'm using the internal Vref = 2.56V making the stepsize 2560/1024 = 2.5mV in 10-bit mode
[05:11:04] <Valen1> question 1 do you need 10 bits of resolution?
[05:11:41] <xelion> Valen1: it's just for temp measuring with a 10k NTC, so I guess not..? 8-bit mode okay then?
[05:12:00] <Valen> I'd look at starting with 8 bit
[05:12:04] <xelion> okay
[05:12:15] <xelion> so I just read the LSB for starters
[05:12:16] <xelion> ?
[05:12:26] <xelion> ADCL
[05:12:31] <kdehl> twnqx: Yes as in that's how it works, or I made it up?
[05:12:37] <Valen> set the adc to 8 bit mode
[05:12:41] <twnqx> yes, that's how it works
[05:12:43] <Valen> are you using gcc?
[05:13:08] <xelion> Valen: I'm programming in assembly and using the avra assembler
[05:13:20] <Valen> oh god you are on your own
[05:13:23] * Valen runs screaming
[05:13:28] <xelion> shit...!
[05:13:41] <xelion> thx anyway, Valen ;)
[05:16:14] <Valen> I do suggest breaking your problem down into small steps however
[05:16:23] <Valen> 1, read a trimpot on the ADC
[05:16:37] <kdehl> Okay... so I sent a "clear screen" command, but the cursor jumped to the lower-right corner. I sat for minutes couldn't understand why until a collegue suggested I turn the display around...
[05:16:40] <Valen> 2) work out how to interface with lcd
[05:16:55] <Valen> 3) output value to lcd through some kind of transform
[05:17:36] <xelion> Valen: I already have 1 and 2 covered... it's step 3 I'm having trouble dealing with :/
[05:18:08] <Valen> what specific issue?
[05:19:58] <xelion> I don't know how to make the raw adc value readable.. I'm sending the raw ADC value directly to my databus on the lcd, resulting in some random characters being printed..
[05:21:22] <xelion> in C you would just write some kind of formula like: Vin = (Vref*ADC)/1024, but in asm you can't do that:(
[05:21:42] <xelion> or at least I don't know how
[05:22:59] <Valen> work out what the formula is doing
[05:23:20] <Valen> thats the whole point of C it takes your formula then turns it into asm
[05:23:28] <Valen> so now you need to do that your self
[05:23:40] <xelion> multiplication, division..
[05:23:52] <xelion> yes, I know.. It's my own fault..
[05:24:20] <xelion> I want to learn it the hard way;)
[05:24:26] <Valen> I suggest re-organising your stuff to get to one constant first
[05:24:55] <xelion> any pointers? :)
[05:25:03] <Valen> yeah, use C ;->
[05:25:07] <xelion> heh
[05:25:22] <xelion> It would have to be last resort only
[05:25:31] <Valen> I haven't done asm before for anything outside of a timing critical whatsit
[05:25:45] <Valen> IE my maths is going to be worse than gcc's
[05:26:04] <specing> Not on AVR, Valen
[05:26:23] <specing> GCC's AVR port is hardly what one would call "optimized"
[05:26:28] <Valen> gods of it can do fancy bits where they xor the gravitational constant with a bit shift and output the 48th digit of pi
[05:26:40] <specing> Look at ARM or X86 disasm and you'll notice the difference right away
[05:26:41] <xelion> lol
[05:26:47] <Valen> specing: you overestimate my abilities ;->
[05:27:18] <Valen> an 8kb chip is 2 cents more expensive than a 4kb chip, I just use the 8kb chip ;->
[05:28:17] <specing> flash storage is hardly the issue here
[05:28:44] <specing> when you have >2000 interrupts going off every second you'll make damn sure stuff executes fast
[05:28:45] <Valen> well the general result of a poor compile will be bigger/slower code
[05:29:11] <Valen> if I have 2k interrupts firing a second I'm not going to be doing complex maths in the ISR
[05:31:28] <Valen> I don't doubt your assertion that gcc on avr may not be the ducks nuts, but I wouldn't call it low hanging fruit either if you know what I mean
[05:31:34] <specing> Its faster to do it in the ISR and notify the main routine every 256th interrupt than notify main every interrupt
[05:31:47] <Valen> it depends what you are doing
[05:31:48] <specing> Think about ADC averaging
[05:32:16] <Valen> suffice it to say, its not a problem I have experienced
[05:32:37] <Valen> as such, I still say the output of gcc is better than what I can output in asm
[05:32:41] <Valen> note the I there
[05:32:51] <Valen> you may well find a different result
[05:37:17] <MrTrick> Should avrgcc be able to optimise fixed array accesses? eg; reading/writing to x[5] is no different to x5 ?
[05:45:54] <MrTrick> I'm trying to make sense of
https://gist.github.com/MrTrick/5466338 and getting very confused.
[05:46:05] <specing> MrTrick: it will likely resuly in shorter, but slower code
[05:46:40] <MrTrick> for instance, why does the same code (eg just differing by indices) in the gist have a different number of instructions for each?
[05:48:19] <Valen> oh xelion that is a good suggestion, compile it from C, and see what result you get in the asm, then do better ;->
[05:49:25] <MrTrick> I would expect that `uin8_t arr[5];` would put the elements consecutively ascending from &arr
[05:53:34] <chickensk> Hi. I have pretty amateur problem. I have connected atmega 1280 to a chip extender like this
http://www.proto-advantage.com/store/images/PRODUCTS/PCB3006-1_0.JPG and connected female jumpers to sides to easily remove wires from the breadboard. Soon i realized i need more pins connected, so i made extenders from flat cables. I connected everything and it worked, upload to chip and download of fuses thru programmer, some of the pins do not worked at the time (ba
[06:02:46] <chickensk> link that should work
http://we.tl/GY3YYFm7if
[06:06:09] <Horologium> chickensk, sounds like maybe all the pins aren't soldered down.
[06:07:59] <xelion> 9
[06:08:07] <chickensk> Horologium Ok, that will be the simplest solution. Thanks I am going to resolder it.
[06:09:22] <Horologium> I just use the atmega1284p in dip package myself.
[06:12:42] <chickensk> me too considered smaller chips with 40 pins 32gpio, my need is up to 100pin more than 70 gpio at the time.. with various inputs and outputs it will be pain to program communication.
[06:20:29] <Horologium> for which I would use multiple chips...or i/o extenders.
[06:20:34] <Horologium> i/o extenders rock.
[06:21:57] <Horologium> but, all depends on the application.
[06:44:32] <chickensk> so I put all pins hot, and nothing changed. so far, old program works, some of pins shows 1,76V at all times no matter if High or Low, no communication with USBasp. could be the chip bad? macro photo with backlight on pcb
https://www.wetransfer.com/downloads/79bfbb5262771312dd95bdcf5529553f20130426112517/816c158d6fa96ff36f640e812512d9b120130426112517/c74f9b
[06:47:20] <tzanger> morning
[07:06:32] <xelion> morning, tzanger ;)
[07:06:43] <xelion> WHAT TIME DO YOU HAVE?
[07:06:46] <xelion> ups
[07:06:51] <xelion> caps lc
[07:13:05] * twnqx locks xelion's caps
[07:13:28] <xelion> hmm
[07:13:31] <xelion> :)
[07:19:19] <MrTrick> I'm wondering if it's possible to write this more efficiently;
https://gist.github.com/MrTrick/5466942
[07:19:52] <tzanger> it's 0806 here
[07:20:07] <tzanger> efficiently how
[07:20:33] <tzanger> space, speed, power...?
[07:20:39] <specing> MrTrick: usually you create a dump with asm interspersed with assembly
[07:20:49] <specing> MrTrick: and then you try and do it more efficiently
[07:21:13] <specing> slowly replacing C statements with inline assembly
[07:22:16] <MrTrick> That's true, though I'm not that familiar with avr assembler - I can read it, not write it.
[07:22:18] <twnqx> most of the time gcc -O3 will beat you, though :P
[07:22:42] <specing> twnqx: on x86/arm, yes
[07:22:44] <twnqx> would an AVR 8bit core for FPGAs be legal?
[07:22:46] <specing> on AVR? no fucking way
[07:22:57] <twnqx> or would atmel be annoyed?
[07:23:10] <tzanger> twnqx: sure why not, the ISA is not copyright
[07:23:22] <tzanger> I see all kinds of PIC cores on opencores
[07:23:33] <tzanger> PIC, 8051, "ARM compatible", etc.
[07:24:07] <tzanger> generally speaking the computation cores are the "easy" part
[07:24:19] <tzanger> the peripherals nobody seems to have, but on an FPGA it's kind of irrelavent anyway
[07:24:51] <MrTrick> specing: I'm wondering more algorithm-wise... in terms of efficiently doing the charlieplexing as a cathode-at-a-time thing.
[07:24:57] <twnqx> i am currently writing a ton of peripheral emulation
[07:25:04] <twnqx> for tc1796, though
[07:25:08] <MrTrick> (lighting N-1 at once, instead of just 1)
[07:25:25] <twnqx> MrTrick: isn
[07:25:31] <specing> MrTrick: what does the disasm have to do with an algorithm?
[07:25:35] <twnqx> 't the problem with charlieplexing that you can only light oen at a time?
[07:25:40] <specing> code the algorithm in C and then optimize that
[07:26:19] <MrTrick> specing true. but sometimes the obvious way to write the C statements doesn't optimise well.
[07:26:45] <specing> MrTrick: yes, but that has nothing to do with the algorithm
[07:27:24] <MrTrick> eg; if I have an array of bytes, and need to set certain bits based on whether or not they contain values over a threshold (in this gist just non-zero), is there a better way to write it?
[07:27:58] <MrTrick> twnqx: not true. With a 4 wire array (12 LEDs) I can light 3 at a time.
[07:28:13] <twnqx> without side effects?
[07:28:29] <specing> I don't know, I would have to look at the problem, the algorithm, the code and the disassembly *very* closely which would take atleast a couple of hours
[07:28:36] <specing> and I don't want to do that
[07:28:54] <MrTrick> specing: fair enough. Need to review it myself, too. ^_^
[07:29:02] <MrTrick> twnqx: the limitation is only if you exceed the current limitations of the pins/port.
[07:36:16] <Tom_itx> xelion, write the C counterpart then look at the asm output and strip out all the excess c code
[08:49:59] <rhumbot> hi all, im trying to send a signal via usb port to test a uart connection but when trying to open the connection using putty it always the error "unable to open serial port". has anyone got experiance with this problem?
[08:50:24] <Tom_itx> are you root or have port permission?
[08:55:08] <rhumbot> nice one :) thank you!
[09:12:15] <yomanurock> can anybody please tell me how to install winAVR for fedora?
[09:12:42] <Tom_itx> winavr?
[09:12:45] <Tom_itx> that's for windows
[09:12:56] <Tom_itx> you want avrgcc?
[09:13:11] <yomanurock> yeah
[09:14:36] <Tom_itx> https://admin.fedoraproject.org/pkgdb/acls/name/avr-gcc
[09:14:39] <Tom_itx> that came up
[09:15:00] <yomanurock> ok. thanx
[09:29:52] <yomanurock> can anyone tell me how i can install avrgcc on fedora
[09:30:39] <tzanger> yomanurock: what have you tried? what have you googled?
[09:30:58] <atom1> he left
[09:31:33] <yomanurock> i tried google-ing "avr gcc" but all i got was a bunch of blogs
[09:32:26] <tzanger> this was within the first 5 hits of "avr gcc fedora":
http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_GCC_Toolchain
[09:32:32] <tzanger> they give the exact line
[09:32:42] <yomanurock> thanx
[09:32:53] <tzanger> you will not get very far if you don't learn to try to answer your own questions before throwing up your hands in dispair
[09:33:29] <tzanger> well that's one person who will be at the bottom of the barrel for my time in the future
[09:34:31] <atom1> haha
[09:35:46] <tzanger> I hope he comes back with another question
[09:35:54] <tzanger> cos I won't be there to answer
[09:38:59] <atom1> naw just give him the wrong one after asking a bunch of questions to him
[09:39:14] <tzanger> not worth the effort
[09:48:52] <tzanger> hm, looks like they were from an .in ip block too
[10:21:19] <langoliers> h
[10:35:42] <jadew> lmfao, my air purifier has a shut down timer with binary display
[10:35:47] <jadew> 1 2 4
[10:35:56] <jadew> 3 is when 2 and 1 is lit
[10:36:09] <jadew> 5 when 4 and 1, 6 when 4 and 2 etc
[10:36:18] <jadew> so basically 3 leds displaying the binary number
[10:36:52] <jadew> kinda easy to read too, especially since each led has a number on top
[10:39:39] <tzanger> yeah that's not unheard of
[10:40:16] <jadew> first time I see something like that
[10:42:45] <langoliers> kdehl<= and also xtal ;)
[10:43:14] <langoliers> though if we define functionality by losing an ADC, then any ADC pins
[10:43:25] <langoliers> [111913] <kdehl> Are there any I/O pins I can't use as general purpose I/O by default without disabling certain functionality first? <
[10:43:36] <jacekowski> a lot
[10:43:48] <jacekowski> read the manual
[10:43:48] <Tom_itx> glad you cleared that up
[10:43:53] <jadew> dW is one of them
[10:44:44] <jadew> or is that only shared with reset?
[10:45:03] <jadew> nope, it's IO
[11:04:59] <RikusW> dW is on reset
[11:05:21] <jadew> yeah, but that pin is not only dW/reset
[11:05:26] <jadew> it's also a normal IO pin
[11:07:27] <kdehl> langoliers: Right, but those you can't use as I/O pins anyway, can you?
[11:10:32] <langoliers> kdehl<= adc pins are io pins...
[11:10:59] <langoliers> reset is reset, if you disable it it will be io, xtal pins are needed if you want quartz oscillator.
[11:13:18] <kdehl> Oh, so you can disable the reset pin and use it as an I/O too?
[11:13:21] <kdehl> I had no idea.
[11:13:36] <jadew> this might interrest someone who's close to the guy selling it:
http://www.ebay.co.uk/itm/Agilent-HP-Model-4261A-Digital-LCR-Meter-/300896093377
[11:13:50] <kdehl> But how, it's not like reset is part of a port.
[11:14:33] <jadew> kdehl, when reset is disabled, the pin becomes something like PB7
[11:14:50] <langoliers> hm, though good question, the ADC6 and ADC7 only serve as ADC input on the MEGAx8
[11:14:56] <langoliers> ;/
[11:15:04] <jadew> langoliers, yeah, IIRC only on the smt versions
[11:15:18] <jadew> because they're missing from the DIP ones
[11:15:19] <langoliers> i use the TQFP right now
[11:15:34] <langoliers> so i have 2 adc in only :)
[11:15:57] <jadew> that cought me by surprise, because I made a pcb that had programmable, external pullups on those pins
[11:16:10] <jadew> then I realized it's only ADC so the circuitry for that was useless
[11:16:31] <kdehl> jadew: You mean two pins have the same programmable I/O pin in port B?
[11:16:31] <langoliers> hah, it has pullup ?
[11:16:48] <jadew> langoliers, no, I just added them in my design
[11:17:00] <jadew> I didn't realize at first that the pins serve only as ADC input
[11:17:14] <jadew> langoliers, if it did, then you could use them as IO :P
[11:17:16] <langoliers> haha ok, but it is not bad.
[11:17:25] <jadew> I guess you still can
[11:17:29] <langoliers> that prevents the pin from floating
[11:17:29] <jadew> you pull them up or down
[11:17:51] <jadew> and then you read the adc and see if it's closer to 0 or to vcc :P
[11:18:03] <jadew> digital IO :P
[11:18:04] <langoliers> floating pins are not good
[11:18:16] <jadew> for the ADC I don't think it matters much
[11:19:22] <langoliers> kdehl<= and if you disable reset you can not use icsp anymore ;)
[11:22:18] <kdehl> Yeah, I won't. Heh.
[11:23:28] <RikusW> kdehl: disabling reset will disable ISP programming too...
[11:24:11] <langoliers> are OTP devices still used?
[11:24:30] <RikusW> what for ?!
[11:24:41] <langoliers> i can only think of a one time programmable micro for a $1 chinese led light flasher
[11:25:37] <RikusW> btw icsp is for pic
[11:25:52] <jadew> means the same thing tho :P
[11:26:09] <langoliers> In Circuit Serial Programming
[11:26:19] <jadew> vs in system programming
[11:29:30] <langoliers> and internet service provider
[12:38:00] <kuldeepdhaka> im try to interface nokia 1100 lcd with avr ,but its not working but lcd is working fine with arduino ,, can anybody point me to a working code of nokia 1100 lcd with avr..
[13:01:12] <xorly> hmm, similar problem, I am looking for tested code for 3310 nokia lcd display. Adafruits library i too big for atmega8... :-)
[13:01:17] <xorly> :-( *
[13:01:25] <TechIsCool> anyone have a favorite or nice terminal block? 2 pos
[13:04:34] <tzanger> I'm partial to the Phoenix MKDS series, but they're not cheap
[13:04:59] <tzanger> Molex mini-fit Jr. is cheap and rugged
[13:05:08] <tzanger> I like those too, they're more dense than Phoenix
[13:06:01] <kuldeepdhaka> xorly,
http://www.microsyl.com/index.php/2010/03/24/nokia-lcd-library/ <---- this might help
[13:06:02] <langoliers> syn
[13:14:14] <TechIsCool> tzanger: thx
[13:24:58] <TechIsCool> I have a question if this part is rated at 300vac at 10a does that mean that it is rated at .4a at 12vdc?
[13:25:00] <TechIsCool> http://www.te.com/catalog/pn/en/1776266-2
[13:25:06] <TechIsCool> woops wrong channel
[13:27:09] <tzanger> TechIsCool: it doesn't work that way
[13:27:43] <tzanger> TechIsCool: (very) generally speaking, device limits fall into two groups: voltage limits and power (not necessarily current) limits
[13:28:00] <tzanger> there is also dissipation limits which is very closely tied to power
[13:28:22] <tzanger> voltage limits are usually due to pinout or silicon characteristics. you just can't get more volts across it because something will fail
[13:28:36] <tzanger> current limits are usually actually power limits.
[13:28:47] <TechIsCool> so it would actually be 10a at 12v
[13:29:08] <tzanger> devices have a certain resistance, resistors heat up, and P=I2R (thsi is also why power losses are called I2R losses)
[13:29:24] <TechIsCool> right but if you find r and then plug it back in
[13:29:36] <TechIsCool> you get 400mA for 12vdc
[13:29:47] <TechIsCool> or am I doing something really wrong
[13:29:48] <tzanger> heat is silicon's enemy. that's why you see ratings on discretes that say 1W continuous but if you look carefully at the datasheet you'll see the thing will pass 300A for a (very brief) amount of time AND SURVIVE
[13:30:05] <tzanger> no
[13:30:09] <tzanger> that's a connector
[13:30:11] <tzanger> it's a piece of metal
[13:30:21] <tzanger> the 300V rating is due to spacing and insulation
[13:30:34] <TechIsCool> ok
[13:30:41] <tzanger> that'll pass 10A at 300V just as well as 10A at 12V
[13:30:46] <tzanger> btw your calculation is wrong
[13:30:51] <tzanger> 300*10 = 3kW.
[13:31:03] <tzanger> 3kW/12 = 250A
[13:31:16] <tzanger> BUT
[13:31:21] <TechIsCool> lol
[13:31:27] <tzanger> this is where "it's not just amps" comes in
[13:31:37] <TechIsCool> right the board will melt before that
[13:31:50] <tzanger> that connector has a certain resistance, and that rating depends on it
[13:31:58] <TechIsCool> just like wire
[13:32:12] <tzanger> you won't get 250A through it for very long because the metal resistance will heat the part up and cause a catastrophic failure way before that
[13:32:15] <tzanger> yes
[13:32:55] <tzanger> with relays the AC/DC rating also is interesting because AC "shuts off" automatically. DC doesn't.
[13:33:16] <tzanger> that's also why a fuse is rated so differently for AC or DC, or why there are AC-only fuses
[13:34:28] <tzanger> almost everything comes down to heat in the end
[13:35:04] <tzanger> if you can keep silicon cold it can pass insane amounts of current. That's why you see SOT23 FETs that can pass multiple Amperes without getting warm, where a MMBT3904 would explode if you tried the same with it
[13:35:06] <TechIsCool> makes sense I see what I was doing wrong with ohms law
[13:36:04] <TechIsCool> tzanger: thank you
[13:36:11] <tzanger> relays also have different AC/DC ratings because of inductive effects. when you open an inductive circuit you create high voltages... relay contacts have to be derated if you are doing that, because the high voltage can arc and cause the contacts to become damaged or ice up
[13:36:26] <tzanger> sorry for hte lecture. just came off lunch
[13:36:35] <TechIsCool> tzanger: Any time
[13:37:05] <TechIsCool> its fine I enjoy learning. I have been working home electrical for about 5 years now with my father and I still don't understand it all
[13:37:27] <tzanger> heh yep
[13:37:50] <tzanger> I've been doing this for ... almost 20 years professionally, and since I was about 5 or 6 if you count learning
[13:37:58] <TechIsCool> nice
[13:38:10] <tzanger> it wasn't until my early 30s that something tweaked in my mind and a lot of the stuff I knew suddenly made sense
[13:38:16] <tzanger> I could apply the rules but not always fully understand why
[13:38:29] <tzanger> now it's an intuitive thing, I know and understand why the rules are there
[13:38:30] <tzanger> it's awesome
[13:38:37] <TechIsCool> that is awesome
[13:39:03] <TechIsCool> I work as a system administrator and it feels that way some days. Not always though
[13:43:24] <kuldeepdhaka> xorly,
http://www.microsyl.com/index.php/2010/03/24/nokia-lcd-library/ <---- this might help
[13:54:53] <xorly> kuldeepdhaka: thanks man, I'll try this one too, I've got some complex example code now (arduino pin numbers translation is hell), IDK if display is OK...
[13:59:27] <kuldeepdhaka> xorly, :)
[14:24:16] <xorly> no effect, probably different or broken display, I have to wait for new one from ebay
[14:42:19] <kuldeepdhaka> has any one earlier tried to interface NOKIA 1100 LCD with AVR (successful or unsuccessful) ?
[14:43:21] <asteve> is your name kuldeep the hacker?
[14:43:32] <tzanger> kuldeepdhaka: it would help you a LOT if you stated your problem clearly and include code on pastebin.com
[14:43:40] <tzanger> "help it's not working" is not helpful for you or for us
[14:43:57] <Tom_itx> as usual they expect a working solution dropped in place
[14:45:21] <tzanger> that's fine... disappointment is a good thing to experience. :-)
[14:45:26] <kuldeepdhaka> tzanger, i m looking for feedback(their experience while working), not code
[14:45:47] <tzanger> earlier you were lamenting that you got yours working on arduino but not AVR and asking for code
[14:46:26] <Tom_itx> is this the same one that joined and got a solution then left right away?
[14:46:33] <tzanger> no that was someone else
[14:47:24] <kuldeepdhaka> tzanger, im looking for some experienced guy that might give some suggestions :)
[14:48:02] <Tom_itx> join #seattlerobotics and ask
[14:48:16] <Tom_itx> you may have to wait a while
[14:48:16] <tzanger> I have no direct experience with that LCD. However there are a lot of us who have a lot of experience in various areas who could help if you weren't looking for something quite so specific.
[14:49:01] <kuldeepdhaka> Tom_itx, thnx
[14:49:02] <tzanger> kuldeepdhaka: for example: I'm trying ot talk to a Nokia 1100 LCD via SPI. my SPI code is
http://here. it looks like I'm sending correctly but the display is showing garbage. any ideas?
[14:49:46] * Tom_itx clicks on 'here' with no results
[14:49:48] <tzanger> kuldeepdhaka: to continue: I know the LCD is fine becuase it works fine when driven from an arduino. my schematic is
http://here. if I put an LED on the MOSI line I can see it blinking when I single step
[14:49:53] <tzanger> heh
[14:50:13] <kuldeepdhaka> tzanger, hum, sure, thnx for reminding
[14:50:25] <Tom_itx> a logic analizer works wonders sometimes
[14:51:10] <Tom_itx> the saleae supports spi protocol amongst others
[14:52:24] <Tom_itx> are you clocking at a known rate or are your fuses set to something other than you think they're set
[14:52:49] <Tom_itx> timing seems to be a big deal with lcds
[14:53:15] <kuldeepdhaka> ^ this could be useful
[14:53:19] <Tom_itx> OLEDs even require a certain power up sequence
[14:53:30] <Tom_itx> or you will destroy them
[14:54:27] <Tom_itx> the arduino runs at 16Mhz probably
[14:54:46] <xorly> some warnings about correct reset at startup are in nokia 3310 display's datashee too...
[14:54:47] <Tom_itx> no tellin what their spi rate is
[14:55:57] <tzanger> see... we're a bunch of smart people but if you don't know how to ask questions we will not often drag them out of you...
[14:56:11] <Tom_itx> data sheets are written by humans and tend to be crappy at best sometimes but there can be a wealth of information in them
[14:56:24] <kuldeepdhaka> till now i haven't found any successful interface with avr , only arduino and PIC
[14:56:49] <kuldeepdhaka> Tom_itx, got the datasheet, made the code like arduino, but still no success
[14:56:52] <Tom_itx> maybe nobody want's that display that bad to write code for it
[14:57:09] <Tom_itx> you did something different then
[14:57:49] <Tom_itx> if you're in it for the long haul, i'd get some tools to work with like a logic analizer or scope etc
[14:58:07] <Tom_itx> otherwise keep pestering until someone gives in
[14:58:31] <kuldeepdhaka> got scope but didnt got any much from it, (dont know how to properly use it)
[14:58:58] <Tom_itx> with a LA you can compare the signals on mosi miso sck all at once
[14:59:13] <Tom_itx> to see if in fact you're sending what you think you're sending
[15:07:00] <Tom_itx> RikusW knows
[15:09:00] <RikusW> knows what ?
[15:09:03] <RikusW> zlog
[15:11:27] <tzanger> kuldeepdhaka: first things first, make a port pin on the AVR toggle at 1kHz. Use the scope to make sure that your timing is set up right
[15:12:09] <kuldeepdhaka> tzanger, k
[15:13:15] * RikusW saw some 1200V 405A continuous current diodes today, with matching heatsinks :)
[15:13:25] <RikusW> 2500A peak
[15:14:01] <tzanger> heh
[15:15:43] <RikusW> btw using a hv fet for lv work isn't too good an idea, hv fets got high RDSon
[15:15:57] <RikusW> unless its small currents
[15:20:37] <cluelessperson> can someone help me make sure I've set my fuses right?
[15:22:48] <xorly> MCU, fuses, expected settings...
[15:23:28] <cluelessperson> xorly, I guess. I'm not even sure if this is running at 8mhz
[15:23:53] <RikusW> which avr and which fuse settings ?
[15:24:04] <RikusW> hex e h l
[15:24:20] <xorly> yup, my message was request on those informations....
[15:26:42] <cluelessperson> RikusW, Atmega328P. external Oscil at 16mhz
[15:26:51] <cluelessperson> that's about all I know as a noob.
[15:27:11] <cluelessperson> xorly, Sorry ^ thanks
[15:28:10] <RikusW> which hex values did you program ?
[15:28:18] <RikusW> or didn't you change it yet ?
[15:30:22] <RikusW> cluelessperson: 0x7F on low fuse should help you
[15:31:03] <cluelessperson> RikusW, I have Extended: 0xFF High: 0xD9 and Low: 0xCE
[15:32:23] <RikusW> change low fuse to 0x7F
[15:32:41] <RikusW> and do connect a crystal and its 18 or 22pF caps
[15:33:28] <cluelessperson> RikusW, This is on an arduino board with those built in
[15:33:33] <cluelessperson> so it has them, definitely
[15:34:04] <RikusW> actually CE is fine too
[15:34:54] <RikusW> just leave it at 0xCE
[15:35:02] <RikusW> should work fine
[15:35:38] <RikusW> 7F got a longer startup period thats all
[15:35:46] <RikusW> err FF
[15:35:52] <cluelessperson> this is weird
[15:35:59] <RikusW> what is ?
[15:36:03] <cluelessperson> before my Pixel would light up as if it had recieved all 1s
[15:36:07] <cluelessperson> now it's staying dark
[15:36:17] <cluelessperson> well
[15:36:23] <cluelessperson> it's supposed to stay dark.
[15:36:26] <cluelessperson> lol
[15:36:28] <cluelessperson> maybe this worked
[15:38:09] <RikusW> 7F will also set clockout and clkdiv8...
[15:38:19] <RikusW> CE of FF...
[15:38:24] <RikusW> I'd leave it at CE
[15:39:09] <cluelessperson> OMG, I have GREEN
[15:39:25] <cluelessperson> aww. It should be black. :(
[15:39:48] <cluelessperson> I really need an oscilliscope
[15:40:36] <OndraSter_> I am using old 40MHz analog scope :)
[15:40:58] <OndraSter_> Kikusui COS5042
[15:43:59] <Tom_itx> cluelessperson, this is your friend:
http://www.engbedded.com/fusecalc/
[15:44:18] <cluelessperson> Tom_itx, I used it, but with confusing results.
[15:44:26] <cluelessperson> also, I don't understand all the options. :P
[15:44:33] <cluelessperson> Tom_itx, your programmer works well though.
[15:45:02] <Tom_itx> you're on win64 bit aren't you?
[15:45:10] <Tom_itx> maybe that was someone else
[15:47:51] <OndraSter_> yay win64
[15:48:13] <cluelessperson> Tom_itx, Yes, I am.
[15:48:18] <cluelessperson> Tom_itx, It was me. :P
[15:48:30] <cluelessperson> Tom_itx, Win Ult 64bit
[15:50:24] <kuldeepdhaka> i added a function layer over arduino code for avr (this code is confirmed to be working by me earlier) and tried on my avr board , it didnt work code:
http://pastebin.com/iZF2hiN1
[15:52:02] <megal0maniac> kuldeepdhaka: I assume it smelled funny?
[15:52:22] <kuldeepdhaka> megal0maniac, why?
[15:52:45] <megal0maniac> Typically that's what "didn't work" means. Or it's one of the possibilites at least
[15:54:01] <megal0maniac> I'm being facetious because you're being vague :)
[16:04:10] <Roklobsta> interedsting... where do i get avr-gdb for windows from?
[16:04:59] <Roklobsta> the atmel download avr-toolchain-installer-3.4.1.1195-win32.win32.x86 doesn't have it./
[16:05:13] <Roklobsta> do i have to use the ancient winavr version?
[16:08:29] <RikusW> megal0maniac_afk: just discovered a U2S "bug" can't have two on XP simultaneously
[16:08:37] * RikusW blames the stupid cdc driver :S
[16:09:22] <RikusW> I'm sure it worked, maybe on SP2...
[16:11:09] <OndraSter> bloody DVD
[16:11:09] <OndraSter> s
[16:11:14] <OndraSter> they always fail :( :D
[16:27:13] <megal0maniac> OndraSter_: They're more reliable than your internet connection :P
[16:28:25] <megal0maniac> RikusW: Meh, lame. Luckily it isn't too serious. Hardly anyone uses XP now, and most of those who do probably won't have two U2S boards
[16:30:54] <megal0maniac> Did I just get netsplat? :/
[16:31:09] <OndraSter_> no
[16:31:28] <megal0maniac> Oh. Just had a 72s ping
[16:42:01] <megal0maniac> I suppose I've got it good :P
[16:42:06] <megal0maniac> 'Night
[16:45:09] <RikusW> megal0maniac_afk: will try on win7 sometime
[16:45:21] <RikusW> night
[16:45:48] <OndraSter> what's the issue with two U2Ss?
[16:46:23] <RikusW> when two is plugged in the second won't work
[16:46:28] <OndraSter> oh
[16:46:30] <RikusW> I didn't put in serial numbers...
[16:46:39] <RikusW> but that was on purpose
[16:46:55] <RikusW> so that each device won't take its own serial port
[16:47:08] <RikusW> which can be a problem if you have a drawer full of them
[16:47:32] <RikusW> like hmm I wonder on which comport that one enumerates... :S
[16:47:52] <RikusW> xp cdc driver is retarded
[17:48:31] <langoliers> [220205] <RikusW> btw using a hv fet for lv work isn't too good an idea, hv fets got high RDSon < :) latest things do not
[17:48:47] <langoliers> notes SiC superfets
[17:52:18] <langoliers> PORTD |= ( (si&1) << red_led ) | ( ((si>>1) & 1) << green_led ) | ( ((si>>2)&1) << blue_led ); // turn on leds
[17:52:18] <langoliers> PORTD &= ( (si&1) << red_led ) | ( ((si>>1) & 1) << green_led ) | ( ((si>>2)&1) << blue_led ); // turn off leds
[17:52:48] <langoliers> anybody know of a simpler logic to do this ?
[17:53:28] <langoliers> (or a universal macro)
[20:45:54] <metalliqaz> does anyone here know of an AVR library for walking the stack?
[20:47:01] <Horologium> never heard of such myself.
[20:48:21] <metalliqaz> man it's so useful
[20:48:39] <metalliqaz> lightweight embedded systems with no debugger interface can be very very hard to debug
[20:48:41] <Horologium> by "walking the stack" you mean going through the data on the stack for some reason?
[20:49:11] <metalliqaz> when my watchdog timer goes off, i want to inspect the stack to find out where it was executing when the WDT fireed
[20:49:50] <metalliqaz> otherwise i'll never figure out what this thing is doing
[20:49:59] <metalliqaz> rather not have to code that myself if I can help it
[22:24:59] <TheFakeazneD525> HAHA, SPAM!
[22:26:45] <TheFakeazneD525> Well looks like the spam...
[22:26:51] * TheFakeazneD525 puts on shades
[22:26:56] <TheFakeazneD525> JUST GOT CANNED!
[22:27:00] <Valen> oh
[22:27:02] <Valen> oh damn
[22:27:14] * Valen is lucky he lives close to the hospital
[22:28:04] <elkng> those are from brazil ?
[22:29:19] <TheFakeazneD525> Im not even sure why im here.........
[22:31:39] <TheFakeazneD525> What does #avr talk about anyways?
[22:31:48] <Tom_itx> atmel avrs
[22:31:54] <Tom_itx> microcontrollers
[22:32:00] <TheFakeazneD525> ahhh,
[22:32:10] <Tom_itx> hardly ever needs moderation
[22:32:11] <TheFakeazneD525> Well I guess i shall take my leave!
[22:32:16] <Tom_itx> thanks
[22:32:29] <TheFakeazneD525> This was fun,
[22:33:48] <Tom_itx> Valen, how long was that going on?
[22:34:16] <Valen> not long
[22:34:30] <Tom_itx> glad i checked in just before sleep
[22:34:31] <Valen> (13:10:01) - (13:16:20)
[22:34:52] <john_f> so what should I set BOOT_SECTION_SIZE_KB to in lufa to compile the CDC bootloader?
[22:35:03] <john_f> it is adafruits 32u4 board
[22:35:56] <Tom_itx> try the default?
[22:36:04] <john_f> not sure how to relate it to the fuses as it suggests
[22:36:19] <Tom_itx> so you're using avrdude?
[22:36:47] <john_f> yes with atmels mkII icsp programmer
[22:36:56] <Tom_itx> btw, you may have to set the fuses with ISP, i'm not entirely sure on the USB chips
[22:37:02] <Tom_itx> don't think DFU or FLIP will do that
[22:37:24] <john_f> the default errors with um...memory out of bounds iirc
[22:37:32] <Tom_itx> http://www.engbedded.com/fusecalc/
[22:37:43] <Tom_itx> probably needs a bump up then
[22:37:52] <Tom_itx> that will give you a list of fuse settings
[22:38:08] <Tom_itx> and an avrdude line at the bottom for the fuse changes
[22:39:00] <Tom_itx> default is 2048 which is the largest size
[22:39:44] <john_f> well I get a linker error with boot section size kb set to 2
[22:40:07] <john_f> default was 8 and 128kb of flash
[22:40:10] <Tom_itx> default is BOOTSZ=00
[22:40:27] <Tom_itx> which is 2048 words
[22:42:23] <john_f> let me double check this is the correct branch
[22:57:24] <Tom_itx> mmm
[23:38:14] <MrTrick> Question about avrgcc; Is there any way for an interrupt to just *clear out* the main stack? So the main code might be in the middle of some long execution, and the interrupt can cancel it and start executing something else?
[23:38:49] <MrTrick> (eg set it up so that on return from interrupt, the pc and stack are set to run something else)
[23:38:58] <MrTrick> Or does it all have to be written cooperatively/
[23:39:22] <Casper> i.e. reset the avr?
[23:40:26] <MrTrick> hmm, in part I suppose. init() doesn't need to be run again, and none of the variables need to be changed.
[23:40:35] <metalliqaz> true if you clear the stack entirely you may as well reset it
[23:40:37] <metalliqaz> Menu: 'p'rint/'c'lear events, 'e'xamine, 'r'eset, 'q'uit.
[23:40:55] <metalliqaz> ugh sorry, left my keyboard in debug mode again
[23:41:07] <MrTrick> but say I've got a long synchronous function that I now want to cancel (because a button was hit) and perform something else.
[23:41:44] <Casper> then need to check it
[23:41:50] <metalliqaz> i'm also looking for stack manipulation help, although i just want to be able to extract the PC prior to the interrupt
[23:41:50] <MrTrick> if I can "clear" the stack like I'm describing, it's easy to do. Otherwise, I'd need to litter the synchronous function with lots and lots of calls to 'if (cancel_flag) return;'
[23:42:37] <MrTrick> (I mean hey, SIGTERM in linux can do it, why can't I?)
[23:42:54] <metalliqaz> basically you want to save your stack pointer at the beginning of main()
[23:43:04] <metalliqaz> and then force it back at some random time
[23:43:22] <MrTrick> that sounds right to me...
[23:43:40] <metalliqaz> i'm not good enough with AVR to come up with that code
[23:44:04] <MrTrick> do you know where you *get* the stack pointer from?
[23:44:20] <metalliqaz> its funny i'm reading up on exactly that stuff tonight
[23:44:33] <metalliqaz> the stack pointer is stored in the SPL and SPH registers
[23:45:07] <grummund> wouldn't the sp be at a known point when main() is entered anyway?
[23:45:09] <metalliqaz> as far as I can tell, there are no helper libs for working with it
[23:45:41] <metalliqaz> grummund: yes, probably but what is it?
[23:45:47] <metalliqaz> also he may not want to go all the way back to main()
[23:45:58] <MrTrick> actually, I do.
[23:46:02] <metalliqaz> oh
[23:46:44] <metalliqaz> can you set a volatile global flag in your ISR that exits your work loop?
[23:46:45] <grummund> stack start and addresses are available as ponters
[23:47:07] <metalliqaz> grummund: which please? i need help with this stuff too :)
[23:47:10] <MrTrick> I'll be filling a function pointer with the next ACTION that should be performed. If the current ACTION finishes, then it goes back to main's loop. If the current ACTION should be cancelled, then I want to reset it.
[23:47:15] <grummund> _start and _end, iirc.
[23:48:25] <MrTrick> is there a header file that contains them?
[23:48:42] <grummund> yeah should be
[23:49:09] <grummund> crt.h maybe
[23:50:13] * metalliqaz looks at avr-libc docs
[23:52:01] <grummund> but you probably don't want to do this except as a learning exercise
[23:52:44] <grummund> volatile flag to restart the main loop would be so much cleaner
[23:53:12] <MrTrick> but then I have to rewrite every external call that may take significant time.
[23:53:19] <MrTrick> and my own delay.h functions
[23:53:35] <MrTrick> (and *write* my own delay.h functions)
[23:53:35] <metalliqaz> well what i need to do is grab the address of the code that was executing when my WDT fires
[23:53:45] <metalliqaz> so i need to examine the stack to find that
[23:55:23] <metalliqaz> i've been examining the stack
[23:55:27] <metalliqaz> on my application
[23:55:34] <metalliqaz> assuming it starts at RAM_END
[23:55:41] <metalliqaz> i don't recognize anything in there
[23:57:22] <MrTrick> there's the 'SP' variable... ?
[23:57:34] <grummund> yebbut RAM_END isn't itself a pointer is it?
