Back
[08:37:35] <rue_mohr> first to say something this morning!
[08:38:14] <RikusW> afternoon here already.
[08:38:27] <rue_mohr> tommorow morning duh!
[08:38:47] * rue_mohr pulls time zone on RikusW
[08:38:56] <RikusW> +2
[08:39:07] <rue_mohr> you cant beat me unless you REALLY think ahead
[08:48:16] <rue_mohr> I dont get it, since I said I'd be away from my project for 3 months, the rate of people following my hackaday project have increased...
[08:51:55] <bojangles> does anyone know what data types the mega 2560 supports?
[08:53:03] <LeoNerd> "data types" ?
[08:57:20] <bojangles> yea like strings, integers, floats etc
[08:59:37] <LeoNerd> Those aren't properties of the CPU, they're properties of the language and compiler
[08:59:41] <RikusW> that is specific to the programming language used, not the processor
[09:04:50] <bojangles> in assembly
[09:07:20] <RikusW> in asm you have to do it all yourself
[09:07:27] <RikusW> or use a lib
[09:10:23] <RikusW> bojangles: it supports a byte only
[09:10:36] <RikusW> build from there
[09:16:07] <bojangles> ahhh i see, thanks
[09:16:48] <Emil_> bojangles: AVRs are mostly 8 bit processors
[09:20:23] <antto> apple_t and potato_t ;P~
[10:28:54] <Getty> just to reassure i dont miss an option, i did saw it right that "ERFOS AVRISP MkII Clone" (so avrispmkii) can't do debugging, right? i actually never did any debugging for avr so i wasnt trying at all when i saw that my programmer probably can't do it
[10:29:06] <Getty> but my math problems exceed ;) so i dont wanna miss an option to avoid doing LCD debug
[10:32:33] <LeoNerd> By "debugging", do you mean dW?
[10:32:43] <Getty> well something more output as the display ;)
[10:32:45] <Getty> i take anything
[10:32:50] <LeoNerd> If so your options are extremely limited, and almost certainly mean running the giant behemoth that is Atmel's AVR Studio, on Windows.
[10:32:52] <LeoNerd> GL;HF
[10:33:29] * Getty puts a Behemoth Dinosaur Gateway in front... adds a Behemoth Dinosaur Gate and feels safe
[10:37:58] <RikusW> to debug you need the Atmel ICE or AVR Dragon
[10:38:25] <Getty> yeah ok that was what i had found out, too... just wanted to be 100% sure
[10:38:49] <LeoNerd> One day I'll get around to working on some dW hardware+software
[10:47:10] <twnqx> jtag clones can work with avarice, though
[10:47:14] <twnqx> dW... i doubt
[10:48:19] <LeoNerd> Most AVR chips don't really do debug over JTAG; at least, none of the tinies and very very few megas
[10:48:30] <LeoNerd> Whereas I've yet to see a tiny or mega that didn't support dW
[10:55:32] <RikusW> LeoNerd: mega mostly do jtag and tiny dW
[10:55:40] <RikusW> though there are a few megas that do dW
[10:55:58] <RikusW> like 328 32u2 etc
[10:56:32] <RikusW> 88 168 328
[10:57:05] <LeoNerd> Ah; maybe just all the ones I tend to use :)
[11:58:24] <bojangles> does avr have any hardware support for power saving?
[11:58:38] <LeoNerd> Lots
[11:59:03] <LeoNerd> There's the SLEEP instruction, the various idle/sleep states, the powerdown register,...
[12:15:46] <Getty> WOW..............
[12:16:03] <Getty> xxx PROGMEM != PROGMEM xxx..... but the wrong one gives no error
[12:16:19] <LeoNerd> Welcome to cpp-style macro systems ;)
[12:16:29] * LeoNerd wants scheme already
[12:16:40] <Getty> damn its still wrong....
[12:18:17] <Getty> i get always the same wrong value
[12:19:45] <Getty> https://gist.github.com/Getty/50ade80d991d9a1014d8
[12:19:53] <Getty> am i doing anything fundamental wrong here?
[12:20:09] <Getty> i also tried casting it to (uint32_t) in the =, but.. i always get something totally odd wrong
[12:20:16] <Getty> (and always the same, which confuses me most)
[12:20:25] <LeoNerd> At least two things, that I can tell
[12:20:30] <Getty> ok?
[12:20:32] <LeoNerd> The types don't match, and you're not using the lookup function
[12:20:51] <Getty> whcih lookup function? could it be that you mean EEPROM ?
[12:20:54] <LeoNerd> http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
[12:21:41] <LeoNerd> gcc can't infer that it needs to use LPM intead of LD to read those, so you have to help it
[12:21:44] <Getty> OH, i am stupid, yes, yes, i hide that on my other PROGMEM usage behind a define... ARGHL
[12:21:45] <Getty> yes yes
[12:23:12] <Getty> the good thing is, while i seeked for that bug i found like 20 others
[12:23:31] <LeoNerd> Well that's the great thing about bugs... an almost limitless supply of more
[12:23:50] <Getty> the good thing is that in C you CAN actually see an end to it
[12:34:14] <Getty> is there btw a good cheat-sheet about casting?
[12:34:29] <Getty> ;)
[12:50:22] <tqbf> helu, i have a really weird avr-gcc/avr-ld question. is there a better place for me to ask it than here?
[12:50:36] <Getty> that is an awkward first question ;)
[12:50:46] <Getty> no we are all sitting here on the 2nd best channel, we are not worthy for the best ;-))
[12:50:52] <aandrew> lol
[12:50:53] <Getty> what is your problem? we might still be able to help!
[12:51:07] <aandrew> shhh, don't give him hope
[12:51:19] <tqbf> wokay then! I am working with a custom (emulated) AVR part, and had been working from avr-gcc's atmega8 definitions
[12:51:24] <Getty> he uses avr, he lost already all hope ;-)
[12:51:26] <tqbf> but I have more than 8k of program text memory
[12:51:50] <Getty> uh... emulated.....
[12:51:57] <tqbf> avr-gcc (or avr-ld) realllllly believes my text wraps around at 8k, and so the linker patches rcall's with negative offsets that make sense only with 8k memory
[12:52:17] <tqbf> nothing i seem to be able to do with linker scripts, gcc arguments, or ld arguments prevents those 8k wraparounds from happening
[12:54:59] <RikusW> LeoNerd: JTAG vs dW ->
http://pastebin.com/AZDLsZtW
[12:56:44] <Getty> tqbf: i am no big expert, but i am confused a bit, you have more program text memory because of the emulation? so you say the combination you emulate doesnt exist in real?
[12:57:06] <tqbf> yes: the part I am emulating is not a part avr-gcc/avr-binutils already has a definition for
[12:57:16] <tqbf> it is essentially atmega8 but with 16K, not 8K, of flash
[12:57:21] <Getty> ok, i MUST ask.... why?
[12:57:27] <tqbf> it's a long complicated story
[12:57:41] <Getty> ok.... thats accepted... as long as its not some stupid idea ;)
[12:57:51] <Getty> you can understand my confusion
[12:58:25] <Getty> and i also think that you will get a BIG hard time.... there are probably so many little switches and details based just on the device definition, you might really will hit a wall here
[12:58:35] <tqbf> so there a whole bunch of flags that supposedly govern the address space wrap
[12:58:42] <tqbf> like -pmem-wrap-around=16K
[12:58:47] <Getty> supposedly is the keyword here
[12:58:48] <tqbf> but none of them seem to have any effect
[12:58:55] <Lambda_Aurigae> tqbf, use the atmega168
[12:59:24] <Getty> that solution is too simple, cant be! ;)
[12:59:28] <Lambda_Aurigae> that is about as close as you will get without writing a whole new part definition.
[12:59:54] <Lambda_Aurigae> otherwise you will need to write a part definition for avr-gcc toolchain and recompile for it.
[13:00:12] <RikusW> tqbf: try using mega168 ?
[13:00:19] <RikusW> almost the same as mega8
[13:00:21] <Getty> RikusW: you lag
[13:00:22] <Lambda_Aurigae> just make sure you don't use any of the extended atmega88 stuff that the atmega8 doesn't have like PCI and such.
[13:00:38] <tqbf> i really have to recompile avr-gcc to use a new part?
[13:00:46] <Lambda_Aurigae> yes.
[13:00:59] <Lambda_Aurigae> avr-gcc, avr-libc, and avr-binutils.
[13:01:08] <tqbf> so, this is helpful, but another dumb question: what are the linker scripts for then?
[13:01:16] <RikusW> Getty: seems so, so some more lagging, with PROGMEM make sure about word/byte addressing...
[13:01:20] <Lambda_Aurigae> for linking.
[13:01:47] <Getty> RikusW: i just need to do it right i have LINE1(&progmemstuff); at the other code, and i forgot that behin the define is the progmem function call
[13:01:49] <LeoNerd> RikusW: Hrm.. about 50/50 mix then
[13:02:03] <Getty> RikusW: and so i just totally forgot to use it at the other coe then
[13:02:14] <Getty> RikusW: works all totally fine now
[13:02:18] <tqbf> -.-
[13:02:31] <tqbf> i mean, if the linker scripts tell the linker what the memory ranges are...
[13:02:41] <Getty> well in an ideal environment in standard C
[13:02:54] <Getty> but this is avr-gcc with whatever avr needed to make it work
[13:03:10] <Getty> i cant point to specifics but you just cant assume the same normal world you know ;) just take PROGMEM! ;)
[13:03:18] <Getty> i mean as example
[13:03:23] <Lambda_Aurigae> avr-gcc is all kinds of hacked up to work properly with a harvard arch.
[13:03:32] <Getty> yeah all harvards fault
[13:03:44] <Lambda_Aurigae> down with harvard! MIT all the way!
[13:04:05] <Getty> who has the forks?.... forks! ... haha... get it? ;-)
[13:04:16] * Getty goes in the corner
[13:04:41] <Lambda_Aurigae> bad Getty
[13:04:50] * Lambda_Aurigae replaces Getty with MGetty
[13:05:15] <Getty> didnt heard of mgetty in a long time, i hope he is still fine :-( last time didnt heard so good
[13:06:35] <Lambda_Aurigae> DESCRIPTION
[13:06:35] <Lambda_Aurigae> Mgetty is a ‘‘smart’’ getty replacement,
[13:06:44] <Getty> yeah but also the nick of a guy ;)
[13:07:27] <Getty> mgetty was the first thing that i compiled by source on my slackware..... and my old nick was Getler, so it was pretty clear to go with Getty (after some girl said Getler is a stupid nick ;) )
[13:08:45] <Getty> Lambda_Aurigae: the best part is always on general linux topic channels getting highlighted once in a while and then giving back a snippy reply to tell the user that his getty is not approving what he wants to do! ;)
[13:09:07] <Lambda_Aurigae> hehe
[13:09:25] <Lambda_Aurigae> you should automate that.
[13:09:44] <Getty> hahaha, well the cases are too different, no real scheme possible
[13:09:57] <Getty> its also not that often, i dont have many of those channels mostly its these days just #raspbian where it happens
[13:10:38] <Getty> but the best part is that the name is also now my real life nickname, so all call me that
[13:10:59] <Getty> i am even hired by that nick, as i dont want them to call me at all by my realname (if i would ever get a normal job again LOL)
[13:11:10] <Lambda_Aurigae> people just call me "Hey you asshole, yeah, you!"
[13:11:35] <Getty> There is a comedian in germany making this flat joke:
[13:11:53] <Getty> I called my dog "stay there" and people laugh at me when i call him: "stay there, come here, stay there, come here"
[13:17:55] <nollan> I have this code: main() { sei(); lcd_init(); lcd_send_char('a'); (and more) . I am trying to implement USART with interrupts with an existing system that has an lcd. However the code runs until lcd_send_char(), and then stops. BUT if I power cycle it it continues. lcd* routines all have cli() and restores SREG. Any clues whats going on? Thanks.
[13:18:48] <Getty> you need to show much more code, but it smells like your communication channel to the lcd is not setup proper (so they hang at some point)
[13:18:53] <Getty> vague guess ;)
[13:19:17] <Lambda_Aurigae> or there is no loop.
[13:19:23] <Lambda_Aurigae> he didn't show a loop.
[13:19:32] <nollan> Lambda_Aurigae: there is a loop afterwards
[13:19:33] * Lambda_Aurigae takes his meds.
[13:19:46] <nollan> Getty: ok, I can pastebin it
[13:20:03] <Getty> Lambda_Aurigae: you sounds like the little boy at the matrix oracle..... "there is no spoon"
[13:20:28] <nollan> Getty: is it problematic if I use a timer for delay in my lcd_init() ?
[13:20:44] <Lambda_Aurigae> yeah....it was supposed to come out as a Marvin the Martian misquote but I got distracted.
[13:20:54] <Getty> it doesnt sound good, but we must see code ;)
[13:20:57] <Getty> there are billion ways todo shit
[13:21:03] <nollan> yeah ok
[13:22:50] <nollan> Getty:
http://pastebin.com/ZVBGuBiY
[13:23:16] <nollan> I didn't send the uart code since it never gets that far anyhow
[13:23:32] <Lambda_Aurigae> you aren't reenabling interrupts.
[13:23:35] <nollan> btw it works fine w/o sei()
[13:23:54] <nollan> Lambda_Aurigae: SREG = sreg ?
[13:23:54] <Lambda_Aurigae> you do an SEI() in main
[13:24:05] <Lambda_Aurigae> then in the various lcd commands you do cli()
[13:24:07] <nollan> Lambda_Aurigae: I save old SREG
[13:24:13] <Lambda_Aurigae> but don't sei() later to reenable.
[13:24:37] <nollan> hm, I thought sei() did exactly the same, just set the "I" bit i SREG
[13:24:48] <Lambda_Aurigae> hmm...it might.
[13:24:54] <Lambda_Aurigae> but I would never count on such things.
[13:25:07] <nollan> Lambda_Aurigae: ok I will try it
[13:25:45] <Lambda_Aurigae> I wouldn't bother with disabling interrupts on the lcd send command and send data though.
[13:26:15] <nollan> Lambda_Aurigae: ok
[13:26:28] <Lambda_Aurigae> I would just use a for loop to create a delay
[13:27:04] <Getty> i use a delay.c i catched from the web
[13:27:08] <Getty> ;)
[13:27:29] <nollan> I set a quest to write everything myself so cannot do it :)
[13:28:55] <nollan> Lambda_Aurigae: the cli(); //code sei(); trick didn't do it :(
[13:28:56] <Getty> well then read what they do and copy it
[13:29:04] <nollan> haha :)
[13:29:04] <Getty> seriously, its not about writing yourself its about getting the shit done ;)
[13:29:12] <nollan> yeah I know..
[13:29:41] <Getty> i actually made a talk about business efficiency for software developer, dont make me force you to look at it ;)
[13:29:49] <Lambda_Aurigae> guess I don't understand how you are sending data to the lcd either.
[13:30:03] <Lambda_Aurigae> looks like 4bit mode almost but you are missing half the send.
[13:30:19] <Lambda_Aurigae> oh..you call it twice.
[13:30:32] <nollan> Lambda_Aurigae: yep
[13:30:35] <Getty> its really hard to imagine other peoples setup if you dont have the hardware in front and what is the target
[13:30:41] <Lambda_Aurigae> look at peter fleury's lcd code.
[13:31:12] <Lambda_Aurigae> http://homepage.hispeed.ch/peterfleury/avr-software.html
[13:31:22] <Lambda_Aurigae> there is an lcd library and a uart library
[13:31:43] <Getty> i used a i2c-ASM implementation and did the commands 1:1 like my dad did with BASCOM ;)
[13:32:31] <Getty> https://gist.github.com/Getty/6ca533b23bdf4369dc8d
[13:33:47] <Lambda_Aurigae> I combined fleury's 3 libs into one program to do uart comms to an lcd connected via i2c port expander.
[13:34:15] <Getty> just for completion also here a precise delay function:
https://gist.github.com/Getty/dbfcc9460853b8b7a8bc
[13:36:16] <nollan> thanks
[13:36:31] <Lambda_Aurigae> fleury's stuff is old but still works well.
[13:36:39] <Lambda_Aurigae> and the lcd and uart libs work well together.
[13:37:12] <nollan> nice, I will take a peak
[13:40:18] <nollan> the weird thing is when I powercycle the chip; it continues execution... wtf ?
[13:40:51] <Lambda_Aurigae> or it restarts and goes through one loop and hangs up again?
[13:42:10] <nollan> the lcd gets initialized, but then execution stops or something.. but if I power cycle the lcd_send_char() gets executed and also the code within the while(1) loop runs perfectly fine
[13:42:24] <Getty> you do know that the lcd display remembers, right?
[13:42:37] <nollan> sure
[13:42:43] <Getty> so what you see "after powercycle" could be the last displayed "before powercycle" just saying
[13:43:04] <nollan> yeah, thought of that as well.. but then the code within the while(1) loop...
[14:39:20] <nollan> USBCON = 0; did it
[14:39:45] <nollan> :/
[15:43:31] <Arch-TK> So I bought this cheap chinese usbasp clone from betemcu.cn and I bought some attiny85s, I correctly connected the attiny to the usbasp and checked things worked by setting fuses. Then after trying to flash a .hex the thing seemed to never write correctly (constant verification failures on the first byte)
[15:43:37] <Arch-TK> After about 30 tries, the thing flashed.
[15:43:51] <Arch-TK> I tried a bunch of other attinys and they all seemed to exhibit the same behaviour.
[15:44:31] <Arch-TK> What could be causing the issue of being able to set the fusebits fine, but not being able to write the ihex to the thing?
[15:45:11] <Arch-TK> I put a 10 µF cap on the power of the thing, and that didn't really do much as far as I could tell.
[15:45:44] <Arch-TK> As you can tell, I'm obviously a professional EE because of all this amazingly technical language I'm employing.
[15:45:54] <antto> i had exactly the same experience (with an atmega) and the same betemcu usbasp
[15:46:09] <antto> it was always failing the verification in avrdude
[15:46:21] <Arch-TK> antto: Are the betemcu usbasps shit and should I scour ebay for another cheap clone of a clone?
[15:46:26] <antto> but when i did a flash dump - the stuff was there
[15:47:19] <Arch-TK> antto: when I dumped the flash it didn't appear there was anything... I think I did that correctly avrdude ... -U flash:r:output.hex:i
[15:48:25] <antto> well, mine is shit.. it suddenly started to act as if it gets disconnected from the computer right when it begins flashing a chip, or just randomly
[15:48:45] <antto> i changed cables, changed usb ports, changed computer and OS - same thing
[15:50:21] <Arch-TK> antto: do you know of a non-shit, guaranteed to work, slightly less expensive than the real deal, replacement?
[15:53:27] <antto> *shrug*
[15:53:40] <antto> i use parallel port now
[15:55:21] <Arch-TK> hmm, I got it to flash again...
[15:55:50] <Arch-TK> I guess it's just being shitty and intermittent, maybe it's this breadboard... I'll have to find a zif socket and build a proper board to flash these things with...
[15:56:10] <Arch-TK> thanks for your time.
[15:56:56] <antto> i also got a olimex avrisp2 at work, but i haven't yet used it
[16:18:00] <RikusW> Arch-TK: why mess with the fuses in the first place ?
[16:18:13] <Arch-TK> RikusW: just to make sure they're set to default.
[16:18:17] <RikusW> try flashing without first setting fuses
[16:18:27] <Arch-TK> RikusW: I don't first set the fuses.
[16:18:31] <RikusW> rather read the signature as a connection test
[16:18:37] <RikusW> ah
[16:18:43] <Arch-TK> RikusW: and the signature gets read fine
[16:19:13] <RikusW> ISP clock might be too high
[16:19:15] <Arch-TK> RikusW: after jiggling the wires a bit and re-running the flashing about 20 times it seems to work
[16:19:18] <RikusW> or not
[16:19:27] <Arch-TK> about 1 in 20 times
[16:19:34] <RikusW> Doesn't sound good at all...
[16:19:45] <Arch-TK> Well, this thing did cost £1.50
[16:21:30] <Jartza> I use -B4 with avrdude with el-cheapo-chinese-usbasp-clone
[16:21:49] <Jartza> faster speeds fail sometimes randomly
[16:21:59] <lem> Wow I did not expect this chatroom to be so populated. Is anyone aware of a way to theme/color Atmel Studio 6.0? I'm stuck using it for a semester and it's just darned bright to be looking at for hours on end late at night.
[16:27:39] <Arch-TK> holy shit, a blinking LED, I feel that the sheer amount of shitty luck I've had with this usbasp clone makes seeing a blinking LED way too exciting.
[16:34:03] <RikusW> lem: adjust the screen ?...
[16:34:30] <RikusW> or the windows theme, though it seems to hard on newer versions of windows... :/
[16:37:51] <lem> Well, I also just flat out prefer darker colors :). I'm surprised there isn't a reasonable easy way to theme Atmel Studio.
[16:38:02] <lem> f.lux is only so effective at night.
[17:09:47] <Arch-TK> I just remembered, there's a project to turn the attiny85 into a usb 1.1 programmer (Yes someone wrote a usb lib which can fit on an attiny85 and someone worked out how to use that to make an isp out of one)
[17:10:09] <Arch-TK> I could try my luck with that.
[18:13:59] <Lambda_Aurigae> Arch-TK, that's the same software used on the usbasp...
[18:14:05] <Lambda_Aurigae> it's called v-usb
[18:14:13] <Arch-TK> I see.
[18:14:14] <Lambda_Aurigae> bitbanged usb on the avr.
[18:14:19] <Lambda_Aurigae> which is a fun toy
[18:14:28] <Lambda_Aurigae> but I would never rely on it for anything more than being a toy.
[18:15:43] <Lambda_Aurigae> I've futzed with avrasp programmers on and off since v-usb came about and never had solid luck with them.
[18:15:52] <Lambda_Aurigae> my stk200 clone always works though.
[18:16:10] <Lambda_Aurigae> as does the programmer I got from Tom_itx that is based on an avr with hardware usb.
[18:21:53] <antto> ++stk200;
[18:25:45] <Lambda_Aurigae> just needs a parallel port.
[18:26:39] <antto> yez.. with many pinz
[18:58:16] <lem> Can anyone help me out with some basic C and a header file? I've created a simple definition to toggle the onboard LED on PB5 (and set the port as an output) on this atmega328p. It works great. However, I'm trying to learn to move my functions to header files. When I move this stuff to a header file, the onboard LED still toggles but is very
[18:58:16] <lem> dim. I'm quite puzzled. Any thoughts?
[19:01:02] <Lambda_Aurigae> you broke something.
[19:01:24] <Lambda_Aurigae> without seeing code, no way to know.
[19:01:49] <lem> lol. only partially, apparently :). If I put the code back into the main .c file it goes back to bright.
[19:02:04] <lem> is there an easy way to share code that people here prefer?
[19:02:09] <Lambda_Aurigae> pastebin
[19:06:05] <lem> ahh, in typing up my question and pasting it I MAY have found the problem... is there a way to get a header file to execute a function?
[19:06:32] <Lambda_Aurigae> a header file is just another source file... .h or .c are just for convenience.
[19:07:04] <lem> when I #include it, is there a way to get it to execute something within it upon being included?
[19:07:30] <Lambda_Aurigae> an #include just puts the code from the included file in that place.
[19:07:37] <Lambda_Aurigae> it doesn't execute...
[19:07:56] <Lambda_Aurigae> it's just text that gets included into the file.
[19:08:40] <lem> well. i feel foolish. that makes this make a lot more sense.
[19:09:23] <Lambda_Aurigae> nothing "executes" until you compile it and load it onto the chip.
[19:10:35] <lem> and there we go! thank you, that understanding made me change some things around, and now it works.
[19:11:06] <lem> I wasn't properly calling the function that sets the pin as an output, so I was toggling the onboard LED without it actually being an output. Thus, dim LED.
[19:11:20] <lem> Now that I realize how that works, I was able to reorder things.
[19:11:21] <lem> Thanks!
[19:11:48] <Lambda_Aurigae> welcome.