Back
[00:04:34] <inflex> Casper: yes, but it's a bit of a "slow death" type thing
[00:04:43] <inflex> Casper: enough to barely keep me alive, but always slowly slipping backwards
[02:56:25] <inflex> hmm.... always a bit of an issue to differentiate between a legitimate brown-out vs a power-off event :(
[03:48:21] <Igor2___> hi
[03:48:39] <Igor2___> i am trying to use avrdude with a programmer that requires vcc signal inverted
[03:48:55] <Igor2___> I've written the config for it, but it seems ~ is not allowed for vcc
[03:49:28] <Igor2___> checked the code. the .y supports my suspiction
[03:49:51] <Igor2___> anyone has experience with this?
[03:50:25] <Igor2___> (avrddude version 5.10)
[03:54:44] <Igor2___> hmm, i think i could patch it somewhat
[08:27:32] <wreiner> hi - is it possible/does it make sense to use a 14.381mhz oscilator for an atmega8/32?
[08:28:20] <RikusW> should be possible
[08:28:42] <RikusW> 14.745 would make more sense for serial
[08:29:37] <wreiner> oh ok - thank you - i'm a little bit confused with fuse settings in the datasheet. the table for external crystal osc. are maxed with 8mhz
[08:29:55] <Steffanx> Uh?
[08:30:05] <RikusW> 8 - ... 16
[08:31:01] <RikusW> check the CKOPT fuse too
[08:31:10] <wreiner> hmm - datasheet tells me ckopt 1/ cksel3..1 111/ 3-8mhz
[08:31:42] <RikusW> lfuse = 0xFF for m8 should be safe
[08:32:09] <RikusW> same for m32
[08:32:24] <RikusW> just check CKOPT, might need to be set
[08:32:45] <Steffanx> That's in the datasheet too wreiner :)
[08:32:59] <wreiner> perhaps i've overlooked it?! :)
[08:33:29] <wreiner> "For resonators, the maximum frequency is 8MHz with CKOPT unprogrammed and 16 MHz with CKOPT programmed."
[08:33:31] <wreiner> ahh
[08:33:31] <RikusW> For resonators, the maximum frequency is 8 MHz with CKOPT unprogrammed and
[08:33:33] <RikusW> 16 MHz with CKOPT programmed. C1 and C2 should always be equal for both crystals
[08:34:21] <wreiner> so hfuse: c9 and lfuse: ff
[08:35:16] <Steffanx> How's rAVR going RikusW ?
[08:35:42] <wreiner> thx to all :)
[08:38:05] <RikusW> Steffanx: not worked much on it lately...
[08:38:19] <RikusW> TPI works with abc's clone now
[08:39:35] <Steffanx> nice
[09:05:51] <ys0> oi
[09:06:16] <Steffanx> Hi
[10:14:08] <doublebeta> night all
[10:48:41] <spow> Hi, what is the proper method to concatenate ADCH and ADCL please into a single 16-bit variable ?
[10:49:22] <spow> I'd bit shift it, but i'm not sure it's that elegant
[12:44:25] <GeorgeJ> uint16_t val = (ADCH << 8) | ADCL;
[12:44:50] <GeorgeJ> Or perhaps uint16_t val = (ADCL << 8) | ADCH; depending on endianness
[12:47:09] <GeorgeJ> Ofcourse the first variant would be the correct one on an AVR platform.
[12:52:30] <karlp> the second wouldn't be correct on any. how the uint16 is stored internally matters, but making a 16bit number in your own memory is done like the former.
[12:55:32] <GeorgeJ> I see.
[12:56:32] <Steffann> Why you dont just read ADC GeorgeJ ?
[12:57:04] <karlp> Steffann: he was replying to spow, who's gone.
[12:57:11] <GeorgeJ> Steffann: I simply gave a suggestion to spow, though forgot to include his nick.
[12:57:11] <Steffann> Ah
[12:57:29] <Steffann> spow.. that must have been hours ago
[12:59:17] <GeorgeJ> Steffann: 18:41, seconds before you've joined.
[13:00:50] <grummund> neither is correct since atmega requires H and L registers read in certain order :P
[13:00:51] <Casper> GeorgeJ: why complicate stuff?
[13:00:59] <Casper> uint16_t val = ADC;
[13:05:44] <Steffann> I was here before, but i left a few minutes :)
[16:06:05] <OndraSter> http://clip2net.com/s/1rkWG
[16:06:07] <OndraSter> lil' wiring
[16:06:24] <OndraSter> I am hoping they can do smaller vias
[16:06:29] <OndraSter> than Eagle has
[16:33:27] <bram1> Ondraster: I've done PCB's with 0.3mm at Eurocircuits, they didn't complain about that
[16:33:35] <OndraSter> 'kay
[16:33:36] <OndraSter> :)
[16:33:41] <OndraSter> hopefuly this company won't complain either
[16:34:50] <bram1> 6 mil for trace width/spacing is usually the lower limit for the cheap/fast services
[16:35:06] <bram1> .25mm for drill as i recall
[16:36:06] <bram1> OndraSter: why do you have such a poor PCB layout?
[16:36:15] <OndraSter> poor?
[16:36:35] <OndraSter> this is "will it fit"
[16:36:37] <OndraSter> before optimalizing
[16:36:41] <bram1> yes, 90 degree angles and the via's are too close to traces
[16:36:42] <OndraSter> but I am not sure I will change much
[16:36:51] <OndraSter> yeah, I thought about vias being too close
[16:36:58] <OndraSter> 90 degree angles are bad?
[16:37:16] <bram1> 90 degree is considered "poor design"
[16:37:21] <Casper> for high frequency yes
[16:37:30] <OndraSter> what does "high" frequency mean?
[16:37:45] <vectory> megahurts
[16:37:46] <vectory> ?
[16:37:52] <OndraSter> how much megajogurts
[16:37:54] <bram1> yes and above
[16:37:57] <Casper> and the traces seems to be too close for no reason
[16:38:08] <OndraSter> Casper, space...
[16:38:44] <OndraSter> motherboards are clocked on hundreds of MHz and they have even closer traces
[16:38:48] <Valen> space doesnt seem to be an issue
[16:38:53] <OndraSter> it is
[16:38:55] <bram1> OndraSter: if space is a real concern, the you should add more layers
[16:39:04] <OndraSter> more layers = 3 times the price
[16:39:09] <OndraSter> more space = 2 times the price
[16:39:11] <Valen> you have plenty of room inside the board as it is and yet you run the traces super close
[16:39:13] <OndraSter> and I am already on really high prices
[16:39:22] <OndraSter> inside the board?
[16:39:38] <OndraSter> I can move only the thick ones inside the LED matrices
[16:39:44] <Valen> the right side of that board you have big traces starting wide then bunching up
[16:39:51] <Valen> they are closer than any of the others
[16:39:56] <OndraSter> yeah, those are the only ones I can move up a bit
[16:39:57] <Casper> OndraSter: rotate IC17 90 degree counter clockwise
[16:40:08] <Casper> you'll save a few via
[16:40:18] <OndraSter> vias are not paid extra
[16:40:19] <Valen> and with a little tweaking you could get a little more room on the othres
[16:40:23] <Valen> others
[16:40:57] <Valen> have you run a drc over it for a normal one and seen where its complaining?
[16:41:02] <bram1> moving ic19 down will save you width, but i don't know what's below it
[16:41:18] <OndraSter> the same IC
[16:41:24] <OndraSter> Valen, no
[16:41:25] <Casper> lots of unoptimised stuff there...
[16:41:38] <Valen> do that, you might be suprised
[16:41:39] <Casper> and lots of useless via due to poor part placement it seems
[16:41:53] <OndraSter> http://clip2net.com/s/1rlcw
[16:42:30] <Casper> learn to use the grid...
[16:42:48] <Valen> rotate ic9 it'll make everything easier
[16:43:03] <OndraSter> 19?
[16:43:10] <Valen> yes sorry
[16:43:14] <OndraSter> will do
[16:43:18] <OndraSter> will see :)
[16:43:50] <bram1> OndraSter: the trace on pad24 on ic19 can go up from the pad, this will save you width
[16:44:13] <OndraSter> yeah, I thought about that already
[16:44:18] <OndraSter> will see once I rotate it
[16:45:43] <vectory> whats the program?
[16:46:01] <OndraSter> Eagle
[16:47:35] <vectory> oh, only used the schematic layouter
[16:48:57] <bram1> OndraSter, is this a LED PWM PCB? At what frequency will the PWM run?
[16:49:22] <bram1> OndraSter: and what current will be drawn?
[16:49:25] <OndraSter> it will be refreshing 32 rows in total
[16:49:44] <OndraSter> 32 rows * 30 times per second probably
[16:50:00] <OndraSter> well, I am still not sure about how much current will be through the LEDs
[16:50:06] <OndraSter> if it will be about 15mA per LED
[16:50:11] <OndraSter> max of 96 LEDs lit up at once
[16:51:21] <bram1> OndraSter: can you post the schematic?
[16:51:29] <OndraSter> sure
[16:51:39] <OndraSter> as the scheme file?
[16:52:01] <bram1> thats fine
[16:53:08] <OndraSter> http://dl.dropbox.com/u/3936936/vse.sch
[16:54:00] <OndraSter> the green/red outputs from the A6275's don't match, because it would be too hard (or even impossible) to route
[16:55:47] <bram1> the mosi/rck/sck will be high speed, and the row/leds will be high current
[16:56:08] <OndraSter> I know that the row current will be rather high
[16:56:20] <OndraSter> just as the total gnd output on the A6275s
[16:56:23] <bram1> and "switchy"
[16:57:04] <bram1> OndraSter: i suggest you use a four-layer pcb for this
[16:57:09] <OndraSter> hmm
[16:57:12] <OndraSter> let me check priving
[16:57:13] <OndraSter> pricing
[16:57:40] <OndraSter> 1dm2 2layer = 500Kc
[16:57:47] <OndraSter> 1dm2 4layer = 1350CZK
[16:57:47] <bram1> a proper ground plane with local power planes
[16:58:22] <bram1> do you have a prototyping stage in you project?
[16:59:02] <OndraSter> that means?
[16:59:05] <OndraSter> free samples?
[16:59:40] <bram1> it means: build one unit that may work, and then build the one that does work
[16:59:53] <bram1> the one unit that may work is called the prototype
[17:00:01] <OndraSter> I'd like to make the 1st one 100% working
[17:00:10] <OndraSter> since one is for me for presentation and the other one is for school itself
[17:00:15] <OndraSter> I will be doing 2 copies
[17:00:33] <vectory> make the one for yourself first, or other way around?
[17:00:51] <OndraSter> doesn't matter
[17:00:56] <vectory> one prototype
[17:01:13] <vectory> and a second revision
[17:01:29] <bram1> if the numbers are low, then you should definitely go for a four layer pcb for this
[17:01:35] <OndraSter> hmm
[17:02:04] <bram1> two layers, "may work"
[17:02:19] <bram1> but only with carefull pcb design
[17:02:25] <OndraSter> the problem is, you need some kind of mask for normal PCB right?
[17:02:38] <OndraSter> with this "pool service" it is cheaper for 2 layers probably by a bit
[17:03:43] <Valen> should be able to do that in 2 layers
[17:03:48] <Valen> 4 might be better
[17:03:54] <Valen> but if 2 is good enough
[17:03:56] <vectory> just read sth about high frequencies on motherboard traces, but its in german and doesnt mention width or corners, but wave impedance and wave lengths ... 50 mhz has a wave length of 4+ m
[17:04:08] <OndraSter> aww german :D
[17:04:10] <Valen> what speed is the bus?
[17:04:17] <OndraSter> the SPI will go on about... 4MHz tops
[17:04:22] <OndraSter> I can actually clock it at low speeds
[17:04:25] <OndraSter> doesn't really matter
[17:04:32] <bram1> 2 layer should be possible indeed, but without a prototyping stage, it may "not" work
[17:04:43] <OndraSter> since I can be sending there data at slow speed and then flip it all at once at proper time
[17:04:49] <bram1> and considering the very poor layout...
[17:05:18] <OndraSter> consider poor student :D
[17:05:31] <Valen> seperate the spi from your power switching and it should be ok
[17:05:34] <Valen> what length?
[17:05:43] <bram1> you can take a gamble, and hope it works
[17:05:59] <OndraSter> length of the traces? few cm
[17:06:07] <OndraSter> whole board will be < 20x20cm hopefuly
[17:06:10] <bram1> just be sure to use is with a proper power supply, and only at room temperature, with no physical stress
[17:06:16] <OndraSter> hmm
[17:06:30] <OndraSter> damn you bram1, now I will have to be thinking about it whole night and won't fall asleep :(
[17:06:33] <OndraSter> lol
[17:06:43] <bram1> OndraSter: sorry
[17:06:51] <OndraSter> just kidding, I am glad somebody looked on it
[17:06:55] <Valen> you don't have bypass caps on anything
[17:07:09] <OndraSter> Valen, they are there, not sure if they are on schematics
[17:07:12] <Valen> you will need them on something like that
[17:07:17] <Valen> they arent on the pcb
[17:07:19] <OndraSter> oh
[17:07:29] <OndraSter> they are prepared on the top of the board
[17:07:31] <bram1> Valen: he has it on the vcc/gnd of the mcu :)
[17:07:33] <OndraSter> waiting to be placed
[17:07:50] <Valen> he needs 1 or 2 on each of the drivers
[17:08:24] <bram1> true, and i think they should not be trough hole
[17:09:27] <OndraSter> 4 layout PCB would ease wiring up the drivers a lot, now I have it wired up in really bad way - G0 R0 G4 R4 G1 R1 G5 R5 etc
[17:09:30] <OndraSter> columns
[17:09:38] <OndraSter> so the data would be sent there really weird
[17:10:04] <bram1> i would bypass the drivers with a 100nF and a 22uF
[17:10:10] <Valen> given the current I'd be tempted
[17:10:14] <Valen> yeah about that lol
[17:10:39] <Valen> though I'd be tempted to put the 100nf on each IC and something like a 100uf for each group
[17:11:15] <bram1> OndraSter: when using 4-layers (low volume), the inner layers are typically only used for power stuff
[17:11:23] <OndraSter> hmm
[17:11:57] <OndraSter> the LED drivers are switching to 0 (active low)
[17:12:12] <OndraSter> they won't be draining any more power... I think
[17:13:13] <bram1> OndraSter: but the LED's are
[17:13:21] <bram1> when switched on
[17:13:37] <OndraSter> ye, then there should be big cap on the power at the MOSFETs
[17:13:59] <bram1> and the A6275 too
[17:14:05] <Valen> thats what I was talking about bypassing
[17:19:57] <OndraSter> why wouldn't I be able to use the middle planes for anything other than power? :/
[17:21:55] <bram1> OndraSter: you can use it for something else, but it is much easier to "debug/cut traces" the hw when you can reach it, and the capacitance between the internal layers will be max. when you use it for power only
[17:22:09] <OndraSter> oh
[17:25:35] <OndraSter> hmm I think my teacher made a mistake when he was counting the pricing
[17:25:48] <OndraSter> creating the photo stuff on the plotter is not 400 CZK/dm2
[17:25:49] <OndraSter> but 40
[17:42:48] <OndraSter> well, thanks for all the stuff bram1 Valen and others, will be back tomorrow! :D
[19:02:59] <Tom_itx> amee2k, find the help you needed?
[22:26:15] <AuroraX> hi
[22:27:41] <AuroraX> im using AVR with arduino/atmega328, im trying to read the values from PB5, but im getting always HIGH... what's wrong here?
http://pastebin.com/qebyZ4Ey
[22:33:04] <Tom_itx> #define IsHigh(BIT, PORT) ((PORT & (1<<BIT)) != 0)#define IsLow(BIT, PORT) ((PORT & (1<<BIT)) == 0)
[22:34:33] <abcminiuser> Wow, that code will be terribly inefficient
[22:34:35] <Tom_itx> #define ClearBit(BIT, PORT) PORT &= ~(1<<BIT)
[22:34:47] <abcminiuser> AuroraX's, not yours Tom_itx
[22:35:16] <Tom_itx> it's arduino gobldegood
[22:35:17] <Tom_itx> k
[22:35:36] <Tom_itx> gobldegook
[22:36:45] <Tom_itx> or at least it looks like it
[22:37:19] <AuroraX> Tom_itx: same behaviour
[22:38:05] <AuroraX> can it be the way im receiving PORTB as argument?
[22:38:16] <Tom_itx> read the port with PINx
[22:38:18] <AuroraX> i cast them as unsigned char
[22:38:31] <AuroraX> Tom_itx: im doing it already, look
[22:38:42] <Tom_itx> you don't need to as it's done in the 328 header for you
[22:39:13] <AuroraX> http://pastebin.com/qebyZ4Ey
[22:39:29] <AuroraX> im reading from PINB, and im passing a pointer to it
[22:39:43] <AuroraX> and casting it as unsigned char*
[22:40:12] <timemage> AuroraX, what was it to begin with?
[22:40:17] <AuroraX> Tom_itx: what's done in the header? i was trying not to relly on the 328 library too much, just to get the feel of things here
[22:41:11] <AuroraX> timemage: what was what? PINB type? I dont know, i never knew, i always used it with macros, this is the first time i need to pass PINB as argument, so i dont know what type should it be
[22:42:17] <Tom_itx> PINB is a bit value i believe
[22:42:19] <AuroraX> this is my full code:
http://pastebin.com/Y6Y1XF37
[22:42:42] <Tom_itx> #define PINB _SFR_IO8(0x03)
[22:42:43] <Tom_itx> #define PINB0 0
[22:42:43] <Tom_itx> #define PINB1 1
[22:42:43] <Tom_itx> #define PINB2 2
[22:42:48] <AuroraX> the setters work very well
[22:42:52] <AuroraX> the getters dont
[22:42:52] <Tom_itx> from io328p.h
[22:43:08] <timemage> don't have my dev environment on this machine.
[22:43:12] <AuroraX> what's _SFR_IO8(0x03) type?
[22:45:05] <AuroraX> what im doing is basically setting one pin's DDR to 0 and then this: isHIGH(PINBx & (1<<x)), where x is that pins number
[22:45:07] <AuroraX> ops
[22:45:09] <AuroraX> wait
[22:45:10] <AuroraX> no
[22:45:12] <Tom_itx> i'm not sure where that's defined but it's an 8bit port
[22:45:15] <AuroraX> what im doing is basically setting one pin's DDR to 0 and then this: isHIGH(PINB & (1<<x)), where x is that pins number
[22:45:55] <AuroraX> isHIGH does the same as Tom_itx 's
[22:55:01] <timemage> AuroraX, so, how do you know that this part of the code is the problem?
[22:55:37] <AuroraX> timemage: this whole file?
[22:55:59] <timemage> well, i'm looking at two functions. if that's the whole file, then yeah.
[22:56:29] <AuroraX> its the onlyone im using, the other one is just a main that uses those function:
http://pastebin.com/ScWfuv2k
[22:56:42] <AuroraX> timemage: the whole file is this
http://pastebin.com/Y6Y1XF37
[22:57:01] <AuroraX> basically it has getters and setters for those ports
[22:57:07] <AuroraX> setters work very well
[22:57:11] <AuroraX> getters, not so much
[23:00:21] <timemage> AuroraX, you're bit banging spi?
[23:00:27] <AuroraX> no
[23:00:40] <AuroraX> im just using them because i will use spi, but not that way
[23:00:51] <AuroraX> now im just trying to do basic stuff
[23:00:57] <AuroraX> reading and writting to ports
[23:01:02] <timemage> ok.
[23:01:55] <timemage> AuroraX, so i take it you know this isn't working simply because you're watching the mosi line and seeing that it isn't changing.
[23:02:25] <AuroraX> no
[23:02:33] <AuroraX> im looking to see the value of MISO
[23:03:10] <AuroraX> if get_SPI_MISO() return HIGH, then ill change the value of MOSI to LOW, (MOSI is connected to MISO), so MISO will be LOW next iteration of that while(1)
[23:04:05] <AuroraX> and the SPI_SCK is just to control the led
[23:04:22] <AuroraX> for me to see, if MISO is HIGH, led lits, else it turn off...
[23:04:31] <AuroraX> well.. omg... im not turning it off...
[23:04:49] <AuroraX> OMG
[23:04:55] <timemage> don't follow that at all. but i take it you see where i was headed.
[23:04:56] <AuroraX> that was it -_-"
[23:05:01] <timemage> good deal.
[23:05:23] <AuroraX> you see, the led from SPI_SCK should lit and unlit according to MOSI input value
[23:05:35] <AuroraX> but i forgot to make it unlit, so MOSI was "always true"
[23:05:43] <AuroraX> i hate low level debugging lol
[23:05:50] <AuroraX> thank you guys, sorry for this
[23:05:56] <timemage> which is why i ussmed you were using MOSI to test. since it's mosi that actually changes.
[23:05:58] <AuroraX> everything is working fine now :)
[23:06:05] <timemage> the only thing in your code it seems like you could test.
[23:06:16] <timemage> , .. with your code, i mean.
[23:06:34] <AuroraX> i have MOSI directly connected to MISO, so that i can test output and input at the same time
[23:06:58] <timemage> i see.
[23:07:13] <AuroraX> so my test code is as this
http://pastebin.com/cbHsQqWf
[23:07:56] <AuroraX> if MISO (that is in input mode) is HIGH, led lits (SPI_SCK) and MODI (that is giving 5v to MISO) goes LOW, else, led unlits and MOSI goes HIGH
[23:07:59] <Kevin`> AuroraX: you are going to use hardware spi after this, right?
[23:08:05] <AuroraX> yes
[23:08:31] <AuroraX> im not going to bitbang it
[23:08:37] <timemage> AuroraX, know that would have helped figure out what was going on.
[23:09:18] <AuroraX> timemage: yes, sorry, i've posted the code of that main before here, but i was focusing on the declarations' one
[23:09:42] <AuroraX> there's still one problem, my compiler warns me about the argument's im passing to those functions
[23:09:54] <AuroraX> void writeToPort(unsigned char* portRegisterDDR, unsigned char* portRegister, int bitNumber, int value)
[23:10:07] <AuroraX> where i call like this: writeToPort(&DDRB,&PORTB,PB5,V);
[23:10:22] <timemage> AuroraX, post the warning.
[23:10:32] <AuroraX> it means that im assuming that DDRB and PORTB are unsigned char
[23:10:33] <AuroraX> ok
[23:11:25] <AuroraX> http://pastebin.com/xcGGzBKJ
[23:11:25] <timemage> fairly normally for anything your perform bit manipulation on to be unsigned. i doubt the avr headers are presenting DDRB and friends as signed; that's just asking for trouble.
[23:11:51] <AuroraX> true, that's why im betting on unsigned chars, but he still complains
[23:12:26] <AuroraX> i've digged those definitions of DDRB and cia, and i cant find in AVR library what are their types
[23:12:26] <timemage> AuroraX, i would guess it's a const-correctness issue.
[23:12:37] <AuroraX> what's that?
[23:14:15] <timemage> AuroraX, actually, it looks like it's probably just missing volatile keyword.
[23:14:48] <timemage> AuroraX, try volatile unsigned char *port .... in your first param.
[23:15:33] <AuroraX> yes
[23:15:35] <AuroraX> it was it
[23:15:36] <AuroraX> thanks!
[23:15:39] <timemage> AuroraX, really the thing to do is use macros, since this is sort of overkill for an AVR. but as long as you're going to use functions you should see what the DDRB and PORTB types actually work out too.
[23:15:42] <timemage> AuroraX, ok.
[23:15:43] <AuroraX> never used volatile before
[23:16:07] <AuroraX> why is this overkill for the avr?
[23:17:11] <timemage> AuroraX, AVRs are just really small. so no need to chew up extra stack, assuming the gcc doesn't do inlining on its own. and you have the overhead of a call and return and stack manipulation where you really don't need it.
[23:18:23] <timemage> AuroraX, anyway, just keep idea of swapping this out with macros in mind for when you do run into that, if not in this code maybe in an ISR.
[23:20:34] <AuroraX> i see
[23:20:44] <AuroraX> never tought of that before
[23:20:45] <AuroraX> thanks
[23:21:06] <AuroraX> i was kinda worried about space, because inlining increases code's size i guess
[23:21:25] <AuroraX> but the stack is smaller so, priority to it
[23:21:48] <timemage> AuroraX, they made DDRB volatile to prevent the compiler from optimizing away write instructions. something that you can usually do with unshared memory, not such a good idea with memory mapped registers.
[23:22:13] <Kevin`> AuroraX: flipping a bit on a port is usually a single cpu instruction, and would be smaller inline
[23:24:22] <AuroraX> what if instead of doing void function blabla() { ... } do inline void function blabla() { ... }
[23:24:30] <AuroraX> will it do the same as the macros?
[23:24:43] <AuroraX> or stack will still be used to separate scopes?
[23:25:48] <timemage> AuroraX, it's a suggestion to the compiler. it may do that. but it will probably also keep a copy of the function in rom just in case you want to form function pointers to it. for something like bit manipulation on a small 8bit microprocessor you're just better off with macros.
[23:26:25] <AuroraX> ok
[23:26:32] <timemage> AuroraX, you can compile to assembly with optimization turned on if you're curious about it will do in one case.
[23:26:54] <AuroraX> i started with macros, but i started having problems with nested macros
[23:27:00] <AuroraX> they weren't working
[23:27:11] <AuroraX> so i used functions like i have now
[23:27:24] <AuroraX> how do i should nest macros?
[23:28:01] <timemage> AuroraX, you just have them invoke each other. if you dig through the avr headers you should see examples of it .
[23:28:41] <AuroraX> i had something like #define max(a,b) (a > b) ? a : b; then #define doubleMax(a,b) 2*max(a,b); and it would complain about max(a,b) not being defined
[23:28:42] <timemage> AuroraX, also you might want to learn how to use -E or the cpp command so you can see what the header stuff is expanding to in your code.
[23:29:54] <timemage> AuroraX, not sure why that would be. have to be careful about parameterized macros though. may want to surround 'a' and 'b' with paren in case you hand a more compilcated expression to them that upsets the operator precedence.
[23:30:58] <timemage> AuroraX, 2*max(ab) become 2*(a>b)?a:b right? which means a>1 gets multiplied by 2 before ?: is evaluted,. at least that's what i look like a cursory glance.
[23:31:30] <timemage> AuroraX, i meant a>b gets multiplied by 2.
[23:31:40] <AuroraX> hmmmm
[23:32:01] <AuroraX> i see, what a raw replacement
[23:32:04] <AuroraX> lol
[23:32:05] <timemage> AuroraX, when in doubt add more paren. around the whole thing and around each use of param.
[23:32:28] <timemage> AuroraX, the paren themselves don't cost anything on any sane compiler.
[23:33:42] <AuroraX> 2*(4 > 3) ? 4 : 3;;;
[23:33:51] <AuroraX> returns this, you're right
[23:34:04] <timemage> AuroraX, 4>3 field 1 1* 2 is 2 so the answer is 4
[23:34:06] <AuroraX> i did the preprocessing
[23:34:12] <AuroraX> yes
[23:34:13] <AuroraX> lol
[23:34:34] <AuroraX> this -E flag is quite amazing
[23:34:38] <timemage> AuroraX, yup. the macro preprocessor in C is pretty crufty.
[23:34:39] <AuroraX> much to learn from it
[23:35:22] <AuroraX> # 99 "c:/winavr-20100110/lib/gcc/../../avr/include/avr/io.h" 3
[23:35:28] <AuroraX> # 37 "c:/winavr-20100110/lib/gcc/../../avr/include/inttypes.h" 3
[23:35:33] <AuroraX> this includes are curious
[23:35:50] <timemage> why's that?
[23:36:59] <AuroraX> that # 99
[23:37:03] <AuroraX> and the ending 3
[23:37:17] <timemage> yeah, that's to help sort out line numbers later.
[23:37:56] <AuroraX> it will read only from 99 ahead?
[23:38:08] <AuroraX> there are many files that start at 99
[23:38:11] <AuroraX> others at 1
[23:38:25] <AuroraX> # 1 "c:/winavr-20100110/lib/gcc/../../avr/include/avr/portpins.h" 1 3 this one end with 1 and 3
[23:39:00] <timemage> i've forgotten exactly how to read them. in short, they need to keep track of lines for later stages of the compiler and linker. otherwise diagnostics wouldn't have as much to go one, debug source data would be wrong etc.
[23:39:58] <AuroraX> i see
[23:40:01] <AuroraX> this is very cool
[23:40:41] <AuroraX> (*(volatile uint8_t *)
[23:41:00] <AuroraX> according to him, this is the correct type of those DDRB, PORTB, PINB etc
[23:41:21] <AuroraX> even that information we can get by preprocessing this
[23:41:22] <AuroraX> amazing
[23:41:49] <timemage> well, yeah. you have to careful reading too much into the output of the preprocessor. sometimes the official way to do something is with a macro that could change in future versions, etc.
[23:42:00] <timemage> but it's good to be able to look at it to see what's happening.
[23:45:31] <timemage> in case you're wondering, uint8_t is going to be a typedef for unsigned char or something similar. you should be able to find the typedef for it somewhere in the piles of -E/cpp output.
[23:48:26] <AuroraX> makes sense
[23:48:53] <AuroraX> it worked with unsigned char
[23:49:12] <AuroraX> this is amazing
[23:49:20] <AuroraX> great tool this preprocessing
[23:49:28] <timemage> heh
[23:51:53] <AuroraX> well, 6AM here
[23:51:57] <AuroraX> need to rest lol
[23:52:03] <AuroraX> it has been a long night
[23:54:12] <AuroraX> thank you for your help ;)
[23:55:05] <timemage> n.p.
[23:58:27] <AuroraX> ;)
[23:58:31] <AuroraX> see ya around :)