Back
[02:27:18] <kieran491> G'day, I am trying to use an LCD with a ILI9163C driver configuered as 4 line 'SPI' but it appears to be I2C. It has the following 4 pins Chip Select, Serial Clock, Serial Data (input/output), and Command Select. any ideas?
[02:30:23] <carabia> kieran491, the D/CX is just a toggle for whether you're sending a command or (as in, trailing a command)
[02:31:14] <carabia> Or wait yeah, you can set the SDI/O to be half-duplex I think
[02:31:26] <carabia> I completely missed your point. I've been up all night heh
[02:33:18] <kieran491> carabia, All good, I wrote the question multiple times so it probably have assed any way, So would i use the SPI or i2C peripheral or am i suppose to use something diffrent all together?
[02:49:09] <Mr_Sheesh> It sounds like it's I2C, yep
[02:52:08] <kieran491> Mr_Sheesh, What would be a sure fire way of telling, I am looking at the documentation and it is saying SPI but SCL and SDA seem like I2C :/
[02:52:39] <Mr_Sheesh> It's possible that it can use both. Have a datasheet for the LCD?
[02:53:57] <kieran491> Yeah i searched for the LCD (TD-T145T2G2360-5) and its driver (ILI9163C)
[02:54:11] <Mr_Sheesh> uC's are pretty cheap nowadays, heck hardware in general is cheap :) But if it says CS, SDA, SCL and CMD (or whatever abbrev's they use) I'd believe it and try talking I2C to it
[02:54:35] <Mr_Sheesh> Any luck finding datasheets?
[02:54:57] <kieran491> I found both data sheets and they refer to the interface as SPI
[02:57:09] <kieran491> http://www.orientdisplay.com/pdf/ILI9163C.pdf for the driver documentation
[02:57:51] <kieran491> http://www.dipmicro.com/?datasheet=DE4447-TD-T145T2G2360-5.pdf for the LCD documentation
[03:04:54] <Mr_Sheesh> Well, try talking SPI at it then? The Orientdisplay PDF, page 8, has SPI4W on the left, looks like you can pick SPI or 4wire which I suspect lets you pick I2C or SPI
[03:05:03] <Mr_Sheesh> Shows also SDA
[03:06:10] <Mr_Sheesh> And PCLK and CSX, don't know what is used for the other pin but suspect it's configured for I2C if that's how the module is labelled
[03:08:03] <kieran491> From what i can understand at the moment CSX is used to select the device as you would normally in a SPI configuration.
[03:09:32] <kieran491> I'll have to read up on the xmega peripherals more to figure out which one is better suited for this task
[03:13:25] <Mr_Sheesh> It sounds sorta messy but I2C is fast enough to do a lot :)
[03:16:21] <kieran491> Thanks for your help Mr_Sheesh, I will have to wire this badboy up and see how it goes
[03:16:41] <Mr_Sheesh> Good luck, make 'er work :)
[07:43:46] <_ami_> i am running attiny85 overclocked at 30 MHz without any problem yet. :)
[08:08:57] <antto> * famous last words
[08:28:05] <Lambda_Aurigae> does it have ADC?
[09:45:27] <_ami_> Lambda_Aurigae: ir receiver seems to work fine. did not check ADC.
[10:05:18] <_ami_> going to work on 2.2 TFT lcd screen. got it from aliexpress.
[10:05:35] <_ami_> do we have tft lcd library for AVR?
[10:05:46] <_ami_> i think its ILI9340C
[10:05:59] <_ami_> 320 X 240
[10:19:12] <_ami_> oh boy, progba is gonna join ManUtd$.
[10:19:24] <_ami_> soooo much overpriced :P
[10:31:13] <_ami_> someone already ported it for avr. nice.
http://community.atmel.com/projects/ili9341-library-drive-22-tft-displayderived-adafruit-tft-library-ili9340-type-controller
[15:18:52] <carabia> https://www.youtube.com/watch?v=WE4GDlBviqk
[15:19:22] <carabia> Ahh stuff like this. The entertainment value is higher than all of the piss-poor tv-shows they mass produce nowadays together
[15:33:12] <gambakufu> JERRY! JERRY! JERRY!
[15:34:18] <Lambda_Aurigae> sorry, don't see how that is entertaining.
[15:34:53] <Lambda_Aurigae> bunch of idiot wasteoid reporters interviewing idiot wastoid political futzes.
[15:35:56] <Lambda_Aurigae> hitting my thumb with a hammer has more entertainment value...and is less painful.
[15:36:08] <carabia> What can I say, I've never been the monty python -type.
[15:36:46] <Lambda_Aurigae> not saying that most tv shows in the last 30 years have been any better.
[15:37:12] <Tom_itx> what's tv?
[15:37:14] <Lambda_Aurigae> although I do numb my brain with one or three...in the middle of season 3 of Agents of S.H.I.E.L.D.
[15:37:29] <Lambda_Aurigae> I watch it on the second monitor on my computer while I'm doing 3 other things.
[15:38:15] <gambakufu> I applaud the effort you made when writing shield.
[15:38:21] <Lambda_Aurigae> hehe.
[15:38:32] <Lambda_Aurigae> for a scifi serial, it's not bad.
[15:38:56] <Lambda_Aurigae> dunno how it matches up with any comic books it might have come from though as I stopped reading comics when I was in grade school.
[15:40:21] <Chillum> ugh
[15:41:33] <carabia> ugh
[15:42:45] <carabia> oh gambakufu, I'd go for jerry springer over monty python hands down, any day of the week
[15:43:21] <carabia> just a random thought.
[16:09:32] <eszett> hi! I have a question.
[16:09:54] <Lambda_Aurigae> don't we all?
[16:10:03] <eszett> ye
[16:10:23] <antto> 42
[16:10:50] <Lambda_Aurigae> there we go..the answer to everything.
[16:11:03] <eszett> the question is "what , actually, is a reset of my AVR?" does it mean i plug the USB cable off on in again? Is that a reset?
[16:11:19] <Lambda_Aurigae> a reset can be caused by several things
[16:11:25] <Lambda_Aurigae> the reset pin
[16:11:29] <Lambda_Aurigae> power off and back on
[16:11:40] <Lambda_Aurigae> watchdog reset
[16:12:18] <antto> programmer reset, jtag reset, software reset, brown-out reset
[16:12:20] <eszett> ah, ok. So when I have a bootloader on my AVR, and the efusebit "BOOTRST" activated, it means when i power off and back on, the AVR jumps to the bootloader right
[16:12:36] <Lambda_Aurigae> so, if your device is powered via the usb port then unplugging and replugging the usb cable will cause a power on reset.
[16:12:44] <Lambda_Aurigae> correct.
[16:12:48] <Lambda_Aurigae> just as it says in the datasheet.
[16:12:49] <eszett> oh, thats interesting
[16:13:06] <eszett> Actually i dont want that.
[16:13:21] <eszett> I want the AVR to go to Bootloader mode by a software trigger
[16:13:24] <antto> that's if it gets power just from the usb
[16:13:30] <Lambda_Aurigae> then jump to the bootloader section.
[16:13:35] <eszett> yes, i use only power from USB
[16:14:05] <eszett> Lambda: do I have to write this trigger in C with inline assembler or is there a C routine for it?
[16:14:09] <Lambda_Aurigae> turn bootreset off
[16:14:17] <eszett> ye, i turn BOOTRST off
[16:14:28] <Lambda_Aurigae> then in your program jump to the beginning of bootloader section.
[16:14:41] <Lambda_Aurigae> inline assembly would be easiest.
[16:14:46] <eszett> ye
[16:15:00] <Lambda_Aurigae> a single jump command to the beginning of bootloader section.
[16:15:09] <antto> wait.. if you're using a bootloader then you should set the fuses so that the chip always runs the bootloader first
[16:15:17] <eszett> well, its a keyboard, and i like to have a key mapped to that trigger
[16:15:24] <Lambda_Aurigae> remember, however, that the bootloader will need to change the interrupt table to the bootloader table if you use interrupts at all in the bootloader.
[16:15:48] <eszett> ye
[16:15:58] <Lambda_Aurigae> antto, normally, yeah, I would say that's true.
[16:16:00] <antto> Lambda_Aurigae mine does, and i can't get it to properly run by jumping to it from the firmware
[16:16:03] <Lambda_Aurigae> but you can do it elsewise.
[16:16:16] <antto> and it works fine on reset
[16:17:06] <Lambda_Aurigae> there are some things the bootrst does when the chip boots...read the bootloader section carefully...you have to do that manually if you jump to the bootloader program from your program.
[16:17:30] <antto> Lambda_Aurigae otherwise, if your only way to go to the bootloader is via some "trigger" in the firmware - if your firmware gets f*cked up then the bootloader becomes unusable, huh
[16:17:55] * eszett has to think about that...
[16:20:19] <antto> eszett configure your chip to always run the bootloader, lock the bootloader from writing (with the lockbits)
[16:20:36] <antto> then, your bootloader should jump to the firmware
[16:20:58] <antto> put a mechanism to let it know when you actually want to remain in the bootloader
[16:21:06] <antto> like, some input pin
[16:21:14] <Lambda_Aurigae> read a key on power up...
[16:21:20] <antto> or that
[16:21:24] <Lambda_Aurigae> or a key sequence or combination.
[16:21:47] <Lambda_Aurigae> flash an LED for 3 seconds on power up, during which time some can type "boot" or something.
[16:22:13] <Lambda_Aurigae> still, it should be possible to jump to the bootloader and have it take over just like a power on reset too...
[16:22:15] <Lambda_Aurigae> or,,,even,,,
[16:22:35] <antto> it should, but i still haven't gotten it to work
[16:22:35] <Lambda_Aurigae> a 3 or 4 key combination that would cause the system to do a reset with the watchdog or something.
[16:22:43] <antto> my bootloader enables interrupts
[16:23:13] <Lambda_Aurigae> as I recall, switching from main interrupts to bootloader interrupts is not a trivial task...there's a sequence to it or something...never bothered to do it myself.
[16:23:21] <Lambda_Aurigae> should be able to find it in the datasheet.
[16:23:36] <antto> that part is working
[16:24:35] <antto> on reset, it goes into the bootloader, it checks a rotary selector, and if it has to remain in bootloader mode - it enables interrupts there in order to have interrupt-driven UART and a timer
[16:25:06] <Lambda_Aurigae> eszett, I would say, go into bootloader on power up,,,like normal...and read the reason for the reset...if it is caused by power on then jump away..if it is caused by watchdog then do bootloader...then in main code, ave some key sequence or combo that causes the main program to do a watchdog reset.
[16:25:39] <antto> then, when i upload a hex to it - the bootloader jumps to the firmware, and the firmware itself enables interrupts there
[16:25:41] <antto> all of that works
[16:25:56] <eszett> one moment please i cant follow all that text that
[16:25:56] <eszett> quickly o_O
[16:25:57] <antto> but jumping from the firmware to the bootloader doesn't work
[16:26:58] <antto> btw, if it's an xmega - you can just soft-reset
[16:27:14] <antto> and there is a nice reset register where you can read the reason for the reset
[16:27:19] <antto> uber elegant stuff ;]
[16:27:32] <eszett> antto: i see, jumpting from firmware to bl doesnt work, so common is a combination of "hold down the key xyz while doing a power cycle reset"
[16:28:20] <antto> yeah.. because just jumping to the bootloader doesn't really equal a "reset"
[16:28:48] <antto> i guess the same goes for jumping to the firmware, but that seems to work
[16:29:15] <antto> i wonder if jumping to 0 is handled somehow specially by the chip
[16:29:39] <Lambda_Aurigae> http://www.fourwalledcubicle.com/files/LUFA/Doc/120730/html/_page__software_bootloader_start.html
[16:29:58] <Lambda_Aurigae> he is using the watchdog jump to bootloader method.
[16:30:13] <eszett> lambda thanks, yes, i want to use&modify the LUFA bootloader since the official Atmel bootloader cant be edited
[16:30:26] <Lambda_Aurigae> anything can be edited.
[16:30:38] <Lambda_Aurigae> you just don't feel like working in assembly with a disassembler first.
[16:30:49] <eszett> ye, for sure.
[16:31:29] <Lambda_Aurigae> right down to extracting data from a chip with the memory protection lock bits enabled...it just takes a scanning electron microscope and lots of patience.
[16:32:47] <antto> or open your third eye and your chakras and you'll see the code ;P~
[16:33:24] <eszett> Someone recommended me this concept: the fusebit "BOOTRST" activated, so that bootloader always starts when doing a power cycle (plugging the USB cable off & in again).
[16:33:24] <eszett> The bootloader (LUFA) checks, if a certain key is pressed, if not, it jumps directly to the firmware. If the key is pressed it remains in bootloader mode.
[16:33:24] <eszett> By this I choose whether to go into bootloader mode, or not. Without a reset-pushbutton.
[16:34:52] <antto> Lambda_Aurigae i might try that watchdog approach
[16:35:20] <eszett> Ye This is what Lambda just recommended me, actually =)
[16:35:35] <eszett> ok, now I got it =)
[16:36:02] <antto> and don't forget to lock the bootloader section so it doesn't get overwritten/corrupted by accident
[16:37:55] <antto> another common mistake is, when the time comes to flash a pile of chips with that thing, to flash the bootloader hex, and then also the firmware hex, and then send it to the customers
[16:38:12] <antto> as a result, they have a working thing, except, without a bootloader
[16:38:47] <eszett> antto: well do i really need to lock it? When the bootloader should ever be corrupt i Can access the AVR via my ISP breakout pads, and programm it new, as i did it from the very beginning
[16:39:10] <eszett> ah!?
[16:39:26] <antto> if it's just for you and you have a programmer - it doesn't matter
[16:39:32] <eszett> You mean the firmware fex overwrites the bootloader section?
[16:39:39] <antto> of course it does ;]
[16:39:46] <eszett> uh oh... hm
[16:40:09] <antto> that's why you have to flash the bootloader hex, then _using_ the bootloader - upload the firmware
[16:40:14] <eszett> And if i do it the other way, first firmware, then bootloader hex?
[16:40:33] <eszett> ah ok got it
[16:40:51] <antto> this can be complicated or impossible to do quickly so the folks tend to put their smart hat on and think "can't i flash both to save time"
[16:40:54] <eszett> antto: but the sake of comfort, is it possible to merge both hex into one?
[16:41:05] <antto> yes
[16:41:32] <eszett> how can i do that? Then i would only need to flash one hex, and spare me the part "use bootloader to flash firmware with Atmel FLIP"
[16:42:24] <antto> the easiest way i can think of is: flash the bootloader, use it to upload the firmware, and if it's all working - attach the programmer again, and dump the whole flash memory to a hex
[16:42:46] <eszett> argh!! easy solution, but i didnt think about that.
[16:42:51] <eszett> very good!
[16:43:23] <eszett> dump the finalized memory down to one hex.
[16:45:19] <antto> you should still check that hex if it works properly, more specifically the bootloader part of it ;]
[16:45:40] <antto> but it should
[16:45:50] <eszett> ye, as far as I have time for it
[16:46:15] <antto> i mean, it can have gone corrupted when reading it
[16:46:45] <antto> i have a pile of linux distribution ISOs at work, and most of them are corrupted
[16:47:09] <antto> one of them went corrupted when i copied it to another computer over the LAN
[16:48:24] <antto> my firmware once or twice got corrupted as i uploaded it via the programmer (because i don't verify the data) and it mostly worked
[16:49:09] <antto> luckily it doesn't control something like a motor.. ;]
[16:52:06] <eszett> jeez.. never had any issues of that kind, but what am i
[16:52:47] <antto> i've reflashed that firmware probably hundreds of times
[16:52:55] <antto> ..while developing it
[16:53:33] <antto> and it's still not finished ;]
[16:56:57] <antto> hm.. ATTR_NO_INIT <- didn't know about that
[16:57:07] <antto> noice
[17:29:07] <eszett> without power cycle, you say, its impossible to jump from the firmware to bootloader, yes?
[17:29:11] <eszett> @antto
[17:29:27] <eszett> I mean without reset..
[17:32:54] <Lambda_Aurigae> not impossible...I see lots of questions about it on avrfreaks.
[17:33:12] <Lambda_Aurigae> it seems the most common method is using the watchdog timer.
[17:33:56] <PinkTieGuy> Hey all - curious is anyone might be able to help me out. Just trying to get SPI working on an atmega328 and I'm running into some problems. Here's the code - hoping someone might be able to clue me in. Thanks!!!
http://pastebin.com/bKRkXRfi
[17:34:06] <Lambda_Aurigae> ummm.
[17:34:11] <Lambda_Aurigae> make the bits go out one at a time.
[17:34:36] <Lambda_Aurigae> you might tell us what is happening, what you are talking to, what is not happening.
[17:34:44] <Lambda_Aurigae> do you have a logic analyzer?
[17:35:06] <PinkTieGuy> Lambda_Aurigae : Is that to me?
[17:35:11] <Lambda_Aurigae> yes.
[17:35:42] <PinkTieGuy> I'm not presently talking to anything. Just trying to get SPI up and running and.... wait... is this because nothing is coming back in as the data is being sent out?
[17:35:50] <Lambda_Aurigae> your asking us to help is like telling us your car makes a noise...without telling us what the noise is or where its coming from.
[17:35:56] <PinkTieGuy> And no, sadly no logic analyzer.
[17:36:04] <PinkTieGuy> Lambda_Aurigae - fair enough
[17:36:04] <Lambda_Aurigae> guessing you actually haven't read anything about SPI.
[17:36:20] <Lambda_Aurigae> have you read the atmega328 datasheet?
[17:36:25] <PinkTieGuy> Lambda_Aurigae : I have but I'm not seeing where exactly I'm going wrong.
[17:36:40] <Lambda_Aurigae> have you read the SPI specifications and understand how SPI works?
[17:36:52] <Lambda_Aurigae> it won't talk if it doesn't have anything to talk to.
[17:37:24] <PinkTieGuy> Ah shit. That makes sense because it's always waiting, right?
[17:37:55] <Lambda_Aurigae> yup.
[17:38:01] <eszett> Lambda: the watchdog timer, I see.. alright
[17:38:06] <Lambda_Aurigae> I suggest reading the spi specification...looking how how it works.
[17:38:10] <PinkTieGuy> Christ I feel dumb now. T
[17:38:13] <PinkTieGuy> Ok. thanks man
[17:38:27] <Lambda_Aurigae> eszett, just like the link I posted from the lufa site.
[17:38:44] <eszett> yep
[17:39:48] <Lambda_Aurigae> https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi
[17:44:45] <antto> eszett i meant without "reset" ... in my case, i was jumping from the firmware to the bootloader, and it doesn't quite work
[17:45:25] <antto> the bootloader starts (i can tell because it clears the leds and sets them in a special pattern) but it doesn't actually respond to the UART
[17:45:57] <antto> the watchdog approach *does* reset the chip
[17:46:06] <antto> so that should work fine
[18:08:53] <Lambda_Aurigae> the 1-liners in this show are what make it.
[18:18:12] <eszett> antto: ye, Im considerung to implement the watchdog approach into my firmware
[18:20:20] <Skippy_42> Hey guys
[18:20:29] <Lambda_Aurigae> hello Skippy_42
[18:21:02] <Skippy_42> does anyone here have experience with the ATMEL-ICE? I try to find out how to use a "Serial equivalent" over JTAG and also understand the strange debugging behaviour
[18:21:50] <Skippy_42> it just does not break where the breakpoints are, does not run "until cursor" and I don'T get why some variables are just not shown in the debugger
[18:38:08] <Lambda_Aurigae> never touched one myself Skippy_42
[18:38:17] <Lambda_Aurigae> not sure what debugger you mean either.
[18:42:05] <Skippy_42> Atmel Studio debugger using an ATMEL-ICE tool
[18:42:57] <Lambda_Aurigae> aahh.
[18:43:09] <Lambda_Aurigae> I'm sure if you wait, someone here has used that.
[18:43:16] <Lambda_Aurigae> it won't run on my computers.
[19:08:53] <carabia> Skippy_42, what device are you debugging?
[19:09:35] <carabia> And as to some variables not showing, they could be optimized out?
[19:10:37] <carabia> And for not reaching breakpoints your code could be doing nawtee things and the libraries might have faulthanders or something that catches them... Really don't know without more info
[19:11:28] <Casper> Skippy_42: I just use serial out, led or lcd for debugging
[19:13:22] <carabia> Casper, nothing really beats a real debugger (ice or on-chip)
[19:13:56] <carabia> perhaps not for avrs, as you shouldn't be doing overly complicated things with them
[19:14:14] <Casper> good enought for my use
[19:14:26] <Casper> but I wish sometime I could inspect the stack...
[19:15:01] <aczid> you could also try simulavr
[19:15:11] <aczid> if you don't have a fancy debug device
[19:30:58] <Casper> simulavr, and all simulator, they all suck when you connect anything external..
[20:00:39] <Skippy_42> Logic Analyzer ftw
[20:01:02] <Skippy_42> can anyone tell me why this is not giving the propper size?
[20:01:10] <Skippy_42> uint8_t frameLen = (sizeof(frame) / sizeof(frame));
[20:01:33] <Skippy_42> uint8_t* frame = new uint8_t[5 + 2];
[20:01:58] <Skippy_42> oh wait
[20:02:22] <Skippy_42> uint8_t frameLen = (sizeof(frame) / sizeof(frame));
[20:02:29] <Skippy_42> but still... the result is 2, but why
[20:03:23] <vegii> I see...
[20:04:13] <rain1> did you mean to do (sizeof(frame) / sizeof(*frame));?
[20:04:31] <Skippy_42> yes, but still the result is 2
[20:04:48] <rain1> well it's not an array
[20:04:54] <rain1> it's just a pointer to dynamically allocated space
[20:05:13] <rain1> you need to use uint8_t frame[5 + 2];
[20:05:13] <vegii> where should I lurk if I'd like to flash "blink" on Attiny13A via usbasp on ubuntu?
[20:05:21] <Skippy_42> ah damn, you'Re right, ty rain1
[20:05:42] <Lambda_Aurigae> vegii, that question makes no sense.
[20:06:06] <Lambda_Aurigae> you are wanting to send the word "blink" out of the attiny13a?
[20:06:43] <vegii> Lambda_Aurigae: I have the attiny13a connected to usbasp, I just need software and a tutorial how to flash a program like the (arduino) "blink"
[20:07:20] <Lambda_Aurigae> you use avrdude to upload the program.
[20:07:23] <vegii> that'd probably be writing the code, compiling and flashing
[20:07:37] <Lambda_Aurigae> before that, you have to compile it and turn it into a .hex file
[20:08:34] <vegii> and before that, I need to have something that can be compiled
[20:08:50] <Lambda_Aurigae> so write a program.
[20:09:23] <Lambda_Aurigae> there are literally hundreds of tutorials out there about writing programs for avr.
[20:09:32] <Lambda_Aurigae> attiny13A is probably not the best beginner chip though.
[20:10:08] <vegii> I just need it to blink two LEDs for a few seconds after a button is pressed
[20:10:35] <vegii> it's smaller than a discrete circuit that could do it
[20:11:13] <Lambda_Aurigae> you will need the compiler toolchain...avr-gcc, avr-libc, avr-binutils
[20:11:16] <Lambda_Aurigae> along with avrdude.
[20:11:54] <Lambda_Aurigae> then read the datasheet on the chip you want....my opinion, but that's where I would send you if you were my student.
[20:12:31] <Lambda_Aurigae> http://www.ladyada.net/learn/proj1/blinky.html
[20:12:58] <Lambda_Aurigae> http://www.toddholoubek.com/classes/pcomp/?page_id=692
[20:13:29] <Lambda_Aurigae> http://brownsofa.org/blog/2011/01/02/the-compleat-attiny13-led-flasher/
[20:14:01] <vegii> oh neat, an attiny13 one
[20:14:10] <Lambda_Aurigae> google is your friend.
[20:14:26] <Lambda_Aurigae> blink led tutorial attiny13
[20:15:38] <vegii> yeah, sucks to be using ddg by default
[20:15:55] <Lambda_Aurigae> no clue what ddg is.
[20:16:52] <vegii> duckduckgo
[20:17:06] <Lambda_Aurigae> and, no way to change that?
[20:17:15] <Lambda_Aurigae> isn't that a malware site anyhow?
[20:17:30] <vegii> no it's not and no, it's not
[20:17:44] <vegii> easy to change that and it's legit
[20:17:50] <Skippy_42> If I have a pointer to a byte, and I start incrementing the number, when I get an overflow (>FF), does the IC start writing stuff in the next memory cell, or does it just start in the current cell from 0?
[20:18:19] <Lambda_Aurigae> oh, worse
[20:18:20] <Lambda_Aurigae> it's yahoo.
[20:18:23] <Lambda_Aurigae> hahaha.
[20:18:27] <Lambda_Aurigae> what a waste.
[20:19:23] <vegii> while duckduckgo is a legit search engine, it feels like a 10-yr older version of google
[20:19:24] <Lambda_Aurigae> Skippy_42, an overflow of what? the pointer or the data you are writing to the memory location?
[20:19:32] <Skippy_42> the data
[20:19:41] <Lambda_Aurigae> vegii, that's because it uses yahoo search engine as a back end.
[20:19:43] <Skippy_42> I just use the pointer to increment the value
[20:20:21] <Lambda_Aurigae> if you don't change the pointer then it always points at the same location so if you increment at 0xFF then it rolls over to 0x00...standard basic plain logic.
[20:20:22] <Skippy_42> I will just debug it and see
[20:20:33] <Skippy_42> ah ok
[20:20:53] <Skippy_42> I thought maybe something understands the situation and starts doing extra stuff
[20:20:54] <Skippy_42> ty
[20:20:55] <Lambda_Aurigae> the same with pretty much any cpu/computer
[20:21:07] <vegii> Lambda_Aurigae: I thought they had their own bots n stuff
[20:21:18] <Lambda_Aurigae> there is an overflow flag.
[20:21:32] <Skippy_42> oh ok
[20:21:38] <Lambda_Aurigae> Skippy_42, if you overflow then, if the overflow flag had been 0 then it gets set to 1.
[20:21:42] <Lambda_Aurigae> so you can test for that.
[20:22:08] <Lambda_Aurigae> I suggest reading the avr instruction set documentation.
[20:22:17] <Skippy_42> but neither the IC nor atmel studio will do anything with that information right? Like solo reactions when some overflow flags are set?
[20:22:28] <Lambda_Aurigae> no..your code has to do something with it.
[20:22:36] <Skippy_42> allright then, ty =)
[20:22:41] <Lambda_Aurigae> beanie babies.
[20:23:04] <Lambda_Aurigae> http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_instruction_list.html
[20:56:07] <Skippy_42> this line of code is freezing my atmega..... uint8_t inv = 0xFF - (*(dataSumPtr))+1;
[20:58:17] <Skippy_42> ok it's not..... but something is messing up my I2C communication, but only sometimes.... wtf
[21:00:08] <cehteh> add some checks that the pointer is *really* valid
[21:00:36] <cehteh> (out of bound, uninitialized, off by one, brainfarts ...)
[21:00:40] <Skippy_42> it is, I get the right result with my logic analyzer
[21:01:07] <Skippy_42> but as I have a line of code with 0xFF - foo.... the atmega breaks after 2 or 3 cycles of i2c write
[21:01:13] <cehteh> also in the case where it the i2c fails?
[21:01:14] <Skippy_42> I am still trying around
[21:01:23] <cehteh> and is that in a isr?
[21:01:38] <cehteh> (or isr's involved)
[21:02:22] <Skippy_42> I don't know what the Wire.h arduino library does, but I didn't put it in any isr
[21:02:50] <cehteh> is that an arduino project?
[21:03:03] <Skippy_42> I rechecked, it sends 2 valid I2C frames with the correct value, then the clock line freezes at low in the third write byte
[21:03:05] <Skippy_42> yes
[21:03:24] <Skippy_42> at least arduino is included, I'm working with Atmel Studio
[21:03:57] <cehteh> dunno then try harder, timing problem or sync problem .. or just some braindead bug
[21:04:54] <cehteh> try to isolate where it fails exactly, maybe not at sendng the frames ... or if the error happens to be one of the things i saied about pointers above when preparing a new frame
[21:05:51] <Skippy_42> http://imgur.com/676u1vK
[21:09:24] <cehteh> that doesnt say much
[21:09:31] <cehteh> if it fails, then its somwhere in the code
[21:09:48] <Skippy_42> http://imgur.com/5oHrXJg
[21:10:55] <cehteh> so your pointer arithmetic is somehow wrong
[21:11:49] <Skippy_42> where did I mistake? Can't see any problem with the pointers
[21:12:12] <cehteh> i didnt looked that close
[21:12:33] <cehteh> i dont even know what you intend to do
[21:13:07] <cehteh> well arithmetic in C is by default on 'int' size .. thats 16bit even on avr
[21:13:21] <Skippy_42> oh
[21:13:30] <cehteh> if you rely on under/overruns you may cast it to uint8_t
[21:13:37] <Skippy_42> but everything is uint8_t --> byte
[21:13:49] <aandrew> if you're ever in doubt get a UART and printf("sizeof(int) is %z\n", sizeof(int_variable));
[21:14:29] <Skippy_42> but I mean everything that is important for that problem is in that 8 lines of code, and everything is uint8_t
[21:14:33] <cehteh> what do you intend to do on the boken line?
[21:15:01] <Skippy_42> just sum up some values, and do that calculation 0xFF - dataSum + 0x01, nothing fancy
[21:15:09] <Skippy_42> it's needed as a checksum
[21:15:10] <cehteh> you can rewrite that as frame[framelen-2] ..
[21:15:19] <cehteh> ah
[21:16:05] <Skippy_42> ok maybe I can rewrite it, but it works with = 0x42 too, so why not for (0xFF - dataSum + 0x01), the access to the pointer / array cannot be the problem
[21:16:32] <cehteh> what is if framelen is <5? :D
[21:16:49] <cehteh> yes that was purely cosmetic
[21:17:18] <Skippy_42> the frameLen is build before the call and is always 8 + x
[21:17:23] <Skippy_42> and x is unsigned
[21:17:27] <cehteh> ok
[21:17:27] <Skippy_42> so that is not the problem
[21:19:21] <Skippy_42> ok wtf, it works with *(frame+frameLen-2) = (0xAA - dataSum);
[21:19:24] <cehteh> but why does it stop transmission when the checksum is wrong .. you should think about whats really going on there
[21:19:36] <Skippy_42> so the problem was the calculation with the 0xFF + dataSum - 0x01
[21:19:55] <Skippy_42> that might be someoveflow stuff....
[21:20:09] <Skippy_42> or calculating with 0xFF, or a bug I don't know
[21:21:01] <cehteh> why do you calculate the checksum that way anyway?
[21:21:09] <cehteh> (FF and +1)
[21:21:17] <cehteh> and adding up
[21:21:44] <Skippy_42> oh wait
[21:21:53] <cehteh> i'd just xor .. and maybe rotate each step by one, and then store the checksum as is, if not using some CRC
[21:22:02] <Skippy_42> it messed up with xor too
[21:22:06] <Skippy_42> that's what I did first
[21:22:35] <cehteh> i wonder why it messes up when you put a wrong calcuation there
[21:22:46] <cehteh> that should not stop the transmission or?
[21:22:59] <cehteh> (dont know the rest of your code)
[21:23:31] <Skippy_42> Yep that's the problem, it shouldn't stop the transmission, but it does, and I try to find out why
[21:23:35] <cehteh> anyway using indexed access frame[] would make it more readable imo .. or using pointers only in the first place
[21:24:04] <cehteh> instead putting 42 there .. try diffent values .. maybe even 0..255
[21:24:12] <cehteh> i bet on some values it breaks
[21:24:16] <Skippy_42> I did, it works, AND this here works: *(frame+frameLen-2) = (0xFB - dataSum) + 0x01;
[21:24:19] <cehteh> which means the error is somewhere else
[21:24:43] <cehteh> and for some values it does not .. which means the error happens in some other place
[21:26:17] <Skippy_42> hmm... I will keep checking
[21:26:18] <cehteh> why dont you just frame[frameLen-2] = dataSum; i mean the arithmetic around doesnt add any value
[21:29:00] <Skippy_42> I try it
[21:29:51] <cehteh> may still fail .. if the error is somewhere else :D
[21:30:23] <cehteh> but for what did you do that arithmetic? .. filling the flash memory up? waste some cycles?
[21:31:08] <cehteh> if you want the checksum never to become 0 then you need to do other things
[21:31:33] <Skippy_42> the checksum can become 0, that's not the problem
[21:31:45] <cehteh> was just my guess :D
[21:31:57] <Skippy_42> I have a frame, with for example 12 bytes
[21:32:01] <Skippy_42> 00 00 FF 05 FB D4 14 01 14 01 02 00
[21:32:26] <Skippy_42> now I have the following before my method buildPostStuff
[21:32:26] <Skippy_42> 00 00 FF 05 FB D4 14 01 14 01 __ __
[21:32:38] <Skippy_42> and now I add up D4+14+1+14+1
[21:33:01] <cehteh> yes
[21:33:12] <Skippy_42> the result of that is FE
[21:33:33] <cehteh> using some CRC would be much more proper here, but understandably thats more complicated
[21:34:01] <Skippy_42> that's the requirement of the chip that gets the frame, I cannot affect that
[21:34:16] <Skippy_42> I need to xor that sum, that FE
[21:34:42] <cehteh> ah
[21:35:08] <Skippy_42> that's why I asked about that overflow earlier, because that should not disturb this operation, it should be "rerolled" when the sum gets higher than 0xFF
[21:35:43] <Skippy_42> and ye, the proper way would be working with ~ but I did that first, it didn't work, and then I played around with that 0xFF - datasum + 0x01
[21:35:47] <cehteh> who is the master on your bus?
[21:35:52] <Skippy_42> I am
[21:35:57] <Skippy_42> atmega
[21:35:59] <cehteh> so you generating the clock
[21:36:03] <Skippy_42> ye
[21:36:21] <cehteh> your program is only sending or also receiving?
[21:36:37] <Skippy_42> later receiving, but at the moment just sending
[21:37:00] <cehteh> then it should just send crap out, no matter how wrong the checksum is
[21:37:13] <cehteh> if that stops .. the bug is somwhere else
[21:38:08] <cehteh> *maybe* .. your cheksum calcuation overrund the buffer, breaks something, but you didnt used the checksum, and thus gcc optimized it completely out
[21:38:24] <cehteh> btw do you compile with all warnings enabled?
[21:39:23] <Skippy_42> I don't know, IK
[21:39:27] <Skippy_42> I see some warnings
[21:39:40] <cehteh> make dataSum global/volatile ... (just for a test) .. and keep the = 0x42 variant
[21:39:40] <Skippy_42> but I never made anything in the settings, so I don't know if it shows ALL warnings
[21:39:42] <cehteh> try that
[21:40:09] <cehteh> -Wall -Wextra on the flags somwhere, dunni i dont use atmel studio
[21:40:48] <Skippy_42> btw. the checksum is added up correctly, if I don't do that 0xFF - datasum stuff, and just do frame[frameLen-2] = dataSum; everything works properly and the logic analyzer shows me the value 0xFE
[21:40:55] <cehteh> i bet frame is a bad pointer to begin with :D
[21:41:41] <cehteh> how do you allocate the 'frame' .. is that static memory?
[21:42:34] <Skippy_42> http://pastebin.com/CvddJ5w2
[21:42:37] <Skippy_42> brb cigarette
[21:42:58] <cehteh> urgs :D
[21:43:19] <cehteh> dynamic allocation on microcontrollers is fail
[21:45:23] <carabia> ffff what the fuck is that? Some object stuff on mcus?
[21:45:29] <carabia> on the pastebin link
[21:46:19] <cehteh> C++ / Arduino
[21:46:31] <carabia> yeah eww
[21:46:34] <cehteh> BLOAAAT :D
[21:46:47] <cehteh> i bet that code is bigger than my whole OS :D
[21:47:32] <cehteh> compiles to something biggier i meant
[21:47:48] <carabia> i would steer clear from c++ on avrs and even on lower end cortexes
[21:48:19] <cehteh> as in always :D
[21:48:33] <carabia> i'd prolly do it on M7 or something where you can start justifying overhead to simplify complex systems
[21:48:35] <cehteh> i consider C++ a big fail
[21:48:52] <Skippy_42> re
[21:49:06] <carabia> well personally I've never learned any C++ apart from the very very basics. It's grown way too big and complex.
[21:49:13] <cehteh> Skippy_42: check the returns of 'new' .. i bet one failed :D
[21:49:36] <carabia> is new like heap allocator or something?
[21:49:52] <cehteh> and really .. use some global buffers or the stack, not dynamic allocation
[21:50:15] <cehteh> yes new/delete is malloc/free .. plus constructors/destructors
[21:50:56] <carabia> Skippy_42, is there a specific reason you're doing this in C++?
[21:51:05] <cehteh> arduino :D
[21:51:26] <Skippy_42> hmm... ye, I should not use new, and c++ because I need classes I guess ^^
[21:51:39] <carabia> What the fuck?
[21:51:48] <cehteh> yot dont need classes
[21:51:58] <carabia> you most certainly don't need classes hahahha
[21:53:20] <carabia> Is this code for like the arm arduino?
[21:53:32] <cehteh> thats normal avr arduino
[21:53:34] <carabia> cause that SAM keeps catching my eye
[21:53:55] <cehteh> well ... bbl
[21:54:15] <Skippy_42> I have actually no idea. It's a product I write the firmware for, and it WAS on arduino, but now they kind of did their own hardware, which still is somehowarduino like wiring, but not some board you would find to by
[21:54:19] <Skippy_42> it uses an atmega2561
[21:54:46] <carabia> Skippy_42, well, you'll save yourself a lot of trouble when you just switch over to regular C
[21:54:54] <carabia> and ditch the arduino bs
[21:55:12] <Skippy_42> my boss wants to have the standard arduino wire.h library used
[21:55:43] <Skippy_42> *to be used
[21:56:03] <carabia> Maybe you should convince your boss not to, then
[21:56:31] <Skippy_42> hmm... I thought I just make everything with classes and stuff, because it's nice to overview and modular when you have classes / fassades / handlers / factories / etc.
[21:57:18] <Skippy_42> I mean.. ok maybe you have your points and don't like it, but this should still do its job properly with arduino and c++
[21:58:09] <Skippy_42> but for now I try to not use new and make some global buffer
[21:59:08] <cehteh> i am somewhat scared that people base products on arduino libs :D
[21:59:11] <carabia> yes, "factories" and so on are maybe nice when you're running on X86 with several GHz to be spent on overhead
[21:59:23] <cehteh> well .. off for today cu
[21:59:32] <Skippy_42> cya and thx a lot for your help
[21:59:52] <carabia> programming those web 400.0 or whatever websites with your favorite trendy language
[22:00:06] <Skippy_42> you got a point there :D
[22:00:06] <carabia> running on top of already bloated web servers running on top of already bloated operating systems
[22:00:37] <carabia> but with so fast cpus and the vaaaasssstttt instruction set of the x86 you don't really give too many fucks about overhead
[22:00:39] <Skippy_42> you will hate me when I tell you that my PN532 class is singleton xD
[22:01:11] <Skippy_42> but you are right, I should take a step back with that fancieness
[22:01:15] <carabia> As I said I'm not well-versed in programming with objects, and I do think it's a horribly bad fucking idea with mcus
[22:01:33] <carabia> it's kind of a causality thing for me. As in, not worth learning
[22:01:55] <Skippy_42> hmm... I will rethink my architecture I guess
[22:02:06] <carabia> If you're writing a complex system, you can still make it modular without objects.
[22:02:39] <carabia> But you really have to take a step back on thinking what needs to be separated and what doesn't
[22:02:51] <Skippy_42> ye, objects would be great, even for the avr, because there are a lot of different protocols that will interact, but I guess I will rethink the bloat stuff I have here and their
[22:03:14] <carabia> different protocols, explain?
[22:03:51] <Skippy_42> I will have my main I2C frame, and later peer stuff, so other packets inside I2C like NDEF, SNEP, LLC, etc.
[22:03:56] <Skippy_42> and some are combined, some not
[22:04:08] <Skippy_42> so that is one point I really want to have the modularness through classes
[22:04:32] <Skippy_42> but I guess I don't need stuff like dynamic memory allocation or singleton
[22:04:59] <carabia> you can use dynamic memory allocation, but you don't need objects
[22:04:59] <Skippy_42> and I should put in more C stuff and less C++ stuff, like global buffers
[22:05:16] <carabia> you could just map those packets into structs, you know
[22:05:52] <Skippy_42> hmmm... that doesn't sound bad, haven't thought about that
[22:06:08] <carabia> just write a fast low level driver for the i2c peripheral (and don't use the arduino stuff, it's complete bullshit)
[22:06:21] <carabia> and then build a _reasonable_ abstraction layer on top of that
[22:06:33] <Skippy_42> that is one point I have to talk with my boss first
[22:06:34] <carabia> where you map your raw data from the i2c as you will
[22:07:01] <Skippy_42> the data packets for the I2C frame may vary
[22:07:28] <Skippy_42> so at that point it would be nice to have an i2c frame struct, where it.... now I wanted to start with to abstract stuff again ^^
[22:07:47] <carabia> Well, yeah, you want some level of abstraction of course
[22:07:58] <carabia> just that you don't need to get into the clusterfuck c++
[22:08:25] <carabia> if you cannot determine the nature of the packet in advance, you identify it and proceed...
[22:09:07] <Skippy_42> hmm... yea...
[22:09:20] <Skippy_42> I guess I will sleep now and think about it
[22:09:32] <Skippy_42> thx for the help and ideas
[22:09:42] <carabia> It's always good to sleep on things such as these. Nn.
[22:09:49] <Skippy_42> cya
[22:59:32] <eszett> hi
[23:00:31] <eszett> someone has a clue why mkdir.exe crashed when i try to compile with "make" (MHV AVR)
[23:09:57] <Casper> eszett: sure, because you use windows
[23:10:57] <Casper> on a more serious note... might as well be windows... or your memory..
[23:54:23] <eszett> Casper ye,, obviously
[23:55:14] <eszett> I will install linux tomorrow, for today I let it be
[23:55:26] <eszett> laters..