Back
[05:57:30] <beaky> hello
[05:57:49] <beaky> when I try to run my avr simulator or avr simulator 2 debuggers in avr studio 4, my thing crashes :( why is that?
[05:58:29] <Horologium> there is something wrong with it.
[05:59:27] <beaky> ah
[06:08:18] <RikusW> beaky: or your code crashes it
[06:08:25] <RikusW> it worked fine for me
[06:08:39] <beaky> ah
[06:08:44] <RikusW> you'll have to select the same device for both compiling and simulation too
[06:08:49] <beaky> oh
[06:09:03] <beaky> btw what is the difference between INT and PCINT?
[06:09:29] <RikusW> yes
[06:18:33] <Horologium> INT is a single pin that generates an interrupt.
[06:18:46] <Horologium> PCINT is tied to all the pins on a single port.
[06:18:54] <Horologium> so any of those pins can generate the interrupt.
[06:19:11] <Horologium> there are other differences but that's the big one.
[06:19:21] <Horologium> I recommend reading the datasheet...it explains all that.
[06:20:13] <RikusW> pcint is for any change
[06:20:21] <RikusW> int can be hi-lo lo-hi
[06:20:32] <RikusW> or hi or lo
[06:20:40] <beaky> ah I wish I can configure the pcint :(
[06:21:05] <RikusW> why cant you ?
[06:21:28] <RikusW> btw m8 doesnt have pcint
[06:22:25] <beaky> ah I am using an ATmega328 :D
[06:33:30] <beaky> yay my pcint works!
[06:33:45] <beaky> but it toggles my leds both when I press my buttons down and when I lift my finger
[06:34:16] <twnqx> in either case, the pin changes
[06:34:27] <beaky> ah
[06:34:33] <beaky> now I understand PCINTs :D
[06:35:00] <RikusW> you'll have to write some code to detect hi or low only
[06:35:14] <beaky> ah how do I detect high
[06:35:14] <RikusW> or a button press
[06:35:40] <RikusW> save the previous state and compare to current state in the interrupt handler
[06:36:15] <RikusW> irq() { compare(old,new); old = new; };
[06:36:43] <RikusW> and a state machine to detect button presses
[09:38:31] <tomatto> tried someone this?
http://elm-chan.org/works/sd8p/report.html it is not working for me, nothing played, any help?
[09:38:36] <tomatto> please
[09:40:39] <Tom_itx> works fine
[09:47:54] <robotustra> hi
[09:48:29] * edman007 waves
[09:51:56] <robotustra> does anybody tried this sensor: Avago ADNS-9800 ?
[09:52:58] <beaky> bonjour
[09:53:07] <robotustra> ca va?
[09:55:32] <tomatto> Tom_itx: so what can be wrong? i removed fuse part, upload, make wav file, insert sd card. use capacitor with 8ohm speaker and nothing
[09:55:55] <Tom_itx> no clue
[09:56:03] <Tom_itx> i just verified the site was working
[09:57:18] <Fleck> :D
[09:57:21] <Fleck> bastard Tom_itx
[09:58:57] <tomatto> site is online. but this sd player not working
[09:59:22] <Tom_itx> maybe you should ask elm chan himself then
[10:05:07] <Fleck> tomatto: check your wiring
[10:05:51] <edman007> Tom_itx, no sound at all? do you have an oscilloscope?
[10:06:10] <Fleck> edman007: wrong nick
[10:06:32] <edman007> ohh, yea... tomatto ^
[10:07:36] <Fleck> also - sure you got FAT fs on sdcard tomatto?
[10:09:03] <beaky> why are 2 leds on my stk500 not lighting on? :(
[10:09:20] <edman007> that thing has not support for FAT anyways, right? you might be better off just writing the wave to the SD card directly, with something like dd (mac/linux) or Win32DiskImager
[10:10:09] <Fleck> edman007: no, it does support fat
[10:11:26] <edman007> Fleck, so then even if he did it right, the FAT fs could have put the wav file at the end of the SD card (which would make it probably not work right), I'd recommend not using a file system to avoid that possibility
[10:11:47] <tomatto> Fleck: i double check. i tried sdcard with FAT32 and FAT16 too
[10:12:00] <edman007> tomatto, try without FAT at all
[10:12:18] <edman007> take the wave, and just write it to the SD card itself, skip the filesystem
[10:13:02] <tomatto> it uses Petit-FatFs module
[10:14:03] <Fleck> tomatto: did you compilr from source or used .hex?
[10:14:26] <tomatto> Fleck: i tried it both ways
[10:14:56] <tomatto> using sd8p_mo
[10:15:04] <Fleck> ok so, my guss is - wrong wiring or wrong fuses
[10:18:06] <tomatto> Fleck: are these fuses ok? -U lfuse:w:0xe1:m -U hfuse:w:0xdd:m -U efuse:w:0xff:m
[10:19:26] <tomatto> Fleck: and this pinout
http://www.google.cz/imgres?imgurl=http%3A%2F%2Felasticsheep.com%2Fwp-content%2Fuploads%2F2010%2F01%2Fsd-card-pinout.png&imgrefurl=http%3A%2F%2Felasticsheep.com%2F2010%2F01%2Freading-an-sd-card-with-an-atmega168%2F&docid=iFv2pqdifYelGM&tbnid=rByYp9f3stpQlM%3A&w=447&h=499&ei=DbyoUfqhEOj44QTXqYD4DQ&ved=0CAIQxiAwAA&iact=rics
[10:20:44] <tomatto> Fleck: is it correct?
[10:53:29] <cart_man> RikusW: Hey Rikus how are you today>
[10:53:30] <cart_man> ?
[10:55:00] <beaky> if I keep reflashing my avr just for changing the value of one variable, will it harm my avr?
[10:55:05] <beaky> or is it okay?
[10:57:33] <cart_man> should be fine
[10:58:09] <cart_man> Ive been relentlessly flashing my AVRs because I have no ISDebugger and all of them still work fine
[10:58:23] <cart_man> well actually the 2 I have
[10:59:08] <beaky> ah
[10:59:18] <beaky> has anyone ever had an avr fail after being flashed or eeprom'd?
[10:59:28] <beaky> also does performance degrade the more you eeprom or flash it?
[11:00:18] <cart_man> Well... I think your EEPROM is the same type that comes in Flash Sticks...and they can be reprogrammed a shitload of times before failing so I dont thinkyou have to worry about that
[11:00:30] <beaky> ah
[11:00:34] <cart_man> BUT...I am not really sure. Although I did learn that wont be a problem in my tests
[11:01:12] <cart_man> I mean...how often do Flash Sticks break? I havent had 1 break actually
[11:01:15] <beaky> my professor said that after 3000 writes on eeprom, the uC becomes slower but maybe it's some ancient thing
[11:01:20] <cart_man> They outlive their usefullness
[11:01:32] <beaky> yeah these chips are always more reliable than we think :D
[11:01:42] <cart_man> Def yea!
[11:01:57] <cart_man> I heard statick go into one of my Atmegas and thought...Ahh shit >.<
[11:02:01] <cart_man> but stil worked fine
[11:27:37] <Casper> beaky: the flash endurance is 10000 write cycle
[11:27:47] <Casper> the eeprom is 100000 write cycle
[11:28:18] <beaky> ah
[11:28:23] <beaky> why is flash worse :(
[11:28:36] <Casper> different technology
[11:28:44] <Casper> and speed
[11:29:02] <beaky> ah t seems flash is faster
[11:29:05] <Casper> but that is why that you usually use the eeprom for variable storage
[11:29:20] <Casper> but 10k is still alot
[12:23:04] <beaky> is it evil to use the _BV macro?
[12:23:09] <beaky> will it confuse folks?
[12:24:01] * robotustra wants to propose to set 1 in = 25.00 mm
[12:27:42] * robotustra and call in "new inch"
[12:28:11] * robotustra 1 nin == 25.00 mm
[12:29:40] <Casper> and nft = 10in?
[12:29:49] <Casper> err 1nft=10nin?
[12:32:04] <inkjetunito> beaky: no
[12:33:02] <robotustra> Casper: probably
[12:34:09] <robotustra> Casper, this is more for convinient convertion without fractions
[12:34:14] <beaky> I love using _BV
[12:36:01] <robotustra> for me 1<<a is better than _BV(a)
[12:36:26] <inkjetunito> >><<
[12:37:34] <robotustra> and sometimes I write just 0x80
[12:37:51] <robotustra> or any other constant
[12:38:38] <robotustra> instead of bitvise operations
[12:43:00] <RikusW> 1 inch = 25.4mm
[12:43:06] <Amadiro> I think gcc has some extension that allows you to write b0000000 or so
[12:43:07] <Casper> beaky: get used to use bitshifting instead of _BV(), it used to be deprecated (thanks to those who don't know to code that complained loudly when it got deprecated....)
[12:43:27] <beaky> ah
[12:43:50] <beaky> so _BV is for folks who don't know bitshifting, rather than those who know it but are tired of typing 1<< ? :D
[12:43:52] <RikusW> robotustra: I've seen bit values move around between different avrs
[12:44:01] <RikusW> not often but it does happen
[12:47:21] <RikusW> Amadiro: 0b01010110
[12:47:21] <RikusW> 0x56
[12:47:29] <Amadiro> right
[12:47:31] <Amadiro> never used it myself
[12:47:49] <beaky> has anyone here tried returning from main? what happened :D
[12:49:52] <robotustra> RikusW: ORLY?
[12:50:14] <RikusW> yes
[12:50:32] <RikusW> I guess PORT registers and hex are safe
[12:51:35] <robotustra> RikusW: sorry, you are late, I know about this already 32 years since my childhood
[12:53:29] <beaky> bit values move around?
[12:54:49] <robotustra> beaky: in C I think no
[12:54:59] <beaky> ah
[12:55:07] <beaky> alright I will continue using _BV
[12:55:50] <RikusW> beaky: between different
[12:55:56] <RikusW> AVRs it might happen
[12:55:57] <robotustra> in asm there are different operations to shift and to rotate
[12:56:05] <RikusW> I've seen it once or twice so far
[12:56:18] <RikusW> robotustra: bitnames are the same as in C
[12:56:20] <beaky> ah
[12:56:28] <beaky> what is programming avr in asm like?
[12:56:40] <RikusW> almost like C
[12:56:43] <beaky> I only know C: asm is like black magic for me :(
[12:56:53] <RikusW> except you have to take care of register usage
[12:56:59] <tzanger> asm is just very discrete, very simple statements and you have to do everything yourself
[12:57:04] <RikusW> beaky: a quick example
[12:57:25] <RikusW> PORTB = 0x14; asm -> ldi r16,0x14 out PORTB,r16
[12:57:29] <beaky> so asm is the essence of imperative programming?
[12:57:37] <robotustra> beaky: it's like lower layers of neocortex
[12:58:14] <beaky> wow asm is nice
[12:58:19] <beaky> is it more concise than C?
[12:58:40] <RikusW> if(val == 0) {} end: asm-> lds r16,val cpi r16,0 brne end <some code> end:
[12:59:10] <RikusW> beaky: you have to code instruction by instruction
[12:59:11] <robotustra> less concise
[12:59:48] <RikusW> though you can do some flow acrobatics not possible in C :-P
[12:59:51] <robotustra> beaky: if you like makro - probably you will not like ASM
[13:00:04] <beaky> ah
[13:00:23] <beaky> alright I will make my atmega1284 blink leds in asm!
[13:00:27] <RikusW> I've done "exception handling" in asm returning back two function calls
[13:01:03] <robotustra> RikusW: there is a forth
[13:01:33] <robotustra> I would like to find good Forth compiler
[13:01:38] <robotustra> for chips
[13:01:42] <beaky> there's forth for avr?
[13:02:03] <Amadiro> write a forth frontend for gcc
[13:02:04] <robotustra> I'm not sure
[13:02:07] <RikusW> beaky: go read
http://www.atmel.com/Images/doc0856.pdf
[13:02:10] <Amadiro> instant-access to most architectures
[13:02:27] <RikusW> beaky: there was a guy in #avr doing Forth for AVR
[13:03:00] <robotustra> RikusW: who is it?
[13:03:06] <RikusW> i440r
[13:03:28] <RikusW> not seen him for a long time
[13:03:40] <robotustra> ok,
[13:03:51] <RikusW> there is #forth too
[13:03:57] <robotustra> oh
[13:04:02] <robotustra> thanks
[13:04:51] <RikusW> its quite beautiful in design, but I still cant get used to its syntax....
[13:05:19] <RikusW> /msg alis help for channel listings
[13:12:48] <beaky> wow
[13:13:59] <robotustra> RikusW: I like Forth syntax
[13:15:02] <beaky> yes it is elegant
[13:15:04] <beaky> like Haskell
[13:15:31] <beaky> but not as elegant as assembly language :D
[13:20:28] <robotustra> beaky: tests are differ
[13:21:23] <robotustra> *tastes
[13:21:25] <beaky> ah
[13:21:51] <robotustra> one like one things, other - different
[13:22:02] <beaky> I dream of the day where I can write my state machines as mutually recursive functions parametrized by state
[13:22:31] <robotustra> what is the final goal?
[13:22:35] <robotustra> AI
[13:22:36] <robotustra> ?
[13:22:54] <beaky> the final goal is to blink leds :D
[13:23:50] <robotustra> not bad, but you don't need to complicate things unless you are just wasting you life
[13:24:01] <beaky> ah
[13:24:37] <beaky> but I thought they would look very simple as mutually recursive functions
[13:24:39] <robotustra> do everything simple - and you'll get efficiency
[13:26:26] <robotustra> blinking of leds is just like : while(1) { PORTC = 0xFF; _delay(1000); PORTC = 0x00; _delay(1000); }
[13:26:46] <robotustra> where do you want to put recursion here?
[13:26:49] <twnqx> yey, another convoluter
[13:26:50] <twnqx> >_>
[13:27:07] <twnqx> PORTC ^= 0xff; _delay (1000);
[13:27:20] <robotustra> yes
[13:27:27] <robotustra> even simpler
[13:27:32] <robotustra> just inversion
[13:28:04] <robotustra> twnqx but what if he wants to made different value of ON and OFF states?
[13:28:05] <beaky> I wanna write a program that has 8 pushbuttosn and 8 leds
[13:28:17] <beaky> and every button press makes the leds blink at bigger frequencies
[13:28:53] <beaky> using pin change interrupt, I tried to do it and it worked :D
[13:29:01] <robotustra> 1 button drive 1 led?
[13:29:11] <beaky> yes
[13:29:25] <robotustra> ok
[13:29:32] <beaky> each led blinks at different frequencies
[13:29:34] <robotustra> so, you already did it?
[13:29:43] <beaky> almost
[13:29:54] <beaky> I have a problem with using PCINT
[13:30:10] <robotustra> why?
[13:30:38] <beaky> I wrote my PCINT isr to do stuff on rising edge
[13:30:53] <robotustra> and?
[13:30:55] <beaky> so when I push two buttons at the same time... the pcint fires twice
[13:31:38] <beaky> maybe using PCINT is a bad idea with pushbuttons
[13:31:38] <robotustra> it can be a problem of bouncing buttons
[13:31:42] <beaky> ah
[13:31:50] <robotustra> it's a first
[13:32:09] <robotustra> second, what kind of buttons do you use?
[13:32:13] <beaky> how do people build remote controls with tons of buttons if MCUs can only properly work with 3 interrupts?
[13:32:23] <beaky> I am using those tiny pushbutton things that go "click"
[13:32:36] <RikusW> poll the pins...
[13:32:41] <RikusW> or use PCINT
[13:32:53] <robotustra> beaky it conects to GND or to VCC?
[13:33:03] <robotustra> when you click it?
[13:33:24] <beaky> it connnects to vcc
[13:33:37] <beaky> I think
[13:33:48] <robotustra> more common way to GND button
[13:34:08] <robotustra> and falling eage for interrupt
[13:34:18] <robotustra> less bouncing
[13:34:44] <robotustra> just expetrience
[13:34:52] <beaky> ah
[13:35:09] <beaky> my proffessor lways had them to Vcc
[13:35:12] <robotustra> but it depends
[13:35:40] <GuShH> beaky: is he/she an imposing professor?
[13:35:41] <robotustra> yes, it's doesn't matter
[13:37:20] <beaky> yes
[13:37:54] <robotustra> beaky: _usually_ when you power up controllers, it's good to have "0" on output pins and "1" on input pins
[13:39:04] <robotustra> but it USUALLY
[13:39:21] <robotustra> sometimes you can do what ever you want.
[13:40:45] <beaky> ah
[13:40:53] <beaky> how do you set input as 1?
[13:41:15] <RikusW> its a good idea to leave it all inputs...
[13:44:24] <robotustra> DDRA = 0x00; //Set port a as input
[13:44:24] <robotustra> x = PINA; //Read contents of port a
[13:45:42] <robotustra> but before you read something do PINA = 0xFF;
[13:46:13] <robotustra> it's for all pins of port A you set pull up resistors
[13:47:29] <RikusW> PORTA = 0xFF; for pullups
[13:47:43] <RikusW> PINA = 0xFF will toggle the port pins instead
[13:47:49] <RikusW> (on new AVRS)
[13:48:19] <robotustra> I usually set PORTA = 0xFF also
[13:48:31] <robotustra> even for older
[13:49:18] <robotustra> does it draws more current?
[13:51:28] <beaky> ah
[13:52:46] <beaky> so this whole time I've been doing it wrong? (reading PIN without setting the PORT beforehand)?
[13:53:20] <robotustra> what controller do you use?
[13:53:32] <robotustra> ATiny?
[13:53:39] <beaky> ATmega328
[13:54:06] <robotustra> it should work without setting PORTA = 0xff
[13:54:11] <beaky> ah
[13:54:42] <beaky> btw what does the AT in ATmega or ATtiny stand for?
[13:55:04] <robotustra> I guess AT== ATMEL
[13:55:09] <beaky> ah
[13:55:31] <robotustra> beaky: are you in OAE?
[13:55:35] <beaky> (before I watched atmel marketing vids, I kept calling pronouncing it as at rather than "eighty")
[13:55:47] <beaky> oae?
[13:55:59] <robotustra> Emirats?
[13:56:05] <beaky> yes
[13:56:16] <robotustra> Dubai?
[13:56:23] <beaky> I am in the abu dhabi city
[13:56:39] <robotustra> ok
[13:56:46] <robotustra> it's hot ?
[13:57:17] <RikusW> from what I hear the road tar melts...
[13:57:20] <beaky> yes at this time of year it is quite warm
[13:57:30] <RikusW> 40C ? or more ?
[13:57:43] <beaky> it was like 50C a couple of days ago
[13:58:15] <RikusW> no thanks
[13:58:28] <RikusW> at 35C its almost to hot for me
[13:58:42] <RikusW> 20-30C is nice
[13:58:46] <beaky> I can't stand really warm weather either :(
[13:59:07] <beaky> indoors its alright (unless you are in a complex with no air conditioning)
[13:59:51] <robotustra> now 35 in montreal
[13:59:58] <robotustra> too hot
[14:02:05] <RikusW> its 18C indoors here now
[14:02:06] <RikusW> ZA
[14:03:22] <inkjetunito> 15-22 C is comfortable
[14:03:51] <RikusW> well waking up at 5C isn't... :-P
[14:04:21] <RikusW> Houses in za isn't as well insulated as in eu
[14:06:19] <Casper> and probably even less than in canada :D
[14:07:28] <robotustra> canadian houses are bullshit
[14:10:01] <beaky> my avr wakes up from sleep 60 times per second to flip bits; how do I keep it asleep while still flipping bits?
[14:10:15] <inkjetunito> beaky: outsource
[14:13:02] <Casper> beaky: the avr can not do anything while it sleep
[14:13:02] <RikusW> beaky might need a Canadian home in Dubai :-D to keep the heat out...
[14:13:12] <Casper> yeah
[14:13:32] <Casper> 6" insulations in the walls, 10" in the ceiling
[14:13:50] <Casper> there is some talk about changing that to 8 and 12
[14:14:12] <beaky> everyone has tinted windows to repel the radiation
[14:14:15] <beaky> except me :(
[14:14:35] <RikusW> get sunglasses :-P
[14:15:33] <robotustra> or dig a well
[14:16:29] <robotustra> beaky: you can work in basement
[14:16:37] <robotustra> under the ground
[14:18:23] <Casper> current outside temp: 31C+humidex = 38C
[14:18:40] <Casper> first heat wave of the year... and people complain already :D
[14:19:27] <robotustra> Casper: where are you?
[14:19:34] <robotustra> canada?
[14:20:38] <Casper> yup
[14:21:03] <Casper> some in our familly (3 hours north) got 8" snow last week
[14:22:05] <tzanger> Casper: you must be significantly more north than me
[14:22:19] <tzanger> our weather has be crazy (frost on may 24?) but not that crazy
[14:23:54] <Casper> montreal
[14:24:24] <robotustra> Casper: neibours
[14:24:41] <robotustra> I'm H3X 2V4
[14:24:50] <tzanger> hm, I'm N2C 1X3
[14:26:16] <Casper> I'm J4K 4S8
[14:26:27] <Casper> (and now people must wonder what is all those :D)
[14:27:13] <robotustra> :)
[14:28:37] <robotustra> oh, Rive Sud
[14:28:51] <robotustra> I don't travel much
[14:29:48] <RikusW> Radio amateur callsigns ?
[14:32:21] <tzanger> no
[14:32:23] <tzanger> postal codes
[14:32:43] <Tom_itx> foreign ones
[14:33:08] <tzanger> heh
[14:33:11] <tzanger> not to us
[14:37:08] <Tom_itx> i have seen some pretty strange looking addresses
[14:41:21] <robotustra> postal codes for canada is rulez
[14:42:37] <robotustra> you can make 5 mistakes spalling the street or other thing, but if you write suite number and postal code correctly - you'll fit
[14:46:26] <tzanger> yep
[14:47:03] <twnqx> and what if you randomize one or more of the random letters?
[14:55:46] <Casper> the postal code identify a strip of address on one street from one corner to the other
[14:55:54] <Casper> so maybe 10-15 houses
[14:56:49] <Casper> the civic number and the postal is all what is needed to identify an house
[14:59:20] <robotustra> Casper: and 99% of people live in houses, isn't it?
[15:03:52] <Fleck> /usr/lib/gcc/avr/4.6.2/../../../avr/include/avr/pgmspace.h|1140|error: unknown type name 'uint_farptr_t'| << ideas?
[15:05:33] <Casper> robotustra: maybe not 99%
[15:05:39] <Casper> but lots yeah
[15:05:47] <Casper> atleast way more than in mtl
[15:06:23] <beaky> How do you get started with avr?
[15:07:00] <beaky> suppose I am a dude who has never seen a uC in his life
[15:07:04] <RikusW> plug in ans switch on ;)
[15:08:25] <robotustra> I just fixed one guy program and in two month I understood that it was avr
[15:09:56] <DagoRed> beaky: Get an arduino, use the AVR tools with it because you will get annoyed with using a programmer.
[15:10:23] <robotustra> I started my embedded programming with ADuC controllers
[15:10:37] <beaky> ah
[15:10:40] <beaky> I got an avr dragon
[15:10:42] <robotustra> after it was C8051F310
[15:10:53] <robotustra> after a lot of stuff
[15:11:01] <robotustra> and only after that avr
[15:11:12] <beaky> so avr is the best uC for noobs?
[15:11:31] <beaky> since I can tell people "just get an arduino :D"
[15:12:08] <robotustra> I think that arduino is a fast way to start, but you'll miss a lot of fun
[15:12:22] <beaky> rather than buying an expensive proprietary debugger (that must have extra pins soldered before it is useful!) with an expensive proprietary compiler that only works on an expensive proprietary OS
[15:12:35] <beaky> aka PIC
[15:12:54] <robotustra> like aploading your code with avrdude from console
[15:13:01] <robotustra> *uploading
[15:13:08] <beaky> ah
[15:13:20] <beaky> avrdude is awesome
[15:13:28] <beaky> I use it on my mac
[15:13:38] <DagoRed> cool
[15:13:48] <beaky> (along with the other stuff on the excellent CrossPack package)
[15:14:03] <beaky> http://www.obdev.at/products/crosspack/index.html
[15:16:34] <beaky> so are arduinos really plug-n-go with the ordinary avr toolchain?
[15:16:56] <beaky> or do they have special firmware that needs the silly arduino ide? D:
[15:19:36] <DagoRed> they are really plug an go.
[15:19:58] <DagoRed> the hard part with AVR is figuring out the baud rate to upload the code with AVR dude.
[15:20:03] <DagoRed> It's that simple.
[15:20:26] <RikusW> http://www.play-hookey.com/semiconductors/specialized/specialized_diodes.html
[15:20:34] <DagoRed> Get an arduino nano and just mess with it. I like it because it's an ateml, fits on a bread board, and just works.
[15:21:53] <beaky> ah
[15:22:02] <beaky> when would I need a baud rate higher than 125kHz?
[15:22:24] <RikusW> there is not much speed improvement about 125kHz
[15:22:40] <RikusW> a bit to 512kHz maybe
[15:23:07] <RikusW> but then avr clocks need to be set up right (high enough)
[15:23:16] <beaky> ah
[15:23:19] <RikusW> >= 2MHz
[15:23:38] <RikusW> preferably 4MHz at least and don't forget about CKDIV8
[15:24:13] <RikusW> 125k usually just works
[15:24:48] <DagoRed> beaky: another nice thing about the nano boards. Crystal on board.
[15:32:51] <robotustra> I play with this board
http://www.ebay.com/itm/STK128-ATMEL-AVR-ATMEGA128-16AU-Development-Board-kit-/390224472153?pt=LH_DefaultDomain_0&hash=item5adb30e859
[15:33:02] <robotustra> ah, beaky has left
[16:09:00] <twnqx> tzanger?
[16:16:50] * robotustra for beaky http://www.youtube.com/watch?v=yHJOz_y9rZE&list=PLF76E2689442DB8A3
[17:08:09] <Fleck> meh, stupid q. - if I want to set/clear bit based on simple true/false expression - should I use if ... else ...?
[17:08:40] <twnqx> true ? set : clear;
[17:09:27] <twnqx> or set_bit_to (!!(whatever you want to test))
[17:09:31] <twnqx> so many options
[17:09:38] <Casper> lotta ways
[17:09:46] <Fleck> I need fastest :D
[17:09:50] <Casper> but often switch are to be avoided
[17:09:54] <twnqx> that will depend
[17:10:12] <Casper> depend on how many conditions
[17:10:26] <twnqx> whether you know the old state, whether you care about the other bits
[17:11:04] <Fleck> I don't know old state, care about other bits
[17:13:47] <Fleck> set_bit(bit,boolean) << would be great :D w/o ifs and conditional assignment
[17:14:00] <twnqx> so... do it?
[17:14:10] <Fleck> if true - sets, if false - clears!
[17:14:19] <twnqx> however
[17:14:20] <Fleck> twnqx: tell me how D
[17:14:31] <twnqx> setbit will expand to set/clear anyway
[17:14:39] <Fleck> ...
[17:14:52] <twnqx> if you care about the other bits you need to mask out
[17:15:29] <twnqx> i don't know the asm of avr enough, i know there are clear bit / set bit instructions
[17:15:42] <twnqx> not if there's a set_bit_to_value instruction
[17:15:43] <Fleck> 2...
[17:16:17] <twnqx> in the end it's all the same
[17:24:53] <Fleck> twnqx: just trying leds with 8-bit latch, but not addressable... so all leds blink while I shift, looks like I can't do it faster than this
[17:25:17] <Fleck> http://paste.opensuse.org/32473766
[17:25:23] <Fleck> the code I have so far
[17:25:35] <twnqx> > 500ms
[17:25:47] <twnqx> oh wait, that's between bytes
[17:25:54] <Fleck> yep
[17:27:00] <Fleck> now the last led blinks with 500ms intervals, but all others blink fast just before last led is turned on, cause shifting happens from 1st output bit to last...
[17:27:10] <twnqx> dunno if this helps you
[17:27:12] <twnqx> http://pastebin.com/4Wx31wKV
[17:27:12] <Fleck> thought - that would happen fast
[17:27:22] <twnqx> this is about as fast as i got SPI which seems similar
[17:28:57] <twnqx> basically it reads the port initially, then calculates the output values for the possible combinations of output bit and clock bit
[17:29:09] <twnqx> so it can just write instead of masking
[17:29:29] <twnqx> of course it dies if an interrupt occurs in between and changes other bits :P
[17:29:39] <twnqx> well, the change done by the interrupt dies
[17:30:01] <twnqx> you might get away with removing the nop and the read
[17:30:04] <twnqx> the read for sure
[17:31:43] <twnqx> mh
[17:32:42] <twnqx> your pulse function is suboptimal too
[17:32:52] <twnqx> tons of overhead if the compiler won
[17:32:56] <twnqx> 't inline the function
[17:33:17] <twnqx> what optimization level did you use?
[17:34:49] <Fleck> -Os
[17:35:17] <twnqx> bad
[17:35:24] <twnqx> try -O3 and see if that changes things
[17:35:34] <twnqx> if yes we can go back at the code
[17:36:27] <Fleck> same
[17:36:35] <Fleck> I think latch is the problem
[17:36:51] <twnqx> well, it will shift the data through all LEDs
[17:36:52] <Fleck> or att13a :D
[17:36:57] <Fleck> yep
[17:37:05] <twnqx> do you clock the tiny at the max?
[17:37:12] <Fleck> just thought it will do it fast
[17:37:20] <Fleck> yep, 9.6MHz
[17:37:23] <Fleck> internal clock
[17:37:43] <twnqx> with or without clkdiv8 fuse? :>
[17:37:49] <Fleck> w/o
[17:38:05] <twnqx> strange
[17:38:17] <twnqx> you shouldn't be able to notice flickering at that speed
[17:38:18] <Fleck> with ckdiv8 delay is not 500ms :D
[17:38:26] <xorly> hw SPI is bad?
[17:38:33] <twnqx> no, why?
[17:39:26] <xorly> as I read code, it was handled by software
[17:40:05] <twnqx> this one yes
[17:40:49] <twnqx> there are reasons :P
[17:41:34] <xorly> yeah, I see, you need low speed for debug by eye
[17:41:40] <twnqx> uh
[17:41:51] <twnqx> that code runs hundreds of kilobits
[17:41:56] <Fleck> twnqx:
http://fleck.rullz.lv/latch/VID_20130601_012529.m4v
[17:42:35] <twnqx> do you want any of the other leds to light up
[17:42:46] <twnqx> ?
[17:42:50] <Fleck> nope :D but you can see, they blink
[17:42:59] <xorly> ok, I read that code with delay, sorry for disturbing
[17:43:16] <twnqx> there is a delay :P one nop.
[17:43:52] <twnqx> it was needed, code was overruning my flash rom
[17:47:30] <Fleck> maybe att13a just toggles pb0 too slow twnqx? :D
[17:47:39] <Fleck> Ill try with atmega2560
[17:49:18] <twnqx> i only used one attiny13 so far
[17:49:27] <twnqx> for the sole purpose of generating a 50hz signal
[17:51:35] <Badaboom> twnqx
[17:51:47] <twnqx> boom
[17:51:59] <Badaboom> I will make an effort this weekend
[17:52:21] <Badaboom> and if all goes well ill send one,, if i can figure it out
[17:52:33] <Badaboom> I want to do likt that link i sent
[17:52:36] <Badaboom> like
[17:52:57] <Badaboom> I have access to a scope thisweekend
[17:53:28] <twnqx> :)
[17:53:44] <Badaboom> Went flying today on another note
[17:53:54] <Badaboom> Cessna 182RG
[17:54:05] <twnqx> your own?
[17:54:09] <Badaboom> lmao
[17:54:11] <Badaboom> I wish
[17:54:18] <Badaboom> no its like a timeshare
[17:54:57] <Badaboom> 4 seperate ppl split the time every month or schedule cycle
[17:55:16] <Badaboom> we change it up depending on the needs and time of the year
[17:55:19] <twnqx> ah
[17:55:30] <Badaboom> I get to wash it tomorrow:(
[17:55:35] <twnqx> heh
[17:56:10] <Badaboom> oh and find out why the fuel has water in it
[17:56:18] <Badaboom> i think its the tankers on the line
[17:56:54] <Badaboom> nothing like going up for a spin over the beach and findoung out it sputters
[17:57:10] <edman007> what is wrong with this? ISR(USI_OVF_vect){int_spi();}
[17:57:19] <Badaboom> I noticed it in my fuel cup but went anyway...oops
[17:57:30] <edman007> I get static declaration of '__vector_16' follows non-static declaration
[17:58:08] <Badaboom> oh well,, leme get dinner started,, bbiab
[17:58:46] <[z_z]> can someone explain this: Uninitialized global or static variables end up in the .bss section.
[17:59:06] <[z_z]> if they are uninitialized, why do they take up space?
[17:59:26] <Fleck> cause mem is getting reserved?
[17:59:39] <twnqx> edman007: nothing, except that you might have it predeclared somewhere
[18:00:33] <edman007> [z_z], I'm not 100% sure about avr, but it's more of a linker option, basically static/global stuff gets put into the .bss so the linker can initialize those variables (instead of making a function that loads them)
[18:00:42] <edman007> I'm pretty sure it actually saves space
[18:01:21] <edman007> twnqx, gcc says it's declared on that line...
[18:01:41] <[z_z]> but they are uninitialized... so there ate no initial values to store.
[18:01:43] <twnqx> it will also tell you why it has a duplicate
[18:01:57] <edman007> says 'note: previous declaration of '__vector_16' was here' (and it's the same line as the error)
[18:02:23] <edman007> looking through the docs, it should be declared in the io.h....but gcc seems to say ISR declares it
[18:03:19] <edman007> [z_z], but you need to reserve the space in memory, global/static stuff is not allocated runtime, it's allocated at program start
[18:03:33] <[z_z]> oh. .noinit will not be initialized to zero during startup as would normal .bss data.
[18:03:35] <edman007> and you can't write to unallocated memory
[18:03:59] <[z_z]> so .bss is just .data but full of zeros?
[18:05:41] <edman007> [z_z], well it doesn't have to be full of zeros
[18:06:25] <edman007> anyways, I'd say it's good form to initialize it...if you're really tight on space, I think there are some linker things to skip it
[18:07:00] <[z_z]> what else can i put in it?
[18:08:54] <Fleck> edman007: what avr-libc version?
[18:09:15] <edman007> 1.8.0
[18:09:17] <Fleck> In more recent avr-libc implementations, the SIGNAL macro and concept is replaced by the ISR macro, and the SIG_xxxx names replaced by xxxy_vect values.
[18:09:34] <edman007> Fleck, yea, I'm using the ISR() stuff though
[18:10:58] <edman007> Fleck,
http://pastebin.com/P8iGNrnH
[18:11:49] <Fleck> what chip?
[18:12:00] <[z_z]> hm. is it possible to have a bss+data sum that is larger than the available SRAM?
[18:12:13] <edman007> tiny24a
[18:19:10] <Fleck> edman007: have you tried static ISR(USI_OVF_vect){int_spi();} ?
[18:20:15] <edman007> error: invalid storage class for function '__vector_16'
[18:20:18] <edman007> :/
[18:20:22] <Fleck> yeah
[18:22:34] <Fleck> and if you move ISR outside of init function?
[18:25:21] <edman007> ...builds
[18:26:04] * edman007 checks docs some more
[18:26:31] <edman007> are ISR's only able to be set at build time in avr-libc?
[18:27:52] <edman007> ahh, docs note "...ISR() macro when declaring the interrupt function..."
[18:28:09] <edman007> so I guess ISR defines a function...that makes some sense
[18:29:04] <edman007> Fleck, thanks though
[18:29:13] <Fleck> yeah, defines a function
[18:29:43] <Fleck> becomes void __vector_16(void) something... :D
[18:29:49] <Fleck> welcome
[18:30:14] <Fleck> I think I saw this @ avrfreaks forum once
[18:30:28] <edman007> yea, for some reason I was thinking it just writes your pointer to the interrupt table...
[18:33:54] <Fleck> twnqx: one mega2560 same story! :D
[18:34:07] <twnqx> no surprise
[18:34:14] <Fleck> yep
[18:34:15] <twnqx> i would bet the chip can handle the clock
[18:34:27] <twnqx> what's the shit reg you're using?
[18:34:29] <twnqx> shift*
[18:34:36] <Fleck> :DDD
[18:35:09] <Fleck> http://argus.lv/shop/download/429810/hwindex.htm
[18:35:10] <Fleck> this one
[18:36:33] <Fleck> and I like adressable more ;D
[18:36:44] <Fleck> no shifting...
[18:37:59] <twnqx> how did you connect the inputs?
[18:38:13] <twnqx> i suppose you tied a&b together
[18:38:14] <Fleck> what do you mean - how?
[18:38:40] <Fleck> I tried A & B together, tried to pin B to high...
[18:38:43] <Fleck> no difference
[18:41:46] <Fleck> anyway - basic idea was to turn on/off relays, I think relay will not turn on with such a small pulse, what do you think twnqx?
[18:42:25] <twnqx> it shouldn't be visible
[18:42:45] <twnqx> no idea what frequency you can clock relais with, but i'd go with a larger chip and proper relais drivers
[18:43:16] <Fleck> well, after latch there is a 8xNPN driver
[18:43:30] <Fleck> ULN2803A
[18:44:49] <twnqx> ... just take some chip with 8pin put and save the latch?
[18:44:53] <twnqx> out
[18:45:16] <Fleck> sure but thats not the point! :)
[18:54:59] <tomatto> Fleck: i double checked wiring and fuses again for that sd8p_mono again and it is correct.
[18:55:23] <tomatto> Fleck: uln2803 is darlington driver
[18:56:58] <Fleck> yep
[18:57:29] <tomatto> i hate darlingtons :)
[18:57:35] <twnqx> awww
[18:57:38] <twnqx> poor things
[18:57:54] <Fleck> why? :D
[18:57:59] <Fleck> I love them :P
[18:58:00] <tomatto> do you know about really npn driver or mosfet thing?
[18:58:28] <tomatto> Fleck: high drop voltage
[18:58:48] <twnqx> they drop high voltage? cool, just what i need
[18:59:36] <tomatto> 1.1 - 1.3V on each darlington between CE
[19:02:53] <Fleck> tomatto: sorry, I don't understand your q.
[19:03:14] <Fleck> I know about really? :)
[19:03:43] <tomatto> Fleck: do you know about 8xNPN or 8xMOSFET driver? not darlington
[19:05:05] <Fleck> yes I know
[19:05:24] <Fleck> there are also mosfet latches ;D
[19:05:37] <tomatto> tell me
[19:05:40] <thetruthisoutthe> h
[19:06:32] <Fleck> tell you what tomatto?
[19:06:39] <Fleck> whats your native lang. btw?
[19:07:05] <tomatto> Fleck: names of these ICs
[19:07:20] <tomatto> Fleck: czech. why?
[19:07:36] <Fleck> tomatto: hard to understand - what you mean! :D
[19:07:48] <Badaboom> h
[19:08:01] <Fleck> TPIC6B595 is mosfet latch
[19:08:06] <Fleck> shift reg...
[19:08:47] <tomatto> something with at least 20 mA per output?
[19:09:04] <Fleck> 130mA
[19:09:20] <Fleck> *150mA
[19:09:20] <edman007> tomatto, what are you driving? a lot of the driver IC's are configured in a H-bridge or half H-bridge
[19:09:55] <tomatto> edman007: 7segment led displays
[19:10:30] <tomatto> Fleck: and with outputs on the same side
[19:10:34] <edman007> tomatto, ahh, they make driver chips that combine them with some form of multiplexing
[19:11:24] <tomatto> edman007: they? do you know some concrete one?
[19:11:31] <edman007> checking
[19:12:28] <thetruthisoutthe> tomatto <= cd4094, and pnp transistors, or just cd4094/digit
[19:13:06] <Fleck> tomatto: outputs on the same side? :D
[19:13:44] <tomatto> thetruthisoutthe: i have cd4094, but it has only 8mA per output
[19:13:48] <Fleck> you mean like in1, out1, in2, out2 on one side?
[19:13:52] <thetruthisoutthe> tomatto <= so?
[19:14:02] <tomatto> thetruthisoutthe: too less
[19:14:07] <Fleck> tomatto: thats why he said + pnp transistor ;D
[19:14:31] <thetruthisoutthe> use 1 4094 / digit and you can have effective 4x current for 4 digits compared to the scaning method.
[19:14:38] <edman007> tomatto, 74451, it's a standard BCD-7 segment chip, if you're doing numbers
[19:14:41] <thetruthisoutthe> 32mA avg.
[19:14:54] <edman007> otherwise, just look through
http://www.digikey.com/product-search/en/integrated-circuits-ics/pmic-display-drivers/2556426
[19:15:00] <edman007> lots and lots of driver ICs
[19:15:09] * edman007 leaves
[19:15:56] <tomatto> Fleck: i mean when you have so16, i want to have outputs pins 9-16
[19:18:14] <thetruthisoutthe> also a led is not a laser diode, it will work just fine and with even more efficiency at 8mA than 15mA.
[19:19:01] <thetruthisoutthe> 8mA/ded = 64mA / digit anyway.
[19:19:05] <thetruthisoutthe> LED
[19:19:14] <Badaboom> hmm
[19:19:59] <thetruthisoutthe> i think i'd go for 1-4mA / segment
[19:20:08] <thetruthisoutthe> if it can be seen in daylight too
[19:20:40] <thetruthisoutthe> ofc it can be PWM-ed
[19:22:10] <Badaboom> <edman007> tomatto, ahh, they make driver chips that combine them with some form of multiplexing.. yes the max7219,, but its quirky
[19:22:13] <tomatto> when sun is shining, i see almost nothing
[19:22:16] <[z_z]> avr32-size -d -B bin/example.elf outputs a .dec section. whats it used for?
[19:26:44] <Badaboom> The reason chicken tastes like everything --->>> diapsids ..they are related to this now extinct species class that now includes reptiles
[19:29:06] <Fleck> tomatto: ok, now I understand why you don't like darlingtons :D cause you whant to use them in the wrong way! :D
[19:29:09] <thetruthisoutthe> tomatto <= what you are doing you definitely do it wrong
[19:30:21] <tomatto> Fleck: how do you know? and what is the correct way?
[19:30:43] <tomatto> thetruthisoutthe: why do you think so?
[19:31:48] <thetruthisoutthe> because E is approximately m*c^2
[19:35:38] <tomatto> are you fucking kidding me?
[19:36:57] <thetruthisoutthe> not my idea though :(
[19:37:47] <jadew> just released a library for SPI over USI for tiny2313 if anyone is interrested:
http://eenoob.com/home/post?id=5
[19:38:04] <jadew> Badaboom, you might wanna take a look at it
[19:38:05] <Badaboom> lmao,, wonder who that might be jadew:)
[19:38:19] <Badaboom> lol,, yes of course,, ty
[19:38:32] <jadew> np, this is not the one I gave you last time ;)
[19:38:56] <jadew> this one supports all the modes
[19:39:19] <Badaboom> nice,, ty,, ill read it now
[19:39:23] <jadew> np
[19:39:44] <jadew> damn it, forgot to spell check
[19:39:47] <jadew> lol
[19:40:48] <jadew> done, fixed the spelling errors, sorry about that
[19:41:24] <Badaboom> np:)
[19:45:23] <Badaboom> nice,, even put the header:)
[19:46:23] <jadew> figured I'd put more info in the article, but there's not that much to say
[19:46:32] <Badaboom> :)
[19:50:02] * Badaboom taps his foot waiting for studio to open
[19:51:10] * Xark finds it somewhat amusing that the AVR Studio "mascot" is a bug. :)
[19:51:27] <Badaboom> lol,, ladybug
[19:51:44] <Xark> Badaboom: Yeah, probably staring at it waiting for the load. :)
[19:51:54] <jadew> nice observation Xark hehe
[19:51:57] <Badaboom> lmao,, yup
[19:52:51] <Xark> However, other than its size, it is a pretty nice "free" IDE (compared to other vendors IMHO).
[19:53:42] <jadew> that's because it's based on visual studio
[19:53:50] <jadew> really good move on their part
[19:54:08] <Xark> jadew: Yeah, and has Visual Assist pre-installed (required to make VS not suck). :)
[19:54:40] <jadew> Xark, hehe, yeah it's a really nice tool, expensive as well
[19:55:14] <Xark> jadew: Yeah, so Atmel gets "bonus points" for including it (no doubt they paid for us). :)
[19:55:43] <jadew> yeah, clearly they paid a beefy fee
[19:56:26] <Xark> jadew: Indeed (no doubt MS VS license isn't "cheap" either).
[19:57:01] <jadew> Xark, about that, I'm not 100% sure, it might be free, but it was a long time since I looked into that
[19:57:41] <Xark> jadew: Pretty sure MS doesn't let companies use it for free (even if they have a free cut-down version). :)
[19:58:29] <jadew> really can't remember, but I did look into a barebones VS a while ago and I think it was free of charge, can't vouch for it tho
[19:58:40] * Xark 's work just paid $599 a pop for some 2010 VS Pro licenses
[19:59:09] <jadew> Xark, will you switch to VS 2012 eventually?
[19:59:09] <Xark> jadew: Yes, they have an "Express" version that is free (with some limits, but still fairly usable).
[19:59:22] <jadew> Xark, I know, but that's not what I'm talking about
[19:59:34] <Xark> jadew: If forced. 2010 actually came with 2011, but 2011 is a "dud".
[19:59:46] <jadew> I'm talking about building _your_ ide on top of VS and redistributing it
[20:00:14] <jadew> Xark, my personal opinion is that VS started to degrade after 2005
[20:00:22] <jadew> scratch that, make it a fact, not an opinion
[20:00:49] <jadew> I tried an express edition from 2012... looks like a joke
[20:01:02] <jadew> like it was made for end users, not programmers
[20:01:03] <Xark> jadew: We liked 2008 (2005 with stability fixes). Some of the newer compiler features are kind of nice though (but we rarely use MS compiler).
[20:01:52] <jadew> well, at this point, the only reason to upgrade would be to get some of the c++11 features
[20:02:01] <jadew> but since thei failed to implement most of them... meh
[20:02:12] <jadew> for auto? no thanks.
[20:02:45] <Xark> jadew: Yeah, kind of nice, but too new for us to use in portable code.
[20:03:18] <jadew> I feel the same way
[20:14:20] <jadew> Xark:
http://www.microsoft.com/en-us/download/details.aspx?id=115
[20:14:22] <jadew> it's free
[20:15:32] <Xark> jadew: Pretty sure it is not. The Visual Studio 2010 Shell is just a SDK for Visual Studio I believe. I quote: " The Visual Studio Shell (integrated mode) seamlessly integrates with Visual Studio 2010 Professional and above. "
[20:15:35] <jadew> http://msdn.microsoft.com/en-us/library/bb129445%28v=vs.110%29.aspx
[20:15:59] <jadew> The Visual Studio integrated shell includes the integrated development environment (IDE), debugger, and source control integration. No programming language is included. However, the integrated shell does provide a framework that allows you to add programming languages.
[20:16:17] <Xark> ...keep reading. :)
[20:16:55] <jadew> on the older versions it doesn't say that it integrates with the current one ;)
[20:17:16] <jadew> and avr studio is using something older
[20:17:38] <jadew> I think the 2005 version used to be paid, or might have came with a pricey msdn subscription, but I'm sure atmel could afford that
[20:18:51] <Xark> jadew: Yeah. If it were free, I am sure we would be seeing a lot more compilers come with VS IDE.
[20:19:13] <jadew> there are some
[20:19:29] <Xark> jadew: Yes, all from companies I have no trouble coughed up cash.
[20:19:38] <jadew> nope, let me find one ;)
[20:20:39] <jadew> here's an example:
http://www.jcxsoftware.com/jcx/vsphp/downloads
[20:20:49] <jadew> "This installer will download the full VS.Php package. It will also install any missing components you may have including the Visual Studio 2012 shell."
[20:21:11] <Xark> jadew: Still requires VS though.
[20:21:48] <jadew> well, yeah, but I think this one wanted this
[20:21:59] <jadew> it probably made no sense installing as a separate program
[20:22:00] <thetruthisoutthe> do you think i should put an endpointer to the first word of my datalog?
[20:22:15] <jadew> endpointer?
[20:22:17] <thetruthisoutthe> if the value pointed to by is not zero, or out of range, then it can be another dataset
[20:22:59] <jadew> that's a bit out of context for anyone to have an opinion :)
[20:23:17] <jadew> how does it get out of range anyway?
[20:23:21] <thetruthisoutthe> yeah i was thinking about i can also subtract start position from the endpointer address to get dataset size, if i point to dataset end
[20:23:39] <thetruthisoutthe> if it is a word, and i point into memory, or eeprom
[20:24:01] <thetruthisoutthe> it can be out of range
[20:24:07] <jadew> why?
[20:24:13] <jadew> how do you get it there?
[20:24:21] <thetruthisoutthe> because the atmega has like 1kB ram and 512B eeprom
[20:24:46] <jadew> so what?
[20:25:05] <thetruthisoutthe> are you trolling me?
[20:25:10] <Xark> thetruthisoutthe: Depending on the life of this application, it may not be a good idea to have a "special" location in EEPROM that you have to write to regularly (vs spreading out the writes).
[20:25:24] <jadew> no... but how the hell do you get a pointer to go out of range in normal operation
[20:25:49] <thetruthisoutthe> well it can bet out of range during normal use by 1-4
[20:26:00] <thetruthisoutthe> *get
[20:26:12] <thetruthisoutthe> depending on how you do the calcualtion, overflow detection
[20:26:25] <thetruthisoutthe> or, intentionally
[20:26:40] <thetruthisoutthe> or pointing to uninitialized eeprom address...
[20:26:45] <thetruthisoutthe> that will be 0xff ...
[20:27:54] <thetruthisoutthe> also, using all 512 byte of eeprom implies not having a valid endpointed address
[20:28:35] <jadew> p = 0; *p = 1; ++p;
[20:28:49] <jadew> that's what you mean?
[20:29:22] <thetruthisoutthe> i just write it after loop, eeprom writes are slow and limited
[20:29:48] <jadew> so you're not checking the range before the write?
[20:30:03] <thetruthisoutthe> ofc i check range
[20:30:18] <jadew> then what's the issue?
[20:30:40] <thetruthisoutthe> i was asking about your opinions about data structure on avr
[20:31:16] <jadew> I'm not entirely sure what you mean by that endpointer or how you plan to use it
[20:31:27] <jadew> normally you don't use an end pointer, you use a start pointer
[20:31:56] <jadew> and when you write stuff to its address you make sure that pointer + sizeof(object) < limit
[20:32:10] <jadew> is that what you had in mind?
[20:36:10] <thetruthisoutthe> yes
[20:36:37] <thetruthisoutthe> i have a start address, i write the dataset's endpointer to there, the next byte is the start of data
[20:37:15] <jadew> then, no, if you're writting stuff one after the other, the start point implicitly becomes the end pointer
[20:37:55] <jadew> if (p + sizeof(obj) < LIMIT) write_stuff(p, &obj); p += sizeof(obj);
[20:38:43] <jadew> forgot some {}
[20:38:46] <jadew> but you get the point
[20:38:56] <thetruthisoutthe> do you like structs in avrs?
[20:39:11] <jadew> if they're necesary, sure
[20:39:17] <thetruthisoutthe> it has extra operations for getting pointers
[20:39:21] <thetruthisoutthe> ;/
[20:39:24] <jadew> not if they're static
[22:17:24] <thetruthisoutthe> jadew <= what if you pass them to a function?
[22:17:44] <thetruthisoutthe> you always resolve the addressed, at least until you cache them
[22:17:57] <thetruthisoutthe> addresses*
[22:18:33] <thetruthisoutthe> on a pc this does not ocunt, but the mcu is limited
[22:19:51] <Xark> thetruthisoutthe: I believe passing a pointer is the same cost, no matter what type of object it points to (PROGMEM excepted).
[22:20:12] <Xark> thetruthisoutthe: Also, on AVR it is as if all of memory is cache. :)
[22:20:12] <thetruthisoutthe> no
[22:20:29] <thetruthisoutthe> the PC tick at 2.2GHz+ and can parallel instructions, and is 64 bit
[22:20:47] <thetruthisoutthe> the MCU ticks at 0-20MHz and it is 8 bit, and pointers can be 16 bit
[22:20:52] <Xark> thetruthisoutthe: Yes, the PC is faster. What does that have to do with anything?
[22:20:55] <thetruthisoutthe> quite a difference
[22:21:31] <Xark> I understand, but when on AVR, passing a pointer is what it is (regardless of static, dynamic etc.).
[22:21:34] <thetruthisoutthe> hm, yeah reading progemm is not much slower than reading sram
[22:22:05] <Xark> One cycle IIRC.
[22:22:08] <Xark> (more)
[22:22:13] <thetruthisoutthe> but eeprom is slow :)
[22:22:31] <thetruthisoutthe> it is like 3ms/byte
[22:22:49] <Xark> I think only for writing. Reading is slow, but only a few cycles IIRC.
[22:23:51] <thetruthisoutthe> so one only use it for data storage and configuration written once from an sram buffer i think
[22:25:12] <Xark> thetruthisoutthe: Yeah. I had to have all the AVR cycle timing sussed out to get my video generation to work (very tight, 4 or 2 cycles per pixel - depending on mode). At one time I was considering using EEPROM for tile memory.
http://imgur.com/a/JO4Cq
[22:25:21] <thetruthisoutthe> amazing how much work can be put into 13kB firmware
[22:25:24] <thetruthisoutthe> ;/
[22:25:34] <thetruthisoutthe> and it is not even optimized
[22:26:51] <thetruthisoutthe> :)
[22:26:56] <thetruthisoutthe> what kind of display device
[22:26:57] <thetruthisoutthe> ?
[22:27:46] <thetruthisoutthe> i think my next project is porting my random function to my avr
[22:27:47] <Xark> thetruthisoutthe: Just two GPIO and two resistors. Here is a pic of the breadboard ->
http://imgur.com/a/YmlWf/noscript#0
[22:27:48] <thetruthisoutthe> :)
[22:27:56] <thetruthisoutthe> hehe
[22:28:03] <Xark> thetruthisoutthe: Same circuit as
https://code.google.com/p/arduino-tvout/
[22:28:05] <thetruthisoutthe> okey, waht kind of display device?
[22:28:09] <thetruthisoutthe> TV ?
[22:28:14] <Xark> thetruthisoutthe: Yes, composite.
[22:28:34] <thetruthisoutthe> yeah interesting
[22:29:00] <thetruthisoutthe> get an xmega, and hook it up to the DACs
[22:29:01] * Xark notes that board had audio output also (another resistor and capacitor) -> http://imgur.com/a/qPis6#0
[22:29:03] <thetruthisoutthe> ^^
[22:29:06] <thetruthisoutthe> :)
[22:29:28] * Xark is not impressed with Xmega DAC
[22:29:42] <thetruthisoutthe> not fast enough?
[22:30:05] <Xark> thetruthisoutthe: PWM (with a bit of filtering) seemed better quality for my audio app.
[22:30:12] <thetruthisoutthe> ;/
[22:30:37] <thetruthisoutthe> did you use a quality analog amplifier?
[22:30:50] <thetruthisoutthe> i assume it is not able to drive heavy loads
[22:31:05] <Xark> thetruthisoutthe: Same as PWM (using scope and line-in).
[22:31:31] <thetruthisoutthe> how can a DAC be worse than a PWM ?
[22:31:46] <Xark> That was with one of these
http://www.batsocks.co.uk/readme/XMegaExamples.htm
[22:32:22] <Xark> Take that with a grain of salt, I didn't mess with it too much.
[22:33:07] <thetruthisoutthe> CPU usage is between 30% (for DMA version) and 60% (without DMA).
[22:33:11] <thetruthisoutthe> looks nice
[22:33:19] <thetruthisoutthe> so, why does not DAC work out for you?
[22:33:44] <Xark> Yes, Xmega is neat with DMA (for video). With out DMA, uses ~90% CPU.
[22:33:53] <Xark> (on regular AVR)
[22:35:26] <thetruthisoutthe> this is your site?
[22:35:32] <Xark> No.
[22:35:51] <thetruthisoutthe> i like that POV thing :)
[22:36:25] <Xark> Yeah. Although I almost tossed my breadboard across the room trying it. :)
[22:36:32] <thetruthisoutthe> hahaha
[22:36:40] <thetruthisoutthe> don't breadboard it
[22:36:54] <thetruthisoutthe> a little stick panel
[22:37:17] <Xark> Yeah, well that little xmega board is made for a breadboard (or socket).
[22:37:45] <thetruthisoutthe> i will do this, but i don't use bitmap
[22:37:46] <thetruthisoutthe> ;/
[22:37:47] <Xark> I use the little 8-LED breakouts from that site all the time (got several). :)
[22:37:58] <thetruthisoutthe> i just put the biosfont in it, and render it
[22:38:23] <Xark> thetruthisoutthe: Well, that is just a tilemap of bitmaps.:)
[22:38:28] <thetruthisoutthe> yeah
[22:38:37] <thetruthisoutthe> but i have a font, and i can define any string then
[22:39:17] <Xark> thetruthisoutthe: That is what my video stuff is doing and why it was so tricky. AVR doesn't have enough memory for decent res bitmap (but it does have enough for 40x25 characters - with font in PROGMEM).:)
[22:39:31] <thetruthisoutthe> ofc
[22:39:46] <thetruthisoutthe> and progmem reading is not slow
[22:40:44] <Xark> Well, 4 cycles vs 3 IIRC. However, even this is a problem when you are going for 2 cycles per pixel (but I cheat and stretch the "black" pixels on the tile edges a bit).
[22:42:17] <Xark> (and I only need to read a byte every ~8 pixels)
[22:43:05] <Xark> thetruthisoutthe: In the end, it uses a ~4K inline routine to render a scanline (no cycles left for looping).
[22:50:23] <thetruthisoutthe> :)
[22:50:40] <thetruthisoutthe> you use internal 8MHz osc?
[22:51:11] <thetruthisoutthe> on an atmegaxx ?
[22:51:30] <thetruthisoutthe> you may prefer going to 16MHz, or 20MHz
[23:05:07] <thetruthisoutthe> Xark <= xmega works with 32MHz internal osc btw
[23:12:01] <thetruthisoutthe> what twisted fontset contains (8 x) 290 elements ? ;/
[23:13:00] <thetruthisoutthe> an ascii table contains 256 elements
[23:13:52] <jadew> Xark, that's pretty neat, what refresh rate were you getting out of it?
[23:17:08] <jadew> hmm, for 60 frames at 128x96 you would have had to put out only 737280 bytes/s that's doable
[23:18:38] <thetruthisoutthe> well tc is 25 fps
[23:18:40] <thetruthisoutthe> *TV
[23:18:47] <thetruthisoutthe> 50 half frames/s
[23:19:05] <jadew> didn't know that, 25 fps sounds a bit low tho
[23:19:21] <thetruthisoutthe> this is why they scan every second line
[23:19:24] <thetruthisoutthe> lold
[23:19:31] <thetruthisoutthe> i always hated the flickering tvs
[23:19:48] <thetruthisoutthe> don't even have one, why?
[23:19:55] <thetruthisoutthe> use a tft monitor instead
[23:20:11] <thetruthisoutthe> does XMEGA like DVI ?
[23:37:37] <thetruthisoutthe> in 1024x768 24 bit mode, the dvi-d link only requires 3 x 471859200 bit/s, so something more suited to fpgas i think ;<
[23:39:27] * Casper thinks thetruthisoutthe did an error
[23:39:36] <thetruthisoutthe> where?
[23:40:00] <Casper> my math ends at 3x 377487360
[23:40:06] <thetruthisoutthe> get number of pixels: 786432
[23:40:12] <thetruthisoutthe> multiply by 10
[23:40:22] <Casper> why 10?
[23:40:22] <thetruthisoutthe> and multiply by 60 fps
[23:40:38] <Casper> oh 10/8 encoding
[23:40:43] <thetruthisoutthe> because 10 bits are transmitted at R, G and B lines for each color, then pixel clock
[23:41:48] <jadew> sounds like a job for the tiny13
[23:42:10] <thetruthisoutthe> ^^
[23:42:12] <thetruthisoutthe> okey
[23:42:13] <jadew> altho
[23:42:23] <thetruthisoutthe> the lowest supported res is 640x480
[23:42:25] <jadew> I don't think you send the channels in a serial fashion, do you?
[23:42:32] <jadew> you're probably sending them in paralel
[23:42:36] <thetruthisoutthe> they are sent serial
[23:42:42] <thetruthisoutthe> http://en.wikipedia.org/wiki/Digital_Visual_Interface
[23:42:59] <thetruthisoutthe> you have 3 differential pairs R, G, B for sending color data
[23:43:02] <Casper> semi parallel
[23:43:02] <jadew> it says it's paralel
[23:43:05] <jadew> yeah
[23:43:17] <Casper> the data is sent individually per color serially
[23:43:25] <Casper> but each color in parallel
[23:43:33] <thetruthisoutthe> hm, yeah send them at the same time, in 10 bit serial encoded form
[23:43:57] <thetruthisoutthe> this is why i wrote "3x "
[23:43:58] <jadew> Casper, it's sent 2 bits at a time it seems
[23:44:11] <thetruthisoutthe> no
[23:44:17] <thetruthisoutthe> it is just differential
[23:44:17] <jadew> there are 2 data lines for each color
[23:44:17] <Casper> depending on the pixel clock rate
[23:44:25] <thetruthisoutthe> one line is inverse of the other
[23:44:28] <Casper> <=165MHz and you use one link
[23:44:36] <jadew> thetruthisoutthe, there are 2 pairs for each
[23:44:37] <Casper> >165MHz and you need to use the 2 links
[23:44:46] <thetruthisoutthe> jadew <= it is a twisted pair
[23:44:51] <thetruthisoutthe> D+ D-
[23:45:00] <jadew> thetruthisoutthe, check the wiki link
[23:45:06] <jadew> there are 2 x D+ D-
[23:45:07] <Casper> Dual-link DVI
[23:45:07] <Casper> To support display devices requiring higher video bandwidth, there is provision for a dual DVI link. A dual link doubles the number of TMDS pairs, effectively doubling video bandwidth at a given pixel clock frequency. The DVI specification mandates how the dual link may be used. All display modes that use a pixel clock below 165 MHz, and have at most 24 bits per pixel, are required to use single-link mode. All modes that require more than 24 bits pe
[23:45:07] <Casper> r pixel, or 165 MHz pixel clock frequency must use dual-link mode. In modes where each pixel uses 24 bits of color data per pixel or less and dual-link mode is in use, the transmitter stripes pixel data across both links; each sequential video pixel is transmitted on alternate links. In modes with color depth greater than 24 bits per pixel, the second link carries the least significant bits of each pixel.
[23:45:23] <thetruthisoutthe> don't use dual link now.
[23:45:35] <thetruthisoutthe> that is some extra
[23:46:00] <thetruthisoutthe> Single-link DVI < this requires less ports
[23:46:06] <theBear> half as many
[23:46:15] <thetruthisoutthe> but still, it needs an FPGA
[23:46:24] <thetruthisoutthe> yey theBear
[23:46:39] <theBear> yey thou art here is bear
[23:46:40] <jadew> morning sunshine
[23:46:47] <theBear> hello darling :)
[23:47:05] <thetruthisoutthe> hahaha
[23:47:06] <theBear> i think i just gonna treat you like a girl from now on, it's easier on my poor head
[23:47:08] <thetruthisoutthe> nah
[23:47:21] <theBear> not you truthguy, the one with the girl name
[23:47:42] <thetruthisoutthe> 640x480x24 bit mode requires 3x 184320000 bit/s, doable on a low end FPGA
[23:47:50] <jadew> that could turn awkward, I'd instantly fall inlove with a chick as smart as I am :P
[23:48:11] <theBear> yeah, but i learned long ago it's no use falling in love with faraway internet people
[23:48:29] <jadew> wanna cyber?
[23:49:20] <jadew> thetruthisoutthe, you could probably do it with an FPGA, but you'd also need some fast memory
[23:49:36] <jadew> it's deffinitely not something you'd wanna use in a hobby project
[23:49:36] <thetruthisoutthe> yes, a little sram for the screen buffer
[23:49:48] <theBear> nup, i'm into real sexing, no other kind
[23:50:14] <Casper> hmm
[23:50:32] <Casper> am I right to say that hdmi can not support more than 1080p due to it being single link?
[23:50:35] <thetruthisoutthe> hm, i think dvi should contain much more pins ;/
[23:51:19] <thetruthisoutthe> ofc that would require thicker cable, but lower quality cables
[23:51:37] <theBear> seems to work fine to me
[23:56:42] <jadew> what'
[23:56:47] <jadew> what's the frequency for hdmi?
[23:56:57] * Xark links to least expensive HDMI FPGA he is aware of ($120 with ARM+128MB+Spartan6LX9+HDMI in & out etc.) -> http://www.adafruit.com/products/609
[23:58:28] <Xark> jadew: This project uses 375Mhz DVI bit clock ->
http://hamsterworks.co.nz/mediawiki/index.php/Dualhead_MCB_Frame_Buffer
[23:58:57] <Xark> (along with 75Mhz pixel clock)
[23:59:02] <jadew> damn
[23:59:05] <theBear> i dunno, ask kenneth :)
[23:59:27] <Casper> kenneth...
[23:59:33] <jadew> I guess I'd need a better scope if I'd get into that hehe
[23:59:50] <Casper> that's the name of one of our supplier seller...
