#avr | Logs for 2016-04-19

Back
[00:09:18] <WormFood> phinxy, I'm running my 12 MHz crystal, without any caps :P It seems to work fine (I won't go to production that way tho)
[00:20:49] <WormFood> [07:18:03] <phaeton> ...my impression from reading is that the arduino platform adds an extra layer on top of the avr <-- Can someone define what "Arduino" actually is? Is it a software layer, or a hardware layout, or both, or some other characteristic, that makes an AVR into an Arduino? I feel the biggest thing that makes an AVR into an Arduino, is their bootloader, with the second thing being their shitty software stack/layer.
[00:21:33] <Mr_Sheesh> brand name on the PC board & the shield connectors maybe
[00:21:58] <Mr_Sheesh> plus the bootloader etc. & the crappy slow Processing libs
[00:22:25] <WormFood> Since it is open source hardware, the name means nothing. The pinout is nothing special.
[00:22:59] <WormFood> You can make your own Arduino, and not even use their hardware layout (pin configuration for the shields, and whatever)
[00:24:24] <WormFood> I have an "Arduino". I played around a little bit with their software and stuff, and that was it. I didn't try to do any real work with it. I promptly erased their bootloader, and been using straight avr-gcc since then.
[00:25:21] <WormFood> And the USB interface, is more or less just another AVR, programmed to be a usb-to-serial converter, which can be reprogrammed for other things.
[00:26:06] <phinxy> WormFood, i ran mine with crystal caps and decoupling caps but forgot pull-up resistor to reset. When i turned on a HID ballast completely separate from the circuit it rebooted and sometimes eeprom corrupted
[00:26:34] <WormFood> Of course, that depends on the model. Some used usb-serial converter ICs, and the ancient ones used straight serial, but the more modern ones use another avr.
[00:27:11] <WormFood> phinxy, that sounds interesting.
[00:27:33] <WormFood> I thought the reset line has an internal pull-up resistor
[00:49:31] <phinxy> WormFood, aw. it might not be the issue then
[02:48:50] <anton02> you ever made a pcb for a cortex m7?
[03:09:02] <skz81> WormFood, AFAIK you're almost right about what is an Arduino, when you dissecate it. There is no special interest for any skilled AVR user, but it's magical for newbies : you can start for few bucks with an arduino and some leds, given you know C basics
[03:11:07] <skz81> then drop IDE, then the lib, etc... But, so far, I do not complain of the bootloader. What is its problem, according to you, WormFood ?
[04:32:18] <inflex> ja, no fan of having an IDE/Arduino
[05:57:39] <WormFood> skz81, your question makes no sense, and is not based on what I said. Please reread my comment, and pose a new question for me.
[06:00:39] <skz81> WormFood
[06:03:29] <skz81> WormFood, what is your favorite color ? ^^ Seriously : why did you "promptly erased their bootloader" ?
[06:04:03] <cehteh> the arduino bootloader has some glitches
[06:04:14] <cehteh> for most people it works anyway
[06:04:14] <skz81> WormFood, You seems implying you dislike it...
[06:04:19] <WormFood> skz81, what makes you think I have a problem with their bootloader?
[06:04:47] <WormFood> I never said that. Their bootloader is the only thing they have going for it.
[06:06:05] <WormFood> The bootloader doesn't mean shit to me. It doesn't help me, do what I want to do with my AVR, and prevents me from using my AVR in the manner that I want to use it in.
[06:07:16] <cehteh> i keep it on development boards .. and when its size and boot-delay doesnt matter
[06:07:33] <cehteh> the more annoying part is the DTR-Reset thing which i often remove
[06:08:26] <skz81> WormFood, ok, sorry for the misunderstanding.
[06:08:55] <skz81> cehteh : isn't that the UART problem at some rate vs. CPU frequency ?
[06:10:50] <cehteh> no
[06:11:05] <Mr_Sheesh> many duino boards have the standard 6- or 10-pin upload connector anyways
[06:11:06] <cehteh> arduinos are hardwired to reset when you plug usb in
[06:11:17] <LeoNerd> Not -quite-
[06:11:32] <LeoNerd> They reset because of DTR. It depends what you've got DTR doing
[06:11:50] <skz81> <cehteh> the arduino bootloader has some glitches <== was telling about this sentence
[06:11:53] <cehteh> well thats the default for most OSes
[06:12:12] <cehteh> you can disable that
[06:12:50] <cehteh> but if you dont want resets because of accidentally misconfigured serial ports then you better disable it by cutting that trace
[06:14:11] <cehteh> skz81: that was discussed here before, the arduino uses the stk500 protocoll with some minor changes/incompatibilities
[06:14:32] <cehteh> dunno the details, works for me
[06:15:10] <skz81> cehteh, ok, thanks :)
[06:15:15] <cehteh> and of course sometimes you dont want the bootloader delay that long, or start the bootloader only explicitly when some button is pressed or whatever
[06:15:48] <cehteh> arduion always goes into the bootloader timeout for sake of simplicity
[06:16:37] <cehteh> with a more customized bootloader you can make it entering this only by pressing reset or pulling some other pin to some potential
[06:18:45] <LeoNerd> I usually just ISP right over the arduino loader anyway
[06:18:54] <LeoNerd> At least on the mega328 based boards
[06:19:05] <LeoNerd> I still have the bootloader on the 32U4 board because that one is actually useful
[06:38:55] <WormFood> On some of these V-USB schematics, I'm seeing a 3.6 volt zener diode, on the data lines. At first, I thought it was to prevent the usb data lines, from sending too high of a voltage to the MCU, but now I'm thinking it's to keep the voltage from the 5 volt powered MCU closer to the usb specs. If my MCU is running at 3.3 volts, I don't need those zener diodes, right?
[06:40:18] <inflex> I still put them there "just in case"
[06:40:29] <inflex> 2c/diode *shrug*
[06:40:49] <WormFood> I think it is totally unnecessary if already running at 3.3 volts.
[06:41:04] <WormFood> I notice that some schematics omit them.
[06:42:42] <cehteh> should be ok
[06:43:40] <WormFood> a 3.3 volt avr is 5 volt tolerant, so I expect it will be perfectly ok, but maybe not the other way around.
[06:45:35] <cehteh> no its not
[06:46:07] <cehteh> pins have diodes to gnd and vcc .. according to spec its vcc+0.5V
[06:46:38] <cehteh> higher voltage gets through that diodes .. potentially drawing too much current if thats not limited
[06:47:29] <cehteh> short spikes mmkay .. but its not really tolerant when you have 5V signals w/o current limit
[06:47:43] <cehteh> (aka resistor on input)
[06:56:50] <cehteh> (AFAIK the specs of the clamping diodes, esp how much current they can sink isnt mentioned in the datasheets, they are only there for ESD protection, you shouldnt rely on them)
[07:04:10] <Haohmaru> in avrgcc, are all the usual headers like io.h, delay.h, .. part of avrgcc or part of avrlibc? or a bit of both?
[07:04:25] <WormFood> libc, of course
[07:04:34] <Haohmaru> all of them?
[07:04:53] <WormFood> I don't think you understand what a C compiler is, and how it relates to the libraries.
[07:04:58] <WormFood> Yes, of course, all of them.
[07:05:15] <Haohmaru> correct, i don't know wtf i'm doing ;P~
[07:05:38] <Haohmaru> configure, make, configure, make, fail fail fail, oops, damn, again
[07:05:51] <WormFood> C is an extremely small language.
[07:06:19] <WormFood> By itself, C is very powerful, but with the standard libraries, it becomes incredibly flexible.
[07:06:27] <Haohmaru> it *SEEMS* i built avrgcc 5.3.0 for windowz, and i just didn't see any familiar header files..
[07:06:35] <Lambda_Aurigae> WormFood, you mentioned earlier running with a crystal without caps...doing it on a solderless breadboard?
[07:06:40] <Haohmaru> well, i need c++ too
[07:07:40] <Lambda_Aurigae> WormFood, I've run with crystal on solderless breadboard many times...there is a lot of excess capacitance in those things, even enough for the crystal circuit.
[07:07:55] <WormFood> Lambda_Aurigae, yeah. I was suspecting that the breadboard has enough stray capacitance to get it running.
[07:08:21] <Lambda_Aurigae> Haohmaru, avr-gcc is just the compiler...should have C++ as well if compiled correctly....avr-libc is all of your C and C++ libs and headers and such.
[07:08:48] <Haohmaru> okay, so imma be building tEh avrlibc nao then
[07:08:51] <Lambda_Aurigae> avr-binutils or binutils-avr(depending on your distribution) is the final assembler and other binary utils.
[07:09:07] <Haohmaru> i already built that one
[07:09:55] <Lambda_Aurigae> there a reason you are building and not using the latest prebuilt release?
[07:10:07] <Haohmaru> the latest is from 2010
[07:11:03] <Lambda_Aurigae> have you checked out the latest from atmel site?
[07:11:18] <Haohmaru> the structure of my build doesn't quite look like the winavr structure, but oh well
[07:11:34] <Haohmaru> uh, atmel distribute avrgcc?
[07:11:40] <Lambda_Aurigae> uh, yeah.
[07:11:46] <Haohmaru> i didn't know that
[07:12:12] <Haohmaru> why do i have the impression that the only place to get avrgcc for windows is from winavr?
[07:12:24] <Lambda_Aurigae> winavr is the official windows port.
[07:12:35] <Lambda_Aurigae> which was kinda stopped when atmel started officially supporting it
[07:12:36] <WormFood> I don't know. Why do you have that impression Haohmaru
[07:12:39] <Lambda_Aurigae> now the place to get it is from atmel.
[07:12:48] <Lambda_Aurigae> http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx
[07:12:51] <Haohmaru> x_x
[07:12:58] <Lambda_Aurigae> updated march 2016
[07:13:00] <Haohmaru> why..
[07:13:02] <WormFood> You can tell that atmel is involved, because of the copyright notice at the top of the header files.
[07:13:06] <Haohmaru> didn't i know about this
[07:13:10] <Haohmaru> >:(
[07:13:20] <Lambda_Aurigae> avr-gcc is officially part of atmel studio even.
[07:13:28] <Haohmaru> i don't want atmel studio
[07:13:34] <Haohmaru> not at all
[07:13:36] <Lambda_Aurigae> didn't say you did.
[07:13:41] <Lambda_Aurigae> on that above link
[07:13:41] <Lambda_Aurigae> is
[07:13:42] <Haohmaru> just sayin
[07:13:48] <Lambda_Aurigae> atmelavrtoolchainforwindows
[07:13:53] <Lambda_Aurigae> not atmel studio.
[07:14:25] <Lambda_Aurigae> atmel has actually been actively involved in development of the avr-gcc toolchain.
[07:14:51] <theBear> how actively ? and pfft, who cares, bout time they started towing some of the weight
[07:15:09] <Haohmaru> well, i feel stupid now
[07:15:15] <theBear> recklessly pumping out superawesome chips for around adecade now, but no compilers or programmers to be seen <grin>
[07:15:36] <Haohmaru> i've beein trying to build this thing for a bunch of days already, and.. bleh
[07:15:59] <Lambda_Aurigae> Haohmaru, you following the build procedures or just freehanding it and trying to figure it out?
[07:16:01] <theBear> meh, i been trying to get my body in the shower about 10' and a couple doorways from this chair almost 5 hours now
[07:16:29] <Haohmaru> Lambda_Aurigae, i followed the tutorial on the savannah website
[07:16:46] <Lambda_Aurigae> and, compiling for windows can be a pain anyhow.
[07:17:00] <Lambda_Aurigae> I tried it once, some years ago, before I deleted all trace of windows from my computers.
[07:17:18] <Haohmaru> tried to do it via mingw/msys first, then from linux, then again from mingw/msys, then cygwin, then msys2.. and finally now i think i succeeded with linux
[07:17:27] <Haohmaru> at least the compiler
[07:18:23] <Haohmaru> yup, all attempts failed in all kinds of wonderful ways >:)
[07:19:21] * theBear confirms that not-trying-that-hard it is quite impossible to make any mingw or cross-os anything compiley/sensible, but fortunately never cared cos he had already search and destroy missioned the ms-menace, and i don't mean those sclerosis dudes from the hospimable either
[07:19:38] <theBear> heh, you'd think more sclerosises would be better than less :)
[07:20:06] <theBear> a guy with nerves like me these days probly shouldn't joke about these things, in case of vengeful god(s)
[07:20:32] <Lambda_Aurigae> theBear, if god doesn't have one hell of a sense of humor then we are all fucked.
[07:20:50] <Haohmaru> god is nullptr
[07:20:52] <Haohmaru> ;P~
[07:21:01] <Lambda_Aurigae> ok..let me rephrase.
[07:21:17] <Lambda_Aurigae> if god is real then she better have one hell of a sense of humor then we are all fucked.
[07:21:19] <theBear> ummm no <grin>
[07:21:49] <theBear> aww, always the she in the afterthought/ass-cover rephrase, i expect something more original from the likes of you heh
[07:22:15] <theBear> that's as cliche as a mentally unstable dude called theBear :)
[07:22:27] <theBear> or maybe it isn't, hard to say
[07:22:30] <Lambda_Aurigae> that's a line I've used for many years, right back to when I was in high school, just to piss off my parents.
[07:22:33] <Haohmaru> pls, stabilize yourself
[07:22:50] <theBear> Lambda_Aurigae, but i don't know that, and seen too many hollywood types steal it in the meantime
[07:23:08] <Lambda_Aurigae> I prolly stole it from one of them way back when.
[07:23:16] <theBear> Haohmaru, no time, stupid chairs and their ever-wiggling+loosenering fixingery
[07:23:20] <theBear> fixingsery ?
[07:23:40] <theBear> fixins'ry, yeah, that's the winner ;-]
[07:23:41] <Lambda_Aurigae> x86 is proof that the devil exists and has a hand in the world.
[07:23:57] <Haohmaru> what's wrong with x86?
[07:24:06] <Lambda_Aurigae> you ever done x86 assembly?
[07:24:08] <theBear> there's proof of the nature of evil in my cupboards ?
[07:24:18] <Haohmaru> i don't speak assembly at all
[07:24:26] <Lambda_Aurigae> try it sometime.
[07:24:30] <Haohmaru> nononono
[07:24:35] <theBear> don't be silly, even 512kb and a few mhz is way too heavy for me to asm, specially before i was 10 hehe
[07:24:51] <Mr_Sheesh> Lambda_Aurigae, yeah, segmentation sorta sucks but it's not that bad
[07:25:25] <theBear> i have retrofitted a tape drive to a fairly early but post tape-rom/traditional-ref-bios-hooks actually working machine, long long ago
[07:25:43] <theBear> Mr_Sheesh, i think you use something called defrag to fix that suck
[07:25:53] <Lambda_Aurigae> ok..time for to go to worky.
[07:25:54] <Lambda_Aurigae> laters.
[07:26:12] <theBear> okey, later, tater
[07:26:30] <Mr_Sheesh> theBear - Nope I mean having to use a segment register with another register for 640k etc. access
[07:26:31] <Haohmaru> what time is it there?
[07:26:36] <Mr_Sheesh> like ES:DX
[07:26:56] <theBear> nighttime
[07:27:06] <theBear> oh lol
[07:27:10] <WormFood> It's 8pm here
[07:27:29] <Haohmaru> you must be on the wrong side of tEh planet
[07:27:32] <Haohmaru> >:)
[07:27:35] <Tom_itx> 7am you're up past your bedtime
[07:27:46] <Lambda_Aurigae> is 7am here.
[07:27:59] <twnqx> 2pm. you ae ALL wrong.
[07:28:01] <Lambda_Aurigae> what the fuck is "tEh planet"?
[07:28:06] <WormFood> wrong side of the planet? I'm on the side of the planet with all the hot asian chicks. I prefer to think I'm on the best side of the planet.
[07:28:08] <theBear> some teen thing
[07:28:16] <Lambda_Aurigae> kids these days,,,sheesh.
[07:28:18] <theBear> there's a side for that ?
[07:28:46] <theBear> and there's hot asian ladies ? crazy white dudes and their inexplicable fetishes
[07:29:16] <skz81> Lambda_Aurigae, a kind of big stone floating in space, but that's not the question right now
[07:29:24] <WormFood> I met this girl the other day. I asked her how old she was, and she said 34. She looks like she is 24
[07:29:42] <theBear> cool story bro !
[07:30:07] <WormFood> I met a girl, that was 37 or so, with the body of a 16 year old. It was weird.
[07:30:22] <theBear> some kinda psycho killer i assume?
[07:30:23] <WormFood> And the brain of a 10 year old.
[07:30:34] <theBear> ahh, a frankenpsycho
[07:30:58] <Haohmaru> Lambda_Aurigae, i intentionally misspell "the" but xchat fixes it.. unless i capitalize the E ..
[07:31:19] <WormFood> You still use xchat?
[07:31:30] <WormFood> I quit using that a year or two ago.
[07:31:35] <Haohmaru> i'm on kubuntu right now
[07:31:50] <WormFood> Oh. I'm sorry.
[07:31:52] <cehteh> thats probably how many people get my nick wrong
[07:31:56] <Haohmaru> yep, i'm sorry too
[07:32:02] <WormFood> Were you not able to get a real distro? ;P
[07:32:07] <Haohmaru> linux doesn't like me
[07:32:23] <WormFood> Linux is very user friendly....
[07:32:28] <WormFood> ...it's just pick about it's friends.
[07:32:34] <WormFood> picky*
[07:33:07] <WormFood> Haohmaru, once you understand the unix philosophy, you should have a much easier time working with it.
[07:34:13] <Haohmaru> by the time i understand the unix philosophy, imma turn into santa - long WHITE beard
[07:34:27] <Tom_itx> until they update it and everything changes
[07:34:37] <Haohmaru> ..yeah
[07:34:57] <Haohmaru> the other beards
[07:35:02] <WormFood> I was using unix-like OSes back in the 80s
[07:35:17] <Tom_itx> are you bald?
[07:35:17] <WormFood> When I got my first Linux machine, I was right at home with it.
[07:35:22] <WormFood> nope
[07:35:49] <Haohmaru> i'm surrounded by h4x0rz
[07:35:49] <WormFood> I've had my eye on Linux since '92. I've been running it since '95.
[07:35:51] <Tom_itx> i don't mind linux however i don't like inconsistent changes in updates
[07:36:25] <WormFood> Haohmaru, I used to write a lot of assembly language, for smart cards. To get free satellite tv. This was years ago, which is why I can talk about it now.
[07:36:35] <Tom_itx> and version changes breaks lots of programs
[07:36:49] <WormFood> Tom_itx, what are you talking about? can you be more specific?
[07:37:33] <Tom_itx> it's been quite a while since i tried much with it but one thing that comes to mind is updating ip information
[07:38:13] <Haohmaru> i have one example of how dumb some things are.. i got ubuntu at home, i cannot configure the mouse to be usable, it either has acceleration (which i hate) or no acceleration but then i cannot control the mouse speed x_x
[07:38:18] <Haohmaru> how dumb is that
[07:38:37] <Tom_itx> usb is another issue
[07:38:48] <WormFood> How likely is, that it actually does what you want, but you don't know how to configure it?
[07:39:02] <Tom_itx> the way it is configured changes
[07:39:16] <Haohmaru> yeah, i know, it's linux.. if you don't quite like something - configure it, or configure it more deeply, or rewrite it
[07:39:22] <WormFood> well, not withstanding, that's not a Linux issue.
[07:39:43] <Tom_itx> it's not a windows issue for sure
[07:39:44] <WormFood> You're talking about software that runs under Linux.
[07:39:53] <WormFood> Linux doesn't know much about mouses.
[07:40:32] <WormFood> A baby seal walks into a club
[07:40:44] <Tom_itx> anyway, all os's have their own little issues...
[07:40:53] <WormFood> What is an OS?
[07:40:58] <Tom_itx> leave the poor baby seals out of it
[07:41:05] <Tom_itx> operating systems
[07:41:10] <WormFood> It was his fault, for walking into a club
[07:41:23] <WormFood> I didn't ask what OS means. I asked what is an OS. Define it.
[07:41:27] <Haohmaru> go hom seal, ur drunk
[07:41:54] <Haohmaru> a system, that operates?
[07:41:55] <Tom_itx> the 2nd defining layer between hardware and dumb user
[07:42:03] <Haohmaru> hahah
[07:42:19] <Tom_itx> err possibly 3rd
[07:42:29] <Tom_itx> anyway, gotta run..
[07:42:38] <Haohmaru> gotta switch to windowz
[07:42:50] <Tom_itx> i run several flavors of both
[07:43:04] <WormFood> I rarely run Windows on bare metal. I almost always run it under vmware.
[07:43:06] <Haohmaru> i just prefer mIRC
[07:43:16] <WormFood> wow!
[07:43:26] <WormFood> Mirc is like the shittiest IRC client I've ever experienced.
[07:43:31] <Tom_itx> heh
[07:43:59] <Haohmaru> WormFood >:(
[07:44:02] <WormFood> You do know, that x-chat/hexchat are configurable? You can change how it looks and feels. You can make it look and feel more like mirc, if you so choose.
[07:44:33] <Haohmaru> i use mIRC as many many things besides irc
[07:44:35] <WormFood> For the longest time, mIrc was the biggest member of the "Exploit of the Week Club"
[07:45:02] <WormFood> Haohmaru, what is your native language?
[07:45:07] <Haohmaru> bulgarian
[07:45:17] <WormFood> cool
[07:45:22] <Haohmaru> why?
[07:45:28] <WormFood> I don't know many people that can speak Bulgarian.
[07:45:38] <WormFood> I was just curious.
[07:45:49] <Haohmaru> there are about seven million roughly ;]
[07:45:55] <WormFood> 我会说一点点中文
[07:45:58] <Haohmaru> wat
[07:46:09] <WormFood> I can speak a little bit of Chinese (Mandarin)
[07:46:11] <Haohmaru> you'll break my xchat
[07:46:16] <WormFood> heh
[07:46:32] <Haohmaru> ah, nah.. it won't break, it's not an iphone >:)
[07:46:57] <Haohmaru> okay.. brb
[07:53:36] <Haohmaru> ah, atmel require me to fill details about myself before downloading teh avrgcc
[07:54:08] <Haohmaru> i don't quite like that sort of stuff
[08:01:03] <Haohmaru> well, it includes avr gcc 4.9.2
[08:29:28] <anton02> where can i find the 2nd biggest electronics channel on freenode
[08:47:41] <LeoNerd> The second biggest? Why do you want that?
[08:48:00] <LeoNerd> Is the biggest one perhaps a little -too- big for your liking?
[09:29:12] <dunz0r> LeoNerd: The biggest is most likely EEVBlog
[09:42:57] <LeoNerd> dunz0r: having a channel on freenode?
[09:43:03] <LeoNerd> I'd have thought ##electronics is quite big
[09:43:41] <Haohmaru> i've heard some.. not very good things about that channel ;P~
[09:43:43] <dunz0r> Oh, I misread. I thought he wanted the second biggest youtube-channel.
[09:44:53] <dunz0r> Haohmaru: It's a bit so and so... It depends if some of the super-asshats are on or not. :)
[09:48:14] <Haohmaru> yeah, that's what i've heard too
[09:49:05] <Haohmaru> there are other more thematical electronics channels, one such might be more suitable, if exists
[09:50:00] <dunz0r> #kicad is quite friendly, #arduino as well.
[09:58:12] <dunz0r> Speaking of absolutely nothing... I've got a bunch of DIP Attiny85s that I bought on a whim, but I can't think of any good project to use them for... any ideas?
[09:59:38] <LeoNerd> I'll tell you what I'd love
[09:59:47] <LeoNerd> An SPI or I²C-attached WS2812 offload chip
[09:59:57] <theBear> i2c/smbus fan/temp sense + pwm control add-ons (pref impersonating something appropriate that already common and drivered) for pcs
[10:00:03] <theBear> effit, what leo said :
[10:00:06] <LeoNerd> Something that performs all the tricky timing-based "talking to WS2812" and lets me talk to -it- over SPI or I²C or something
[10:00:11] <theBear> or do i mean ws8212
[10:00:18] <LeoNerd> 2812.. what Adafruit calls "neopixel"
[10:00:22] <theBear> mmm, not what he said
[10:00:27] <dunz0r> LeoNerd: Now that is a pretty good idea.
[10:00:29] <LeoNerd> Personally I prefer to use the APA-102s as they're already an SPI chain. They're nice
[10:00:41] <LeoNerd> dunz0r: This I want becauseI need to talk to 90 of those LEDs while receiving DMX-512
[10:00:47] <LeoNerd> I have plenty of code ideas for you if you want hints
[10:00:56] <theBear> i thinking a common pc mobo multi handy sensor/this and that chip or maybe even an older southbridge or floppy/keyb controller in thecase of that part no
[10:01:17] <theBear> aww. pixeldata over dmx, universes collapsing all in my mind
[10:01:21] <dunz0r> Just need to get me some of those LEDs, been planning to for a while
[10:01:40] <LeoNerd> eBay has big long tapes of them cheap
[10:01:45] <LeoNerd> I got 5m of 60/m tape
[10:01:58] <theBear> yeah, i worked out a bunch of things like taht one i just mentioned LONG ago and still not got to em, i got tips/ideas for how to do almost everything there could possibly be on a tiny avr micro :)
[10:02:30] <LeoNerd> The trick I found is that a 16MHz AVR chip is plenty fast enough to talk to the WS2812 chain in hand-rolled assembly, with lots of NOP instructions inbetween
[10:02:57] <LeoNerd> So.... if you're -really- cunning, you can thread a second program into those NOP slots
[10:03:14] <LeoNerd> Provided you don't branch enough to upset timing, and you restore flags/registers to how the WS2812 driver wants them, you're all set
[10:03:33] <dunz0r> LeoNerd: That does sound like a fun challenge... I'll have to get me some WS2812-tape
[10:03:40] <LeoNerd> In that second thread, there's enough cycles spare to service the UART or SPI port just enough to shuffle bytes into a RAM buffer
[10:03:59] <LeoNerd> You don't need to interpret it, you just need to keep the buffer going, so that when you get to the end of an LED run, you can process the buffer afterwards
[10:04:08] <LeoNerd> I needed to do this because DMX512 comes at the fast serial rate of 250kBaud
[10:05:18] <LeoNerd> I might publish that sometime.. my WS2812+UART driving code
[10:11:39] <LeoNerd> I reckon I could adapt it to do 2812 + SPI-over-USI quite easily
[10:11:50] <LeoNerd> I²C might be harder.. needs more cycles in the slave to make it work
[10:12:15] <LeoNerd> But then, you've got enough pins even on a tiny85 to do that - 1 pin for WS2812, 3 pins for USI DI/DO/CLK, 1 pin for SS. Perfect. :)
[10:12:39] <LeoNerd> In faaaact... if you play RSTDIS games with HVSP you could drive -two- independent 2812 chains ;)
[10:12:49] <LeoNerd> Or have a spare GPIO pin or PWM or whatever
[10:13:12] <theBear> it's a pretty darned minimal "protocol"/packet structure, and old discrete 90s ttl and cmos could keep up without buffering it, that's why it comes in with the break to find the start of frames easily, and the simple sequential from there deal
[10:13:26] <theBear> dmx that is
[10:13:46] <LeoNerd> Yah
[10:14:21] <LeoNerd> The DMX half of the UART driver consists of a memory location that knows a "skip" count after a break, and a "length" of bytes to then read into the buffer
[10:14:31] <LeoNerd> So you put the device's address as that skip count
[10:42:36] <Haohmaru> when talking to a UART from a linux terminal, there seems to be some settings like "16550A" and such, what should be selected there?
[10:43:00] <LeoNerd> Hm?
[10:43:10] <Haohmaru> on the linux side i mean
[10:43:25] <LeoNerd> You'll have to start the question again.
[10:43:37] <LeoNerd> "there seems to be some settings" ... in what program? Where do you see these settings?
[10:43:51] <Haohmaru> some gtk terminal or so
[10:44:05] <LeoNerd> *shrug* Whoknows then
[10:45:53] <Haohmaru> not me.. i gave something which features a microcotroller and a max232 converter to a "guy" who should talk to the device, but he says it ain't working, seems the data is getting corrupted totally.. and he mentioned that he has some additional options besides what i instructed him to do (8bits, 1 stop bit, no parity, no flow control, 19200)
[10:46:23] <LeoNerd> 19200,8,n,1 is pretty standard, and should be sufficient to characterise the serial setup
[10:46:38] <LeoNerd> Possibly also some idea of flow control
[10:46:52] <LeoNerd> But you'd hope that neither the PC not an AVR chip is going to need flowcontrol at that rate
[10:46:54] <Haohmaru> i'm not using flow control on the mcu side
[10:47:28] <LeoNerd> I'd apply usual UART debugging trickery. Check baud rates. Twice.
[10:47:36] <LeoNerd> Then apply logic analyser. Check baud rates a third time
[10:47:46] <LeoNerd> Then check things like MCU clock rate in case of mistakes there. I've had that before
[10:47:58] <LeoNerd> My baud settings were correct for a 16MHz MCU. Except the MCU was running at 8 ;)
[10:47:59] <Haohmaru> the guy probably doesn't even have a screwdriver there ;P~
[10:48:18] <Haohmaru> the device worked here before i gave it to the guy
[10:48:39] <Haohmaru> so the mcu side is proper
[10:49:37] <Haohmaru> when he sends a byte, my mcu appears to be seeing it, as 0xFF or 0xFE or so (quasi-random but it seems mostly high bits)
[10:49:49] <LeoNerd> Could well be a baud issue
[10:50:11] <LeoNerd> 0xFF might just be seeing the START condition as all the data bits, if the MCU was running a lot faster
[10:50:11] <Haohmaru> there must be some kind of downwards spike to cause it to start receiving a byte, so it's not totally wack
[10:50:27] <LeoNerd> Ahyes, a noisy line might also be creating false starts
[10:50:33] <LeoNerd> ... pardon the pun
[10:50:47] <Haohmaru> nah, it seems to only happen when he INDEED sends a byte
[10:50:57] <Haohmaru> just the byte values tend to be 0xFF
[10:51:28] <Haohmaru> but the mcu side is okay, i unplugged it from here and gave it to the guy.. it worked here of course
[10:51:44] <Haohmaru> 19200 fo sho ;]
[10:54:33] <Haohmaru> oh wellz.. i blame the aliens
[10:54:49] <Haohmaru> and/or linux >:)
[10:56:58] <skz81> no clue where he found this "16550A" ?
[10:57:06] <LeoNerd> Yah.. weird
[10:57:31] <LeoNerd> GUI-level user programs really ought not care or need to know what the UART chip is
[10:57:46] <LeoNerd> .. also unless you're running this on a 1990s-era DOS-based PC, it's unlikely to actually be using a real 16650
[10:58:01] <Haohmaru> he uses either some text-mode app, or a terminal emulator with built-in serial port capability, and it has settings or command line arguments, no idea
[10:58:02] <LeoNerd> Those went out of fashion right around the time of the more integrated bridge chips of Winbond et.al.
[10:58:53] <skz81> hooooo was guessing it was some byte string, was totally not on a chip ref, thanks leo
[10:58:59] <Haohmaru> he said that it's currently set to "16550A" and asked if he should change it
[10:59:05] <Haohmaru> i shrugged ;P~
[11:00:06] <LeoNerd> skz81: The legacy of the 16650 lives on, though. You can buy modern chips that are essentially SPI-attached 16650s
[11:00:30] <LeoNerd> Same registers, same bitflags.. just accessed over SPI instead of sat on an ISA bus. Someone literally just took the 16650 silicon and stuck an SPI interface on the front
[11:01:00] <LeoNerd> Very handy if you're stuck on some MCU that lacks a UART, or you need multiple fast UARTs and only have one, and can't be bothered to bitbang it
[11:01:29] <Haohmaru> bitbanging the receiver is NOT fun
[11:01:33] <LeoNerd> Mhmm
[11:01:35] <Haohmaru> never
[11:01:53] <Haohmaru> unless you don't care about errors
[11:01:55] <LeoNerd> Bitbanging a TX only isn't -too- bad. That can be sufficient if you're just outputting debug console information
[11:02:21] <LeoNerd> Especially if you don't care about the speed, because debug
[11:02:57] <LeoNerd> I've done that before where I didn't even care what baud rate it will be. I just stuck it on sigrok's pulseview and let it figure out the baud rate :)
[11:03:32] <Haohmaru> that's cheating, u cheat0r
[11:03:37] <LeoNerd> ;)
[11:03:50] <LeoNerd> That's nowhere near my most cheatingest of hacks in the past year
[11:04:08] <LeoNerd> For that prize, you probably want to see my I²C-like point-to-point bus over 95m of unshielded alarm cable
[11:04:43] <Haohmaru> wat, i don't even like i2c
[11:05:19] <LeoNerd> It's a link between two machines. I'm rebuilding it now to be a much more sensible RS-485, but at the time I didn't have the requisite max481 chips to hand and I was in a hurry ot make /something/
[11:05:46] <LeoNerd> So.. data on one pin, clock on another. Down it goes. uplink has a separate cable pair. So each line is unidirectional. useful, because I needed to optoisolate one end of it
[11:06:25] <LeoNerd> The signal is sortof I²C-like, but full-duplex on separate pairs. So instead of the ACK bit, the sender sends a "more/done" flag. To a bus analyser it -looks- just like I²C though
[11:07:11] <LeoNerd> Now.. fast slew rates of digital signals down 95m of alarm cable tends to induce -horrible- spikes on all the other wires going parallel to it. Nasty horrible stuff. On every clock edge, every data line in both directions saw it.
[11:07:23] <Haohmaru> i've done some stupid things in the past.. like.. transfering files between my two computers (in the same room) over analog audio, because i didn't have any other connection between them x_x
[11:07:25] <LeoNerd> But remember I said it was optoisolated? Those cheap 4N25s are slow. Slooooow.
[11:07:34] <LeoNerd> So slow, that they filtered out those stray coupled edges :)
[11:07:35] <Haohmaru> so i wrote a transmitter and receiver app
[11:07:54] <LeoNerd> So hey presto - just run the link at 5kbit/sec and everything is lovely :)
[11:08:44] <LeoNerd> Ah audio link stuff can be fun.
[11:08:51] <LeoNerd> I've seen a sound-based ATmega bootloader
[11:08:58] <Haohmaru> h0h0h0
[11:09:40] <Haohmaru> hex2wav ;P~
[11:10:23] <LeoNerd> Ooh lucky me - my PCBs I sent to OSHpark earlier today are already panelled.
[11:10:39] <Haohmaru> party.gif
[11:14:05] <bss36504> OSHPark has been pretty speedy lately. I'm quite pleased. I ordered some 2oz boards that could have taken a week longer to process and they were panneled and sent to fab in a day.
[11:14:24] <bss36504> Could be I got lucky, but that's happened twice now. and the panel was originally scheduled 5 days out
[11:15:20] <LeoNerd> Yeah.. I do like them. A little slow for us UK-lot, but otherwise quite nice. The specs are surprisingly good for the price
[11:15:48] <Haohmaru> where are they located?
[11:15:53] <LeoNerd> There's a UK company that are faster than OSHpark, but I don't know what kind of drill equipment they have. Must be some guy sat with a dremel or something... the minimum drill size is horribly huge
[11:16:17] <LeoNerd> They rejected a board of mine on the drill size for vias. I had to reroute a bunch of tracks to make extra space for via circulars
[11:18:12] <LeoNerd> Haohmaru: Ragworm.. Kent somewhere I think
[11:18:26] <Haohmaru> ugh, usa
[11:18:50] <LeoNerd> Oh.. wait
[11:18:54] <LeoNerd> OSHpark are US I think
[11:19:02] <LeoNerd> The UK company I was talking about is Ragworm in Kent
[11:23:51] <bss36504> Yeah OSHPark is US
[11:24:18] <bss36504> I buy all my boards from the greatest country in the world, with all my freedom bucks ;)
[11:24:24] <LeoNerd> I don't know where their actual production fab is, but the shipping at least starts there
[11:24:41] <bss36504> Pretty sure the fab is actually in the US as well
[11:25:11] <bss36504> the OSHPark guys are in Colorado somewhere, or maybe Seattle or though.
[11:25:20] <LeoNerd> Ah cool
[11:25:34] <LeoNerd> I wonder how they get it so cheap though
[11:27:20] <bss36504> I guess they have enough volume to wheel and deal with the fab. I used to order full panels from a fab for $300 a panel, and those were like 11"x15" (28cmx38cm) I think
[11:28:26] <LeoNerd> Yah.. well, OSHpark are a space-filler.. they sit in the gaps of bigger panels
[11:28:32] <LeoNerd> Maybe that's how?
[11:28:34] <bss36504> But, that is a single panel at a time. Perhaps they made a deal with the fab to be able to slip single panels in when the fab isnt busy with higher priority orders, in order to keep the price down
[11:28:52] <LeoNerd> Oh single panels have tooling costs usually...
[11:28:57] <LeoNerd> Ithink that's why oshpark boards come in threes
[11:30:06] <bss36504> I think OSHpark does the panelizing, I may be wrong though. The fabs get a little annoyed if you ask them to panstuff for you, in my experience.
[11:50:51] <methuzla> OSHpark are in Portland, Oregon. They do the panelizing, and the panel is fabbed with 100% their stuff.
[11:51:04] <LeoNerd> Iseee
[11:51:51] <methuzla> They just get enough volume of orders to be able to send out at least a panel per day
[11:53:53] <methuzla> Example panel can be seen at 3:14 in this video: https://youtu.be/XssjD97-xGM
[12:03:43] <WormFood> "If you need to run the AVR at 5 V, add 3.6 V zener diodes at D+ and D- to limit the voltage." <-- I was right. :D
[12:04:34] <LeoNerd> Quite
[12:04:45] <LeoNerd> Or.. yaknow.. don't do stupid hackery like that. Get a 32U4
[12:04:47] <LeoNerd> Real USB PHY
[12:05:21] <WormFood> cost is a factor. This isn't really needed. It's insurance against needing the customer to update their firmware.
[12:06:42] <LeoNerd> How many are you making? How long have you spent on IRC talking about it?
[12:07:03] <LeoNerd> If I had to spend 2 hours of talking to save myself $0.50 on the BOM, I honestly wouldn't bother unless I was making /hundreds/ of them at least
[12:07:41] <WormFood> Yeah, I'm expecting to make a least 1000 of these
[12:07:50] <LeoNerd> Hmm, well OK
[12:50:06] <WormFood> What is the modern way, of connecting a 3 color LED to an MCU. Are they still doing 4 legged tricolor LEDs, or is that a thing of the past?
[12:52:23] <LeoNerd> Those are a way. WS2812s or APA102s are another
[12:52:36] <LeoNerd> I tend to prefer 102s by default - individually controllable SPI chain
[12:55:00] <WormFood> Thanks for the comments LeoNerd. I'll check 'em out
[14:25:02] <WormFood> what AVR settings are preserved over reset? I read that the watchdog status is preserved across a reset. It also appears that the clock prescaler is also preserved on a reset.
[14:25:45] <LeoNerd> I would hope that none of them ever
[14:25:52] <LeoNerd> The entire point of reset is to reset everything
[14:38:42] <cehteh> the whole SRAM is preserved
[14:38:54] <cehteh> registers are reinitialized as per datasheet
[14:39:33] <cehteh> i wonder already about prescaler, that should be reinitialized
[15:04:10] <antto> any sane program should explicitly set its prescalers before using a timer ;P~
[15:06:12] <LeoNerd> Any /sane/ program, sure... But where's the fun and adventure with mere sanity?
[15:07:50] <Tom_itx> WormFood, there are at least 2 types of reset
[15:12:57] <antto> xmega has like 6 or more
[15:12:57] <Jartza> evening
[15:12:58] <antto> ;P~
[15:13:18] <cehteh> MCUSR
[15:13:55] <antto> yeah, i'm kinda biased towards xmega
[15:14:05] * antto is not ashamed
[15:14:15] <cehteh> WDRF, watchdog, BORF brownout, EXTRF reset button, PORF power on
[15:14:24] <cehteh> .. thats what most avr's have at least
[15:14:37] <antto> programmer/debugger reset
[15:14:42] <cehteh> where brownout and watchdog may be disabled
[15:14:50] <cehteh> thats the reset button
[15:14:53] <cehteh> (pin)
[15:14:56] <antto> and soft-reset
[15:15:05] <antto> ^ that's on the xmega
[15:15:12] <cehteh> most most avrs dont have a soft reset
[15:15:18] <cehteh> which somewhat sux :D
[15:15:30] <antto> xmega somewhat rox
[15:15:37] <antto> >:)
[15:15:54] <antto> much x, very mega
[15:43:38] <carabia> Are there any avrs (apart from the 406) capable of operating at > 5 Vcc?
[15:44:36] <phinxy> "use external reset" Nice button
[15:44:39] <carabia> think i'm gonna have to lean towards hv pics
[15:44:40] <phinxy> why isnt it always active
[15:53:44] <phinxy> Erase chip.. OK Programming chip.. OK Verifying chip Failed!
[15:54:06] <phinxy> can read fuses fine and eeprom is fine
[15:55:04] <phinxy> only thing different from when it worked is a 10K external pull up reset
[15:58:16] <carabia> Any suggestions of european stores having a good selection of microchip's stuff and ships in low-qty?
[15:58:24] <phinxy> program works fine for a couple seconds then i freezes. it may be my new caps for the crystal that are too hgih value
[15:59:16] <phinxy> Farnell
[15:59:36] <phinxy> sells to private persons and companies
[15:59:40] <phinxy> Conrad
[16:00:09] <phinxy> also very good
[16:04:59] <carabia> Farnell sells to pvt too?
[16:05:07] <LeoNerd> I buy from them sometimes
[16:05:18] <carabia> As private?
[16:05:39] <phinxy> if you go to export.farnell.com
[16:06:01] <phinxy> its always English there but it seems to work for me (EU)
[16:07:30] <carabia> Yeah alright. I'll try
[16:07:42] <carabia> Have to order some HV PICs
[16:15:21] <phinxy> When i read memory from the atmega128 i only get FF data. now running on internal oscillator.
[16:16:34] <antto> phinxy usbasp?
[16:16:45] <antto> verification fails?
[16:18:44] <carabia> Jesus fucking christ pickit 3 is expensive compared to other entry level programmer what the actual fuck
[16:18:49] <antto> do a dump to hex and compare with the hex you flashed, it may be perfectly fine.. my chinese usbasp NEVER verified anything, but it was flashing.. (till it broke)
[16:19:06] <antto> pickit3 is a pile of crap
[16:19:20] <aandrew> s/kit3//
[16:19:56] <antto> pic is a pile of crap? yes
[16:20:02] * antto runs before Lambda_Aurigae sees
[16:21:29] <carabia> pic's better suited for this application.
[16:22:14] <antto> pickit3.. programs uber slow, their equivalent of avrdude runs uber slow on top of that, and if that's not enough.. flash pic18? - pickit3 must change its firmware first.. *growing_beard* .. then flash pic12? - pickit3 must change its firmware again...
[16:23:07] <antto> their programmer can't flash pic12 and pic18 with the same firmware x_x
[16:23:39] <antto> i can program any atmega with a parallel port and some cables
[16:24:34] <antto> it's incredible.. how the one tool you'd use the most is surrounded by slowness
[16:25:00] <antto> you be outtaken by herds of snails all the time ;]
[16:25:08] * antto runs
[16:31:57] <phinxy> i successfully programmed the chip when i unplugged it from its circuit
[16:32:09] <phinxy> i bet its the 10K pull-up thats either too high or low
[16:34:05] <phinxy> or maybe its the decouple caps and choke that has a harmonic oscillation with the JTAG .. maybe too far fetched
[16:40:49] <Emil> What was the procedure to print strings from progmem?
[16:40:51] <Emil> as in uart_puts(pointer_to_string_in_progmem) doesn't seem to work
[16:41:35] <liwakura> Emil: either copy them to a rambuffer first with memcpy_P
[16:41:53] <Emil> or?
[16:42:00] <liwakura> or copy the uart_puts function to make an uart_puts_P variant
[16:42:20] <liwakura> which reads the bytes with pgm_read_byte instead of using *pointer
[16:42:20] <Emil> Damn, why must if be like that :(
[16:42:29] <liwakura> havard architecture :D
[16:42:51] <Emil> hmm
[16:42:55] <liwakura> think of all the RAM you are gonna save
[16:43:21] <Emil> wouldn't use any ram if I could simply print from dataspace
[16:43:27] <liwakura> yeah
[16:43:30] <liwakura> Emil: https://github.com/liwakura/avr-sh/blob/jumpexec/print.c
[16:43:38] <liwakura> i solved that problem a while ago
[16:43:41] <Emil> anycase, could I add a check if data is in programspace?
[16:44:16] <liwakura> hm, if you just get an address, you simply dont know if its pgmspace or ram
[16:44:23] <Emil> well, that sucks
[16:44:38] <Emil> Well, two different functions it is, then
[16:45:09] <liwakura> Emil: in the worst case you have an string in the ram and in the pgmspace at the same address
[16:45:56] <Emil> if I copy to buffer
[16:46:09] <Emil> but I rather just print byte by byte
[16:46:35] <liwakura> print byte by byte would be cleaner i think
[16:46:39] <liwakura> it also uses much less ram
[16:46:43] <Emil> yap
[16:47:06] <liwakura> just think of whats more valuable to you - flash space or ram space
[16:47:17] <Emil> neither, really here
[16:52:23] <liwakura> what are you trying to do?
[16:52:47] <Emil> liwakura: it's a simple controller for the psr1212
[16:53:11] <Emil> What if I have a list of strings in programspace that I want to iterate over?
[16:53:43] <liwakura> make an array of pgmspace pointers
[16:53:57] <liwakura> which will point to the individual string
[16:54:01] <Emil> Yeah, I have, but printing them don't seem to work
[16:54:25] <Emil> as in uart_putps(list_of_strings_in_pgmspace[i]) doesn't seem to work
[16:54:37] <liwakura> in 80% its some unintended read from ram
[16:54:43] <Emil> seems like so
[16:55:22] <liwakura> a[b] is defined as *(a + b)
[16:55:32] <liwakura> and the *p read from ram again
[16:56:51] <liwakura> didn't knew that until now
[16:57:11] <liwakura> also, there is a high risk of defining them wrong
[16:57:47] <liwakura> because if you dont explicitly state the pgmspace attribute for every level of items, i will end in ram instead
[16:58:24] <liwakura> showing code could help further
[16:59:00] <Emil> Doing that right now
[17:00:57] <Emil> https://emil.fi/jako/pgmstring.txt
[17:01:01] <Emil> results in printing ????
[17:01:58] <Emil> I kind of understand where I'm going wrong
[17:02:05] <liwakura> hm
[17:02:06] <Emil> but what was the way to fix it
[17:02:18] <Emil> It's that str is in pgmspace
[17:02:22] <Emil> right?
[17:02:35] <Emil> so I can't just pass a pointer to it
[17:02:38] <Emil> or can I?
[17:02:43] <liwakura> > str[i]
[17:02:52] <liwakura> > a[b] is defined as *(a + b)
[17:03:03] <liwakura> the bad *( ) is there hidden again reading from ram
[17:03:47] <Emil> so what to change to what?
[17:04:12] <liwakura> oh
[17:04:17] <liwakura> let me think for a while.
[17:05:24] <liwakura> if i just replace * by the corresponing pgm_function
[17:05:28] <liwakura> it would be pgm_read_word(str + i);
[17:06:41] <liwakura> use at own risk
[17:07:10] <liwakura> never had this insights before. im also quite new to AVR
[17:07:14] <Emil> no risk involved really
[17:07:32] <Emil> but thanks
[17:07:38] <Emil> I'll try and report
[17:09:35] <liwakura> nice. also just learned that int i[] and int *i are basically the same
[17:10:48] <Emil> did't work
[17:11:10] <Emil> it warned me about casting issues, so I casted it to char * but still didn't work
[17:11:37] <liwakura> uhm
[17:11:54] <liwakura> sort of expected that when you randomly add pointers
[17:12:11] <liwakura> post code again?
[17:13:16] <liwakura> im also interested in the thrown errors about the casting issues
[17:13:40] <Emil> Calling uart_putps(... is now uart_putps((const char *)pgm-read_word(str[i]));
[17:13:48] <Emil> Otherwise the same
[17:14:26] <liwakura> uhm
[17:14:32] <liwakura> that looks bad
[17:14:45] <liwakura> the bad [ ] operator is still there
[17:15:36] <Emil> holy shit
[17:15:37] <liwakura> this should be better: uart_putps((const char *)pgm-read_word(str + i));
[17:15:37] <Emil> it worked
[17:15:39] <Emil> yeah!
[17:15:42] <Emil> NICE
[17:15:43] <liwakura> code?
[17:15:48] <Emil> changed to what you said
[17:15:59] <liwakura> magic
[17:16:05] <Emil> uart_putps((const char *)pgm_read_word(str+i));
[17:16:30] <Emil> Thanks, man!
[17:16:37] <liwakura> i have no idea what is a pointer or what but that * to pgm_ translation seemed to work xD
[17:16:40] <Emil> I'll show what I have at the moment
[17:16:57] <Emil> what, mate you don't know what a pointer is?
[17:17:07] <Emil> Still managed to help me, though :D
[17:17:13] <liwakura> no, what actual types str and i have
[17:17:44] <liwakura> but figured out that pgm_read_xyz(p) is the pgmspace equivalent to *(p)
[17:17:44] <Emil> i is unsigned char, str is const char * const
[17:17:59] <liwakura> Emil: its also that magic pointer addition
[17:18:24] <liwakura> you add 1, and the pointer increases by 2, because word size or something
[17:18:53] <Emil> Nice point
[17:19:27] <liwakura> by using normal math logic you would end with shit addresses if you use uneven array indices
[17:19:36] <Emil> On an unrelated question: would you happen to know why the ISR for USART_RXC_vect doesn't seem to work on atmega162v?
[17:19:51] <Emil> USART0*
[17:19:59] <liwakura> one of these:
[17:20:07] <liwakura> - UART TX not enabled
[17:20:13] <liwakura> - UART TXIE not enabled
[17:20:28] <liwakura> - Interrupt flag in Status Register never set
[17:20:45] <liwakura> - It actually works but something else fails
[17:20:56] <Emil> AHAHAHA
[17:21:04] <Emil> Fucking a, always forgot the fucking sei() call.
[17:21:21] <liwakura> lol :D
[17:21:25] <liwakura> uhm
[17:21:41] <liwakura> never forget: your main code is actually the ISR reset routine
[17:21:56] <Emil> "Why don't my interrupts work!?" "Have you enabled your interrupts for realzies?"
[17:22:08] <theBear> "nah, just for play plays"
[17:28:31] <Emil> Thanks liwakura!
[17:29:58] <liwakura> now about the payment
[17:30:15] <liwakura> if a blond dude with a suit comes to your door, Emil, sell him your soul
[17:31:04] <Emil> What's the punishment for the sale of nonexistent goods?
[17:31:33] <liwakura> its not a good.
[17:31:36] <liwakura> its a service.
[17:31:44] <liwakura> also, a soul is not exactly a good.
[17:31:58] <Emil> Wait, a soul is a service?
[17:32:39] <liwakura> ignore that
[17:32:44] <liwakura> im just shittalking
[17:33:34] <Emil> Or are you now!? Only THE DEVIL could know such intricate details about programming microcontrollers!
[17:35:37] <liwakura> uhm.
[17:35:41] <liwakura> im revealed!
[17:35:46] <liwakura> oh no!
[17:35:48] * theBear too !
[17:35:54] <theBear> ^^^^ found him
[17:36:04] <theBear> it's the stripy beanie gives me away
[17:38:16] <liwakura> also http://hellkitchen.smackjeeves.com/
[17:38:20] <liwakura> good comic
[17:42:12] <theBear> i do enjoy good fiction, or at least, i don't approve of non-fiction outside of things like technical information :)
[17:42:51] <theBear> hmmm... i'm sceptical, i getting the feeling they care more about the drawing/art than funny stories
[17:44:42] <liwakura> i guess so
[17:46:15] <theBear> that's ok, you still allowed to like it
[17:47:03] <theBear> NOONE likes the things i really enjoy artistically/recreationally, in many cases literally, to the extent of a one or 2digit sized audience, total, for the entire human race style :)
[18:08:13] <Emil> HEy
[18:08:56] <Emil> is there a eeprom command to read byte from higher than a byte range?
[18:09:11] <Emil> ah
[18:09:12] <Emil> hue
[18:09:28] <Emil> const char * is 16 bits -.-
[18:09:32] <Emil> NEvermind
[18:11:38] <liwakura> yea
[18:11:40] <eszett> hi
[18:11:44] <eszett> Hi! I have a question. The fuse calculator http://www.engbedded.com/fusecalc/
[18:11:44] <eszett> gives me for my Atmega32U4 this overview http://imgur.com/hvkzUCG
[18:11:44] <eszett> which has the bits 7, 6, 5, and 4 of the extended fuse as non-existant..
[18:11:44] <eszett> However, when i read the extended fuse it gives me "0b11000011",
[18:11:44] <eszett> ie. the bits 7, 6, 5 and 4 exist! How can that be?
[18:13:16] <liwakura> how should a non-existing bit read?
[18:14:29] <eszett> liwakura: ok, but why does the fuse calculator give no info for those bits?
[18:14:52] <liwakura> i guess because it doesn't know those bits
[18:15:14] <liwakura> look into your datasheet if those bytes actually exist on your device
[18:15:20] <liwakura> * bits
[18:15:23] <eszett> hmm.. that is deceptive
[18:15:27] <liwakura> * is defined
[18:15:27] <eszett> ok
[18:15:41] <liwakura> its like, if those bits are quite new
[18:15:53] <liwakura> and the fusecalc wasnt updated for a while
[18:15:58] <liwakura> such things may happen
[18:17:25] <eszett> hmm strange.. the datasheet says those 4 bits are empty too
[18:17:30] <eszett> or "non-existant"?
[18:18:02] <eszett> 28.2 Fuse Bits http://www.atmel.com/images/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf
[18:18:24] <liwakura> just undefined
[18:19:07] <eszett> alright, but why do i read the extended fuse as "0b11000011" than? I would expect "0b11110011"
[18:19:28] * eszett .oO( headache )
[18:20:01] <eszett> undefined bits should have other values than "1", right?
[18:20:06] <eszett> shouldnt..
[18:20:30] <Emil> Hey
[18:20:40] <Emil> When using the eeprom
[18:20:52] <Emil> the addresses were from 0 to 512 (or whatever the size)?
[18:21:10] <liwakura> Emil: yes
[18:21:28] <liwakura> eszett: try reading again
[18:21:35] <eszett> liwakura: I will read again..
[18:21:44] <liwakura> i mean the fuse bytes
[18:21:50] <eszett> yes
[18:22:19] <eszett> still the same. extended fuse is: 0b11000011
[18:22:39] <Emil> Are you sure your m32u4 is legit and not a copy?
[18:22:50] <liwakura> uh-oh
[18:22:50] <theBear> eszett, whaddyou mean undefined ?
[18:22:51] <eszett> Emil: yes, its from Mouser
[18:23:02] <liwakura> eszett: your avr has hardware RTS and CTS
[18:23:05] <Emil> Because some of my avrs report different fuses from what I set :D
[18:23:15] <eszett> theBear, undefined as in datasheet table 28.2 here http://www.atmel.com/images/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf
[18:23:17] <theBear> all fuses have default settings, and you can't un-set a bit, that's not how flash/proms work
[18:23:35] <theBear> what page ?
[18:23:48] <eszett> page 354
[18:23:52] <liwakura> theBear: the problem is, he reads 1 and 0 on places where all bits should be 1
[18:24:00] <liwakura> undefined area in fuse byte
[18:24:10] <eszett> liwakura: yes..
[18:24:12] <theBear> woop got it, stupid pdf viewers
[18:24:40] <eszett> liwakura: i dont know much about RTS and CTS
[18:24:47] <liwakura> flow control for uart
[18:25:12] <liwakura> -> wait until the other side has processed the data
[18:25:22] <liwakura> useful to avoid overflows on bulk data transfers
[18:25:44] <theBear> have the fuses been set (ANY of them) since you got the chip, or perhaps at bootloader install time by the person you bought it off ?
[18:25:52] <eszett> liwakura: ja aber was hat das mit den fuses zu tun?
[18:25:59] <liwakura> nothing
[18:26:08] <eszett> hmm
[18:26:09] <liwakura> but its a nice feature i wish my atmega328 also had
[18:26:16] <eszett> argh ;-)
[18:26:30] <liwakura> i tried to implement it manually
[18:26:44] <eszett> Bear: i flashed it with the official bootloader from atmel
[18:27:00] <liwakura> but my on-board CH340 cares as much about his flow control pins like the NSA does with privacy
[18:27:03] <eszett> bear: well, i could make a little test and try to change these "ghost bits"
[18:27:39] <theBear> eszett, does a bootloader flash not imply some fuse changing in order for it to "do something" ?
[18:27:46] <eszett> Bear: the fuses have not been set since i got the chip, i dont know the original settings anymore.
[18:27:57] <eszett> Bear: not sure..
[18:27:58] <Emil> What's an efficient way to print a char in hex through uart?
[18:28:10] <theBear> wait, what ? isn't that sentence contradictory ?
[18:28:14] * phaeton chants Tom_itx
[18:28:35] <theBear> either way, it really shouldn't matter if they undefined
[18:28:41] <eszett> theBear: hmm ok
[18:29:15] <liwakura> Emil: wierd question. https://github.com/liwakura/avr-sh/blob/jumpexec/print.c#L26
[18:29:45] <liwakura> just remove the *dev stuff and put your uart_put in place of the dev_put
[18:30:24] <theBear> i can't spot anywhere nearby in the datasheet any comments re: undefined bits.. but generally if they have ANY effect on anything the datasheet makes that very clear right next to the table/whatever describing them
[18:31:02] <eszett> Bear: so how do i call those bits? empty bits?
[18:31:16] <eszett> those empty bits should have the value "1"
[18:31:50] <theBear> i kinda got the feeling we had all silently agreed on undefined before the conversation began
[18:32:02] <theBear> and why should they have that value ?
[18:32:17] <eszett> "1" means unprogrammed
[18:32:46] <theBear> only in bits where it is defined as such
[18:32:49] <theBear> i think
[18:33:09] <theBear> i sure, look at thatwhole table on teh right column
[18:33:37] <eszett> yes, it says default value for bit 7 6 5 4 of the efuse is "1"
[18:33:40] <theBear> i know they still different to the claimed default, but re: the meaning
[18:33:52] <theBear> prog/unprog,it doesn't apply to the undefined bits
[18:34:20] <eszett> they have no function, but they are unprogrammed
[18:34:22] <theBear> worth checking atmel site for any errata/doc updates too, mighteven be at the start/end of this one already
[18:34:37] <eszett> im trying to change them to value "0"
[18:35:07] <theBear> READ THE TABLE, THOSE BITS DO NOT HAVE A PROGRAMMED/UNPROGRAMMED VALUE DEFINED, ONLY THE ONES WITH ACTUAL USES WORK LIKE THAT
[18:35:17] <theBear> right hand column, like i sai
[18:35:17] <theBear> d
[18:36:04] <liwakura> theBear: by trying to change them he will find out if the datasheet is just mismatching with his controller
[18:36:39] <theBear> controller ?
[18:36:50] <theBear> and err, what ?
[18:37:02] <liwakura> s/controller/avr
[18:37:53] <liwakura> also, his datasheet also mismatches his controller of those bits read as 0
[18:38:03] <liwakura> s/controller/avr
[18:38:27] <theBear> and outside of security fuses, i'm not entirely sure that programmed/unprogrammed stuff makes any sense, cos you can reprogram a normal and not-locked-elsewhere fuse and set any bit to anything you want, over and over, so long as you dont accidentally set one that makes it unprogrammalbe :)
[18:41:21] <eszett> there is some kind of mismatch i guess. coz "0b11110011" is hexadecimal "f3" and when i try to write the efuse with the value "f3", then Avrdudes gives me the message "avrdude: safemode: efuse changed! Was f3, and is now c3. Would you like this fuse to be changed back? [y/n]"
[18:41:44] <eszett> and I cant change it back..
[18:42:30] <theBear> wait, 3? oh, hmm, i'm outta practice
[18:42:31] <eszett> so.. avrdude wants to stay with "0b11000011" (hexadecimal "c3")
[18:43:14] <theBear> that doesn't sound right, you sure you using the right syntax to avrdude ? i recall it's a bit confusing with fuses, just to make things more exciting for yer
[18:43:31] <eszett> yea the syntax is fine, i use it all the time
[18:43:47] <theBear> specially if something is f3, you try to make it f3, and it changed to smeothing else, that doesn't sound right however you look at it
[18:44:04] <theBear> unless, hmm, which way up was taht table
[18:44:12] <eszett> yea
[18:44:19] <theBear> oh, upside down upside down
[18:44:27] <theBear> yeahk, and ineresting
[18:44:29] <eszett> I mean... i could simply ignore it, but im asking because it riddles me
[18:45:15] <theBear> but that means you weren't really testing what you wanted to.... what happens if you try to make it err, cf i think
[18:45:19] <theBear> 0xcf
[18:45:45] <theBear> so far you only really confirmed that the defined bits do what the datasheet claims
[18:48:15] <WormFood> If my program is small enough, I should be able to write it to the bootloader section, and have it run like normal, right? (of course, enabling the bootloader fuses, and all the other stuff to make it work)
[18:49:41] <eszett> When i try to change the efuse to 11111111 (hexadecimal: FF), it falls back to 11001111 (hexadecimal: CF)
[18:49:47] <theBear> WormFood, i guess, assuming you boot with whatever you need to choose bootload with your settings, but erm, aside from possibly needing to do a "please bootload" something at boot time, pretty sure that's EXACTLY the same as just programming normally and not setting bootloader fuses/mode, literally, like byte for byte
[18:50:33] <theBear> eszett, hmm, and what about 0xc0 ?
[18:50:35] <WormFood> theBear, yeah, that was my understanding too. With, of course, some other fuse limitations, as far as reading/writing to/from bootloader/application sections.
[18:50:45] <phaeton> In lieu of Tom_itx's avr programmer, what's another good one to start with?
[18:51:18] <theBear> WormFood, bootloader section is just the start of the whole raw mem from memory, only becomes "special" when bootloader mode makes the real program 0 appear at an offset above tha
[18:51:31] <theBear> unless newer chips do it differently
[18:51:49] <eszett> theBear: one second..
[18:51:59] <theBear> phaeton, if you got a parport handy 74???245 makes a solid/good one
[18:52:06] <WormFood> So, the next question is...how the fuck do I program it into the bootloader section?
[18:52:42] <theBear> WormFood, been a while, but either just program normally THEN activate bootloader mode, or activate mode then tell avrdude to write to bootloader vs progmem/eeprom/etc
[18:52:47] <WormFood> --section-start=.text=0xc00 didn't seem to work for me.
[18:52:49] <eszett> Bear: avrdudes allows to write "C0" (extended fuse is: 0b11000000)
[18:53:33] <theBear> eszett, so if i not wrong-endified again, that proves that the undefined bits don't have that programmed/unprogrammed definition like the others, just like the table says :)
[18:53:41] <eszett> long story short, the bits 7 6 5 and 4 of the efuse are "1100", and not to change by avrdude
[18:53:48] <theBear> woohoo, you can now successfully program bits that have no effect !
[18:54:06] <WormFood> theBear, what drugs are you on? There is no extra bootloader section that avrdude can program. It just programs it at the address given in the hex file.
[18:54:22] <WormFood> theBear, the xmega can do that.
[18:54:46] <theBear> WormFood, not drugs this time, more like haven't ever programmed a bootloader onto a fresh/unprebootloadered avr, and haven't read about the details for probly a decade, give or take 9months
[18:55:05] <theBear> and if the xmega even existed then, it was brand new, and far from the datasheets i was looking at:)
[18:58:11] <WormFood> well shit! All these AVR bootloaders won't work for me. I obviously must be doing something wrong.
[18:58:19] <eszett> anyway im off to bed, cu later
[18:58:34] <WormFood> see ya l8r eszett 晚安
[19:00:44] <LeoNerd> Mmm.. I think I just successfully crimped a BNC plug onto RG174 cable.
[19:00:56] <LeoNerd> Not just once in fact, but twice. Thus proving the first wasn't just a coincidence :)
[19:08:08] <Emil> Is it possible to do a list of ports that are masked some way?
[19:08:26] <WormFood> masked in what way?
[19:08:45] <Emil> so that I can have like statuspins[]={*(&PORTB)&0b00001000, so on};
[19:08:52] <LeoNerd> What do you mean "masked" ?
[19:09:49] <Emil> or is that purely for functions?
[19:11:04] <LeoNerd> I don't understand the question
[19:11:14] <WormFood> me too neither
[19:11:46] <Emil> I think the example is pretty clear but eh, I'll just do it with a function
[19:12:19] <WormFood> It's not clear, because you never clearly stated what you want to do.
[19:22:13] <theBear> lol
[19:22:15] <theBear> i agree
[19:24:34] <theBear> my guess btw, would be that he wants to do like (this is both explaining what i think he asking, and the way i figure it works) STATUSPINS=0bSUMTHINMASK then when he wants to "use"that he would do the old binary operator thing on the same line as he applying/feeding his data (for the statuspins, other bits obviously irrelevant) using statuspins var for the mask element
[19:25:22] <theBear> i'm assuming sensible c not stupid arduino addadd style non-linear kinda C :)
[19:31:34] <WormFood> I can't fuckin' find any documentation on how to program my own bootloader. I get tons of shit, about how to do everything, except tell gcc to produce code, that will be loaded in the bootloader. The code I've downloaded, doesn't seem to work at all.
[19:32:24] <WormFood> I've double checked my fuses. Bootloader are is set to execute on reset, and the size is properly set. Is there something else I'm overlooking?
[19:33:28] <WormFood> avrdude: safemode: Fuses OK (E:00, H:D7, L:FF) <-- ATmega88
[19:40:20] <WormFood> I don't have access to google.
[20:16:32] <WormFood> I sure as fuck can't seem to figure it out.
[20:20:46] <somn00b> hey guys umm what should the default value be in F_CPU for aymega328
[20:21:06] <Lambda_Aurigae> somn00b, whatever your processor is running at.
[20:21:08] <Lambda_Aurigae> speed wise.
[20:21:22] <somn00b> ahh ok
[20:21:23] <Lambda_Aurigae> WormFood, http://www.atmel.com/Images/AVR109.zip
[20:21:40] <Lambda_Aurigae> source with makefile and all for gcc for a bootloader.
[20:21:46] <somn00b> k thx
[20:21:59] <Lambda_Aurigae> goes along with the avr109 appnote, http://www.atmel.com/images/doc1644.pdf
[20:22:36] <Lambda_Aurigae> avr112 is a twi bootloader for devices without boot section too.
[20:22:57] <somn00b> hmm k i dont understand any of that cause im pretty new to avr but i will have look thx
[20:23:11] <Lambda_Aurigae> somn00b, most of that was for WormFood
[20:23:40] <somn00b> haha that makes sence
[20:23:43] <somn00b> sense
[20:23:48] <Lambda_Aurigae> F_CPU is a constant used by some routines and it needs to be set to the speed of the clock. So if you are running with a 16MHz crystal then it should be 16000000
[20:24:14] <Lambda_Aurigae> if you are running from the default internal rc oscillator with div/8 fuse set as the chips generally ship from atmel then it would be 1000000 indicating 1MHz
[20:24:57] <Lambda_Aurigae> now that I've been helpful, time to go back to stapling down my carpet.
[20:25:00] <somn00b> atemga328 has a 8MHz right?
[20:33:32] <cehteh> as shipped?
[20:33:45] <cehteh> thats 8mht internal osc divided by 8 .. so 1mhz
[20:34:31] <cehteh> Lambda just told :)
[20:36:40] <inflex> mm... in Eagle, what are the little circle end points I can put on the end of a 'wire' on the schematic? Not sure where to find them
[20:37:08] <inflex> just so it doesn't look like I've got random dangling wires in my schem (even though I do have them labelled)
[20:41:20] <theBear> inflex, in schem mode i suspect , err, no, that can't be right, hmmm
[20:42:03] <theBear> inflex, been years, but isn't there a section in the partlib list for stuff like connectors and headers, maybe mixed with (the other likely spot) the place you get stuff like gnd and vcc's from in that laist
[20:42:40] <theBear> heh, why DO you have random dangling wires in y our schem?
[20:43:43] <Lambda_Aurigae> 1x1 header.
[20:46:23] <inflex> Lambda_Aurigae: except that actually produces an on-board part.
[20:46:50] <inflex> theBear: different sections too far away from each other on the schem and between sheets
[20:46:59] <theBear> inflex, you can't just have imaginary wires that go nowhere and magically don't exist when you go to pcb mode ! that's just silly and impossible
[20:47:02] <inflex> there's the "supply" library, I'll try that
[20:47:37] <theBear> hmmm, i was gonna say that's when you use named nodes/buses but between sheets suggests you abusing the free eagle to do massive stuffs, and i got no answer for that
[20:47:52] <inflex> er no... I have a licenced copy :)
[20:47:53] <theBear> then again, that wouldn't work either, wtf you mean between sheets ?
[20:49:16] <inflex> Say you have a signal line ABCX that is used by multiple sections, but the different sections are on different sheets. So you have a short schematic wire coming out of (say) a chip and then terminating visually on the schem with a little round terminator
[20:49:19] * inflex goes and finds an example
[20:49:41] <inflex> I could just keep using short un-terminated wire instances on the schem, just doesn't look as 'clean'
[20:53:55] <tehhd> Can the atmega32 self program its clock fuses
[20:54:39] <Lambda_Aurigae> no
[20:54:48] <Lambda_Aurigae> fuses can not be programmed by a bootloader.
[20:55:00] <Lambda_Aurigae> they can be read by an onboard program or bootloader but not written.
[20:55:58] <cehteh> i wonder if there is some undocumented backdoor to do so
[20:56:14] <Lambda_Aurigae> not that I've ever seen.
[20:56:35] <Lambda_Aurigae> must use spi/pdi/tpi/jtag to change fuses on atmega and attiny chips.
[20:56:36] <cehteh> would be somewhat dandgerous
[20:56:38] <Lambda_Aurigae> not sure about atxmega
[20:58:13] <inflex> I'd love to watch the experiments... worth the cost of popcorn :)
[21:01:29] <cehteh> connect a tiny to the tpi pins with a small program only for reprogramming fuses .. pushes the intended fuses up it and go :)
[21:30:45] <WormFood> Lambda_Aurigae, I already have those files, and I still don't see how they make it work as a bootloader. I'm obviously overlooking something.
[21:32:24] <Lambda_Aurigae> look at the build process in the makefile. I believe it's in there where it links it to the bootloader section.
[21:57:20] <WormFood> Lambda_Aurigae, did you even look at those files? There is no Makefile.
[22:01:07] <WormFood> and, they're using IAR C
[22:01:20] <WormFood> The information I seek, does not appear to be in those files.
[22:20:59] <lorenzo> I have to say this Peter Fleury did a beautiful job
[22:21:19] <lorenzo> I'm using his hd44780 and his uart library to make a uart -> lcd bridge
[22:21:28] <lorenzo> all works just fine on the first "make" :-)
[22:27:01] <Casper> lorenzo: yes he did a really good job
[22:27:15] <Casper> jis library not only work, but work beautifully
[22:27:22] <lorenzo> yup, pretty compact code too
[22:27:48] <lorenzo> I've tried rewriting some routines with the strict necessary I needed to handle interrupts but meh
[22:27:52] <Casper> his code is good commercial quality
[22:27:56] <lorenzo> the whole hd44780 + usart fits in less than 1K
[22:30:12] <Casper> now... if you could tell me where my ps3 controller is...
[22:30:37] <Tom_itx> they used to have cords on them just so you wouldn't lose them
[22:33:23] <Casper> I most likelly put it away at xmas...
[22:33:31] <Casper> somewhere so the kids don't play with it
[22:37:10] <Casper> found it!