#avr | Logs for 2012-04-19

Back
[00:43:50] <SuperMiguel> avrdude -p ATMEGA328P -P COM7 -c arduino -U flash:w:psgrade_duemilanove.hex
[00:43:53] <SuperMiguel> avrdude: stk500_getsync(): not in sync: resp=0x00
[00:43:55] <SuperMiguel> avrdude done. Thank you.
[00:43:58] <SuperMiguel> any idea why?
[04:09:17] <kline> hey guys. it says in ( http://www.atmel.com/tools/STK500.aspx?tab=devices ) that the 328P is supported, but i cant see it in the AVR Programming dialog. any idea what im doing wrong?
[09:50:10] <Duality> what is pin 13 in syntax for chip 328P?
[09:52:08] <Steffanx> PORTD, PD7
[09:52:12] <Kevin`> Duality: http://arduino.cc/en/uploads/Main/arduino-duemilanove-schematic.pdf
[09:52:42] <Kevin`> or did I misunderstand the basis for your question
[09:52:49] <Steffanx> Or i did
[09:53:18] <Kevin`> if you mean the pin at the ic level, it's all listed on the second page of the datasheet
[09:53:19] <Duality> well, i am used to upload files that are written in arduino and they just define pins with nummers like pin 13 is number(int) 13
[09:53:26] <Kevin`> you have that open on your monitor, right? :)
[09:53:54] <Kevin`> if you mean arduino, look at the document I linked (the numbers on the headers)
[09:54:08] <Kevin`> the numbers on the chip are actually the pin numbers, and apparently not what you want
[09:55:10] <Duality> no i have no arduino libs here what so ever, i am programming my arduino as a avr chip in eclipse :0
[09:55:12] <Duality> :)
[09:55:29] <Duality> used to arduino, and they hide alot of stuff,
[09:57:53] <Duality> the arduino libs make it so that if you define a pin, you just use a number like 13, but i don't know how to set a pin to output and write it high/low in avr :)
[10:01:11] <Kevin`> Duality: you should read the port/gpio section of the datasheet
[10:01:28] <Kevin`> (again, you have it open already on your screen, right?)
[10:01:28] <Duality> I think I have to start from scratch :) with avr...
[10:01:44] <Duality> what would happen if i said no?
[10:02:04] <Kevin`> nothing world-ending
[10:02:07] <Kevin`> just go download it an open it
[10:02:24] <Kevin`> you want the full one, not the summary, of course
[10:04:12] <Duality> got it
[10:05:51] <Duality> says pin i need to have is PD5
[10:06:37] <Duality> how would i make this and output ?
[10:06:54] <Duality> tutorial says something like DDRB |= 1<<PD5;
[10:07:03] <Duality> but does not work
[10:08:16] <Duality> how do i find out what i've got to change DDRB into?
[10:08:59] <Kevin`> what were you expecting to happen on PD5? just doing that would have it driven low (to 0v)
[10:09:01] <OndraSter> CapnKernel, CapnKernel ! CapnKernel !
[10:09:03] <OndraSter> you around?
[10:09:49] <Duality> Kevin`, needs to be output
[10:10:08] <Duality> PD5 needs to be output :)
[10:10:17] <OndraSter> then you need DDRD |= 1<<PD5
[10:10:30] <OndraSter> DDRB is Data Direction Register for PortB
[10:12:21] <Kevin`> Duality: and how are you observing that it is not an output
[10:13:19] <OndraSter> CapnKernel, I will be back later
[10:13:19] <OndraSter> bb
[10:15:14] <CapnKernel1> OndraSter: Hi there
[10:16:04] <Duality> it's not blinking the led?
[10:19:30] <Duality> yay!
[10:19:34] <Duality> got it working!
[10:20:51] <Duality> http://pastebin.com/j312uW8E
[10:23:57] <Kevin`> Duality: btw, for ports and similar things that have JUST the 8 bits in order as their fields, I like to just use numbers, eg DDRB|=(1<<5);
[12:18:01] <grummund> or _BV(5)
[12:18:41] <specing> or sbi (DDRB, 5);
[12:18:45] <specing> even better!
[12:25:29] <Steffanx> specing has macro's far all asm instructies
[12:25:37] <Steffanx> *macros
[12:25:58] <JyZyXEL> how do i get going with a attiny2313 and a FT232RL?
[12:26:41] <grummund> get going?
[12:26:45] <Steffanx> RX-TX TX-RX and done :)
[12:27:02] <Sgt_Lemming> lol
[12:27:05] <JyZyXEL> where do i get the example code how to get communication going both ways
[12:27:09] <Kevin`> gnd should also be connected, serial stuff is single ended
[12:27:43] <JyZyXEL> well the hardware is all in place, i just done have any firmware yet
[12:27:54] <grummund> google avr uart tutorial
[12:32:50] <specing> Steffanx: this one is actually in <sfrs.h>
[12:33:29] <JyZyXEL> i googled "avr-gcc attiny2313 ft232"
[12:33:59] <grummund> not ft232 specific
[12:34:03] <specing> JyZyXEL: OH GOD FUCKING DAMMIT, DO WE NEED TO WIPE TOO?!?!
[12:34:17] <specing> open datasheet and start coding
[12:34:40] <Kevin`> JyZyXEL: ft232 is irrelevant to this, as is the specific avr chip for the most part
[12:36:21] <JyZyXEL> ok well that is good to know
[12:50:35] <JyZyXEL> there is some talk about avr-libc containing a UART library
[12:51:39] <ziph> That'd suck.
[12:52:27] <ziph> It would kick off a long unending path towards Arduinoisation.
[12:52:30] <grummund> afaik it has some #define's for setting baud rate but that's it
[12:55:15] <JyZyXEL> google is finding me a lot of "why doesn't this code work" type of stuff
[12:56:14] <grummund> look for abcminiuser's uart tutorial (part 1) on avrfreaks.net
[12:58:00] <JyZyXEL> whats the difference between UART and USART?
[12:58:55] <grummund> lookup what they stand for and you can answer that one for us
[12:58:55] <Kevin`> JyZyXEL: usart has some secondary features. datasheet covers all of them in any case
[13:00:27] <JyZyXEL> well i found a tutorial about USART
[13:01:10] <grummund> hey, look what i found in the /topic of this channel...
[13:01:10] <grummund> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_usart_index.php
[13:02:06] <abcminiuser> I also have PDFs available
[13:02:17] <abcminiuser> fourwalledcubicle.com/AVRArticles.php
[15:05:14] <JyZyXEL> so if your using attiny2313 on its internal oscillator its set by the fuses?
[15:06:45] <vectory> JyZyXEL: you got cause and effect mixed up, but yes
[15:07:13] <JyZyXEL> does avrdude have some way of reading the fuses so that its actually understandable by a human?
[15:09:42] <Thetawaves> JyZyXEL, you can't use a hex calculator to come up with the proper fuse settings?
[15:09:44] <RikusW> JyZyXEL: only in hex, use the datasheet to understand that
[15:09:47] <Thetawaves> s/hex/fuse/
[15:10:58] <RikusW> JyZyXEL: are you using Linux ?
[15:11:03] <JyZyXEL> yeah
[15:11:31] <RikusW> JyZyXEL: http://sites.google.com/site/megau2s/home -> software -> RavrProg
[15:11:58] <RikusW> that will help you with fuses, and can program avrs too
[15:12:09] <RikusW> JyZyXEL: what programmer and avr do you have ?
[15:13:33] <JyZyXEL> t2313 and usbtiny
[15:14:59] <RikusW> my sw don't support that one... but you can still use it as a fuse calculator
[15:15:13] <Thetawaves> i love the usbtinyisp
[15:15:40] <izua> i love the usbtiny stack
[15:15:46] <RikusW> JyZyXEL: what fuses are you trying to change ?
[15:15:54] <Thetawaves> JyZyXEL, this will even give you the avrdude command arguments http://www.engbedded.com/fusecalc/
[15:16:03] <JyZyXEL> im trying to figure out how the clock fuses are set
[15:16:13] <Thetawaves> izua, usbtiny stack?
[15:16:20] <RikusW> do you want to use an external crystal ?
[15:16:28] <RikusW> and what frequency will that be ?
[15:16:36] <izua> the usb stack usbtinyisp is based on
[15:16:39] <Thetawaves> crystal or ceramic resonator?
[15:16:42] <JyZyXEL> apparently the t2313 can run either 1,4 or 8 MHz without an external crystal
[15:16:50] <izua> (the software client)
[15:16:58] <JyZyXEL> im not sure which one its set to
[15:17:21] <RikusW> what is the current lfuse value ?
[15:17:35] <RikusW> (then I can tell you ;) )
[15:18:03] <JyZyXEL> 0x64
[15:18:16] <RikusW> lfuse = 0xFF -> external crystal >= 8MHz CKDIV8 = off
[15:18:55] <RikusW> its currently running at 8 but CKDIV8 is on so effectively its at 1MHz
[15:19:09] <Thetawaves> izua, so usbtiny is good eh?
[15:19:15] <RikusW> do you use 5V ?
[15:19:20] <JyZyXEL> yeah
[15:19:40] <RikusW> setting lfuse = 0xFF will work
[15:19:44] <izua> it's a neat hack. i had some midi descriptors somewhere for it
[15:19:48] <RikusW> what crystal do you have ?
[15:19:53] <JyZyXEL> i have no clue which one is best for UART but i guess everything will work
[15:20:00] <JyZyXEL> it has no crystal at all
[15:20:10] <RikusW> 14.745 is good for uart
[15:20:30] <OndraSter> depends on what speeds do you want the UART to be running
[15:20:36] <RikusW> or 7.372
[15:20:44] <OndraSter> I am succesfuly running 1Mbaud with 16MHz xtal :)
[15:20:57] <RikusW> JyZyXEL: how fast do you want the baud to go ?
[15:21:05] <JyZyXEL> 2400 is enough
[15:21:12] <JyZyXEL> bauds per second i guess
[15:21:15] <OndraSter> you can go with internal RC oscillator as well
[15:21:25] <RikusW> internal 8MHz will work for that
[15:21:27] <OndraSter> for that speed
[15:21:36] <OndraSter> hell, even internal 1MHz would do that :P
[15:22:02] <RikusW> JyZyXEL: you'll want to change the prescaler in sw, or change lfuse = 0xE4 though
[15:22:46] <JyZyXEL> maybe i should go with a 9600 rate because its more common?
[15:23:03] <RikusW> internal RC osc will still work for that
[15:23:14] <RikusW> and 9600 is common
[15:23:43] <JyZyXEL> i wonder what the good fuse settings for that would be though
[15:24:06] <Thetawaves> i have tested 2400->5000000 baud with a 20mhz crystal
[15:24:08] <Thetawaves> works fine
[15:24:31] <RikusW> JyZyXEL: if you don't change lfuse = E4 do have a look at the CLKPR register
[15:24:49] <RikusW> you can change the clock prescaler in firmware too
[15:25:13] <RikusW> JyZyXEL: your 0x64 is ok if you change CLKPR
[15:25:50] <JyZyXEL> what kinda value would 0xe4 give me?
[15:26:05] <RikusW> if will turn of the clock prescaler
[15:26:12] <RikusW> you can do that in FW too
[15:26:17] <nickoe> How fast can I count with a timer/counter in i.e. a ATmega328?
[15:26:20] <JyZyXEL> well ill try doing it with a fuse
[15:26:23] <RikusW> see the CLKPR docs
[15:26:36] <RikusW> its only 2 or 3 lines of code
[15:26:46] <JyZyXEL> well docs don't have such thing
[15:26:48] <RikusW> nickoe: at full clock speed
[15:26:51] <JyZyXEL> at least for low fuses
[15:27:09] <RikusW> JyZyXEL: search the whole pdf
[15:27:12] <nickoe> If I cant the counter to count an external freq?
[15:27:33] <JyZyXEL> ill rather set the 0xe3 to spare lines of code
[15:27:41] <nickoe> ie. I clcok the MCU with 1 MHz, can't I then count frequencies higher that that?
[15:27:45] <RikusW> JyZyXEL: 0xE4
[15:28:16] <RikusW> E3 will require external clock, bricking the avr :-P
[15:28:59] <RikusW> nickoe: you should be able to supply a external timer clock higher that avr clock I think, not sure
[15:29:19] <RikusW> nickoe: don't know if the timer clock input pin is filtered or not
[15:29:29] <nickoe> hmm :/
[15:29:44] <nickoe> I can't seem to find any info about it in the datasheet either
[15:30:18] <JyZyXEL> echo -ne "\xe4" > low
[15:30:33] <JyZyXEL> -U lfuse:w:low:r
[15:30:43] <JyZyXEL> would those be correct
[15:30:52] <RikusW> -U lfuse:w:0xE4:r
[15:31:22] <RikusW> JyZyXEL: or you can use avrdude -t for terminal mode
[15:31:39] <RikusW> I find setting fuses in terminal mode to be easier
[15:31:51] <JyZyXEL> avrdude: write to file '0xE4' failed
[15:32:14] <JyZyXEL> ill try the one i came up with
[15:32:25] <RikusW> try terminal mode, its easier
[15:33:09] <JyZyXEL> mine worked
[15:33:14] <RikusW> -U lfuse:w:0xE4:m
[15:33:41] <JyZyXEL> its e4 now
[15:33:53] <RikusW> -U lfuse:w:E4:h
[15:34:12] <RikusW> so you now have a 8MHz t2313
[15:34:34] <JyZyXEL> now all i need is to upload some UART code
[15:35:01] <RikusW> have a look in the uart chapter for UBRR settings
[15:35:15] <JyZyXEL> im looking at this: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=45341&start=0
[15:35:29] <JyZyXEL> hopefully their full code examples that i can just copy&paste and compile :D
[15:36:04] <JyZyXEL> i have no clue what all these upper case variables and bitwise operations are doing
[15:36:36] <RikusW> nickoe: An external clock source applied to the T1/T0 pin can be used as Timer/Counter clock (clkT1/clkT0). The T1/T0 pin is sampled once every system clock cycle by the pin synchronization logic.
[15:37:15] <RikusW> nickoe: so external timer clock can't be higher than avr clock...
[15:37:39] <RikusW> Found it in: 16.3 External Clock Source
[15:39:18] <RikusW> JyZyXEL: here http://tom-itx.dyndns.org:81/~webpage/ is a bitwise operator tutorial afaik
[15:39:29] <nickoe> hmm, yeah, I was just reading taht after a search on your first comment
[15:39:47] <JyZyXEL> i think these code examples are missing some #defines
[15:39:54] <RikusW> JyZyXEL: the uppercase variables is memory mapped registers controlling the peripherals
[15:39:57] <JyZyXEL> warning: #warning "device type not defined"
[15:40:00] <nickoe> Each half period of the external clock applied must be longer than one system clock cycle to
[15:40:00] <nickoe> ensure correct sampling. The external clock must be guaranteed to have less than half the sys-
[15:40:00] <nickoe> tem clock frequency
[15:40:07] <JyZyXEL> i wonder what all else their missing
[15:41:18] <RikusW> nickoe: and that is for 50% duty cycle
[15:41:27] <JyZyXEL> or maybe my gcc line needs some work
[15:41:28] <nickoe> yes
[15:41:34] <JyZyXEL> i just used: avr-gcc main.c
[15:42:08] <RikusW> JyZyXEL: you need to specify the avr type somehow, not sure how I use AS4 ;)
[15:42:22] <RikusW> but I'm mostly using linux so I have to reboot :S
[15:43:14] <JyZyXEL> avr-gcc -mmcu=attiny2313 main.c
[15:43:34] <JyZyXEL> im missing URSEL and F_CPU
[15:44:36] <JyZyXEL> im guessing i can just #define F_CPU 8000000
[15:44:46] <RikusW> JyZyXEL: look at -p too
[15:45:08] <RikusW> err thats for avrdude...
[15:45:27] <JyZyXEL> i think this example UART code wasn't for 2313
[15:45:44] <RikusW> JyZyXEL: you'll need to include the t2313 header too
[15:45:58] <RikusW> err #include <avr/io.h>
[15:46:05] <JyZyXEL> oh yeah i did that
[15:46:17] <JyZyXEL> that was in the example
[15:47:18] <JyZyXEL> ill need to find some t2313 spesific UART code
[15:48:01] <RikusW> uarts is mostly the same for all avr's
[15:49:00] <JyZyXEL> i don't understand why none of the projects im finding define F_CPU
[15:49:34] <RikusW> at 8MHz UBRR = 51 to get 9600 baud
[15:49:45] <RikusW> provided U2X = 0
[15:50:05] <RikusW> and you get 0.2% error rate which is quite goot
[15:50:07] <RikusW> *good
[15:50:35] <JyZyXEL> ok so void UARTinit(void){ UBRR = 51; UCR = (1<<TXEN)|(1<<RXEN); }
[15:50:49] <nottwo> JyZyXEL: each project will have its own F_CPU. typically you define it in your project's Makefile
[15:51:21] <JyZyXEL> oh i saw an example makefile on the avr-gcc page
[15:51:54] <RikusW> JyZyXEL: not UCR use UCSRB
[15:52:17] <JyZyXEL> oh, i found a project using UCR
[15:52:54] <JyZyXEL> its the problem with this random code found by google, you never know if its any good
[15:53:06] <RikusW> probably some old avr
[15:53:38] <RikusW> doing an app to echo everything should be less than 50 lines
[15:53:52] <JyZyXEL> yeah that would be the goal for now
[15:53:58] <JyZyXEL> just replying everything back thats received
[15:54:01] <nottwo> JyZyXEL: you'll always have to consult the datasheet to make sure the model-specific register names are used
[15:54:23] <JyZyXEL> there is an USART_init(baud) in the documentation for 2313
[15:54:36] <JyZyXEL> probably a good start to copypaste that
[15:54:39] <OndraSter> capn
[15:54:41] <OndraSter> hmm he is gone again
[15:54:57] <OndraSter> !seen CapnKernel
[15:54:58] <tobbor> CapnKernel was last seen in #avr on Apr 19 08:07 2012
[15:55:00] <JyZyXEL> the code on the docs should be at least correct
[15:55:03] <OndraSter> !last capnkernel
[15:55:23] <Steffanx> /msg nickserv info capnkernel
[15:55:59] <OndraSter> I am more interested in his last word he spoke here :)
[15:56:05] <OndraSter> and when that was
[15:56:38] <Steffanx> oh :P
[15:57:15] <RikusW> JyZyXEL: while(1) { while(!(UCSRA & (1<<RXC)); while(!(UCSRA & (1<<UDRE)); UDR = UDR + 1; } // UDR + 1 just to modify the char
[15:57:47] <JyZyXEL> i found USART_Tx and USART_Rx from the docs
[15:59:12] <JyZyXEL> ok ill USART_Init(9600); and try that code
[15:59:40] <RikusW> if you have a simulator check that UBRR is set to 51
[16:00:27] <JyZyXEL> you forgot some )'s
[16:01:12] <Thetawaves> that is not how you write good usart code
[16:01:35] <Thetawaves> it took me a long time to prove my buffered usart
[16:02:21] <RikusW> I've don't some ring buffered usart code too ;)
[16:03:06] <RikusW> *done
[16:03:39] <Thetawaves> yeah thats what i've got
[16:04:28] <Thetawaves> there is only a very specific scenario where i've actually used the circular capacity
[16:04:42] <Thetawaves> as soon as you run out, you start overwriting data
[16:05:13] <Thetawaves> so thats no good... but what about a queue style setup.. well that never happens
[16:05:35] <Thetawaves> you always end up resetting the buffer after a message has been processed
[16:06:08] <grummund> that assumes only ever one message is queued at a time
[16:06:27] <grummund> if not, then that's where a circular buffer comes in...
[16:07:32] <Thetawaves> thats interesting
[16:11:46] <JyZyXEL> ok well my first program didn't produce any output
[16:12:21] <JyZyXEL> http://pastebin.com/FyHqTenY
[16:12:43] <JyZyXEL> did make and avrdude -c usbtiny -p t2313 -U flash:w:main.hex and cu -l /dev/ttyUSB3 -s 9600
[16:14:02] <JyZyXEL> maybe i just: while(1) { USART_Transmit(USART_Receive()); }
[16:15:12] <grummund> you haven't read the tutorial you were pointed at, have you?
[16:15:33] <JyZyXEL> i've gone thru all kinds of stuff
[16:16:36] <grummund> let's put it another way... have you read the tutorial you were pointed at?
[16:17:07] <JyZyXEL> i did but the code in it didn't work
[16:17:23] <JyZyXEL> it was setting something that attiny2313 didn't have
[16:17:38] <grummund> what did it say about setting UBRR ?
[16:17:56] <RikusW> did you remember (1<<RXEN)|(1<<TXEN) ?
[16:18:18] <JyZyXEL> yeah
[16:18:22] <RikusW> and UBRR = 51; should work too
[16:18:40] <JyZyXEL> oh yeah!
[16:19:39] <JyZyXEL> hmm t2313 doesn't have a UBRR
[16:20:16] <OndraSter> it must have UBRR, most likely split into two bytes
[16:20:21] <RikusW> UBRRH = 0; UBRRL = 51;
[16:20:22] <OndraSter> UBRRL and UBRRH
[16:20:35] <RikusW> you must write H _before_ L
[16:21:13] <JyZyXEL> oh wait the Init from documentation already does that
[16:21:20] <JyZyXEL> UBRRH = (unsigned char)(baud>>8); UBRRL = (unsigned char)baud;
[16:21:25] <grummund> sigh
[16:21:45] <JyZyXEL> it doesn't take into consideration the F_CPU though
[16:21:51] <OndraSter> sure it does not
[16:22:01] <JyZyXEL> ill try with 0 and 51
[16:22:02] <OndraSter> you are directly writing the register
[16:22:43] <JyZyXEL> ok, now were getting something!
[16:22:58] <OndraSter> waaait, why are you writing the baud value into UBRR?!
[16:23:17] <JyZyXEL> no idea, thats what the doc said haha
[16:23:23] <OndraSter> no
[16:23:38] <OndraSter> there is some math around UBRR value
[16:23:39] <grummund> i'll bet it did not say that
[16:23:53] <JyZyXEL> i copy&pasted it
[16:24:03] <essobi> COPYPASTA!
[16:24:04] <OndraSter> you have to count the UBRR value, depends on fcpu and speed
[16:24:07] <essobi> I love pasta.
[16:24:07] <grummund> yes, without thinking.
[16:24:28] <RikusW> JyZyXEL: I like to add 1 to the returned char to make sure the rx and tx wires didn't short and give a HW loop :-P
[16:24:34] <essobi> Man.. I wish I could find my dev board and programmer. :(
[16:24:44] <JyZyXEL> RikusW: yes next thing i was gonna do
[16:24:54] <JyZyXEL> make sure its actually my code thats doing the echoing
[16:25:02] <OndraSter> oh noes, shorts! :P
[16:25:07] <essobi> hehe
[16:25:16] <OndraSter> I prefer skirts on ladies over shorts :P
[16:25:21] <OndraSter> aanyway
[16:25:57] <essobi> I scored an older working BetaBrite screen I need to hack up... I need to find my 328p and RS-485 stuff since I moved, but can't seem to find it anywhere yet. :(
[16:28:58] <essobi> ugh..
[16:29:05] <essobi> Is there a channel where the arm folks hang at?
[16:29:17] <OndraSter> #arm? :)
[16:29:57] <RikusW> /msg alis list *arm* -min 10
[16:33:33] <grummund> essobi: depends which arm and what you want to do
[16:35:20] <essobi> grummund: I'm pissing around with netbsd on my 920T atm...
[16:35:36] <essobi> Wondering if there's any other folk out there doing weird shit with ARMs.
[16:35:59] <grummund> there is ##stm32, #beagle, #edev, ##arm, #emdebian ...
[16:36:14] <essobi> Roger that.
[16:36:31] <OndraSter> I am PRETTY sure there are other folks out there doing weird shit with ARMs :P
[16:36:53] <essobi> OndraSter: Thank you captain obvious.
[16:37:02] <OndraSter> ;D
[16:37:46] <essobi> grummund: emdebian on @freenode?
[16:38:34] <grummund> @oftc
[16:38:45] <grummund> and #debian-arm
[16:39:07] <grummund> geez how many channels am i idle in :P
[16:42:24] <essobi> ALL TEH CHANNELS!11!ONE!1!!ELEVEN!!!!!
[17:11:13] <RikusW> RS part no for the dragon 719-3944
[17:11:30] <RikusW> ooops 696-2566
[18:57:24] <sh0ckkk> somebody wanna do me a huge favour? u can make 1$ out of it. setup a buy it now listing on ebay (which is accessible from ebay uk) and label it "ebook: how to tell people who stalk you online and dont even mention it to you to go and die"
[19:45:18] <JyZyXEL> what should i search for if i wanna know what commands to use when i wanna define portB 0-7 as outputs and set them all low?
[19:46:38] <Casper> DDRB and PORTB
[19:46:49] <Casper> as specified in the first few pages of the datasheet
[19:51:31] <JyZyXEL> so i want DDRB = 1 and PORTB = 0 to make it Output thats Low
[19:52:46] <Casper> not quite
[19:52:59] <Casper> read the section in the datasheet for any of the port, it's the same way for all
[19:53:15] <JyZyXEL> im reading the exact same one
[19:53:44] <JyZyXEL> or actually i don't know its very general
[19:53:48] <JyZyXEL> I/O ports
[19:53:49] <Casper> the port have up to 8 pins
[19:53:53] <Casper> so 8 bits
[19:53:59] <Casper> each individually controlled
[19:54:18] <JyZyXEL> oh i see its a bytes worth of data
[19:54:18] <Casper> DDR, Data Direction Register... in or out...
[19:54:43] <JyZyXEL> both DDRxn and PORTxn are bytes?
[19:54:50] <Casper> PORT, output data, when in input mode this control a pullup resistor (a resistor from VCC to the pin)
[19:54:55] <CapnKernel> They are byte-sized registers
[19:55:05] <Casper> PIN is input data
[19:55:25] <Casper> ALL registers (except X Y Z) are 8 bits
[19:56:04] <Casper> this is why you need to get familliar with bitwise operations
[19:56:22] <Casper> not hard, but can be scarry for newscommers...
[19:56:42] <JyZyXEL> so since i want same thing for all ports i could do: DDRB = 0b11111111; PORTB = 0; ?
[19:57:20] <JyZyXEL> i mean according to this Port Pin Configuration table it would mean Output and Low
[19:57:20] <Casper> ... which is why the arduino junk came up...
[19:57:21] <Casper> make it less scary... but in the end everything is harder
[19:57:56] <Casper> if you want to set all of the pin of port b low, yes
[19:58:01] <JyZyXEL> or maybe DDRB = 255; is more neat?
[19:58:10] <Casper> 0xFF is neater
[19:58:15] <JyZyXEL> oh yes
[19:58:52] <Casper> hex have some big advantage over decimal, it's not as messy as binary, yet easier to see since you can mentally split it in 2 4 bits
[19:59:06] <Tom_itx> octal ftw!
[20:05:22] <JyZyXEL> now to make Port B, pin 1 high i somehow use PB1 and PORTB?
[20:06:01] <awozniak> DDRB = ~0; // neater, but more cryptic
[20:06:02] <JyZyXEL> to achieve same as PORTB = 1; i guess
[20:06:13] <Tom_itx> JyZyXEL, read this: http://tom-itx.dyndns.org:81/~webpage/avr/c_bits/bits_index.php
[20:07:18] <JyZyXEL> awozniak: how come Not 0 equals to 255?
[20:08:07] <awozniak> http://en.wikipedia.org/wiki/Bitwise_operation#NOT
[20:08:56] <awozniak> I don't recommend doing it that way, Iwas just trying to be funny.
[20:09:26] <awozniak> Also, don't confuse ~ with ! (the first is bitwise, the second is logical)
[20:09:58] <JyZyXEL> well according to my trusty scientific calculator Not 0 equals 0
[20:10:14] <awozniak> I wouldn't trust that at all then.
[20:10:33] <JyZyXEL> 0 Not equaled -1
[20:10:44] <awozniak> same thing.
[20:11:04] <awozniak> see http://en.wikipedia.org/wiki/Two's_complement
[20:11:08] <JyZyXEL> i don't see how it could ever become 255
[20:13:57] <awozniak> Also, 255+1 = 0 for 8 bit numbers. just like -1 + 1 = 0
[20:14:19] <JyZyXEL> well yeah but a calculator is not limited in 8 bit numbers
[20:14:35] <awozniak> the bits are the same, it's just how you interpret them (signed two's complement vs unsigned) that's different.
[20:16:32] <Casper> PORTB |= (1<<whateverpinyouwanttosethigh);
[20:16:59] <Casper> PORTB &= ~(1<<whateverpinyouwanttosetlow);
[20:17:07] <Casper> remember that pin start at 0, and not 1
[20:17:49] <JyZyXEL> was that turning a pin high and low?
[20:18:14] <awozniak> first example was high, second was low.
[20:18:14] <Casper> high = 1, low = 0
[20:18:29] <Casper> also, take note that...
[20:18:50] <Casper> outputting 1 on an input pin will read high with a multimeter
[20:19:07] <Casper> as I said, when in input mode, you control on/off a pullup resistor
[20:19:18] <awozniak> Casper: that's device dependent.
[20:19:24] <Casper> it's a 20-60kohms
[20:19:34] <Casper> awozniak: good luck to find a device with no pullup
[20:19:37] <JyZyXEL> well im guessing it should be left on if you have a button connected to that input?
[20:19:55] <awozniak> Casper: not all devices have pullups. Some have configurable pullups and pulldowns.
[20:20:09] <Casper> JyZyXEL: maybe, or not. the resistor inside is so weak that the use of an external one is recommanded
[20:20:33] <Casper> awozniak: in attiny/atmega/at90?
[20:20:35] <JyZyXEL> well im not quite there yet
[20:21:16] <awozniak> xmegas have pullups and pulldowns, and you can disable both and get Hi-Z
[20:21:18] <Casper> JyZyXEL: btw, never ever leave an input pin unconnected (floating), turn on the pullup or set it to output
[20:21:34] <Casper> awozniak: those are another class, here it's for the tiny/mega/at90
[20:21:59] <awozniak> I'm pretty sure you can disable the pullups on the mega too. I'm looking
[20:22:23] <Casper> awozniak: . . . not reading what I said don't you
[20:23:05] <JyZyXEL> so |= means you wanna turn a certain bit on and &= means you wanna turn a certain bit off
[20:23:22] <awozniak> don't forget the ~ for the &=
[20:23:39] <JyZyXEL> oh
[20:23:41] <awozniak> might be a good idea to work through an example on paper so you understand it
[20:23:42] <JyZyXEL> i didn't even notice it
[20:24:17] <JyZyXEL> and there also the left bitshift with 1 and the pin
[20:24:25] <JyZyXEL> why does it have to be so horribly complicated
[20:24:56] <awozniak> Casper: mega64 can disable pullups. Also, JyZyXEL didn't mention a specific device.
[20:25:38] <Casper> awozniak: again, you didn't read what I said at all about writting to port while in input...
[20:25:50] <Casper> JyZyXEL: actually those are some bitwise operations
[20:26:09] <Casper> foo |= bar is a short hand for foo = foo | bar
[20:26:17] <Casper> | = OR
[20:26:20] <awozniak> Casper: it is device dependent. Best not to get into the habit of thinking that is always true.
[20:26:28] <awozniak> because it is not.
[20:26:46] <JyZyXEL> one thing that would help is to know the base10 values of PB0-7
[20:26:46] <Casper> awozniak: true for basically all tiny/mega/at90
[20:27:10] <Casper> JyZyXEL: so | is or, & is and, ~ is invert
[20:27:17] <awozniak> 1,2,4,8,16,32,64,128
[20:27:19] <Casper> << is bit shift
[20:27:26] <JyZyXEL> yeah i figured
[20:27:29] <awozniak> most people don't think that way though
[20:27:50] <Tom_itx> JyZyXEL, you didn't read that page did you
[20:27:52] <Casper> but knowing the values isn't of great help when you do like foo = 86
[20:28:48] <JyZyXEL> it was too complicated
[20:29:10] <Tom_itx> was not
[20:29:17] <Tom_itx> it was very explanatory
[20:30:10] <JyZyXEL> i don't see how i can memorize the operation truth tables for all bitwise operations
[20:30:27] <Casper> you don't need to memorise everything
[20:30:34] <Tom_itx> not so much that as the operators
[20:31:11] <Casper> remember the operators and what they do, then you can calculate it when needed or refert to it when needed
[20:31:21] <Casper> the important when you start isn't to remember all
[20:31:27] <Casper> but to know that it exists
[20:32:11] <Casper> this is why I suggest that you read the datasheet, read the first few paragraph of each section to know what each thing do, stop when you understand or it start to get too technical
[20:32:21] <Casper> or when it repeat itself
[20:32:42] <Casper> for example, read about porta, but skip portb portc and portd as they are the same
[20:34:31] <Casper> the main bitwise operations are AND (&), OR (|), NOT (~) and bitshifting (main one: << or for the reverse: >>)
[20:34:58] <awozniak> XOR (^) is fun too
[20:35:15] <Casper> yes, but more advanced and less commonly used
[20:36:06] <JyZyXEL> maybe there is a video tutorial explaining these
[20:36:38] <Casper> explaining what?
[20:36:45] <JyZyXEL> bitwise operations
[20:36:45] <Casper> good luck
[20:36:53] <Casper> you seems to refuse to want to read
[20:37:01] <Casper> you will fail
[20:37:04] <JyZyXEL> im dyslexic
[20:37:05] <Casper> bath time, bbl
[20:37:19] <JyZyXEL> wouldn't be anything new failing
[20:37:55] <JyZyXEL> i don't seem to have the ability to learn anything complicated by reading
[20:38:09] <awozniak> But IRC works?
[20:38:38] <JyZyXEL> its better
[20:39:00] <awozniak> Does bitwise not (~) make sense to you?
[20:42:03] <JyZyXEL> well apparently it makes a 0 into a 1 and a 1 into a 0
[20:42:14] <awozniak> excellent, you've got it exactly.
[20:42:30] <awozniak> one down, 5 left to go.
[20:42:53] <JyZyXEL> you can only use it for binary?
[20:43:27] <awozniak> so remember that everything in a computer, and everything in a microcontroller, is represented in binary.
[20:44:01] <awozniak> it's all about how the numbers get interpreted.
[20:44:28] <JyZyXEL> i just don't understand how it can have two operands
[20:44:48] <JyZyXEL> i mean if it just toggles a value wouldn't a single operand suffice
[20:44:54] <JyZyXEL> the value you wanna toggle
[20:44:59] <awozniak> Bitwise not is a unary operator. It only takes one argument.
[20:45:32] <awozniak> It is the only unary bitwise operator
[20:45:44] <JyZyXEL> oh, maybe thats why i couldn't find a truth table for it haha
[20:45:58] <awozniak> usually it's so simple no one bothers writing it as a truth table.
[20:46:22] <JyZyXEL> well this solves making a toggle function for a boolean variable with if(true) and if(false)
[20:46:24] <awozniak> 0 becomes 1, and 1 becomes 0. The truth table would have two lines. It would have one input and one output
[20:46:52] <JyZyXEL> can simply booleanVariable = ~booleanVariable;
[20:47:15] <awozniak> yep, that'll toggle all the bits, then assign back to the original variable
[20:47:20] <awozniak> be careful though.
[20:47:33] <awozniak> ~0x01 is 0xFE
[20:47:52] <awozniak> both of which evaluate to true in a conditional expression.
[20:48:51] <awozniak> for example, you don't want to use "if (~ 0x01) { }". You probably want "if (! 0x01) { } "
[20:49:39] <JyZyXEL> why would you do that?
[20:49:39] <awozniak> the first is bitwise. The second is logical.
[20:50:03] <awozniak> In C, any nonzero value is "true" in a conditional
[20:50:17] <JyZyXEL> but a conditional with a static value?
[20:50:19] <awozniak> ~0x01 evaluates as 0xFE, both of which are "true"
[20:50:37] <awozniak> That was an example. Imagine you had a variable there with that value
[20:52:35] <JyZyXEL> so basically making sure the variable is not zero?
[20:53:37] <awozniak> Other way around. Let's say you wanted to do something if a variable was zero. How would you write your if statement?
[20:54:06] <JyZyXEL> if (variable == 0)
[20:54:17] <awozniak> that's the best and most readable way to do it.
[20:54:24] <awozniak> Can you think of a different way to do it?
[20:54:52] <JyZyXEL> well i guess if (!variable)
[20:55:32] <awozniak> That's also good, and also commonly seen in code.
[20:55:50] <awozniak> if (~variable) // this is wrong, however.
[20:55:53] <JyZyXEL> but i would only use that for a boolean variable
[20:56:04] <JyZyXEL> i would never use that one :D
[20:56:25] <awozniak> I wanted to make sure we pointed out the difference between ~ and !
[20:56:59] <JyZyXEL> well i figured ~ was a tool to toggle a binary value
[20:58:40] <JyZyXEL> true becomes false, false becomes true, 0b0011 becomes 0b1100, 0x00 becomes 0xff
[20:59:23] <Tom_itx> ^
[20:59:37] <Tom_itx> xor
[20:59:43] <awozniak> xor is fun
[21:00:07] <specing> clr is xor rx, rx
[21:00:09] <JyZyXEL> i thought that was not :D
[21:00:26] <Tom_itx> PORTB ^= 0xFF ;
[21:00:38] <Tom_itx> will toggle
[21:00:47] <awozniak> PORTB ^= 0xFF is the same as PORTB = ~PORTB
[21:01:06] <Tom_itx> is the asm the same?
[21:01:33] <awozniak> That 0xFF operand tells us which bits to flip; in this case all of them. I think the asm would look different, but a compiler may optimize them as the same thing.
[21:04:52] <inflex> lo folks
[21:16:56] <inflex> bloody lava!
[21:17:00] <inflex> oops, wrong ch
[21:41:41] <Martyn> Okay, the sam3u has redeemed itself :)
[21:42:00] <Martyn> With the new interrupt work-around, all timers and all outputs and inputs are working as expected
[21:42:29] <Martyn> I can see why it's taking so long for the Due to make it out though .. the sam3u has .. quirks