Back
[01:02:54] <nn7> I want to check if a pin is high, such as (PINA & (1<<PA2)) but I need that to be a 1 or 0
[01:03:14] <nn7> would I (PINA & (1<<PA2)?1:0
[02:01:02] <unclouded> or ( PINA >> PA2) & 0x1
[02:48:31] <megal0maniac> unclouded: That method hurts my brain
[02:49:03] <megal0maniac> Although so did (PINA & (1 << PA2)) until I stared at it for a while
[02:50:44] <unclouded> think of the bits. the one we're interested in is in bit position 2 ( third across since zero-based). after the shift it's in bit position 0 ( least significant)
[02:51:10] <megal0maniac> No, I get it. I just prefer the other way logically :)
[02:51:11] <unclouded> & 0x1 to mask out all more significant bits
[02:51:43] <unclouded> would be interesting to see what the compiler makes of both approaches
[02:52:23] <megal0maniac> I'm just not used to shifting the register instead of the bit I'm interested in.
[02:52:28] <megal0maniac> I'm actually going to test that
[03:02:52] <megal0maniac> unclouded: Exactly the same disassembly
[03:03:23] <megal0maniac> SBIS 0x03,2 followed by RJMP PC-0x0001
[03:04:15] <megal0maniac> Genius that I am, I first tried it with the compiler set to release mode :P Didn't get very far
[03:04:15] <unclouded> nice work on the compiler's part then. best use the one that's more explicit and easier to understand
[03:05:55] <megal0maniac> unclouded: Did you hear about that 'feature' when using switch; case on devices with >64kb memory?
[03:08:16] <megal0maniac> Can't remember exact details, but basically the standard branch function only caters for memory addresses within 64kb, so the branch wouldn't be valid and you'd end up in NOP land :D
[03:08:28] <megal0maniac> Something like that. I could be way off base but that's the general idea
[03:09:50] <megal0maniac> Ah, it was a jump not a branch
[03:10:35] <ecilop> Is branch eqal short jump?
[03:10:43] <ecilop> like rjmp
[03:24:49] <RikusW> yes
[03:35:25] <megal0maniac> RikusW: I'm getting closer to ASM. It isn't scaring me quite as much :P
[03:35:40] <RikusW> good :)
[03:35:51] <megal0maniac> Finding the easiest way to learn is to write simple functions in C and see what the compiler does with them
[03:35:53] <RikusW> its really not _that_ hard
[03:36:03] <RikusW> indeed
[03:36:20] <RikusW> but gcc sometimes makes a mess and use way to many instructions
[03:36:28] <megal0maniac> It's extremely simple. Like a brick is simple. And cement is simple. But building a house is bloody complicated
[03:36:34] <RikusW> read the u2s source ;)
[03:37:00] <RikusW> not so much complicated , mire tedious
[03:37:23] <RikusW> and you need to keep to your conventions else...
[03:37:53] <RikusW> if stuff gets inconsistent in a 1500 line asm program, well good luck...
[03:38:14] <RikusW> *more
[03:38:44] <RikusW> I mainly use r16 and up for passing parameters for example
[03:39:58] <RikusW> in the jtag code each function lists the variables used as in out modified
[03:40:13] <RikusW> *registers rather
[03:40:42] <RikusW> I had to do it to prevent unintentional modifications to registers
[03:42:31] <RikusW> good analogy with a house there :)
[03:49:53] <megal0maniac> You just need to break it down into the little pieces
[03:50:07] <megal0maniac> But yeah. I'm supposed to be focussing on Java at the moment :/
[03:50:21] <megal0maniac> C is a bit easier to manage for bigger projects for sure
[10:10:33] <hypermagic> hello my friends
[10:13:15] <Lambda_Aurigae> hello hypermagic
[10:24:46] <Jartza> hmmmmh
[10:24:52] <Jartza> I'm having strange problem with avr-gcc
[10:25:12] <Jartza> I have few eeprom variables defined in "common header" which gets included to many files
[10:25:22] <Jartza> it has "circular inclusion protections"
[10:25:26] <Jartza> I even tried #pragma once
[10:25:47] <Jartza> but still gcc complains that those variables are defined in multiple places
[10:27:05] <Jartza> multiple definition of `ee_contrast'
[10:27:15] <Jartza> when linking
[10:29:11] <Jartza> ahh. got it
[10:29:34] <Jartza> never mind, forgot to declare them "extern"
[10:33:43] <Lambda_Aurigae> oops
[10:34:35] <Jartza> maybe I'm a bit tired, coded last night till 5am :)
[10:35:05] <NicoHood> how can i merge arrays like this?
https://gist.github.com/NicoHood/52feeb056866a08a36b9#file-gistfile1-cpp-L68
[10:36:26] <Lambda_Aurigae> very carefully.
[10:36:58] <Lambda_Aurigae> I would start with looking at something that does both mouse and keyboard in the same application. There are some pic samples that do it.
[10:42:05] <NicoHood> Lambda_Aurigae: i just want to merge the arrays. i want to put the array code in another .ccp file for each device
[10:42:12] <NicoHood> i know how usb works
[10:42:53] <Lambda_Aurigae> so, you want both usb hid devices declared in the one array, yes?
[10:44:03] <hypermagic> the snowdrop engine is almost as good as i imagined a good game engine
[10:44:12] <NicoHood> yes. just move the content to two seperate .cpp files
[10:44:16] <hypermagic> i like this game, this is exactly what will happen soon :)
http://www.youtube.com/watch?v=84OIuVdurUQ
[10:44:37] <Lambda_Aurigae> NicoHood, merge means put them together..you are talking about moving them apart.
[10:44:38] <NicoHood> so everything about the keyboard is in the keyboard.h/cpp
[10:45:06] <NicoHood> well then i want to put them apart but merge them together in the hid descriptor array
[10:45:19] <NicoHood> the hid report descriptor is transmitted to the pc
[10:45:29] <NicoHood> thatswhy it needs to be a continous array
[10:45:56] <NicoHood> or is the only way a define with carriage return \
[10:46:54] <Lambda_Aurigae> ok...I think you can just pull the keyboard one out of that file and put it in another file so long as that other file gets included in this file just before the hidPreportDescriptor declaration
[10:47:39] <Lambda_Aurigae> but putting it in a separate .cpp file, might be a problem.
[10:48:29] <Lambda_Aurigae> as it has to get included in that hidReportDescriptor definition at compile time. You would have to insure the keyboard part gets compiled first...I think.
[10:50:43] <Lambda_Aurigae> I would put that all in one .h file...dunno if that is the right way to do it or not but,,,
[11:06:10] <NicoHood> Lambda_Aurigae: the code i linked above isnt working. it tells i cannot put in a pointer there. and a dereference of cource only gives the first object. or crap, i guess i got crap, my usb device crashed
[11:08:47] <Lambda_Aurigae> then it is possible the keyboard descriptor has to be defined all in one, not broken and referenced/included
[11:09:07] <Lambda_Aurigae> guessing it is a progmem issue there.
[11:09:22] <Lambda_Aurigae> progmem variables don't behave like ram based variables.
[11:57:48] <NicoHood> from Keyboard.h i include this header file. if the enum is above the inlude its working, below its complaining it cannot find the enum.
https://gist.github.com/NicoHood/7aa14362f5f32e675bf2
[11:58:35] <NicoHood> the double include must confuse the compilerß
[15:01:18] <bitd> In an AC generator, why is the amount of magnets always unequal to the amount of magnets?
[15:01:29] <bitd> Is it just so it wont "lock up"?
[15:01:44] <LeoNerd> ...mmm?
[15:01:57] <LeoNerd> I suspect one of those words "magnets" should be something else
[15:02:37] <bitd> Oh sorry man, yeah.
[15:02:46] <Tom_itx> so it's always at odds with itself
[15:02:46] <bitd> magnets in one instance should be coil.
[15:03:14] <Casper> bitd: like 1 coil 2 magnet?
[15:03:23] <bitd> Yeah, or 6 coils, 8 magnets.
[15:03:28] <bitd> Its never 6 coils, 6 magnets.
[15:03:38] <Lambda_Aurigae> multiple phases out of "phase"
[15:03:49] <Casper> 6 coils indicate a triphased output most likelly
[15:04:09] <bitd> Thats correct.
[15:04:10] <Tom_itx> when the made parts for it they made to many magnets
[15:04:13] <Casper> so most likelly still make 1 coil per phase once you analyse it
[15:04:32] <Casper> now it make it a 6 poles alternator
[15:04:48] <Casper> the output frequency is 6 times higher than the rotational speed
[15:05:44] <bitd> So my question should be, would a 6 coil stator, work with a 6 magnet rotor?
[15:05:51] <Casper> higher frequency can, in some case, increase the efficiency, can also possibly reduce the wire usage (so a more light alternator)
[15:05:59] <Casper> sure
[15:07:04] <bitd> The locking up isnt that much of a problem, so you would need some extra "push" to turn the generator.
[15:07:19] <Casper> just need a bigger flywheel maybe
[15:07:24] <bitd> Its way easier for me to make a 6 magnet one, thats why I ask :)
[15:07:27] <Lambda_Aurigae> if all the magnets hit all the coils at the same time you just get single pulses...as in, they all pulse at once, causing you to have to spin it faster.
[15:07:40] <Casper> but look at this: triphased alternator for a diesel genset
[15:07:42] <Lambda_Aurigae> with 8 coils and 2 magnets, you can spin slower and get the same frequency out.
[15:07:51] <Casper> will have 3 coils and 2 magnets
[15:08:09] <Lambda_Aurigae> 3 phase vs single phase?
[15:08:21] <Lambda_Aurigae> sounds like a 3 phase generator.
[15:08:26] <Casper> that way, the alternator need only 1800rpm to generate 60Hz
[15:09:05] <Lambda_Aurigae> look at the phases of 3-phase vs single phase power.
[15:09:09] <Casper> standard portable genset use 1 coil 1 magnet, and need 3600rpm if it had 2 magnet it need 1800...
[15:10:04] <bitd> I need to start reading up on this.
[15:10:07] <bitd> Thanks guys :)
[15:10:14] <Casper> bitd: will the output be AC or DC?
[15:10:25] <bitd> AC.
[15:10:46] <Casper> then don't forget that the number of magnet will dictate the rotational speed needed
[15:11:11] <Casper> which then can become a big issue
[15:11:39] <bitd> Well yeah its beginning to dawn on me. Indeed what Lambda_Aurigae said makes sense.
[15:11:46] <bitd> They now just all pulse at the same time.
[15:11:55] <bitd> With 8, phase shift would set in.
[15:12:39] <bitd> So 6 magnets, 6 coils makes no sense for low rpm application.
[15:12:49] <Lambda_Aurigae> nope.
[15:12:58] <Lambda_Aurigae> but 6 coils and 2 magnets does.
[15:13:19] <bitd> But 8 even more right?
[15:13:24] <Lambda_Aurigae> true
[15:13:37] <bitd> Then I will have to bite down and just try that.
[15:13:47] <Lambda_Aurigae> watch your densities too...how close they are vs how big the magnets are and all that.
[15:14:40] <bitd> Ah, yes. Will do.
[16:02:52] <malinus> any suggestion for compression of data (PCM audio) that could easliy be uncompressed in real time by my avr?
[16:03:37] <malinus> It seems like RLE encoding is the only option? It should however look well, looking at the PCM data.
[16:11:37] <Casper> you might also want to reduce the bits and bitrate, that will also help alot
[16:12:37] <malinus> Casper: it's already 8-bit @ 8000samples/sec.
[16:13:10] <Casper> ok
[16:13:29] <malinus> Any other suggestion? Without external flash/IC
[16:16:40] <Casper> move to avr32 or arm? :D
[16:16:53] <Tom_itx> skip avr32
[16:16:57] <Tom_itx> it's a lost cause
[16:18:30] <malinus> Tom_itx: stm32?
[16:19:04] <malinus> Casper: but yeah, it's a school project, and it has to be on a 8-bit avr.
[16:19:16] <Casper> bbk
[16:19:17] <Casper> bbl