Back
[00:26:31] <phryk> I've been trying to figure out how to properly use the UART. It kinda-sorta works, but it only seems to be sending garbage. What are the things I should double-check for first?
[00:29:34] <Hexum064_2> kinda working on the same thing.
[00:29:53] <Hexum064_2> But first, check the parity frame and stop bits and the baud
[00:30:22] <phryk> meh
[00:31:10] <phryk> i just noticed UCSZn1 and UCSZn0 are in UCSRnC, I used UCSRnB…
[00:32:09] <phryk> Hexum064_2:
http://www.appelsiini.net/2011/simple-usart-with-avr-libc Haven't tried much with this yet, but binding the uart to stdin and stdout seemed like a nice thing.
[00:32:34] <phryk> Though, I gotta say I don't know jack shit about C and other low level stuff :P
[00:33:07] <phryk> be aware that you have to include stdio.h for this to work, though.
[00:33:26] <phryk> I'm always wondering why all those examples are only half working and totally shit. Then I remember I'm doing C :F
[00:33:29] <Hexum064_2> well, it depends how you are implementing it.
[00:33:54] <Hexum064_2> If you are just sending data, it's just USART.DATA (for the xmega anyways)
[00:34:13] <Hexum064_2> what chip are you using?
[00:34:15] <phryk> having some weird atmega board and need to go both ways
[00:34:25] <phryk> atmega 2560 on some "seeeduino" board
[00:34:47] <phryk> i basically want a usb api to control my awesomely bright rgb leds :P
[00:34:47] <Hexum064_2> are you programming it using the arduino studio?
[00:34:56] <phryk> fuuuuuuuuuuuck no :P
[00:35:06] <Hexum064_2> we that I have been doing
[00:35:09] <Hexum064_2> well*
[00:35:15] <phryk> I mean, I might be bitching about C, but processing feels even worse :P
[00:37:46] <phryk> anyways, since basic operation seems to work (except when it just doesn't send anything \o/), I'm going for a smoke break. have been at this thing all night^^
[00:50:25] <phryk> can somebody explain in simple language what the parity bit is for?
[00:50:43] <Hexum064_2> I will try
[00:51:11] <phryk> I'm having the problem that often but not always communication with the uart will fail. Can I fix this with using a parity bit?
[00:51:33] <phryk> cu will connect, but my uart won't send. the rx led seems to blink, tho.
[00:51:43] <Hexum064_2> basically, if the number of bits that are set is even, the parity bit is set
[00:52:25] <phryk> but what is it for? just a simple check for data integrity?
[00:52:32] <Hexum064_2> yep
[00:52:38] <Hexum064_2> parity is only for error correction. It kinda sounds like you have a baud rate problem
[00:52:45] <phryk> Okay, so it won't help me fix my problem, right?
[00:52:50] <phryk> Righty^^
[00:53:35] <Hexum064_2> most likely not
[00:54:34] <Hexum064_2> My issue is interesting. I can set out just fine but my comp will not recognize the connection. Thank God for this little logic analyser.
[00:55:44] <phryk> Hexum064_2: diagnosed a software problem with a multimeter earlier :P
[00:56:09] <Hexum064_2> nice
[00:56:21] <phryk> got (seemingly) all 12 16-bit pwm channels of this thing running. now I'm going for the usb api :)
[00:56:59] <phryk> Hexum064_2: you wouldn't happen to be at the cccamp next month, would you?
[00:57:23] <Hexum064_2> nope. Japan, then burning man
[00:58:07] <phryk> ooh, burning man. you making things for there?
[00:58:29] <Hexum064_2> yep
[00:59:23] <phryk> nice, what will it be? .3
[00:59:27] <phryk> :3
[00:59:44] * phryk actually has two eyes.
[01:07:01] <Hexum064_2> A large RGB led screen
[01:07:28] <phryk> Oooh, I'm just having 4 insanely bright pixels :P
[01:08:04] <Hexum064_2> I know of which you speek
[01:08:47] <phryk> huh?
[01:09:09] <phryk> insanely bright pixels? ^_^
[01:16:08] <phryk> Hexum064_2: avr config registers have random values at start up?
[01:16:54] <phryk> if so: just how random is it? could it potentially be a real random seed for an prng?
[01:21:13] <phryk> ooh, i think i actually fixed my problem :)
[05:45:28] <zulusbg> hello
[05:45:56] <zulusbg> im trying to make small program that will save data to EEPROM
[05:46:29] <zulusbg> what im faceing is after restart i overwrite existing values
[06:02:27] <zulusbg> got answer
[06:02:28] <zulusbg> thanks
[06:53:03] <Lambda_Aurigae> no clue what your question is.
[09:30:10] <abetusk> sorry for the beginner question, but on an attiny13, while interrupts are disabled (cli), if a timer interrupt fires, does the ISR get called after interrupts are enabled again (sei)? Or is the interrupt fire ignored?
[09:30:42] <Lambda_Aurigae> if they are disabled then they are disabled...
[09:30:54] <Lambda_Aurigae> it doesn't stack things that happen while they are disabled.
[09:31:09] <Lambda_Aurigae> otherwise it would go haywire soon as you turn on interrupts.
[09:31:49] <abetusk> ok, thanks
[09:34:26] <abetusk> I thought there was a 'sticky bit' sometimes that would get cleared when the interrupt finally did fire
[09:35:04] <LeoNerd> Huh?
[09:35:11] <LeoNerd> That's the entire point of the IE flag - it *does* remain pending
[09:35:28] <LeoNerd> The *global* interrupt disable (CLI, SEI) prevent it firing right now; it remains pending
[09:35:42] <Lambda_Aurigae> oh?
[09:35:44] <LeoNerd> That's different from the individual per-unit enable flags, that entirely stop it *generating* the interrupt in the first place
[09:35:53] <Lambda_Aurigae> aahh.
[09:35:54] <Lambda_Aurigae> yeah.
[09:36:06] <LeoNerd> The very idea behind the global interrupt flag is that you can turn it off for short durations to do atomic things, and when you enable it again you'll catch up a missed oe
[09:36:07] <LeoNerd> one
[09:36:10] <Lambda_Aurigae> but with global disabled, it won't stack up interrupts.
[09:36:33] <LeoNerd> Yes it will... to a degree. Any individual kind of interrupt can't be pending more than once, but it can all be pending
[09:36:39] <LeoNerd> They're very similar to POSIX signals, actually
[09:37:21] <Lambda_Aurigae> aahh.
[09:37:24] <abetusk> wait, so if a timer interrupt fires in a cli/sei block, it will get called after the sei call?
[09:37:32] <Lambda_Aurigae> apparently.
[09:37:34] <LeoNerd> Yes
[09:37:38] <abetusk> ok, thanks...
[09:37:41] <LeoNerd> It ensures you don't miss any
[09:37:57] <LeoNerd> But it allows you to have small blocks of processing time when you need not to be disturbed, for doing some sort of atomic operation
[09:38:16] <Lambda_Aurigae> but if you have 2 timer interrupts happen on the same timer you only get the last one...correct LeoNerd ?
[09:38:39] <LeoNerd> Correct; each unit that generates an interrupt has an interupt flag. That flag can be set, or not.
[09:38:49] <LeoNerd> So you can't have an interrupt twice-pending.. it's either pending or not
[10:20:49] <phryk> Still trying to get the UART stuff properly working. For some reason the UART often doesn't reply, even though i can see the rx led blinking.
[10:21:10] <phryk> and that's another thing, the RX/TX leds are apparently on the same port as one of my 16 bit timers. Can I suppress the RX/TX blinking?
[10:23:34] <phryk> https://paste.xinu.at/Oldt/ This is the current version of my code in case that's needed
[10:27:25] <Lambda_Aurigae> blinking LEDs is probably something in your code.
[10:29:51] <Lambda_Aurigae> although I'm not seeing anything in your code that would blink LEDs on UART tx/rx
[10:31:35] <Lambda_Aurigae> and not knowing where the RX led is connected, kinda no way to know what is happening.
[10:41:54] <phryk> Lambda_Aurigae: I don't exactly know *why* that happens, this is on an arduino mega equivalent board. I don't know if it's how the hw is wired up, the bootloader thing or whatever…
[11:09:37] <antto> maybe he has leds directly on the tx/rx
[11:17:28] <phryk> works now for some reason
[11:17:53] <phryk> I even got 57.6kbaud going, exchanging about 100 messages a second :)
[12:52:22] <LeoNerd> Ohman ohman... I am laughing too much for this
[12:52:41] <LeoNerd> An amusing trick I've just found for using a large number of I2C sensors on the same bus, even though they only have one hardware address pin.
[12:53:16] <LeoNerd> Just use that pin like a "slave-select" line on SPI. Configure *all* the devcies to use the same address, and never talk to that address. Instead, raise the address of one sensor by 1, using its A0 pin, talk to it, then put it back
[12:53:51] <Lambda_Aurigae> LeoNerd, interesting...but logical.
[12:53:58] <Lambda_Aurigae> never had to deal with them that way..
[12:54:27] <Lambda_Aurigae> one could use a pcf8574 chip to handle 8 additional devices....said chip being an i2c to 8pin gpio.
[12:55:20] <LeoNerd> Mhm
[12:55:35] <Lambda_Aurigae> somewhere I have a 16pin gpio device similar..
[12:55:38] <Lambda_Aurigae> from microchip.
[12:55:58] <Lambda_Aurigae> 20pin dip package as I recall.
[12:57:22] <Lambda_Aurigae> maybe a 24pin package.
[12:57:32] <Lambda_Aurigae> yeah....
[12:57:41] <Lambda_Aurigae> the 8bit gpion was 14 pin though.
[12:59:37] <Lambda_Aurigae> never had need for more than 8 of a single device on an i2c bus myself though.
[12:59:42] <Lambda_Aurigae> but I can see how it could happen.
[13:00:43] <antto> i kinda like SPI more
[13:02:24] <Lambda_Aurigae> spi is good for up to 8ish devices.
[13:02:38] <Lambda_Aurigae> if you have pins for the chip select.
[13:02:52] <Lambda_Aurigae> i2c is better for many more various devices on one bus.
[13:05:35] <LeoNerd> If you want to talk to *lots* of SPI devices, you can always move slave-select lines onto say some sort of shift register, which itself is SPI-attached
[13:10:59] <Lambda_Aurigae> true.
[13:11:20] <Lambda_Aurigae> there are spi to gpio adapters too
[13:11:34] <Lambda_Aurigae> which are basically shift registers with some nifties included.
[14:43:39] <NicoHood> if I do PORTD |= 0x01 on a port that is in tristate, does this also set the other pins? would be PORTD = 0x01 the same? I want to keep the tristate if possible. if its not, I would use the = since it takes less flash (I need 4 more bytes for my bootloader XD )
[14:46:32] <NicoHood> or another question first: If an AVR MCU is booted, the pins are in tristate. is that correct? Thats what I've heard and I dont want to touch this with my bootloader if possible
[15:09:34] <tpw_rules> NicoHood: when booted, all pins are tristated. whenever a register is shown in the datasheet, it has a bit on its value at boot (
https://i.imgur.com/YGt9kJC.png )
[15:09:43] <tpw_rules> i think you want the register DDRD though
[15:09:59] <tpw_rules> if a bit there is 0, the pin is input. if 1, the pin is output
[15:10:20] <tpw_rules> if the pin is input, its corresponding bit in PORTD controls whether a pullup resistor is enabled or not. if it's output, it controls the output value
[15:10:33] <tpw_rules> DDRD |= 0x01 would just set pin 0 to output
[15:10:47] <tpw_rules> DDRD = 0x01 would set pin 0 to output, and all other pins to input
[15:10:55] <NicoHood> I need to set 2 led pins to output and high (connected to vcc). But I want to keep the other pins just how they are at boot
[15:11:22] <NicoHood> so is there a difference between |= and = ? will the = affact the other pins somehow?
[15:11:44] <tpw_rules> = will set the entire register. if you set 0x01 then pin 0 is output and all the others are input
[15:11:49] <NicoHood> yeah thats what I wanted to know. so |= is important here?
[15:12:19] <NicoHood> but at what state it the register at boot? zero? so arent they already input?
[15:12:35] <tpw_rules> yeah
[15:12:48] <tpw_rules> if it's a bootloader, you're probably concerned about space
[15:13:03] <NicoHood> so at boot = or |= wont matter?
[15:13:07] <tpw_rules> no
[15:13:19] <tpw_rules> but if you're setting only one pin = 0x01 and |= 0x01 are the same size in assembly
[15:13:26] <NicoHood> yes. and = is smaller. but since it is a bootloader I dont want to touch the pins if possible (except the leds)
[15:13:35] <tpw_rules> but if it's = 0x03 to set the first two vs |= 0x03, then = is simaller
[15:13:52] <NicoHood> yes thatswhy I am asking. I need to set more bits
[15:13:56] <tpw_rules> but it won't matter because they're all input by default
[15:15:49] <day> why isn't it possible to compile asm files with the normal avr-gcc toolchain? :/ Isn't the usual way *.c > asm > output, anyways?
[15:17:07] <tpw_rules> if you pass -S to avr-gcc, it will output assembly instead of an object file
[15:17:37] <tpw_rules> if you want to compile assembly into an object file, just name your file .s instead of .c and it should work
[15:18:00] <day> hm but why does the avra project exist then?
[15:18:26] <day> http://avra.sourceforge.net/README.html
[15:18:36] <tpw_rules> i think it you want something lightweight. i tried it but it just didn't have the capability i wanted, and it can't mix c and assembly
[15:19:02] <tpw_rules> it's supposed to be comparable to atmel's own standalone assembler, but cross-platform
[15:19:07] <day> well if avrgcc can do everything i wont bother with avra. I want to learn more about assembler, not to battle a compiler
[15:19:30] <tpw_rules> i have a 100% assembly project compiled with avrgcc, lemme dig that up and see if i can help
[15:19:47] <Lambda_Aurigae> avra is very old...probably as old as avr-gcc even if not older.
[15:19:56] <tpw_rules> it has a bit of a different syntax though
[15:20:47] <day> i used the windows atmel asm toolchain once. it would be nice if the syntax would be similar
[15:22:33] <Lambda_Aurigae> it happens...different tools, different syntax, different bits here and there.
[15:22:34] <tpw_rules> avra has similar syntax. gcc is a bit different
[15:22:35] <tpw_rules> http://pastie.org/private/lyifqtjdsmtpcod0kyjirw
[15:22:45] <tpw_rules> that's my build script for a single file assembly program
[15:23:55] <day> ty i give it a try :>
[15:25:45] <tpw_rules> the nice thing about using avr-gcc is you can use all the libraries
[15:26:06] <tpw_rules> so i #include <avr/io.h> in assembly and i get all the defines and stuff
[15:26:41] <day> you mean things like port definitions?
[15:26:44] <tpw_rules> yeah
[15:26:55] <day> thats neat indeed
[15:27:10] <tpw_rules> and #define and any c preprocessor features
[15:27:56] <day> the *.S tells avr-gcc that it is a mix of assembler and c?
[15:28:06] <tpw_rules> .S is strictly an assembler file
[15:28:11] <tpw_rules> but it runs it through the c preprocessor
[15:28:16] <day> :D
[15:28:16] <phinxy> What are the best lightbulb for cars? most light per power?
[15:28:31] <Lambda_Aurigae> carbon arc
[15:28:31] <tpw_rules> phinxy: not sure why you're asking here, but how far are you willing to go?
[15:28:45] <tpw_rules> i put HID ones in my car and they are amazing
[15:29:08] <Lambda_Aurigae> carbon arc lights are like daylight complete with sunburn dangit!
[15:29:39] <tpw_rules> i don't think they make them in H7 Lambda_Aurigae :(
[15:29:51] <Lambda_Aurigae> bah.
[15:29:52] <day> https://www.youtube.com/watch?v=swZUC1PZKJI :D
[15:29:53] * tpw_rules bolts imax 30kW xenon to the front of his car
[15:30:59] <tpw_rules> day:
http://pastie.org/private/jfurbbtavykm52zuzujkag here's a sample to get a feel for it. those two defines at the top are covered here:
http://www.nongnu.org/avr-libc/user-manual/group__avr__sfr__notes.html
[15:31:48] <tpw_rules> the problem is 30kW on my car is more than a quarter of its total power output
[15:32:23] <Lambda_Aurigae> so get a nice ford f350 with a V10.
[15:32:49] <tpw_rules> i can keep the massive dc-dc power supply in the bed
[15:33:05] <tpw_rules> also if you crash, that would be fun
[15:33:09] <tpw_rules> but it would be hard to
[15:38:07] <tpw_rules> day: what are you planning to do with assembly? i really like it
[15:38:29] <day> tpw_rules: mainly understanding how things work better
[15:39:00] <tpw_rules> btw, maybe you missed it, but if you pass -S to avr-gcc while it's compiling a c program, it will output an assembly text file instead of .o
[15:39:17] <day> didnt miss it
[15:44:32] <tpw_rules> also my one pro tip re asm is be very careful with which io registers are in what banks
[15:45:20] <tpw_rules> i've had some quite painful bugs because i was using the wrong instruction
[15:49:36] <day> tpw_rules: i wasnt aware of io register bank issues. do you have an example?
[15:51:14] <day> do you mean things like: ldi vs ld?
[15:54:01] <tpw_rules> most registers can be accessed with in/out and sts/lds, but it's two different addresses
[15:54:57] <tpw_rules> some require sts/lds. but if you use the wrong instruction with the wrong constant, it won't wokr
[15:59:05] <tpw_rules> i think if you use this it will help:
http://www.nongnu.org/avr-libc/user-manual/group__avr__sfr__notes.html
[15:59:10] <tpw_rules> i didn't because i was lazy
[17:12:30] <day> tpw_rules: are there any tricks/guidelines to make asm readable?
[17:13:08] <day> or lets say, 'easier to read'
[17:13:43] <Lambda_Aurigae> comments
[17:14:33] <Lambda_Aurigae> lots and lots of comments.
[17:14:39] <Lambda_Aurigae> comment every second line at least.
[17:14:49] <Lambda_Aurigae> then comment the ones you missed the first time around.
[17:18:28] <day> Lambda_Aurigae: implying its impossible to avoid spaghetti code?
[17:18:54] <Lambda_Aurigae> nothing of the sort.
[17:19:13] <Lambda_Aurigae> just comment your code then you will be able to go back to it in 3 weeks or 3 months and know what you were thinking when you wrote it.
[17:20:22] <day> i was thinking along the line of 'self running code pieces' that are intertwined with gotos
[17:20:49] <Lambda_Aurigae> goto is awesome.
[17:21:05] <Lambda_Aurigae> jmp is even better
[17:21:20] <day> well i meant jmps
[17:22:03] <day> i can see why its bad in C. but in assembler its impossible to create local variables anyways. so its all one big blob
[17:22:24] <Lambda_Aurigae> assembly programming is a different mindset.
[17:22:43] <Lambda_Aurigae> specially for those who started with something like Java or Python or other high level,,,thing.
[17:23:01] <day> i started with c
[17:23:49] <Lambda_Aurigae> I started with basic, then pascal, then assembly on 6502, then fortran, C, ada, C++, java, perl, python, php, etc..
[17:24:08] <Lambda_Aurigae> added in assembly on 68000 and x86 in there.
[17:24:11] <Lambda_Aurigae> somewhere.
[17:24:30] <tpw_rules> it's possible to create local variables
[17:24:50] <day> how?
[17:24:59] <Lambda_Aurigae> variables...bah...just references to memory locations.
[17:25:08] <day> unless you mean, that you simply purge them within that 'locality' again
[17:25:11] <tpw_rules> i haven't researched how to do it with avr-gcc, but most assemblers let you create a scope block
[17:25:19] <tpw_rules> so you can say r17=in_height
[17:25:28] <tpw_rules> and then add total_height, in_height
