Back
[03:49:25] <skz81> I was looking at those AT90USB* datasheet, seems a good chip, does anyone knows why they "overlapped" OC0A/OC1C on PB7 ? I mean, why *2* PWM output on the same pin ?
[03:50:24] <^Richard> presumably so you've got frequency choice
[03:50:38] <^Richard> i.e. you can choose which pin is which rather than being more fixed
[03:59:06] <skz81> ^Richard, was for me ? Unsure to understand your answer...
[03:59:39] <skz81> Actually, sure to NOT understand it, sorry
[06:02:21] <lowin> "cpi R26, R24" Gives me error: undefined reference to `R24'. How do I fix R24 to reflect the address of R24?
[06:02:38] <lowin> I want to compare value inside R26 with R24's memory address
[06:33:29] <Jartza> lowin: you can't
[06:33:33] <Jartza> cpi = compare immediate
[06:34:09] <Jartza> it performs a compare between register and a constant
[06:34:36] <LeoNerd> AVR is a load/store architecture. ALU operations work between registers. If you want to perform ALU on a memory location that is not a register, you'll have to LD it into a register first
[06:34:45] <Jartza> register must be between r16 and r31, and constant is 0..255
[06:35:16] <Jartza> so I guess you want CP, not CPI
[06:35:20] <Jartza> CP compares two registers
[06:35:33] <lowin> Every register has an address
[06:35:45] <Jartza> constant is not register
[06:35:51] <lowin> I want to compare with the constant
[06:35:52] <Jartza> all "immediate" commands compare with constant
[06:36:02] <Jartza> then write the constant there
[06:36:02] <LeoNerd> That's what "immediate" means :)
[06:36:27] <Jartza> if you want to compare register r26 with value 42, then just write it
[06:36:31] <Jartza> cpi r26, 42
[06:37:12] <Jartza> if you want to compare contents of two register, then use cp, not cpi
[06:37:23] <lowin> I want to compare the value of R24 with the physical memory location of R24
[06:37:33] <lowin> I mean R26 with location of R24
[06:37:38] <LeoNerd> Huh?
[06:37:43] <Jartza> heh
[06:37:45] <LeoNerd> "the location of R24"? does not make sense
[06:37:50] <LeoNerd> R24 is at a fixed place
[06:37:56] <LeoNerd> Read the datasheet to find out where that is
[06:37:57] <LeoNerd> That's a constant
[06:38:07] <lowin> yes. and I want to compare it with that very fixed place
[06:38:25] <liwakura> lowin: can you write in C what you want to do?
[06:38:37] <LeoNerd> In fact, register 24 is at memory location 24, or 0x18
[06:38:40] <LeoNerd> So.. thyat's easy
[06:38:46] <lowin> But I don't want to type in the actual address as operand, I want to write the register name so the code is readable
[06:38:48] <LeoNerd> cpi r26, 0x18
[06:40:08] <Jartza> or cpi r26, 24
[06:40:11] <Jartza> if you don't want to use hex
[06:40:20] <LeoNerd> Yes; that even. Would be pretty clear :)
[06:40:20] <Jartza> although I really don't know why you want to do that :D
[06:40:33] <LeoNerd> Yah - Ican't imagine any situation wherein the /address/ of a register matters
[06:40:41] <Jartza> lowin: there is no operand to get register address
[06:41:03] <Jartza> but in avr, the registers are always in the very beginning of memory
[06:41:12] <Jartza> r0 is at address 0, r1 is at address 1....
[06:41:14] <lowin> I don't understand why register names aren't #defines in the first place
[06:41:42] <Jartza> I don't understand why they should be
[06:42:01] <Jartza> again, would be nice to know what is the problem you're trying to solve with this :)
[06:42:11] <lowin> Because they represent an address, that need to be replaced with during assembly
[06:42:52] <Jartza> they are constants, why they need to be #defines
[06:42:57] <Jartza> I still don't understand
[06:43:18] <lowin> because #define is the way to define constants?
[06:43:20] <liwakura> i guess sth like PORTA and PORTB just for r23 and r24 and stuff
[06:43:47] <liwakura> lowin: usually, you dont access the registers via memory addressing
[06:43:56] <Jartza> indeed
[06:44:02] <liwakura> i dont even know why atmel even did this
[06:44:04] <Jartza> r0..r31 are known to assembler
[06:45:03] <lowin> liwakura, yes. but now that we do in avr, I don't mind taking advantage of it. Anyway I expect cp 0, 1 to work the same way as cp r0, r1
[06:45:32] <Jartza> lowin: depends what you're talking about. constants are defined with .db, .dw etc.
[06:45:37] <Jartza> and expressions with .equ
[06:45:56] <liwakura> lowin: no, we are on a RISC arch, you'd have to ld them first into an register to compare them
[06:46:17] <liwakura> but since they are already registers
[06:46:17] <lowin> Jartza, .db and .dw are used to put bytes in the assembled program not the preprocessor.
[06:46:44] <liwakura> lowin: those would be constant variables then
[06:46:46] <lowin> liwakura, I mean cp 0, 1 should compare r0 and r1
[06:47:03] <liwakura> 0 and 1 are memory addresses
[06:47:28] <liwakura> not registers. they just happen to point to those registers
[06:47:48] <lowin> right
[06:48:06] <liwakura> 2 different ways to access the same data
[06:48:08] <lowin> but r0 and r1 still get translated to a number during assembly
[06:48:13] <Jartza> r0, r1 etc. are just syntax to assembler to tell apart constants and registers
[06:48:35] <Jartza> I still don't understand what is the problem you're trying to solve?
[06:49:01] <liwakura> Jartza: hacker curiousity, "what happens if,...", most likely no actual problem
[06:49:29] <lowin> Jartza, I wanted to avoid saving a state by using different registers for each state, and then at the end check which register i was using to pop it correctly
[06:49:29] <Jartza> depends of the assembler
[06:51:29] <Jartza> I read that multiple times but it doesn't really make sense to me :)
[06:52:05] <lowin> lemme try to rephrase it
[06:54:06] <lowin> Let's say I compare two numbers, if first was bigger I send one thing, if the other was bigger, i send another thing. at the end of sending, I need to check which one was bigger again, but i don't have the numbers anymore.
[06:55:21] <lowin> The solution was to use let's say R25 if first was bigger, and use R24 if the other was bigger as the buffer for sending the data. Now I have to determine which register I was using at the end of sending routine
[06:55:41] <lowin> If I do this, I avoid having to save the 2 numbers from the beginning
[06:56:07] <liwakura> lowin: but now you have to save the address of the registers
[06:56:21] <liwakura> you could instead just save which of the number was greater, instead
[06:56:26] <Jartza> indeed, I still don't get how that
[06:56:34] <lowin> but addresses are constants, I know them before assembling it
[06:56:34] <Jartza> ...solves anything :)
[06:57:58] <liwakura> lowin: you could also just use some GPIOR bit to save which of the both numbers was bigger previously
[06:58:26] <Jartza> you already know which one is bigger because you do different things based on that information
[06:58:31] <lowin> didn't check gpior but i did think about setting t bit in sreg
[06:58:40] <lowin> turns out I need to use it during the routine
[06:59:03] <lowin> Jartza, no, the sending routines are the same. I just send different data
[06:59:30] <liwakura> lowin: consider showing your code
[06:59:56] <liwakura> this feels like restoring mona lisa without being able to see it
[07:00:00] <lowin> but its embarrassing :(
[07:00:25] <lowin> btw problem is solved If i use 0x18 directly, I just wanted to be able to use r24
[07:00:50] <liwakura> im pretty confident that there is a much easier solution
[07:00:56] <lowin> Isn't there a macro to expand register name to their respective address?
[07:01:09] <liwakura> not for the ALU registers
[07:01:25] <liwakura> *the non-I/O registers
[07:11:10] <Jartza> I'm also pretty sure there are better ways of doing what you
[07:11:13] <Jartza> 're trying
[07:11:19] <Jartza> but hard to be sure without the code
[07:12:07] <Jartza> people tend to share their code, even if it's embarassing. you have to start the learning process from something.
[07:12:12] <Jartza> we all were beginners once
[07:13:08] <lowin> yeah alright
[07:15:03] <liwakura> when i came here i was asking like 10 questions a day
[07:15:21] <liwakura> and 9 of them could be answered 'its written in the datasheet on cap. n.n'
[07:15:46] <liwakura> today i have still not read the whole datasheet of my controllers :D
[07:15:49] <lowin> here you go. good luck.
https://bpaste.net/show/a40173ea04e9
[07:15:50] <Thrashbarg> in a room of ten EE's you'll have eleven answers
[07:15:51] <liwakura> but i use ctrl+f more often
[07:16:12] <liwakura> oh my gosh
[07:16:17] <liwakura> bitbanging usb?
[07:16:21] <liwakura> im out
[07:16:28] <lowin> problem: check if we were doing usb_transfer_nak or usb_transfer_packet at the end
[07:16:36] <lowin> I told you!!
[07:17:40] <liwakura> lowin: uhm, the numbers after the ';' , do they represent the cycle number?
[07:17:52] <liwakura> because some instructions take 2 or more cycles
[07:18:09] <lowin> btw I just checked. r0 translates to 0 and r1 translates to 1 in assembly. I'm betting the rest also translate to their respective memory address
[07:18:31] <lowin> liwakura, yes. they represent the cycles already past before the current instruction
[07:18:41] <LeoNerd> We said that already
[07:18:55] <LeoNerd> 12:12 <LeoNerd> In fact, register 24 is at memory location 24, or 0x18
[07:19:08] <lowin> I mean when used with cp
[07:19:19] <lowin> so using cp 0, 1 should be completely legal
[07:19:26] <LeoNerd> 12:14 <Jartza> r0 is at address 0, r1 is at address 1....
[07:19:39] <LeoNerd> No, because that is not the syntax that is allowed
[07:19:56] <LeoNerd> When the assembler sees the 'cp' instruction, it knows the two operands must be names of registers that begin with the letter r
[07:20:15] <LeoNerd> You can't write cp 0, 1 any more than you can write cp APPLE, BANANA
[07:20:32] <liwakura> i wish i had an apple
[07:20:44] <lowin> Why the hell not? I'm giving the register address directly
[07:20:44] <liwakura> i mean, the fruit
[07:22:28] <liwakura> you can also write uint16_t if(a=b); in C, but i doubt it would be valid syntax
[07:23:08] <liwakura> if you feel like it, you could also write your own assembler
[07:23:20] <liwakura> who accepts that other syntax
[07:23:24] <lowin> liwakura, I did. for my own cpu architecture
[07:23:26] <liwakura> but imho its confusing
[07:26:56] <Jartza> lowin: giving register address directly is against the language syntax, that's why
[07:27:32] <Jartza> avr assembly syntax says registers are denoted with r and number.
[07:27:52] <Jartza> plain number denotes constant value
[07:29:02] <lowin> I just tested and cp 0,1 produces the same assembly as cp r0, r1
[07:29:12] <lowin> as I expected
[07:29:18] <LeoNerd> Ah, well there you go.
[07:29:27] <lowin> cpi r0,r1 doesn't work tho ;_;
[07:29:39] <LeoNerd> Indeed not
[07:29:45] <LeoNerd> because r1 is not an immediate number
[07:29:50] <LeoNerd> It is the name of a register
[07:33:21] <skz81> #define _r24 0x18
[07:33:21] <skz81> #define BANANA r24
[07:33:21] <skz81> cpi BANANA, _r24
[07:33:24] <skz81> ^^
[07:34:22] <lowin> Maybe I'll provide a patch to avr-libc for a macro that translates registers to their address location
[07:41:26] <skz81> huh... lowin, this behaviour is not a bug, that what Jartza said...
[07:41:36] <skz81> no need for a patch ^^
[07:41:45] <lowin> skz81, didn't say it is
[07:41:52] <skz81> but you can try to change you local compiler
[07:42:17] <skz81> sorry if i misunderstood, though
[07:42:41] <lowin> but say, if you were able to use cpi r16, addr_of(r24) wouldn't it be useful?
[07:44:52] <Jartza> lowin: doesn't work with all assemblers
[07:44:56] <Jartza> Error : No register associated with 24
[07:44:56] <skz81> ho yeah, additional operator could be nice for that ! (or a macro but I doubt any macro can do the job... At least without a dirty, ugly and hardly maintainable hack)
[07:45:04] <Jartza> Error : Garbage in operand (24)
[07:45:12] <Jartza> Error : cpi can only use a high register (r16 - r31)
[07:45:43] <Jartza> lowin: so if you want your code to compile with other avr assembler, you should stick to assembly definitions
[07:46:39] <lowin> Jartza, assemblers are already fully incompatible outside basic operators
[07:46:55] <skz81> Jartza, different avr asm compiler are compatible ? I just use the gcc flavour, never checked other
[07:47:15] <lowin> I mean with each other
[07:48:23] <skz81> But I would have assume they were not syntax-compatible
[08:27:23] <Jartza> skz81: atmel assembler and avra are syntax compatible
[08:28:15] <Jartza> lowin: well... gcc assembler is it's own breed. atmel assembler (avrasm32) and avra are compatible
[08:29:17] <Jartza> http://www.atmel.com/webdoc/avrassembler/index.html
[08:30:55] <Jartza> there are few missing features from avra, mainly #pragma, but one can live without them
[08:52:37] <Jartza> and on top of avra, there's still tavrasm
[08:53:06] <Jartza> albeit I think it's development has ended like 10 years ago
[08:55:10] <Jartza> personally I use avra, it's amazing
[08:55:24] <liwakura> i have a fetish for C
[08:55:27] <Jartza> though it hasn't been updated in few years either, needs some patching to support few more chips
[08:55:28] <liwakura> so i use avr-gcc
[08:55:39] <Jartza> well I use C most of the time too
[08:55:51] <Jartza> but sometimes there are things you can't do with C :)
[08:55:55] <Jartza> like my attiny85 vga :)
[08:57:15] <skz81> Yes, but avr-gcc still reliable for ASM, too :p
[08:57:29] <Jartza> I just hate the syntax, that's all
[08:59:12] <skz81> Huh, I don't speak about inline volatile asm directive or forgot what, but clean .S files in the project
[08:59:18] <skz81> or even .s
[08:59:40] <skz81> No, actually, no .s
[09:00:04] <WormFood> it's usually .S that are preprocessed into .asm files.
[09:00:07] * Haohmaru uses C++ on teh xmegas
[09:00:19] * WormFood never uses C++ for anything.
[09:02:32] <liwakura> i have s strong dislike for C++
[09:02:36] <liwakura> s/s/a/
[09:02:59] <WormFood> because you don't understand it?
[09:03:04] <WormFood> :P
[09:03:24] <rue_bed> I havea number of reasons I hate c++
[09:03:31] <bss36504> But but C++ has operator overloading, the feature nobody needs yet somehow you want it once you have it
[09:03:38] <Haohmaru> rue_bed aren't you... in bed?
[09:03:42] <rue_bed> yup
[09:04:14] <rue_bed> c++ promotes a number of bad coding practices
[09:04:17] <WormFood> But his hatred of C++ caused him to go through the effort to chime in on the subject ;)
[09:04:42] <bss36504> C
[09:04:59] <bss36504> c'mon Rue, *real* friends let friends touch their privates
[09:05:26] <liwakura> WormFood: i had to do it at the academy
[09:05:41] <rue_bed> do you REALLY know whats happening when you use someone elses code with c++?
[09:05:44] <skz81> bss36504, \o/ !!
[09:05:54] <WormFood> in C++ class, a male student reaches out, and grabs the breast of the female student next to him, and she says "HEY! That's private", and he looked at her with a confused look, and said "But I thought we were in the same class"
[09:06:10] * liwakura slaps WormFood
[09:06:58] <WormFood> ok. I have to tell a better joke, to try to cover up how bad that joke was.....
[09:07:10] <WormFood> Why do programmers get Halloween, and xmas mixed up?
[09:07:16] <bss36504> I thought it was pretty good
[09:07:19] <WormFood> Because Oct 31 = Dec 25
[09:07:20] * liwakura slaps WormFood
[09:07:25] <bss36504> why?
[09:08:01] <WormFood> ^^^
[09:08:32] <skz81> bss36504, 031 = 25 actually :p
[09:08:33] <bss36504> oy that one went over my head. I'm tired.
[09:08:33] <bss36504> I got it now though
[09:08:36] <skz81> ==*
[09:10:36] <WormFood> Actually, October and December used to be the 8th, and 10th months. But we had July and August inserted into the middle of the calendar, pushing back the other names, pushing their names out of sync with their actual position within the year.
[09:12:01] <skz81> Ho right ? I guessed It was because Roman year began in March (like, "time to re-start the war, boys, winter has gone !")
[09:20:43] <Haohmaru> C plus plus has moar plusses than C
[09:24:12] <Chillum> every + has a - inside of it
[09:24:17] <Chillum> so c++ has more minuses than C
[09:26:25] <WormFood> It uses two - to make a +, so that's actually 2x more -
[09:27:05] <Chillum> well a negative turned on its side can be seen as half of a positive
[09:27:06] <Chillum> lol
[09:27:22] <Chillum> I am sure there is a metaphor in there somewhere
[09:29:34] <WormFood> What about MC Plus +?
[09:29:52] <liwakura> y'all dudes need jesus
[09:30:08] <WormFood> huh?
[09:30:30] <WormFood> Which jesus?
[09:30:46] <WormFood> You mean the guy who cleans the weeds out of my garden?
[09:34:16] <WormFood> If jesus is the answer, then it must have been a really stupid question.
[09:37:25] <Chillum> a man needs religion like a fish needs a bicycle
[09:39:53] <WormFood> If you give a man a fish, you feed him for a day. but, if you give a man a religion, he'll starve to death, praying for a fish.
[09:58:30] <skz81> But why did you feed him in the first place !!
[10:55:14] <lowin> So, I installed simavr.. I'm not sure how I'm supposed to use it. I mean I can connect to it using avr-gdb and see my program run. but how do I edit registers and stuff? I'm absolute newbie to gdb
[10:58:58] <skz81> lowin, i don't have that in mind, but be careful, some peripherals are buggy in simavr. I think of timers / PWM, but there are other
[10:59:27] <lowin> Well I don't think I don't have to worry about that since I don't even know how to read them
[10:59:29] <skz81> good piece of software, though, when you don't have to deal with thoses parts
[10:59:57] <skz81> for that you can dump memory
[11:00:07] <skz81> or layout registers
[11:00:29] <lowin> I tried changing sreg register by using it's memory address but it didn't change
[11:00:39] <skz81> (liyterrally type 'lauoyt register' (registers?) as a command)
[11:01:12] <lowin> general register I know how to see/change
[11:01:16] <lowin> how about io register
[11:02:12] <skz81> hum maybe using C instruction ? 'SREG &= ~0x01;' etc...
[11:02:40] <skz81> You should be able to print at least
[11:03:04] <skz81> argg that's old in my mind... Sorry i'm npot helpful
[11:03:25] <skz81> plus never used simavr as backend but simulavr, can make a difference
[11:03:32] <lowin> Well that didn't work
[11:03:39] <lowin> I have simulavr too
[11:03:46] <skz81> you said simavr
[11:03:49] <skz81> not the same
[11:03:52] <lowin> I have both
[11:03:57] <skz81> ha okay :)
[11:05:05] <skz81> simulavr was working for my needs (i.e. playing with timers), but i was not playing much interactively with I/O regs, so... Hope someone else knows.
[11:05:11] <skz81> Have to go, good week-end all
[11:05:50] <lowin> Well running sei instruction doesnt change sreg at all
[11:05:55] <lowin> or I'm reading it wrong
[11:32:03] <lowin> Got it. should treat i/o registers as variables.. like set SREG=0xff
[11:32:07] <lowin> I feel so stupid now
[15:24:20] <LeoNerd> GAHHHHHHH
[15:24:26] <LeoNerd> Seriously whothefuck designed the 32U4?
[15:24:45] <LeoNerd> There are 4 nice "INT" pins...they're sadly muxed onto UART (I'm using that), and I²C (I'm using that too)
[15:24:52] <bss36504> Hey now, that's a great little chip
[15:25:02] <LeoNerd> But that's OK, there's 8 PCINT pins. Oh, but 4 of those are on the SPI port (guess what - I'm using that)
[15:25:06] <bss36504> lol
[15:25:11] <bss36504> Well just use the PCINT ones then
[15:25:13] <LeoNerd> So that leaves me just four interruptable input pins.. PB0 to PB3
[15:25:16] <bss36504> oh
[15:25:16] <bss36504> lol
[15:25:43] <bss36504> How many interrupts do you need?
[15:25:49] <LeoNerd> Worst of all (And I admit this one isn't Atmel's fault), the Arduino Micro Pro breakout board doesn't bring PB0 out to a header pin at all
[15:25:54] <LeoNerd> So I only have 3 pins useable
[15:25:57] <LeoNerd> I'd like 4 buttons
[15:26:18] <bss36504> Well sounds like you're in a bit of a pickle
[15:27:00] <LeoNerd> I begin to wonder if I should move all the buttons and local LEDs (currently on a 74'595 chip on the SPI port) onto an I²C expander instead.. since I'm already talking I²C anyway, so that's not much extra IO
[15:27:14] <LeoNerd> I'd need one more interrupt in from that, but that's OK because I'd have all the PCINT pins back once I move the buttons off them
[15:27:30] <LeoNerd> Or I sacrifice one harware ability and live with just 3 buttons
[15:28:11] <LeoNerd> But seriously,... why doesn't every pin have PCINT ability? There's only 8 on here, on PORTB. None on PORTC or PORTD
[15:28:54] <liwakura> LeoNerd: lol
[15:29:03] <LeoNerd> Oooh... or could I move all my aux buttons onto a single pin analog read chain? I'd have to use the ADC then, but I have plenty of ADC inputs spare.
[15:29:14] <liwakura> even the atmega328p (arduino) has all pins available as PCINT
[15:29:23] <LeoNerd> liwakura: yah.. I've got so used to it
[15:29:28] <LeoNerd> Every tiny chip too, has PCINT on all pins
[15:30:23] <bss36504> You could actually handle 4 buttons with 3 pins, if you are ok adding 4 diodes to the circuit
[15:30:42] <bss36504> Wouldn't be interrupt driven, but it would work
[15:30:56] <LeoNerd> I could do four buttons with /one/ pin given an analog read chain
[15:31:00] <LeoNerd> Without interrupts
[15:31:00] <liwakura> bss36504: with the analog reader, you can handle more than 10 buttons with a single pin
[15:31:07] <bss36504> Actually, you'd only need two diodes and 3 pins.
[15:31:12] <bss36504> Oh I know
[15:31:17] <bss36504> Just providing an alternate solution
[15:31:33] <bss36504> With the analog method, you'd need what, 9, 10, resistors?
[15:31:41] <LeoNerd> Actually the usual trick of using the anacomp as well usually makes it possible to do interrupt-driven as well
[15:31:52] <LeoNerd> No, one R per button. I don't need or want multitouch
[15:32:14] <bss36504> Ok, well I still win in part count :P
[15:33:47] <bss36504> And, you'd need 5 resistors for four buttons, right?
[15:43:30] <LeoNerd> Oh duh.. I am an idiot. I have plenty of IO pins spare (e.g. PD7, all of PF), just none of them are PCINT
[15:43:46] <LeoNerd> But that's OK.. these are only buttons for humans to press. I'll just poll them every timer tick and look for changes.
[15:44:00] <LeoNerd> So all is fine :)
[15:44:41] <bss36504> Oh good
[20:01:28] <z3t0> Is this the right place to ask for help about the Arduino Zero? Even though the board has an arm chip?
[20:01:55] <Snert> #arduino might be better.
[20:02:41] <Tom_itx> no
[20:02:49] <Tom_itx> this is about 8bit avr
[20:07:14] <z3t0> ok thanks
[22:23:22] <liwakura> i replaced the controller in my rgb controller with an atmega328p, on the pwm ports
[22:23:36] <liwakura> the thing now is, that the led's never go completely dark
[22:24:27] <liwakura> even when the atmega has the pins on DD=0, PORT=0, its still "positive" enough to make the led's glim visibly.
[22:24:53] <liwakura> i tried adding a pull-down resistor, but even 220 Ohms only reduce the effect by half
[22:26:00] <liwakura> if i short the pin directly to ground, the led's go completely dark
[22:26:39] <Casper> there is a mode on the PWM that never go to zero
[22:26:45] <Casper> check the PWM mode
[22:29:50] <liwakura> currently using fastPWM
[22:31:09] <liwakura> yeah, it has exactly that behavior - a narrow spike when OCR is 0
[22:32:54] <Casper> there is a mode that don't have that spike, I forgot which one
[22:34:00] <liwakura> i just switched to one of the phase correct modes
[22:34:10] <liwakura> and it works perfectly fine
[22:37:16] <liwakura> thanks
[23:10:22] <Casper> rue_whatever: do you know if they make an adapter for stove outlet to welder?