Back
[01:30:43] <Flipp_> got a quick question on TWI control registers if anyone around knows about it
[01:34:06] <rue_house> oh whats the question
[01:34:18] <rue_house> Flipp_, knock knock
[01:34:52] * Casper knocks on rue_house's door
[01:35:02] <Casper> did you used a tiny85 timer1?
[01:35:22] <rue_house> no, if you give me some tiny85, I can try
[01:35:33] <rue_house> I'll give you the useless tiny13 I have instead
[01:36:35] <rue_house> well they aren't useless they are great for some things that could be done with a lot of fuss with a 556
[01:36:46] <Casper> hehe
[01:38:22] <Casper> ow well, I'll just continue to code, and hope for the best :D
[01:40:51] <Flipp_> rue_house: sorry, was outta the room :)
[01:41:17] <Flipp_> rue_house: so I'm looking at the start of I2C protocol, and I see that the start condition starts with
[01:41:22] <Flipp_> TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);
[01:41:35] <Flipp_> then most libraries/examples wait until the transmission is completed
[01:41:39] <Flipp_> while(!(TWCR & (1<<TWINT)));
[01:41:50] <Flipp_> the while condition seems odd to me though
[01:42:04] <Flipp_> the first line sets the TWINT bit of TWCR to 1
[01:42:20] <rue_house> ah
[01:42:34] <rue_house> master or slave library?
[01:42:51] <Flipp_> why does the loop condition wait until the TWINT bit of TWCR go to one, when it seems it's immediately set?
[01:42:56] <Flipp_> mostly master implementations
[01:44:00] <Flipp_> I feel like TWCR = (1<<TWINT) followed by while(!(TWCR & (1 << TWINT)) means the latter immediately falls through as a nop?
[01:44:51] <Flipp_> example is the Fleury library's twimaster.c, i2c_start()
[01:45:42] <Flipp_> the datasheets suggest "this bit is set by hardware", so I'm not sure why we're setting it in software...?
[01:46:33] <Flipp_> oh, nevermind, apparently "set" = 0 in this case... duh.
[01:46:44] <Flipp_> still doesn't really 'splain the loop condition though O.o
[01:53:04] <markm_> does anyone know who coded this divide routine?
[01:53:05] <markm_> http://www.avrfreaks.net/forum/asm200-maths-apnotes?name=PNphpBB2&file=viewtopic&t=4716
[01:53:11] <markm_> its a bit STUPID in one regard
[01:53:29] <markm_> divide a 32 bit number by a 16 bit number and you CNNOT ever have more than 16 bits of remainder
[01:53:57] <markm_> this computes a 32 bit remainder so is wasting clock cycles on bit shifting remainder3 and remainder4
[03:18:11] <Flipp_> rue_house: *poke* I gotta head out soon, just curious if you had any insight
[03:27:17] <rue_house> master or slave library?
[03:33:23] <Flipp_> rue_house: master
[03:35:56] <rue_house> when I was trying to do this there was flakeyness
[03:36:23] <rue_house> are you having problems where under certian situations the i2c bus will jam up?
[03:37:37] <rue_house> goodnight
[03:37:51] <Flipp_> rue_house: erm, haven't gotten that far yet :) only just trying to understand why in one line they set TWINT, then the very next line they loop until it's set
[03:38:01] <Flipp_> rue_house: 'night :) thanks though
[04:03:47] <markm_> flipp rhats obviously a bug
[04:04:22] <markm_> it should clear the flag.
[04:04:44] <markm_> clear interrupt flag. wait for an incoming char to set it... process char
[04:04:50] <markm_> interrupt never actually happens
[04:05:01] <markm_> its a crappy way to do serial recieve
[04:05:27] <markm_> poor mans isr with no isr
[04:06:09] <Flipp_> markm_: I see it all over though: TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN) followed immediately by some variation on while ((TWCR & (1<<TWINT))==0)
[04:06:48] <Flipp_> doesn't setting TWCR |= 1 << TWINT make the TWCR & (1 << TWINT) evaluate to nonzero
[04:06:52] <Flipp_> making the loop immediately exit?
[04:07:05] <markm_> let me double check that
[04:07:08] <Flipp_> (idle looping is not efficient bit shifting, sure)
[04:07:28] <Flipp_> just wondering if the TWINT bit is somehow toggled between those two lines
[04:07:42] <Flipp_> e.g. by hardware when it detects the TWSTA bit is set
[04:08:25] <markm_> rtfm a sec
[04:09:24] <Flipp_> markm_: k. I mean that's how Fleury's I2C library has it so it must be "right". just trying to see why it's that way, since it doesn't make sense to me from the datasheet
[04:10:53] <markm_> wirting 1 to the int bit clears that flag
[04:11:08] <markm_> abit 7 - atwi interrupt flag
[04:11:22] <markm_> this bit is set by hardwae when the TWI has finished its current job
[04:11:29] <markm_> and expects application software response.
[04:11:45] <markm_> if the I-bit in the SREG and TWIE in TWCR are set, the mcu
[04:12:07] <markm_> will jump to the TWI interrupt vector. While the TWINT flag is set, the SCL low period is stretched.
[04:12:25] <markm_> Th TWINT flag must be cleared by software by writing a logic 1 tyo it
[04:12:40] <markm_> stooy, cat was helping me type :)
[04:12:56] <markm_> sorry even
[04:13:23] <markm_> halp! im under a cat!
[04:13:55] <markm_> that was from the 32u4 doc
[04:16:10] <markm_> the lib obviously has the global interrupt flag disabled and is effectivly POLLING
[04:16:16] <markm_> pure suckage
[04:16:26] <Flipp_> markm_: okay, that jives with the 2560 doc
[04:16:56] <markm_> i would assume all avrs have the same i2c :)
[04:17:02] <Flipp_> markm_: so I think I understand the polling part
[04:17:12] <Flipp_> but after the TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN) line
[04:17:14] <markm_> its really cheap and easy
[04:17:31] <Flipp_> TWCR = 0b10100001
[04:17:31] <markm_> that initiates a start
[04:17:39] <Flipp_> then the next line is the while loop
[04:17:54] <Flipp_> which tests if TWCR & 0x01000000 == 0
[04:18:22] <Flipp_> oops, sorry
[04:18:28] <Flipp_> 0x10000000
[04:18:38] <markm_> can you break those up into 4 bit chunks lol
[04:18:43] <Flipp_> haha
[04:18:44] <Flipp_> sure :)
[04:19:02] <Flipp_> TWCR = 0b1010 0001 after that set line (according to the docs)
[04:19:04] <Flipp_> then it's
[04:19:23] <Flipp_> while ((TWCR & 0b1000 0000) == 0)
[04:19:38] <Flipp_> which becomes
[04:20:02] <Flipp_> while ((0b1010 0001 & 0b1000 0000) == 0)
[04:20:10] <markm_> what are you using to debug? could be you writing that start pulse got you some incoming data BEFORE you could re-read that control register
[04:20:12] <Flipp_> which becomes (0b1000 0000 == 0)
[04:21:24] <Flipp_> markm_: not debugging anything yet :) just trying to understand the sequence before I use it :)
[04:21:49] <markm_> then how do you know the register has that value in it after a write?
[04:22:13] <Flipp_> I thought the line TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN)
[04:22:15] <Flipp_> set it
[04:22:16] <Flipp_> ?
[04:22:52] <markm_> setting that bit CLEARS it :)
[04:23:13] <Flipp_> err, okay, so it clears it
[04:23:15] <Flipp_> :)
[04:23:21] <Flipp_> then the condition for the while loop
[04:23:58] <Flipp_> seems to indicate to idly loop until the bit flips from 0 to 1... but it is already 1?
[04:24:14] <markm_> no its 0
[04:24:21] <markm_> wite a 1 to it and it becomes a zero
[04:26:07] <markm_> i know.. sounds weird lol
[04:26:09] <Flipp_> I....
[04:26:10] <Flipp_> hmm...
[04:26:21] <Flipp_> hahaha, yeah, I'm tryin' to wrap my head around that one...
[04:26:21] <Flipp_> :)
[04:26:35] <markm_> just trust that to CLEAR that bit you have to write a ONE to it
[04:27:03] <Flipp_> okay. in that context I ... guess it makes sense
[04:27:04] <Flipp_> ?
[04:27:07] <Flipp_> haha
[04:27:50] <Flipp_> I thought by "setting it means clearing", i just assumed it meant the 0/1 logic was swapped
[04:28:09] <Flipp_> not that writing a 1 to the register meant it actually turned the register bit to zero
[04:28:15] <Flipp_> which... ... ... ow my brain D:
[04:28:17] <markm_> on a vga (ye olde vga) you would write values into color registers and mask registes then you would do a dummy write to the vga memory
[04:28:28] <markm_> didnt matter what value you wrote, it was never stored there
[04:28:40] <markm_> the values in the registers defined what colors got written to what pixles
[04:29:36] <markm_> actually, you did a dummy read then a dummy write? i ferget
[04:30:01] <Flipp_> hm... I remember reading somewhere that VGA was loosely based on (or the parent of) i2c?
[04:30:29] <markm_> i doubt it :)
[04:30:40] <markm_> vga = video graphics array
[04:30:57] <markm_> i2c is phillips 2 wire serial transfer
[04:31:13] <markm_> i was just commenting on a similar scenario
[04:31:31] <markm_> writing X to video memory does not write X to video memory (depending on mode that is)
[04:33:29] <Flipp_> huh. I thought they were all based on DDC, which in turn was based on I2C. guess I got more readin' to do :)
[04:33:39] <Flipp_> they = VGA, DVI and HDMI
[04:34:17] <Flipp_> alright, got some thinkin' to do
[04:34:21] <Flipp_> bedtime for me
[04:34:26] <Flipp_> thanks for the clarification!
[04:35:03] <markm_> i2c was developed in 1982
[04:35:09] <markm_> vga i think is older
[04:35:37] <markm_> maybe not! lol
[05:05:02] <Xark> Flipp_: I think I2C was added later to VGA spec so monitor can tell VGA card its capabilities (and do power save). Before that it was manual (and it was possible to damage monitor with wrong settings).
[05:05:22] <Xark> VGA DCC, IIRC
[05:07:26] <Xark> (this is how people e.g., reprogram a BIOS flash with VGA connector). :)
[05:07:41] <specing> damage the monitor? How?
[05:08:11] <specing> unless you purposefully made a controller that fires electrons into one single point... but even then
[05:08:23] <markm_> it was not only possible to damage the video monitor but the video card and the computer it was connected to
[05:08:30] <Xark> specing: Early CRTs could get damaged running at wrong frequency. The DCC channel was also very handy to show user a list of working modes (as opposed to "try" all possible modes).
[05:08:42] <markm_> and you could do it by simply writing bogus values into the CRTC registers
[05:09:39] <Xark> Later, monitor timing got programmable, so the monitor could ignore bad modes, but early on, there was no "smarts".
[05:10:05] <markm_> making michale abrash VERY brave lol
[05:10:09] <markm_> mode x ftw
[05:10:12] <Xark> :)
[05:11:09] <Xark> I believe he is still working at the games research division of Microsoft. :)
[05:11:22] <markm_> yes. he moved from ID to MS :)
[05:12:34] <Xark> Yep. I've read some white papers from him fairly recently.
[06:59:33] <EI24> Hi, im trying to switch a LED on and of repeatedly in a pattern, using a timer. However the LED just stays on. any ideas why?
http://pastebin.com/US7tEPxG
[07:05:13] <specing> you are using pastebin.com
[07:09:23] <EI24> specing: should i not?
[07:12:34] <specing> you shall not
[07:13:15] <specing> well you can, but some of us wont open the links unless something really interesting lurks in them
[07:14:08] <runde> Should he just paste it here instead?
[07:14:54] <specing> pastebin.com is not the only pastebin around
[07:15:14] <specing> but it is arguably the worst pastebin around
[07:18:06] <RikusW> which is better ?
[07:19:45] <EI24> So, i should use paste sites, but not specifically pastebin.com?
[07:20:21] <specing> yes, avoid pastebin.com like the plague
[07:22:18] <specing> gist.github.com is good
[07:23:42] <specing> https://paste.debian.net
[07:24:35] <EI24> ok, sure x) seems ridiculous to me but, does not matter if it gets the job done
[07:24:40] <specing> It is pretty hard to find a pastebin that has: HTTPS, highlighting and is simple looking without ads and javascript and whatnot
[07:25:35] * RikusW disables images and got noscript installed
[07:25:44] <RikusW> and addblock too
[07:26:02] <RikusW> adblock pluse
[07:26:04] <RikusW> -e
[07:26:10] <Xark> hastebin.com isn't too bad
[07:26:34] <Xark> Supports avr asm highlighting too. :)
[07:33:50] <specing> No https
[07:34:02] <specing> and wants javascript
[07:34:13] <RikusW> why do you need https ?
[07:34:18] <specing> why not?
[07:34:39] <RikusW> since its public anyways there is no point in having https
[07:35:02] <specing> there is
[07:35:12] <Xark> It supports https, just has a bogus cert (so generates warning).
[07:35:14] <RikusW> js otoh tends to annoy me
[07:35:39] <specing> RikusW: with https, mitm cannot know what you looked at
[07:36:13] <RikusW> specing: if it is innocent code who cares ?
[07:36:29] <specing> How do you know it is innocent until you see it?
[07:36:48] <RikusW> I'd suppose most code in here is
[07:36:50] <specing> or how do you know it is innocent before you post it?
[07:37:11] <specing> Do you know all the laws in your country?
[07:37:21] <RikusW> its not like someone will post top secret stuff publicly...
[07:37:26] <RikusW> nope
[07:37:27] * Xark adds another layer of tin-foil to his hat...
[07:37:41] * RikusW lost his tinfoil hat :-D
[07:38:39] * RikusW goes to post a 50 shades chapter on hastebin :-P
[07:40:02] <specing> RikusW: have a nice read of this:
https://falkvinge.net/2012/07/19/debunking-the-dangerous-nothing-to-hide-nothing-to-fear/
[07:40:27] <RikusW> ok
[07:42:27] <specing> The "You have nothing to fear, you have nothing to hide" is widely attributed to the nazi propaganda minister
[07:42:49] <specing> We in Europe in particular know how that ended up being for those boarding the trains
[07:46:53] <Xark> However, doesn't mean you have everything to hide. :) I use https everywhere, noscript etc,. But I do use some pastebins on IRC.
[07:47:17] <specing> you should hide as much as possible
[07:47:31] <RikusW> specing: valid and somewhat scary article indeed
[07:47:31] <specing> even if you think that piece of information is harmless
[07:48:45] <RikusW> I can't imagine how pasting some code can cause harm, unless its of the dvdcss type....
[07:49:04] * Xark still has an "illegal" T-shirt...
[07:54:40] <specing> RikusW: article point 2...
[07:56:03] <RikusW> it shows just how stupid things can get.....
[07:56:10] <RikusW> unfortunately
[08:39:17] <megal0maniac> Xark: I want one too
[08:39:37] <Xark> megal0maniac: I believe mine was from EFF...
[08:41:12] <megal0maniac> Illegal t-shirt. I just like the sound of that :)
[08:42:00] <Xark> https://www.cs.cmu.edu/~dst/DeCSS/Gallery/tshirt_back.jpg
[08:42:57] <Xark> However, might not be illegal anymore...
http://yro.slashdot.org/story/00/08/01/129205/if-you-can-put-it-on-a-t-shirt-its-speech
[08:43:46] * Xark is glad he didn't get the tattoo...http://www.cypherspace.org/adam/rsa/tattoo3.jpg
[09:19:25] <DKordic> EI24: Why don't You ``.include "atmega328p"''? All of those comments would be in register names :D . Are You sure OUT expects IO address space and not Data address space (depends on __assembler__)?
[09:20:22] <DKordic> s/328p/328p.def.inc/
[09:31:26] <EI24> DKordic: I thought that i would think it would be easier to work with the adresses in hex instead of keyword. Maybe i will try using the inc file in the future. :) Ok, i will check, that i read in the data sheet i think it was(or some tutorial) that the I/O instructions, addresses I/O regs from 0x00-0x3F, but in otherwise from 0x20-0x5F
[09:33:54] <DKordic> EI24: How is it easier? I have no idea what is it doing. I even have to __disassemble it__.
[09:34:49] <DKordic> BTW "Intel HEX" file format is irelevant.
[09:38:22] <EI24> its just how i think, i find it easier to think in number. Though i have not tried using the inc file, maybe it will be easier. when addresses and data are in hex, there is a clear distinction between instructions and data/addresses
[09:44:21] <LeoNerd> So.. I measured my PCB yesterday. The plain traces on the XTAL lines measure 5pF on one side and 9pF on the other; added to the 18pF crystal load caps, that makes 23pF and 27pF - asymmetric. Would that be sufficient to skew the timing..?
[09:51:30] <EI24> DKordic: I think OUT expects IO addresses, because i tried to this: SBI 0x04 , 5 ;set data dir SBI 0x05 , 5 ;set PB reg bit 5 to 1
[09:51:34] <EI24> And it worked
[09:56:05] <DKordic> EI24: k. Interesting decisions. How do You burn devices? avrdude?
[09:56:53] <Fleck> matches
[13:38:41] <DKordic> EI24: There is no trace of interrupts in Your code.
[13:43:06] <EI24> DKordic: yes i use avrdude. If i check the TIFR continuously, is there still a need for interrupts?
[13:44:51] <DKordic> EI24: R0 and R1 are used before initialization!
[13:47:31] <DKordic> Use better names for registers. ``tmp'' is still better than ``r0''.
[13:48:04] <Tom_itx> it tells you it's expendable
[13:48:19] <Tom_itx> poor but still..
[13:49:24] <EI24> oh, ok.. Did not know that. so i cant use r0 and r2?
[13:49:36] <EI24> r0 and r1*
[13:49:41] <EI24> at all
[13:49:53] <DKordic> Of course You can.
[13:50:29] <DKordic> AFAIK You can even use numbers. Like 0 instead of r0 and so on.
[13:51:44] <DKordic> EI24: You still have not explained uninitialized registers R0 and R1.
[13:52:47] <DKordic> EI24: You can also ask simulator why program is not working as You would like.
[13:56:30] <EI24> DKordic: Ok, thanks! I will use a simulator, though simulavr(think it was called) didnt work so well for me. What is initialize, Cant i just load numbers into registers?
[13:57:36] <DKordic> EI24: Yes. You initialized only R16.
[13:59:08] <DKordic> On some devices, PORT bits can be toggled by writting to RIN register.
[14:00:22] <EI24> ohh, i think i understand now, i need to put i value into each regs when i use them. But, dont they have 0 as default value?(cleared)
[14:00:36] <DKordic> EI24: Your procedures fnc, subfnc0 and subfnc1 all together simply toggle bit 5 of port A.
[14:01:20] <DKordic> IDK. Perhaps GPRs do.
[14:03:19] <DKordic> EI24: cpse is a race condition! That test will not be executed for every value of counter.
[14:03:41] <DKordic> Use less than.
[14:04:36] <DKordic> EI24: Have You done busy wait pause?!
[14:06:10] <EI24> Dkordic: hmm, ok that must be it then.. X)
[14:06:33] <EI24> I will, rewrite the program, and check if it works. What simulator do you use?
[14:09:40] <EI24> DKordic: srry if dont follow you but, what is busy wait pause?
[14:13:13] <EI24> yes, register that is loaded with TIFR, does not get cleared.. So it just puts the LED on, then goes in a infinite loop..
[14:14:00] <DKordic> Why are You using counter?
[14:16:31] <DKordic> I still haven't searched enough for a simulator :) .
[14:22:48] <DKordic> EI24: Create a procedure, called ``wait'' or ``pause'', that will waste 1 second. Then improve it with timer/counter interrupts.
[14:23:57] <DKordic> (first version should use
http://en.wikipedia.org/wiki/Busy_waiting loop)
[14:25:49] <DKordic> Like ``clr count; loop: dec count; brne loop''.
[16:16:49] <Tekkkz> Hey!
[16:17:37] <Tekkkz> im programming my led matrix with two 74hc595, works great, but at the define of the letters something went wrong, donno why, maybe im an idiot
[16:17:53] <Tekkkz> http://ix.io/gNy
[16:17:55] <Tekkkz> my define
[16:18:04] <Tekkkz> abc.h:5:15: error: expected expression before '{' token
[16:18:06] <Tekkkz> # define H { \
[16:18:08] <Tekkkz> ^
[16:18:10] <Tekkkz> the error
[16:18:17] <Tekkkz> i dont understand what's wrong
[16:18:50] <Lambda_Aurigae> do you have the whole file?
[16:18:50] <tpw_rules> you can't have a tab there
[16:18:58] <Lambda_Aurigae> oh..yeah
[16:18:59] <tpw_rules> it has to be like #define
[16:19:06] <Lambda_Aurigae> # define is different from #define
[16:19:41] <Tekkkz> oh jes?
[16:19:47] <Tekkkz> whats the difference?
[16:19:56] <Lambda_Aurigae> #define is a keyword...one word.
[16:19:58] <Lambda_Aurigae> # define
[16:20:05] <Lambda_Aurigae> is two tokens...two keywords.
[16:20:48] <tpw_rules> also λ aurigae, he already pasted the file
[16:20:57] <Tekkkz> hm i dont understand this
[16:21:30] <tpw_rules> a space separates words
[16:21:34] <tpw_rules> so #define means one thing
[16:21:45] <tpw_rules> but # define is the words #, then define
[16:21:50] <tpw_rules> which doesn't mean anything useful
[16:22:00] <Tekkkz> hm, but if i remove the tab, same error
[16:22:39] <tpw_rules> #define H {
[16:22:52] <tpw_rules> it may have been the two spaces in between define and H
[16:23:06] <Tekkkz> ahh
[16:23:08] <Tekkkz> wait
[16:23:23] <Tekkkz> nope
[16:23:36] <tpw_rules> can you re-paste the fixed file?
[16:23:45] <tpw_rules> the whole file, don't only paste bit
[16:24:14] <Tekkkz> http://ix.io/gNA
[16:26:02] <tpw_rules> it works for me
[16:27:08] <Lambda_Aurigae> do you have other files with other letters defined?
[16:27:11] <Tekkkz> http://pastebin.com/raw.php?i=yaHiXm46
[16:27:20] <Tekkkz> nope i dont have
[16:27:26] <Tekkkz> or wait
[16:27:58] <Tekkkz> no i dont have
[16:28:10] <Lambda_Aurigae> how big is your main.c ? can you post that?
[16:28:22] <Lambda_Aurigae> because it looks like something earlier.
[16:28:39] <tpw_rules> Lambda_Aurigae: i don't think the macro is being expanded properly
[16:28:41] <Tekkkz> http://ix.io/gNC
[16:28:43] <tpw_rules> he's referencing it like H[0]
[16:28:47] <Lambda_Aurigae> tpw_rules, agreed.
[16:28:54] <tpw_rules> i'm not sure that will work
[16:29:54] <Tekkkz> yes?
[16:30:06] <Tekkkz> how should it work then?
[16:30:11] <tpw_rules> i'm not sure it's legal to start an array inside a function call like that
[16:30:20] <Tekkkz> ahh
[16:30:22] <Tekkkz> hm
[16:30:34] <Tekkkz> i think it is but im not sure
[16:30:41] <tpw_rules> i bet if you replaced H[0] with {0}[0] it would have the same error
[16:31:09] <Tekkkz> uhh
[16:31:18] <Tekkkz> if i dont use H[0] in the function call
[16:31:22] <Tekkkz> ahh wait
[16:31:26] <Tekkkz> -.-
[16:31:34] <Tekkkz> H[0] is an array
[16:31:37] <Tekkkz> :D
[16:31:49] <tpw_rules> no i mean you can't put {0} in a function call
[16:31:58] <tpw_rules> but the macro syntax is confusing
[16:31:59] <Tekkkz> maybe, but wait a mom
[16:33:05] <tpw_rules> #ifndef _ABC_H_39efd53da47c40a3b17a58643cf20ae1
[16:33:05] <tpw_rules> #define _ABC_H_39efd53da47c40a3b17a58643cf20ae1 1
[16:33:06] <tpw_rules> #ifndef H
[16:33:06] <tpw_rules> #define H { \
[16:33:06] <tpw_rules> {0,1,0,0,0,0,1,0}, \
[16:33:07] <tpw_rules> {0,1,0,0,0,0,1,0}, \
[16:33:08] <tpw_rules> {0,1,0,0,0,0,1,0}, \
[16:33:17] <Tekkkz> hahaha
[16:33:24] <tpw_rules> sorry
[16:33:27] <Tekkkz> kicked out
[16:33:28] <Tekkkz> :D
[16:33:33] <tpw_rules> main.c:24:33: error: expected expression before '{' token
[16:33:33] <tpw_rules> printf("Hello, World!%d\n", {0}[0]);
[16:33:44] <tpw_rules> so it's just putting the arrow in the macro instead of in your function call
[16:34:03] <tpw_rules> Lambda_Aurigae: can you remember how to give it a name? i'm not sure
[16:34:17] <Lambda_Aurigae> I don't do defines like that.
[16:34:29] <Lambda_Aurigae> I will create a variable and build that.
[16:34:29] <tpw_rules> you probably want something like const H[][] = <stuff>
[16:34:40] <tpw_rules> but ig2g
[16:35:07] <Tekkkz> yeah, i re-configured my H
[16:35:18] <Tekkkz> http://ix.io/gND
[16:35:40] <Tekkkz> 38 uint8_t dat = H[0];
[16:35:42] <Tekkkz> 39 spi_send_data(~0b11111111, dat);
[16:35:54] <Tekkkz> but error:
[16:35:57] <Tekkkz> main.c:38:9: warning: excess elements in scalar initializer
[16:35:59] <Tekkkz> uint8_t dat = H[0];
[16:36:01] <Tekkkz> ^
[16:36:07] <Tekkkz> never had this error
[16:36:13] <Tekkkz> what is it meaning?
[16:39:16] <Lambda_Aurigae> it is a warning, not an error.
[16:39:53] <Lambda_Aurigae> http://stackoverflow.com/questions/8108416/excess-elements-of-scalar-initializer-for-pointer-to-array-of-ints
[16:53:41] <Flipp_> tekkz: you're using a compiler definition as a variable
[16:54:08] <Flipp_> tekkkz: it substitutes the array for H before compiling it
[16:54:13] <Flipp_> which means the assignment becomes
[16:54:43] <Flipp_> uint8_t dat = {0b01000010... 0b01000010}[0];
[16:55:02] <Tekkkz> hm ok
[16:55:07] <Tekkkz> whatever, im using a PROGMEM
[16:55:13] <Flipp_> and the compiler is just letting you know that all those other variables are being discarded
[16:55:33] <Tekkkz> hm ok
[16:55:39] <Tekkkz> now it makes sense
[16:56:25] <Tekkkz> but im away for today, need to going to sleep now, im coming back tomorrow to finish solving my problem (ofc now i dont need your help anymore, but thanks for the help and information) see you, bye bye good n ight
[17:14:32] <malinus> Tekkkz: stop
[17:14:35] <malinus> Tekkkz: posting
[17:14:37] <malinus> Tekkkz: code
[17:14:41] <malinus> Tekkkz: in irc
[17:14:48] <Tekkkz> ahh
[17:14:50] <Tekkkz> it isnt code
[17:14:53] <Tekkkz> its makefile
[17:14:57] <Tekkkz> echo
[21:53:36] <Casper> grrrr what did I messed up...
[21:53:42] <Casper> the 3 PWM outputs are wrong!
[21:54:44] <Tom_itx> woops
[21:56:30] <Casper> actually, 1 is right... I think
[21:57:01] <Casper> OC1B is right... and it's the one I expected to be wrong :D
[21:59:42] <Tom_itx> i forgot how to port fwd i do it so seldom
[22:03:12] <Casper> I'm also in the process of finishing to setup my workarea compilling stuff...
[22:03:18] <Casper> so now it's a bit of a pita...
[22:03:42] <Casper> come here, edit, compile, run there, flash, observe... come here, ...
[22:06:25] <Casper> really, it look like if the timer0 is not running
[22:10:42] <Tom_itx> ok that works now
[22:13:10] <Casper> https://bpaste.net/show/7c0098939de7 <=== what am I missing?
[22:13:32] <Casper> timer 1B is running at 50% as expected, timer 0A and 0B are high
[22:14:34] <Casper> oh Tom_itx... is your programmer going tristate when not in use?
[22:15:02] <Tom_itx> it may be, why?
[22:15:30] <Casper> the pin used for 0A and 0B are mosi and miso, just wondering if the programmer could cause the issue
[22:15:45] <Tom_itx> oh, i would disconnect it if you're using spi
[22:16:02] <Tom_itx> it will probably interfere with it
[22:16:44] <Casper> I disconnected, no change...
[22:17:12] <Casper> seriously, I'm starting to think I have a faulty chip
[22:17:24] <Tom_itx> check the solder joints?
[22:17:49] <Casper> breadboard
[22:17:56] <Casper> and it's a strong 1 I have
[22:18:14] <Casper> pin -> 1k -> led -> gnd
[22:18:23] <Casper> led is on 100% of the time
[22:18:25] <Casper> scope prove it
[22:18:45] <Casper> on both timer0A/B
[22:42:07] <Casper> yay!
