#avr | Logs for 2016-01-30

Back
[01:01:23] <Deskwizard> well, I tried.
[03:11:58] <julius> morning
[03:12:13] <julius> PORTB &= 253U <- whats the u doing at the end?
[03:51:48] <nuxil> julius,
[03:52:09] <nuxil> it means the number is unsigned
[03:53:02] <nuxil> 253U would be the same as uint8_t foo = 253
[03:57:27] <nuxil> also there is like L for long.
[03:57:42] <nuxil> LUL :p
[03:59:35] <tekkkz> hi
[03:59:37] <grummund_> technically the same as uint16_t foo = 253;
[03:59:51] <grummund_> (avr gcc is 16-bit int)
[04:00:40] <tekkkz> is it possible to flash a atmega32u4 like following: flash the default dfu loader from atmel website by: »avrdude -p atmega32u4 -c stk500v2 -P /dev/mysmart0 -U flash:w:ATMega32U4-usbdevice_dfu-1_0_0.hex« and then how to flash a firmware via the dfu with avrdude?
[04:00:54] <tekkkz> please help me fast, i need to flash fast a firmware on the chip
[04:03:29] <grummund_> also 0x8000 is implied unsigned, 32768 is signed, and 0x7fff is signed, go figure...
[04:04:03] <Xark> grummund_: What? 0x8000 and 32768 should be the same...
[04:04:14] <grummund_> you would think so
[04:04:30] <grummund_> 32768 is implied signed long
[04:04:31] <julius> nuxil, what else would it be? a negativ number for the port wouldnt make much sense
[04:04:49] <grummund_> 0x8000 is implied unsigned int
[04:05:13] <nuxil> julius, you asked what the tailing U ment. and i answered. :p
[04:05:25] <julius> yeah, i was more talking to myself
[04:05:28] <julius> thank you
[04:06:05] <nuxil> np
[04:06:55] <julius> and now the age old guestion, this thing: http://shelfkey.com/prodimg/48747050.jpg is called a crystal resonator. but in the fuse calculator: http://www.engbedded.com/fusecalc/ theres only "crystal osc" - is it the same?
[04:07:16] <sebus> yep
[04:07:22] <julius> ah good
[04:07:59] <nuxil> getting a crystal ?
[04:08:09] <julius> the atmega168 is supposed to run up to 20mhz, yet the fuse calculator 0.4-0.9, 3-8, 8-endless so i tell it that its 8-?
[04:08:17] <julius> got a 16mhz
[04:08:21] <nuxil> dont forget to get a couple of small caps aswell.
[04:08:34] <julius> yes, already attached it with 22pf
[04:08:42] <nuxil> :)
[04:09:04] <Xark> grummund_: Bizarre, but you are absolutely correct (just tested in Arduino IDE). :)
[04:10:06] <tekkkz> or how to use the dfu_
[04:10:10] <tekkkz> dfu-programmer?
[04:10:28] <julius> tekkkz, im sorry, i dont even know what a dfu is
[04:10:37] <tekkkz> lul
[04:10:42] <Xark> tekkkz: I suspect you can use dfu to flash serial bootloader (but I haven't tried it).
[04:10:44] <nuxil> grummund_, what ? if you use hex it becomes uint ?
[04:10:44] <tekkkz> programming mode, different than isp
[04:11:29] <Xark> AFAIK, DFU is the built in method to update AVR flash via USB. Short two pins and reset chip.
[04:11:34] <sebus> Afair crystals have some capacity inside, usually few pF... Some even 12pF ó_ó In some cases external 6-10pF is enough for them, but.. ye, first, find a datasheet for your crystal :]
[04:11:47] <Xark> (AVR USB chips)
[04:12:02] <grummund_> nuxil: no, 0x by itself does not imply unsigned, the rules are more subtle than that.
[04:12:22] <julius> sebus, capacities around crystal seems to be a extended topic, but i cant even determine my capacity on the breadboard
[04:12:41] <sebus> breadboard? ouch...
[04:13:07] <julius> is there something better to get started?
[04:13:09] <nuxil> intresting
[04:13:12] <sebus> I hate them... Loosy contacts. :D
[04:13:22] <sebus> julius for simple stuff its okay
[04:13:43] <sebus> like LED, lcd display, some I/O keys, terminal...
[04:13:45] <grummund_> Xark: Try: if (~(0x8000) != ~(32768)) { printf("How can that be? ;-)\n"); }
[04:15:02] <Xark> grummund_: I was testing with (e.g.) auto i = 32868; and static_assert(sizeof(i)==4, "32868 is long"). etc.
[04:15:07] <nuxil> yeah.. how can that be. please explain the technical stuff here :p i find that confusing,
[04:15:21] <Xark> 32768*
[04:15:46] <grummund_> yep that would do it
[04:19:23] <Xark> nuxil: As grummund_ mentioned, 32768 is considered long (32-bit on avr), whereas 0x8000 is considered unsigned int (16-bit on avr) and -0x8000 == 0x8000 (a quirk of twos-complement, negation of the most negative number is itself)
[04:20:19] <nuxil> auto .. think its the 1st time i see someone used it.
[04:20:27] <Xark> Er, -32768 == 32768 (with a long it is not most negative).
[04:20:28] <nuxil> Xark, thanks
[04:21:14] <Xark> nuxil: It has made a bit comeback with C++11 (which latest gcc supports). :)
[04:21:21] <Xark> big*
[04:21:23] <nuxil> isnt auto from the B language. i can recal reading something like that and is almsot never used in C
[04:21:28] <nuxil> oh
[04:22:05] <Xark> nuxil: Auto as always been there, but it just meant "static variable" and was implied (so no one used it).
[04:22:54] <Xark> Now with C++ it means "make this variable whatever type is appropriate for what I am assigning to it" (or close to that).
[04:23:00] <Xark> C++11*
[04:23:29] <Xark> Er, auto means stack variable* (opposite of static variable).
[04:23:51] <grummund_> Xark: for the avoidance of doubt, 32768 is only long because it will not fit in 16-bit int
[04:24:16] <grummund_> Xark: if the platform uses 32-bit int then 32768 is indeed int
[04:24:49] <nuxil> that makes sense
[04:25:29] <Xark> grummund_: Right, makes (some) sense. :)
[04:26:01] <grummund_> whereas 0x notation says to the compiler if it won't fit an int then try unsigned int
[04:26:39] <grummund_> and if it won't fit unsigned int then try long, etc.
[04:26:57] <Xark> So ultimately 0x constants default to unsigned vs decimal constants default to int.
[04:27:07] <grummund_> no :p
[04:27:10] <nuxil> no
[04:27:16] <grummund_> 0x7fff is signed int
[04:27:23] <grummund_> because it fits
[04:27:26] <nuxil> thats what i asked earlyer in a way :p
[04:27:31] <Xark> I see, so it is "subtle".
[04:27:49] <grummund_> "screwy" :P
[04:29:11] <Xark> I was going to say it pretty much only affects int == 16-bit targets...but I guess the same "confusion" can happen for 0x80000000 and 64-bit "long".
[04:30:42] * Xark files that away for his day job. :)
[04:33:00] <julius> sebus, true
[04:33:27] <julius> finally, easy to understand and running serial to usb code: http://paste.pound-python.org/show/VGPlmKrnVUBOgcZkex5U/
[04:36:02] <julius> Xark, whats your day job if i may ask?
[04:36:27] <Xark> Long time game developer (currently PS4 and Xbox One).
[04:36:57] <Xark> Started on Atari 2600. :)
[04:37:09] <Xark> (professionally)
[04:37:16] <nuxil> nice :D
[04:37:26] <nuxil> any known titles ?
[04:37:52] <julius> sounds like a nice job
[04:38:22] <Xark> nuxil: A safe bet. :)
[04:38:40] <julius> cant tell?
[04:38:49] <Xark> Here are a few (but far from all, and this is several years old) -> https://justpaste.it/uop
[04:39:34] <nuxil> thats just your game collection :p
[04:39:36] <nuxil> jk
[04:39:48] <nuxil> thats alot of game you been involved in
[04:39:51] <nuxil> *games
[04:39:55] <julius> i know starcraft
[04:39:56] <julius> great game
[04:40:01] <Xark> Hehe, no, that is far larger. I played a role in programming all of those (often a significant role).
[04:40:43] <julius> i was more a pc player, did you do work on something like battlefield?
[04:40:53] <nuxil> Xark, is it mostly inhouse 3d enginge or are you using ubisoft/unreal etc ?
[04:41:08] <Xark> julius: We did Starcraft 64, cramming ~80MB of PC game into a 16MB N64 cart (challenging). :)
[04:41:42] <julius> wow
[04:41:55] <Xark> nuxil: Depends. In house, or "retrofit" some other companies engine to run on another platform.
[04:43:03] <nuxil> nice. i started experimenting with gamedev. didnt get far. :p
[04:43:19] <Xark> julius: PC is usually a target these days, but not one I work on too much. I am generally on console optimization team (getting low-level and down and dirty).
[04:43:37] <nuxil> my 1st project http://www.jointheriot.org/Games/CSG.html :p far far from done though
[04:44:58] <nuxil> erm. closed wrog window :p
[04:47:18] <Xark> I started my professional gamedev career in 1981, hired for Atari 2600 (and then the 2600 market collapsed [ET etc.] so I was switched to 400/800/5200 - mercifully). :)
[04:48:22] <nuxil> impressive :D
[04:51:02] <Xark> It has been a pretty fun ride starting when game industry was "tiny" to where it is huge (comparatively). Mostly survived and have done well (and still working on interesting "AAA" games).
[05:07:04] <sebus> Xark o_O
[05:07:09] <sebus> Atari 2600? Woah....
[05:08:22] <Xark> Yeah, a great machine to make sure you know all the 6502 instruction cycle times by heart (or you would have bugs like the screen would "roll"). :)
[05:08:51] <sebus> ye, because no video framebuffer
[05:09:12] <sebus> and huge amount of RAM
[05:09:19] <Xark> Nope, "racing the beam" (with a tiny amount of hardware support to shift out sprites etc.).
[05:09:40] <Xark> If 128 bytes is huge. :)
[05:10:10] <sebus> I was shocked back in time when my parents bought me Solaris cartridge
[05:10:21] <Xark> 20 pixel "frame buffer" (and you could repeat or mirror it for 2nd half of screen).
[05:10:37] <sebus> even more shocked few years later because I had no idea what was inside 2600...
[05:11:12] <sebus> tricky stuff
[05:12:41] <Xark> Yeah, very tricky. I was relieved when I got to move to Atari 400/800/5200 (much less "voodoo"). :)
[05:14:07] <Xark> Although 5200 was a bitch, because no good development station (not official developer), so had to burn UV EPROMs for each test (kept them cycling in UV eraser). Took ~45 minutes per test iteration (with no debugger).
[05:16:26] <Xark> [Translation: Uphill in the snow both ways, and get off my lawn. ] :)
[05:17:04] <sebus> I though devs had SRAM carts with power pack to simulate "eeproms"
[05:17:10] <sebus> ouch x2
[05:17:22] <Xark> I did not.
[05:18:00] <Xark> For 400, they replaced dynamic RAM with static RAM board so I could use off the shelf 6502 ICE (unplug 6502, plug in ribbon cable from box hooked to MP/M system via serial).
[05:18:18] <Xark> So I had great debugging for 400 (and 800) version.
[05:18:45] <Xark> Luckily, 5200 was "very similar" to 400/800.
[05:19:03] <sebus> reminds me of AVGN video for 5200
[05:19:07] <sebus> huge beast :D
[05:20:50] <Xark> Seriously embarrassing to look at now -> https://www.youtube.com/watch?v=XDn4J5N7bCA :) [But my first released game when I was 17 years old and having a blast]
[05:21:57] <sebus> Wow ;o
[05:24:44] <Xark> I put my aunt's phone number hidden in the ROM (I lived with her at the time - she had the Apple ][) with Call XXX-XXX-XXXX and say "Yoho". I got all kinds of interesting calls from "phone phreaks" and pirates (fun times). My aunt was not quite as amused (but she would hand me the phone). :)
[05:25:54] <sebus> Xark http://s7.fmdx.pl/basement1.jpg :P
[05:26:34] <Xark> sebus: Nice. I think I have programmed for pretty much all of those at one time or another. :)
[05:27:09] <Xark> What is in the right corner? PET? OSI?
[05:27:26] <sebus> pet. still no time to fix crt and replace ROMS
[05:27:28] <Xark> Must be PET with the trapizond monitor.
[05:27:44] <Xark> trapizoid*
[05:27:47] <Xark> yeah
[05:27:54] <sebus> also, need some 6845's for other PETs
[05:28:11] <sebus> no Vsync, no Hsync...
[05:28:18] <Xark> I loved my PET 2001. Wore the paper key-caps blank. :)
[05:29:35] <sebus> Haha :D
[05:29:50] <Xark> I got it in exchange for writing educational software for the local school district. :)
[05:29:58] <sebus> Much same with my ZX Spectrum....
[05:31:42] <Xark> I never had one of those, but I did get to play around with a friends. Easy to take a pass on if you have access to (e.g.) Apple ][.
[05:31:42] <sebus> Once PLA died. Ye, ferranti chip... Had to replace it with bunch of TTL. Not fitting in case anymore, but works ;]
[05:33:12] <sebus> k, time to go
[05:33:15] <sebus> work time \o/
[05:33:16] <sebus> o/
[05:33:17] <Xark> My aunt ran an early computer school the "Computer Workshop" and I had a room very similar to your picture with Apples, C64s, Ataris etc. Pretty much ideal playground for me. :)
[05:33:36] <Xark> Take care \o
[07:24:21] <tekkkz> Hi. Can someone have a look here please: https://www.mikrocontroller.net/topic/388412#4447575
[07:25:59] <julius> UCSR0C = (3<<UCSZ00); <- what is UCSZ00 doing here? usually there would stand the number of left shifts. since USCZ00 is a bit in UCSR0C how does this work?
[07:31:29] <julius> looks like this operation sets: /* Frame format: 8data, No parity, 1stop bit */
[07:38:34] <julius> the thing is that 8bit, no parity, 1 stop bit is also the default....so why write that 3<<UCSZ00 at all?
[07:40:13] <coded1> hello all
[07:41:24] <coded1> I bought some cheap Atmega 328p chips from ebay. I doubt there are any bootloaders installed. I want to bring these guys to life with my raspberry pi
[07:41:35] <coded1> has anyone ever accomplished such a feat ?
[07:42:34] <grummund_> julius: probably just a placeholder, so other settings could be used.
[07:43:44] <julius> grummund_, how would UCSR0C look like after that bit operation if its all 0 before?
[07:45:43] <grummund_> depends on UCSZ00. and what's *your* best guess?
[07:49:38] <mimer> coded1, totally possible!
[07:50:23] <julius> grummund_, UCSZ00 is 1 by default. so UCSR0C is 00000110
[07:51:03] <julius> its just confusing to use UCSZ00 to get "1" when UCSZ00 is a bit in the UCSR0C byte
[07:51:24] <julius> or at least it does not make sense to me
[08:20:43] <coded1> mimer; know of any how to's ?
[08:35:55] <grummund_> julius: that's correct. if you prefer just write UCSR0C = 0x06; /* 8N1 */
[08:38:24] <nuxil> coded1, do you have a breakout board?
[08:39:45] <nuxil> coded1, this is how i got started with my PI & tiny85 chips. idk if its any usefull for you though.
[08:39:47] <nuxil> http://www.instructables.com/id/Programming-the-ATtiny85-from-Raspberry-Pi/
[08:48:07] <tekkkz> HEllo, someone knows what "$(LINK.o)" is? I found at in a makefile, but its not defined there ... ?
[08:50:37] <Tom_itx> do you need it?
[08:50:39] <Tom_itx> delete it
[08:51:17] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/avr/atmega328/PCINT0/makefile
[08:51:24] <Tom_itx> there's a sample make i use
[08:53:51] <coded1> nuxil: thanks, yes I have a breakout board, a ton of resistors, transistors and power regulators
[08:54:22] <coded1> does the AT tiny 85 have the same hookups as the 328p?
[08:55:31] <Lambda_Aurigae> hookups?
[08:55:37] <Lambda_Aurigae> like, for programming?
[08:55:41] <coded1> yes
[08:55:54] <Lambda_Aurigae> they both use ISP.
[08:56:14] <Lambda_Aurigae> same interface.
[08:56:29] <Lambda_Aurigae> pins will be in different locations as the chips have different number of pins.
[08:56:47] <coded1> can I use ISP even if there is no bootloader?
[08:56:54] <Lambda_Aurigae> yes
[08:57:00] <Lambda_Aurigae> you use ISP or bootloader
[08:57:02] <tekkkz> Tom_itx, i also own a sample makefile i use at every project ... but in combination with the m8lib i cant use mine anymore and i need to use the LINK.o code line ... could you please help me changing my makefile from this codeline into a normal one generating OBJS: SRCS and so on?
[08:57:09] <Lambda_Aurigae> without bootloader you have to use ISP
[08:57:16] <Lambda_Aurigae> with bootloader you don't need ISP.
[08:57:35] <coded1> Lambda_Aurigae: cool thanks
[08:57:35] <Lambda_Aurigae> except for changing fuses...that must be done with ISP...or in some chips JTAG.
[08:58:14] <Lambda_Aurigae> I recommend actually reading the datasheet
[08:58:23] <tekkkz> Tom_itx, thats mine working one: https://bpaste.net/show/f68d470963df and in line 42 is the bad code ... can you help me changing it please?
[09:00:27] <Lambda_Aurigae> coded1, if you are going to use an rPI as the programmer, remember that the rPI i/o pins are 3.3V and are NOT 5V tolerant so you must run the AVR at 3.3V.
[09:05:33] <Lambda_Aurigae> tekkkz, looks like you are missing a line up top that defines LINK.o....
[09:06:30] <Lambda_Aurigae> LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
[09:06:34] <Lambda_Aurigae> like that maybe.
[09:07:54] <Lambda_Aurigae> that exhausts my google/makefile-fu capabilities.
[09:12:39] <tekkkz> Lambda_Aurigae, nono, it works fine
[09:12:58] <tekkkz> but the problem is that my $(Q), so the @ to mute the command, does not work for LINK.o
[09:14:23] <coded1> Lambda_Aurigae: do I need an occilator ? I have 8MHz - 20MHz
[09:15:36] <Lambda_Aurigae> tekkkz, then, no clue.
[09:15:56] <tekkkz> Lambda_Aurigae, you have an idea how to mute it "recursively"?
[09:16:22] <Lambda_Aurigae> coded1, haven't read the datasheet I see.....if the chips are new from the factory then they are set to 1MHz internal RC oscillator, no external oscillator or crystal needed....
[09:16:33] <Lambda_Aurigae> tekkkz, sorry, makefiles are black magic to me.
[09:16:57] <tekkkz> lool haha okay, thanks anyway
[09:17:12] <Lambda_Aurigae> I use executable bash files myself most of the time...which, granted, are not as powerful, but do the job for me.
[09:17:35] <coded1> Lambda_Aurigae: thanks again
[09:18:10] <Lambda_Aurigae> coded1, welcome....again, I strongly recommend reading, and learning to understand, the datasheet for the chip you are working with.
[09:18:38] <Lambda_Aurigae> the kids I teach here don't get to touch a chip until they have done do...but, I'm a bastard teacher sometimes.
[09:20:08] <tekkkz> SOMEONE KNOWS HOW TO "RECURSIVELY" MUTE, AKA @, THE COMMAND $(LINK.O) IN A MAKEFILE SO IT PRODUCES NO OUTPUT?
[09:20:12] <tekkkz> oh shit sry for caps
[09:20:33] <sebus> tekkkz ouch, my ears, don't scream :D
[09:20:36] * sebus is back
[09:20:57] <tekkkz> sebus, hehe :D btw, you know a solution?
[09:21:42] <sebus> or, rather, don't shout :D
[09:21:44] <sebus> nope
[09:21:49] <sebus> but lemme find out
[09:22:48] <sebus> tekkkz http://stackoverflow.com/questions/10371440/supressing-output-from-my-makefile
[09:22:49] <sebus> this?
[09:24:10] <tekkkz> sebus, tryed already with @, but LINK.o ignores it with its output ...
[09:24:17] <Lambda_Aurigae> try the make -s
[09:24:30] <sebus> make --silent
[09:24:33] <sebus> ye Lambda_Aurigae
[09:24:39] <Lambda_Aurigae> SSDF
[09:25:03] <Lambda_Aurigae> or, maybe make > /dev/null
[09:27:12] <coded1> Lambda_Aurigae: makes sense.
[09:28:46] <Lambda_Aurigae> coded1, I find that a good majority of the questions asked in here about the AVR chip itself and its configuration and use are answered in the datasheet...that's where I find many of the answers I might give here and I suspect many of the answers that others give as well. Unfortunately, too many people try to run before they learn to crawl.
[09:28:59] <Lambda_Aurigae> there are lots of code examples in the AVR datasheets too.
[09:30:50] <Lambda_Aurigae> I don't mind answering questions as that's why I'm here and I often learn from looking them up myself...but it is like the give a man a fish story...
[09:31:08] <Lambda_Aurigae> glub...I'm going into teacher mode....must go do something to alleviate that!
[09:31:42] <sebus> Lambda_Aurigae true that, a lot of useful stuff can be found in avrxxx.pdf docs
[09:31:58] <Lambda_Aurigae> and in the appnotes as well.
[09:32:13] <Lambda_Aurigae> I have binders full of datasheet and appnotes printed out.
[09:32:15] <coded1> Lambda_Aurigae: I'm on it!
[09:32:20] <sebus> well, google is your friend, sometimes...
[09:32:23] <Lambda_Aurigae> and have them all in digital form too.
[09:33:27] <Lambda_Aurigae> I spend hours each week reading various datasheets from all over,,,even for chips I may never see or use....yes, I'm an uber nerdy techno-geek.
[09:40:48] <sebus> I used to print datasheets / various schematics in school library.
[09:41:04] <tekkkz> Lambda_Aurigae, sebus nono, not the whole thing should be silent
[09:41:08] <tekkkz> only this command
[09:41:59] <sebus> find a call to gcc and redirect output somewhere else
[09:45:36] <tekkkz> sebus, its not only gcc, its doing all, rm and everything, and also in strange orders ...
[09:58:13] <martinus> Here's a question that might make a few of you wince: If you don't have any mdae-for-purpose contact cleaner what would you use instead if you wanted to clean PCB-mounted contacts that probably have moisture infiltration?
[09:58:43] <martinus> I have isopropyl (99%) and all of the standard household cleaners.
[09:58:57] <tekkkz> ahh maybe i can redirect the output to /dev/null
[09:59:18] <sebus> isopropyl should work martinus
[09:59:27] <martinus> Feel free to shout "go get some actual contact cleaner!" if you think it's appropriate. :D
[10:01:39] <sebus> in some cases when I have some corrosion or battery leaks on PCB I use... lemon juice :D
[10:01:51] <sebus> works perfect
[10:02:13] <sebus> dont forget to wash board afterwards and dry :>
[10:02:18] <martinus> mild acid - makes sense.
[10:10:13] <coded1> is there a way to detect if the 328p is defective or not?
[10:10:42] <coded1> just incase I spend the next week trying to get this thing going just to figure out it's a "brick"
[10:11:23] <martinus> IIRC you can damage some of the pins without killing the chip outright.
[10:12:29] <sebus> coded1 once I had a problem with mega644 chip - random reset or toggling pins on ports
[10:12:51] <sebus> replace chip if you have and test it
[10:13:19] <sebus> also look @ martinus
[10:17:25] <coded1> this is my first AVR, never actually interfaced with this chip before
[10:18:07] <martinus> Probably best to write some code that toggles pins. You could use a bit of perf-board and some LED's to do at least simple analysis. Anything more requires a 'scope
[10:18:34] <coded1> right now I would be happy getting avrdude to ack the chip
[10:18:37] <coded1> but I will see
[10:18:39] <coded1> :)
[10:18:46] <martinus> If you can't upload code then that points to misconfigured fuses or potential damage.
[10:19:09] <coded1> I doubt I've even done it right yet
[10:19:35] <coded1> I just put together a nice wiring harness to make sure everything lines up
[10:19:41] <coded1> will let you know how it goes
[10:19:49] <martinus> Good luck. :)
[10:19:59] <coded1> thanks
[10:22:02] <sebus> martinus also if you do some test on a breadboard, dont forget to put some caps on it and check for loosy contacts
[10:22:34] <sebus> meh
[10:22:51] <sebus> s martinus / coded1
[10:27:13] <coded1> when connecting MISO from the AVR does it go to MOSI on the programmer?
[10:28:43] <sebus> nope, 1:1
[10:28:49] <sebus> MISO - MISO
[10:28:52] <sebus> MOSI - MOSI
[10:28:54] <sebus> SCK - SCK
[10:56:14] <martinus> Eh? MISO should go to MOSI unless I've missed something about coded1's circuit
[10:57:57] <martinus> No, wait, I'm an idiot.
[11:06:04] <Lambda_Aurigae> miso to miso
[11:06:06] <Lambda_Aurigae> mosi to mosi
[11:06:08] <Lambda_Aurigae> sck to sck
[11:06:14] <Lambda_Aurigae> master out slave in
[11:06:30] <Lambda_Aurigae> master in to slave out.
[11:10:39] <Lambda_Aurigae> so, mosi is output on the master and input on the slave.
[11:10:51] <Lambda_Aurigae> and versa visa.
[11:13:51] <inkjetunito> :o~ MISO ramen
[11:49:03] <tekkkz> HEllo! Im my makefile i need to use "$(LINK.o) " ... but its making so much output, how can i mute it?
[11:51:59] <cehteh> MAKEFLAGS = -s or .SILENT target or starting lines with @
[11:52:48] <tekkkz> nono
[11:52:55] <tekkkz> @ wont work
[11:53:08] <tekkkz> idk why, but maybe because the $(LINK.o) is running so much
[11:54:01] <tekkkz> .SILENT and -s also not work
[11:55:33] <cehteh> i have no idea what you exactly doing
[11:55:39] <cehteh> when you do it right it should work
[11:56:56] <tekkkz> im doing following:
[11:57:38] <tekkkz> https://bpaste.net/show/00f3169752b9
[11:57:42] <tekkkz> cehteh, line 42
[11:59:14] <cehteh> what is LINK.o anyway?
[11:59:45] <cehteh> i dont see that defined
[12:01:10] <tekkkz> its from make defined
[12:01:16] <tekkkz> check it out »make -p«
[12:01:22] <tekkkz> in a directory where no makefiel is
[12:01:57] <cehteh> ah
[12:02:23] <tekkkz> any idea how to mute it?
[12:02:31] <cehteh> but thats a mix of implicit and explcit things
[12:02:50] <cehteh> LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
[12:02:55] <tekkkz> yu
[12:03:01] <tekkkz> and how to mute that?
[12:03:03] <cehteh> .. and you double the flags
[12:03:15] <tekkkz> its working like i have it
[12:03:26] <tekkkz> my makefile works, i just wanna get it muted
[12:03:33] <cehteh> working by cance
[12:03:38] <tekkkz> ?
[12:03:41] <cehteh> $(Q)$(LINK.o) $(CFLAGS) $(LDFLAGS) $(FIRMWARE).a -o $@
[12:03:46] <tekkkz> no
[12:03:47] <cehteh> is what you have
[12:03:51] <tekkkz> ye
[12:03:52] <cehteh> that expands to
[12:04:17] <cehteh> $(Q)$(CC) $(LDFLAGS) $(TARGET_ARCH) $(CFLAGS) $(LDFLAGS) $(FIRMWARE).a -o $@
[12:04:25] <cehteh> LDFLAGS is twice there
[12:04:59] <tekkkz> okay
[12:05:03] <cehteh> anyway i dont know why and what it prints, and i try not to rely on implicit rules and variables
[12:05:08] <tekkkz> but without doubling it would it be quiet?
[12:05:22] <cehteh> no just pointing out some other problem
[12:05:34] <cehteh> i have no idea why its printing so much
[12:05:50] <cehteh> in my makefiles silenencing things works well
[12:05:56] <cehteh> but i do it differently
[12:05:56] <tekkkz> its printing this: http://ix.io/o0X
[12:06:46] <tekkkz> how you do it?
[12:07:36] <cehteh> http://paste.debian.net/377658/ .. thats my output :D
[12:07:48] <cehteh> but i made a lot more stuff for the makefiles
[12:08:00] <cehteh> (and its not finished)
[12:09:13] <tekkkz> in my makefiels i have simiar output ... except this makefile, cause i need to use this LINK.o ... how to mute its output? q.q
[12:09:46] <cehteh> i really dont know what wrong there, i would have to debug that too
[12:11:38] <tekkkz> cehteh, any idea how i can make own rule out of the LINK.o ? ... i mean, i need to generate a lib.a file .... how to do that?
[12:12:25] <cehteh> git.pipapo.org/?p=muos;a=blob;f=src/muos/hw/atmel/platform.mk
[12:12:30] <tekkkz> ahh
[12:12:37] <tekkkz> i found out how i need to do it manually :D
[12:13:04] <cehteh> note that i have to 'sed' out some warning because of a gcc bug .. :D
[12:51:25] <julius> if RXCn is set, theres data to be read from the uart register...right? ive got a function here that looks like this: return( UCSR0A & (1<<RXC0)) ; this function is called from a loop, so until the condition is true it loops endlessly. but why is there UCSR0A & (1<<RXC0) ? why not return RXC0 ?
[12:51:38] <julius> RXC0 would be 0, if there is not data and 1 if there is data
[12:51:47] <Jartza> ahh. the LTO bug
[12:52:06] <julius> ah wait, outside of UCSR0A that RXC0 has no meaning, right?
[12:52:06] <Jartza> ISR handlers become "misspelled" with LTO
[12:52:18] <tekkkz> cehteh, how to make a rule for generating a file.a via : avr-ar rv file.a source.o where i have multiple sources so it must run miltiple times?
[12:52:40] <tekkkz> cehteh, how to make a rule for generating a file.a via : avr-ar rv file.a source.o where i have multiple sources so it must run miltiple times?
[12:53:40] <Jartza> julius: UCSR0A & (1<<RXC0) takes content of UCSR0A and ANDs it with 1 << RXC0, which is RXC0 bit "value" in that register.
[12:54:25] <Jartza> so RXC0 is not "variable" containing that bit, it's just defined as a bit number in UCSR0A register
[12:54:57] <julius> if RXC0 is a bit number in UCSR0A - why the shift?
[12:55:09] <Jartza> bit number, as in 0-7
[12:55:25] <julius> yeah, so its 7
[12:55:26] <Jartza> not bit value
[12:55:56] <julius> and the shift is to get the bit value?
[12:55:58] <cehteh> tekkkz: i dont do libraries/archives i just link all .o's togehter (with -flto)
[12:56:00] <Jartza> if you and UCSR0A with value 7, you only get values of 3 lowest bits
[12:56:12] <Jartza> as 7 = 0b00000111
[12:56:26] <Jartza> but 1 << 7 = 128'
[12:56:38] <tekkkz> cehteh, but i get error at using all .o's... see here (wait a moment pls)
[12:56:43] <Jartza> essentially that's then same as UCSR0A & 128
[12:57:06] <cehteh> tekkkz: possibly because your approach which doubles some flags
[12:57:43] <julius> Jartza, ah ok. so i shift my 1 seven times to the left
[12:57:49] <Jartza> yes
[12:58:00] <julius> complicated, but ok
[12:58:02] <Jartza> 1 -> 2 -> 4 -> 8 -> 16 -> 32 -> 64 -> 128
[12:58:08] <Jartza> not really complicated
[12:58:24] <cehteh> tekkkz: its a bit ugly with 'buildin' variables and rules in make
[12:58:26] <julius> and what header defines RXC0?
[12:58:55] <Jartza> what chip?
[12:59:09] <Jartza> usually you #include <avr/io.h>
[12:59:13] <tekkkz> cehteh, with this makefile: https://bpaste.net/show/40594a9413aa im getting this output: https://bpaste.net/show/cc67d028ad77
[12:59:19] <tekkkz> cehteh, what did i wrong?
[12:59:19] <Jartza> but that header file includes several others depending of the chip
[12:59:50] <cehteh> tekkkz: that looks like you double something
[13:00:02] <tekkkz> what? can you help me finding it?
[13:00:15] <tekkkz> cehteh, you need .map file or sth else?
[13:00:27] <cehteh> nah .. keep it simple
[13:00:49] <Jartza> julius: but for example, atmega328p has it in avr/include/avr/iom328p.h
[13:01:01] <tekkkz> cehteh, what do you mean with keep it simple?
[13:01:12] <cehteh> i'd really recommend that you dont use any implicit suff, unless you exactly know whats happening
[13:01:31] <cehteh> keep it simple as you dont want .map files or linker scripts to make this work
[13:01:34] <Jartza> there's:
[13:01:35] <Jartza> RXC0
[13:01:37] <Jartza> oops
[13:01:40] <Jartza> #define RXC0 7
[13:01:47] <cehteh> you may want to have some explicit rules instead buildin ones
[13:02:35] <cehteh> and comment things out / disable features to get a basic test (just main) linked
[13:02:52] <cehteh> then readd things step by step and see what happens
[13:02:53] <julius> Jartza, ah..was just curios. ive got a 168 here
[13:03:16] <cehteh> thats the best way to debug this i think
[13:05:38] <cehteh> bbl
[13:06:40] <tekkkz> what does explicit means?
[13:07:30] <julius> this is working code for a serial connection: http://paste.pound-python.org/show/7f3cGgFH6IKSUnnSVhSQ/ but sometimes the code does not send the H (infinite times) before it receives data...why is that?
[13:07:55] <julius> when it receives data, the H output should stop and the code echoes the input back....the echo works
[13:21:41] <sebus> 16MHz, 9600bps
[13:21:49] <sebus> ~0,2% error
[13:22:00] <sebus> If I did math correctly
[13:24:32] <Lambda_Aurigae> julius, you have an atmega168 with the external crystal(or oscillator) at 16MHz and fuses correctly set to that clock source?
[13:25:20] <sebus> Lambda_Aurigae also.. look at line 111 and 112
[13:25:27] <sebus> UBRR should work?
[13:25:39] <sebus> UBRR = MYUBRR;
[13:25:46] <sebus> instead of shifting
[13:26:03] <Lambda_Aurigae> meh.
[13:26:06] <Lambda_Aurigae> I wouldn't do it that way.
[13:26:27] <sebus> as far as he said he can receive "H" letter or 0x48 in ascii
[13:26:34] <sebus> then it should be okay
[13:27:34] <Lambda_Aurigae> I would set UBRRH = 0x00; and UBRRL = 0x67; but I like explicit settings..
[13:28:07] <Lambda_Aurigae> or, UBRR0H and UBRR0L
[13:28:23] <Lambda_Aurigae> I didn't know the 168 had dual USARTs
[13:29:26] <sebus> but then you have to re-calculate stuff. You can also use equation like (( F_CPU + (16 * BAUD) / 2 ) / (16 * BAUD) -1)
[13:29:42] <sebus> just store in 16 bit unsigned int and put to UBRR ;]
[13:30:19] <sebus> useful if you control /switch between clock sources by avr for some reasons
[13:30:21] <Lambda_Aurigae> as for why it doesn't send the H sometimes, looks like there might be some data in the USART buffer to start.
[13:30:56] <sebus> I would use interrupt for receiving bytes
[13:31:17] <Lambda_Aurigae> random noise, the other end sending something or doing something on the line...doesn't take much to get random data on a line for the USART to pick up.
[13:31:19] <sebus> putting stuff to array + volatile integers
[13:31:21] <Lambda_Aurigae> I would flush the buffer.
[13:31:28] <Lambda_Aurigae> then start up.
[13:32:31] <Lambda_Aurigae> read the UDR0 at least once before starting the whole process.
[13:33:20] <sebus> julius just got a question... why no uart receive interrupt?
[13:33:35] <sebus> it would help you a lot
[13:33:45] <sebus> really
[13:33:55] <Lambda_Aurigae> sebus, just looks like a simple non-blocking check for data, read data system...
[13:34:03] <julius> Lambda_Aurigae, yes. i did set it that way. ive used a loop to send the number 1...1000 to the uart and they all echoed back correctly
[13:34:29] <julius> sebus, first time uart...let me google that
[13:34:44] <sebus> Lambda_Aurigae true that, he's polling
[13:34:46] <Lambda_Aurigae> and I'm gonna go make sawdust.
[13:36:27] <julius> ok, interrupt driven is better...but for this "simple" example maybe not needed
[13:37:38] <julius> Lambda_Aurigae, random data...ok
[13:38:08] <julius> could a usb programmer cable crossing the usb-> serial cable on the desk do that already?
[13:39:15] <julius> forgot to mention, when the H isnt send it always echoes back input. so the explanation that something already entered the buffer is plausible
[13:40:16] <sebus> julius 232 itself can be easily harmed by other signals.
[13:40:27] <sebus> it's not like 485...
[13:42:05] <sebus> good you are trying to play with low speed, but still... ouch
[13:42:57] <sebus> Also, do you have any caps on breadboard? Are you powering stuff from USB/programmer?
[13:43:26] <julius> weird, when the circuit got no power and i reattach the usb->serial converter i can read the last number from ttyUSB0 no external power source on the circuit and the +5v from the converter is not attached
[13:44:19] <julius> theres a 22pf between +5v and gnd just before VCC/GND of the atmega
[13:44:53] <julius> and the 16mhz crystal is also connected with two 22pf to gnd
[13:44:53] <sebus> Always use capacitors on power lines
[13:45:17] <sebus> alike 22uF/47uF electrolytic+100nF near every pair of VCC/GND
[13:45:25] <julius> i mean a 22pf couldnt buffer a atmega for some time?
[13:45:30] <sebus> why? lemme see...
[13:46:10] <sebus> it may be good only in case you have HF noise on power lines
[13:46:12] <julius> the caps are all non electrolytic
[13:48:25] <sebus> julius http://1.bp.blogspot.com/-glU0jDwbpiY/T4SsHO-DvtI/AAAAAAAAAV4/rGgImBhdlPk/s1600/VCC_bez_filtracji.jpg without capacitors you got a lot of noise
[13:48:44] <sebus> http://2.bp.blogspot.com/-kUXesXJmIqY/T4Ss5OffLjI/AAAAAAAAAWA/IhsDp-6NWf4/s1600/VCC_plus_filtracja.jpg just put 22uF electrolytic + 100nF on power pins
[13:50:08] <sebus> you have atmega168, right?
[13:50:11] <sebus> julius?
[13:52:02] <julius> yes
[13:52:13] <julius> just got my capacitor bag
[13:52:44] <sebus> You don't use ADC?
[13:52:46] <sebus> right?
[13:52:48] <sebus> right...
[13:53:17] <sebus> so PIN no 7 and Pin no 20 should be tied to VCC, and PIN 8 & 22 to GND
[13:53:34] <julius> no adc in use
[13:53:43] <sebus> both pairs VCC+GND and AVCC+GND must have 100nF at least
[13:54:00] <sebus> + one 47uF or 22uF electrolytc
[13:54:09] <julius> got some 100nf capacitors without electrolyte
[13:54:13] <julius> will they do?
[13:54:24] <sebus> put few of them at least on power pins
[13:54:28] <sebus> near chip
[13:55:29] <julius> yes
[13:57:17] <sebus> julius chip itself generate a lot of noise. If you were in touch with old TTLs like 74LS family, you would have a lot of troubles figuring out why things doesnt work as expected. Much same with CPUs.
[14:00:07] <julius> i see
[14:03:38] <sebus> julius ye, found it http://www.atmel.com/Images/doc8396.pdf
[14:03:52] <sebus> AVR178
[14:06:10] <sebus> and this http://www.avrfreaks.net/forum/decoupling-capacitor-vcc-pin
[14:13:47] <julius> found it
[14:14:12] <julius> the software is ok, but the circuit only works if the programmer is connected. but VCC/GND is there without the programmer
[14:14:27] <julius> the led PB1 goes on when the programmmer is connected
[14:17:51] <sebus> serial communication requies common ground and RX or/and TX lines
[14:18:21] <julius> the gnd from the serial converter is connected to the circuit
[14:20:25] <julius> looks like youre right, if the gnd from the programmer is not connected and i attach the converter. nothing
[14:21:59] <julius> it even resumes sending h when i reconnect gnd without restarting anything
[14:24:18] <sebus> don't mess with grounding. Disconnecting ground may kill your usb-uart converter
[14:24:39] <sebus> or kill avr input/output
[14:25:58] <sebus> if you're unlucky, there might be huge difference between I/O voltages without common ground
[14:26:43] <julius> oh
[14:27:48] <julius> for testing purposes i measured gnd versus vcc of the serial -> usb converter, it was +5v
[14:27:55] <julius> so gnd is generally connected on that thing
[14:30:12] <sebus> That's the case when you for eg. have two different things connected from different power supplies. Like you have uart debug on one computer, programmer connected to 2nd computer, both have separate power supplies. No common ground between them may harm your devices
[14:30:56] <julius> ok, will a passive usb hub protect my computer usb port?
[14:31:49] <sebus> Just use common ground or use optocoupler for communication
[14:32:17] <sebus> IIRC there are uart converters with optocouplers
[14:32:53] <sebus> Lol, too much to talk about analog stuff :<
[14:33:14] <julius> hm ok
[14:46:24] <julius> heres protectiong: https://www.olimex.com/Products/USB-Modules/USB-ISO/
[14:47:23] <cehteh> nice price :D
[14:48:39] <Lambda_Aurigae> I just use a usb hub and haven't had any issues.
[14:49:38] <sebus> for serial communication I use my stuff based on ADM2587E chip
[14:49:40] <cehteh> put a 1k or so resistor in series with data lines and maybe some zener to ground is often a good idea too
[14:50:05] <sebus> cehteh ye, but first he must have rock solid ground
[14:50:19] <cehteh> yes
[14:50:43] <sebus> if it fails, then who knows where magic smoke may appear :D
[14:51:39] <cehteh> usually its not that hard to make good ground connection, if you cant and/or you dont trust the devices then you may look into isolation of some sorts
[15:43:21] <julius> Lambda_Aurigae, does it protect usb from voltages below ground or above 5v?
[15:44:18] <Lambda_Aurigae> julius, well, I've never blown out a usb port on a computer but have had to replace the usb hubs several times...usually overvoltage is my problem.
[15:45:08] <julius> thing is that i would bet all my money that the cheaper hubs dont have any protection at all
[15:45:14] <Lambda_Aurigae> I generally buy them in bulk, 10 at a time, for under 5 dollars each.
[15:46:16] <Lambda_Aurigae> I've let the magic blue smoke out of at least 20 usb hubs in the last 10 years.
[15:47:52] <julius> i will probably just wait for that esp8266 and test all my things over wireless
[15:48:21] <julius> Lambda_Aurigae, thats not what they meant when it say's "smoke more"
[15:48:39] <Lambda_Aurigae> I was just looking at a new wireless device to compete with the esp8266
[15:49:02] <Lambda_Aurigae> http://hackaday.com/2016/01/30/esp8266-killer/
[15:50:15] <julius> sounds interresting but for my part i wanted to start cheap
[15:50:29] <Lambda_Aurigae> those are cheaper than esp8266.
[15:50:37] <Lambda_Aurigae> I found some on ebay for under 5.00 USD
[15:50:51] <julius> hm, a search on aliexpress showed them starting at 7
[15:50:54] <cehteh> julius: i'd just check that ground is connected to PE ('erde') on each device .. then protection with zener and resistor should reasonable well for normal devices
[15:51:08] <Lambda_Aurigae> http://www.ebay.com/sch/i.html?_from=R40&_nkw=nl6621
[15:51:32] <julius> esp-12e is <2€ from the chineese market
[15:52:07] <Lambda_Aurigae> will be a competition soon though.
[15:52:15] <julius> cehteh, this is a laptop from 2001. but when i get a new one thats expensive im not experimenting with a self made security device
[15:52:25] <Lambda_Aurigae> I'm still playing with old first generation nordic 2.4GHz chips.
[15:52:25] <julius> ah yes
[15:52:58] <julius> when the chinese copycats get going they get going
[15:53:04] <cehteh> julius: you can just measure with a DMM if the laptop has PE connected to gnd or not, some have (esp ones with metal casings) some dont
[15:53:25] <cehteh> often they dont have
[15:54:19] <cehteh> otherwise getting some full isolation is a bit more expensive, some time o looked into that but parts where hard to source esp for bidirectional busses
[15:54:20] <julius> the power adater has a gnd pin on the connector, but after that its 19,1v or something
[15:54:49] <julius> dont know how ground works when the power supply switchted the voltage to dc
[15:55:07] <Lambda_Aurigae> ground is a common reference point.
[15:55:08] <Lambda_Aurigae> nothing more.
[15:55:48] <cehteh> just measure the voltage between something which should be GND on the laptop and PE (on another socket, water tap, radiator)
[15:55:52] <julius> since the circuit works when the programmer is connected, the laptop does provide ground and "meets" the circuit power supply there
[15:56:19] <cehteh> if that is very close to 0V then you can measure the resistance between .. should be close to 0 ohms as well
[15:56:25] <julius> cehteh, its plastik case...where do you look for ground?
[15:56:29] <cehteh> if thats true then its really grounded
[15:56:53] <julius> ah never mind
[15:56:55] <cehteh> ethernet shield, vga connector shield or such places
[15:57:06] <julius> just wondering why the GND from the serial converter does not work as expected
[15:57:07] <Lambda_Aurigae> laptop ground should be available on the outside of the barrel connector for the power supply, or any of a number of other interfaces on the device.
[15:57:25] <cehteh> julius: btw where do you live?
[15:57:41] <julius> niedersachensen, near hannover
[15:57:52] <cehteh> when i tried to order some iso chips i canceled that idea because it got too expensve for a few only
[15:57:57] <Lambda_Aurigae> I feel sorry for kids who live there...
[15:58:10] <cehteh> (4 iso1500 for 50eur ... wtf)
[15:58:11] <Lambda_Aurigae> trying to learn to spell that, much less pronounce it.
[15:58:18] <julius> most electronics companys in china do send without postage
[15:58:46] <julius> hannover is not hard to pronounce
[15:58:57] <julius> cehteh, try aliexpress
[15:58:58] <Lambda_Aurigae> niedersachensen would be.
[15:59:05] <julius> oh yes, lower saxony
[15:59:06] <cehteh> nidersachsen .. would be correct :D
[15:59:21] <cehteh> julius: didnt found it there
[15:59:42] <julius> well, its a different language here...niedersachsen in american english is probably a killer
[15:59:53] <Lambda_Aurigae> yeah.
[15:59:58] <julius> ok, then youre out of luck
[16:00:07] <cehteh> http://www.ti.com/product/ISO1540
[16:00:31] <cehteh> julius: btw i originate from Lüneburg .. lower saxony too
[16:00:40] <cehteh> but in karlsruhe now
[16:00:45] <julius> http://www.aliexpress.com/item/Di-ISO1540DR-ISO1540-SOP8-New-original/32545637201.html
[16:00:56] <cehteh> ah nice
[16:01:03] <julius> my parents life 30km near lüneburg
[16:01:05] <cehteh> well this bugs are expensive
[16:01:35] <cehteh> but i like their specs
[16:01:44] <julius> iso1540 did show up some results, that was just one
[16:02:18] <cehteh> its some time ago i searched for them and maybe i left aliexpres out
[16:02:47] <cehteh> irc they have some USB isolators in that series to
[16:02:47] <julius> just remember, deliver time will take 15-30 days
[16:02:52] <cehteh> i know
[16:02:57] <cehteh> ordered there before
[16:03:15] <julius> i will just use a old pc as isolator and program over a ssh connection
[16:03:21] <julius> and then later then wireless chips
[16:03:27] <cehteh> dont need them now but for you some of the iso15xx series or adum things may be interesting
[16:03:54] <julius> good idea
[16:04:12] <cehteh> http://www.analog.com/en/products/interface-isolation/isolation/standard-digital-isolators/adum1200.html
[16:04:15] <julius> but i will stay with a "tested" solution, got other things on my plate than worrying about a laptop
[16:04:20] <cehteh> ISO are capacitative coupled
[16:04:31] <cehteh> ADUM are micro inductive couplers
[16:04:46] <cehteh> they are quite common for such things
[16:04:53] <julius> see, i got no clue what youre talking about
[16:05:02] <cehteh> only problem is that they are always aroiund 4Eur a piece
[16:05:13] <Lambda_Aurigae> different technologies for coupling and isolating.
[16:05:33] <cehteh> means basically different patent trolls :)
[16:05:35] <julius> Lambda_Aurigae, our "naming" might not be the best part, but we got a great motorway system
[16:05:46] <julius> ah i see
[16:05:49] <Lambda_Aurigae> julius, yeah...I never got to drive out there.
[16:05:59] <Lambda_Aurigae> I never got off the military base while in Germany.
[16:06:20] <julius> you probably had nicer toys to play with
[16:06:48] <Lambda_Aurigae> yeah.
[16:06:58] <Lambda_Aurigae> I worked with bleeding edge monitoring technologies back then.
[16:07:15] <Lambda_Aurigae> doing worldwide nuclear weapons test monitoring.
[16:07:34] <julius> uh
[16:07:43] <cehteh> luckily the job was boring :D
[16:07:45] <Lambda_Aurigae> was at Ramstein for 2 days to pick up some gear to take to Ankara.
[16:08:09] <Lambda_Aurigae> cehteh, actually, I was on duty and saw 2 tests from 2 different countries that weren't scheduled...
[16:08:24] <Lambda_Aurigae> so, years of boredom separated by minutes of pure terror....
[16:08:29] <julius> i read that before they tested the first hydrogen bomb they didnt know if the reaction would stop or burn the atmosphere of the planet...so they tested it
[16:08:54] <cehteh> Lambda_Aurigae: yes .. but imagine you had 2 tests a day :D
[16:09:12] <Lambda_Aurigae> julius, yup...several theories said it would stop, a couple said it would just burn the entire atmosphere off, and one said it would trigger a worldwide nuclear reaction and burn up the entire planet to the core.
[16:09:44] <Lambda_Aurigae> cehteh, yeah....10 years before I got into it they had several a year for a while.
[16:09:47] <cehteh> that would have solved a lot problem .. no worried anymore
[16:10:02] <cehteh> see LHC :)
[16:11:28] <Lambda_Aurigae> the russian's big H-bomb was considerably larger than it should have been too.
[16:12:26] <Lambda_Aurigae> but not as big as it could have been.
[16:30:55] <julius> Lambda_Aurigae, and they still tested it
[16:31:35] <Lambda_Aurigae> had they not added the lead isolation segments on stage 2 and 3 then it would likely have been over 100MT
[16:32:38] <Lambda_Aurigae> segments/stages
[16:33:46] <Lambda_Aurigae> scary pieces of tech are fission/fusion bombs.
[16:54:16] <cehteh> the small nuclear bombs are imo much more scary
[16:54:59] <cehteh> there are ppl discussing about "why dont we build them small enough to be really used now"
[16:55:47] <Lambda_Aurigae> but,,,,we do.
[16:55:58] <cehteh> thats scary
[16:56:30] <cehteh> i mean a 100MT bomb is a nice show off .. but there isnt pretty much use of it in actual conflicts
[16:57:10] <Lambda_Aurigae> first nuke used in war was only 15Kt
[16:57:14] <cehteh> while i am pretty sure some shitheads wont hesitate to throw a few kt range bombs on terrorists somewhere if they could
[16:57:45] <cehteh> these tactical small atillery ones or bunker busters
[16:57:50] <Lambda_Aurigae> we can now make 15Kt bombs man portable.
[16:57:57] <cehteh> yeah i know
[16:58:09] <cehteh> and that scares me more than a 100MT bomb
[16:59:07] <Lambda_Aurigae> there are things that scare me far worse than any bomb.
[16:59:23] <cehteh> its the people
[16:59:28] <Lambda_Aurigae> yup.
[16:59:43] <Lambda_Aurigae> and weapons available that are much rose than any bomb.
[16:59:52] <Lambda_Aurigae> much worse
[17:01:04] <cehteh> so .. new pulseview installation .. they made a major release, nice
[17:01:16] <Lambda_Aurigae> no clue what pulseview is.
[17:01:37] <cehteh> free software for saleae logic analyzers
[17:01:44] <cehteh> (and clones)
[17:02:04] <cehteh> http://public.pipapo.org/logic_analyzer.png screenshot from the old version
[18:11:12] <coded1> I'm using avrdude to try to connect to my 328p. If I run the IC at default clock, 1MHz what would be the appropriate baud rate to send to avrdude?
[18:12:35] <Lambda_Aurigae> 1/4 of the clock rate orless.
[18:13:27] <coded1> so about 250,000 baud?
[18:13:57] <coded1> if I just want to see if it's alive can I go much lower? Lets say 10,000 ?
[18:15:24] <cehteh> yes
[18:15:36] <coded1> ty
[18:15:52] <cehteh> (but not too slow, timeouts, counter overflows may happen at extreme slow speeds)
[18:23:33] <coded1> I'm trying to troubleshoot, I put a LED on the SPI SCLK line and it pulses when I fire up avrdude, the reset line is connected to GPIO 22 (which is also declared in avrdude.conf) and is tied to ground via 10K ohm resistor. Using my multimeter I can't detect any change in voltage on the reset / GPIO 22.
[18:24:07] <coded1> the command line is:
[18:24:33] <coded1> avrdude -p m328p -P /dev/spidev0.0 -c linuxspi -b 10000
[18:24:55] <coded1> each time I get "error: AVR devcie not responding"
[18:26:21] <cehteh> whats that? bootloader over spi?
[18:28:04] <Lambda_Aurigae> cehteh, rPI and linux gpio bitbanged spi most likely.
[18:30:25] <Lambda_Aurigae> coded1, guessing the mega328 is virgin, internal oscillator at 1MHz?
[18:31:09] <Lambda_Aurigae> how is the chip powered?
[18:33:16] <Tom_itx> thermocouple
[18:35:34] <coded1> from the raspberry pi's 3.3v
[18:35:41] <Lambda_Aurigae> at least it isn't hamster wheel generator..those tend to be a bit unstable.
[18:36:22] <coded1> depends on what you feed the hamster :)
[18:36:39] <coded1> gatorade and red bull gives me the best results
[18:36:51] <Lambda_Aurigae> burns them out pretty quick.
[18:37:05] <coded1> that's where the gatorade comes in, rookie
[18:37:06] <coded1> lol
[18:38:04] <coded1> the SPI0_SLCK seems to be giving a steady 3.3v even when not programming is that ok?
[18:38:06] <nuxil> coded1, im using the 5v pin to power my tiny. but the gpio pins are 3.3 V . cant you hook you mega up the same way as the tiny or does it use another way.
[18:38:45] <Lambda_Aurigae> nuxil, careful with that...gpio pins are not 5V tolerant.
[18:39:18] <coded1> ^^^ that
[18:40:43] <nuxil> :\
[18:41:22] <coded1> I can turn the reset line on and off though the command line but avrdude doesn't seem to toggle it, or maybe it is but it's so quick I'm missing it
[18:42:27] <nuxil> no wait.. had to double check my board. power to the tiny comes from gpio 17. its 3.3v :p
[18:42:30] <nuxil> lol
[18:43:41] <nuxil> wirering,, http://cdn.instructables.com/FX1/LMLD/HQA04EOP/FX1LMLDHQA04EOP.MEDIUM.jpg
[18:44:19] <nuxil> works fine :)
[18:47:44] <nuxil> that reminds me. only 44 more wires to solder onto my 48bit shift register board :\
[18:47:50] <nuxil> yay
[18:48:29] <coded1> good times, good times
[18:48:50] <coded1> my reset line is getting a solid 0.5V
[18:48:59] <coded1> is it supposed to toggle?
[18:49:56] <nuxil> umm. not by itself. but yea during writing it sets it low or high. dont recal
[18:50:28] <Lambda_Aurigae> to go into program mode you have to pull it low.
[18:50:43] <Lambda_Aurigae> normally it should be pulled high by a pullup resistor.
[18:50:44] <nuxil> coded1, did you take a look at that example.. the make file. it does some gpio suff
[18:50:58] <coded1> what voltage would be condiered low?
[18:51:05] <coded1> considered
[18:51:28] <Lambda_Aurigae> 0V
[18:51:51] <Lambda_Aurigae> guessing we haven't read the programming section of the datasheet.
[18:51:57] <nuxil> Lambda_Aurigae, take a look at that pic. if i make a buffer between the RPII and the tiny. and use 12V. do i get a hvxp thingy?
[18:52:30] <Lambda_Aurigae> nuxil, read the datasheet, section on programming,,specifically section on HVSP/HVPP
[18:52:50] <Lambda_Aurigae> and I'm out to make more sawdust.
[18:52:51] <coded1> Lambda_Aurigae: you're right, time to read
[18:54:27] <nuxil> Lambda_Aurigae, im reading it. using search for thouse keyword give 0.. trying to scan up/down but cant fint any info about that
[18:57:49] <Lambda_Aurigae> find the section on memory programming
[18:57:52] <Lambda_Aurigae> it's in there.
[18:58:19] <Lambda_Aurigae> what chip are you using?
[18:58:35] <nuxil> duh.. ofc. thanks. page 159 :D..
[18:58:39] <nuxil> tiny85
[18:59:54] <Lambda_Aurigae> I have page 155 on datasheet just downloaded...for high-voltage serial programming
[18:59:56] <nuxil> Lambda_Aurigae, hmmm. +11.5 - 12.5V
[19:00:06] <Lambda_Aurigae> yeah
[19:00:08] <Lambda_Aurigae> 12V
[19:00:36] <Lambda_Aurigae> not sure if the programming algorithm is the same as for standard ISP though...
[19:00:49] <Lambda_Aurigae> I would have to read it...
[19:01:40] <nuxil> SDI, SII, SDO, SCI does have spesifyed any voltage. VCC +4.5 - 5.5V
[19:01:53] <Lambda_Aurigae> normal programming voltages.
[19:01:59] <nuxil> ok :)
[19:02:41] <coded1> seaching for "programming" brings up Memory Programming but nothing about the ISP protocol used
[19:03:06] <Lambda_Aurigae> section 20
[19:03:14] <Lambda_Aurigae> has the protocols laid out in detail.
[19:03:38] <Lambda_Aurigae> section 20.5.1 is the protocol for ISP
[19:03:57] <Lambda_Aurigae> section 20.7 has the HVSP protocol
[19:04:53] <coded1> USART Initialization?
[19:05:20] <Lambda_Aurigae> you are looking at a different datasheet.
[19:05:33] <Lambda_Aurigae> I'm looking at the latest attiny85 datasheet
[19:06:00] <nuxil> what ?
[19:06:11] <coded1> ATmega48A/PA/88A/PA/168A/PA/328/P Complete
[19:06:12] <coded1> (file size: 32.1MB, 660 pages, revision J, updated: 11/2015)
[19:06:12] <Lambda_Aurigae> was talking to coded1
[19:06:20] <nuxil> hes not uing a tiny
[19:06:28] <Lambda_Aurigae> yeah..
[19:06:30] <coded1> does that look right?
[19:07:49] <Lambda_Aurigae> for the atmega328, the memory programming is section 28
[19:09:04] <coded1> Lambda_Aurigae: thank you again good sir
[19:09:52] <Lambda_Aurigae> don't call me sir....I work for a living.
[19:10:06] <Lambda_Aurigae> sir is for politicians and drill instructors.
[19:10:09] <coded1> lol, you got it
[19:10:14] <coded1> thanks
[19:10:35] <Lambda_Aurigae> welcome
[19:11:43] <nuxil> hehe