Back
[00:24:11] <Deskwizard> 0/ Casper
[00:24:16] <Deskwizard> so 16x any better ? ;)
[00:24:37] <Casper> dunnot yet
[00:24:46] <Casper> but had to shuffle the cards around
[00:25:00] <Casper> and since I had to remove 3 out of 4, I removed all, and removed the psu to check the caps
[00:25:03] <Casper> surprise...
[00:25:08] <Casper> the powersupply...
[00:25:35] <Casper> is a better brand than what I remembered!
[00:25:47] <Deskwizard> nice surprise ! :)
[00:26:00] <Casper> tought it was an OCZ, it is, but the pc power and cooling branded one
[00:26:09] <Casper> instead of using chinese caps, it use nichicon :D
[00:26:10] <Deskwizard> oh nice !
[00:26:40] <Deskwizard> I had an ocz that started to show sign of weakness after a couple years, recapped, still going strong today :)
[00:29:14] <Casper> they are well made, but the caps are crap
[00:30:15] <Casper> https://www.asus.com/media/global/products/QPhR6dGjcvkYnazE/OTcCpwMgZC1hPFaW_500.jpg <=== where would you connect the video card double width, pci sound card, pcie 2x sata card, pcie 1x usb3 card ? we'll see if you do the proper choice :D
[00:31:33] <Deskwizard> careful, i might have the same board :P~
[00:31:49] <Deskwizard> 'cause, I RTFM.. ;)
[00:32:31] <Deskwizard> oh okay yeah I see hehe
[00:32:55] <Deskwizard> thats a lot of 16x
[00:33:48] <Casper> and you clearly didn't RTFM ! :D
[00:34:13] <Deskwizard> physical 16x doesnt mean x16 lanes ;)
[00:34:29] <Casper> 1 x PCI Express 2.0 x16 slot at max. x16 link (blue) 1 x PCI Express 2.0 x16 slot at max. x8 link (white) 2 x PCI Express x16 slot at max. x4 link (black) 1 x PCIe x1 2 x PCI
[00:34:55] <Casper> so, your cards connections would be what? :D
[00:36:09] <Deskwizard> depends on the interrupt table for the lower x4 and the x8 :P~
[00:36:30] <Deskwizard> id probably do sata black usb white
[00:36:46] <Deskwizard> since usb wire is likely going to go up
[00:37:38] <Casper> white 16X?
[00:37:52] <Casper> well 8x..
[00:38:08] <Deskwizard> yeah, not the PCI ones :P~
[00:38:38] <Deskwizard> and for the sound card id check the interrupt table if one isnt use id take that slot, if they both are, either, its a fkin sound card... lol
[00:39:04] <Casper> and you just made the video card link to 8x
[00:39:52] <Deskwizard> its the fkin white isnt it
[00:40:01] <Deskwizard> it always the effing white, if you enable it drops both
[00:40:08] <Deskwizard> *rool eyes*
[00:40:14] <Deskwizard> I should have remembered that
[00:40:47] <Deskwizard> my old biostar's like that too
[00:41:44] <Casper> yup, for this situation, white 8x need to be empty, usb go to the 1x and possibly lose speed (since it's version 1, who care, it's for the sd card reader that was supposed to be usb3, but is really usb2)
[00:42:30] <Deskwizard> so... which one you're not gonna use ? :P
[00:42:43] <Deskwizard> ah 1x at the top i missed that
[00:42:50] <Deskwizard> *facepalm*
[00:43:10] <Deskwizard> too late to change my answer is it... lol :P~
[00:46:14] <Deskwizard> now... I can I make this damn usart cock itself instead of chasing tail... lol
[00:46:53] <Casper> I need a new computer...
[00:46:56] <Casper> ... too expensive...
[00:47:03] <Casper> specially with the $CAD value...
[00:47:14] <Deskwizard> Casper: yeah... same country here ...
[00:48:00] <Deskwizard> Casper: what fsb you running on that board?
[00:48:09] <Casper> dunnot :D
[00:48:24] <Deskwizard> check cause if < 1333, free overclock maybe
[00:48:27] <Deskwizard> what cpu ?
[00:48:30] <Casper> whatever goes with model name : Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz
[00:48:46] <Deskwizard> i think that one is 1333 let me check
[00:49:03] <Casper> and don'T want to overclock
[00:49:06] <Casper> ain't worth it
[00:49:28] <Deskwizard> had a Q6600, went from 2.4 to 3.0, bit of electrical tape under it
[00:49:33] <Deskwizard> I swear to god hehe
[00:50:07] <Deskwizard> Casper: thought might help while rate is so low ;)
[00:50:16] <Casper> the q6600 is a slow cpu
[00:50:46] <Deskwizard> same as yours less a bit of cache once overclocked
[00:50:54] <Deskwizard> but yeah, slow cpu nowadays
[00:51:02] <nuxil> want slow cpu's go amd :p
[00:51:32] <nuxil> morning btw
[00:51:46] <Casper> nuxil: depend on which amd
[00:51:52] <Deskwizard> ^^
[00:51:56] <Casper> the A10 really surprised me
[00:52:24] <Casper> of course, it won't beat an intel one, but with their radeon onchip, it sure beat the hell out of intel for budjet pc
[00:53:19] <Deskwizard> I would argue, but I looked around, and only AMD left so.. ill shut up hehehe
[00:53:30] <Deskwizard> but yeah, surprising those A10
[00:53:47] <Deskwizard> for those who remember... Cyrix MediaGX
[00:54:00] <nuxil> Casper, the thing about amd, they are really not true multicore cpu- esp the fx series. since only one core can use the cache at the time.
[00:54:17] <nuxil> leaving the other cores to do nothing
[00:54:30] <Casper> nuxil: take a look at the A10
[00:55:14] <Deskwizard> old man's an A8 iirc and honestly can't complain...
[00:55:35] <Deskwizard> thats where I declare I wish I knew about the FX cache thing before I bought this one...
[00:55:41] <nuxil> http://legalnewsline.com/stories/510646458-amd-faces-suit-over-alleged-misrepresentation-of-new-cpu
[00:55:58] <Deskwizard> it'll just piss me off... lol
[00:56:19] <nuxil> hehe
[00:57:05] <Deskwizard> but then again, it was that, or stuck with a low power amd64 dual core, so I can't complain much
[00:57:17] <Deskwizard> I was cold earlier, started compiling a kernel solved that lol
[00:58:02] <Deskwizard> my I7-4770 was a fkin beast though
[00:58:15] <Casper> better framerate with 16x
[00:58:30] <Deskwizard> Casper: cool :)
[01:02:00] <Casper> I wonder if there is a difference in wined game
[01:03:27] <nuxil> wine ? its a nightmare last time i tried it.. been some years now tho.
[01:04:38] <Casper> still a nightmare
[01:04:42] <nuxil> maybe steam has put in to $ to get the project more uptodate, im guessing steamOs is dependant on Wine so who knows.
[01:04:54] <nuxil> *put in some
[01:05:09] <Casper> steamos is linux
[01:05:12] <Casper> no wine
[01:05:25] <Casper> there is lots of linux native games now
[01:05:36] <nuxil> Casper, yea i know. but it uses wine to play win games
[01:06:12] <Casper> there is no win game on steamos afaik
[01:10:00] <nuxil> well. there are many topics on this. you need wine,. and you can install your win games on it. using pol which is a easy way of setting up wine iirc.
[01:11:20] <nuxil> but linux sucks. so its a waste of time if you ask me :p
[01:11:23] * nuxil hides
[01:13:51] * Casper uses a tig torch on nuxil
[01:13:52] <nuxil> what i mean is. there is only shity aps on linux. altho the linux core is a masterpize. but when it comes to missing desktop apps. like photoshit. autodesk etc all thouse app people will not see any reason to use it.
[01:14:58] <nuxil> doesnt matter if you have a superior core.. if no good apps to run on it. no one want to use it. simple as that
[01:15:16] <nuxil> exept the nerds and geeks :D
[01:16:44] <nuxil> my 1st try with linux was redhat 5.2 think it was back in 96/97 or something.
[01:17:06] <Casper> mine was with 7.3
[01:17:30] <Casper> and redhat seemed to hate french canadian keyboard and fucked it at every single version
[01:19:56] <nuxil> its not qwerty ?
[01:22:20] <Casper> yes
[01:22:23] <Casper> but have accents
[01:22:35] <Casper> and they broke them every single time
[01:22:45] <Casper> I had to fill a bug report each time
[01:23:10] <nuxil> annoying
[01:30:51] <Casper> yeah
[01:31:58] <Deskwizard> Casper: yeah they really hated us
[01:32:47] * Casper wants 2 new computers
[01:33:03] <Casper> one a i7-something
[01:33:21] <Casper> the other an used xeon with ecc memory, atx form factor would be nice
[01:33:46] <Casper> that however is not for now..
[01:33:58] <Casper> first, I want a new toy for my camera
[01:34:14] <Casper> http://www.adencamera.com/product-overviewer.asp?ProdID=3002&Category=7 <=== that toy
[01:34:21] <Deskwizard> yeah I second the old xeon with ECC, if you find a source, let me know :)
[01:35:09] <Casper> I do have one: our supplier :D
[01:35:21] <Casper> but don'T think they have atx
[01:36:14] <Deskwizard> Casper: you sure that board you showed earlier doesnt do xeon ?
[01:36:21] <Deskwizard> ah it probably doesnt do ecc though
[01:36:59] <Casper> my nas currently run an old board with a q6600
[01:37:07] <Casper> I'ld like to upgrade it to ecc memory
[01:37:30] <Casper> a xeon quad core 3GHz with 8G ram would be quite nice
[01:37:47] <Deskwizard> for sure
[01:38:04] <Deskwizard> a dual with 4gb would probably enough for me, more is just icing on the cake hehe
[01:39:13] <Casper> but look on ebay
[01:39:17] <Casper> some are dirt cheap
[01:39:44] <Deskwizard> Casper: you know how it is up here, border takes is cut, shipping takes the rest, something free jsut cost you 200$ since its heavy
[01:40:59] <Casper> I did a quick search a few days ago
[01:40:59] <Deskwizard> ideally id need a tiny board that runs linux, and has a 8x pci-e for the raid card
[01:41:14] <Casper> 150-200 for a board, cpu and memory
[01:41:25] <Deskwizard> Casper: not so bad
[01:41:59] <Casper> yeah
[01:42:02] <Deskwizard> btw if you dont already, look at the federal goverment auctions, theres lots of crap but I scored some nice things for not too much on there
[01:42:16] <Casper> but for now, I'm broke
[01:42:22] <Deskwizard> yeah same here
[01:42:27] <Casper> I just forgot the car insurance that was due this month
[01:42:41] <Casper> so... forgot a tiny detail
[01:42:47] <Deskwizard> ah that blows
[01:43:01] <Casper> yup
[01:43:12] <Casper> next week I'll finish to pay it back
[01:47:00] <Casper> now.... things to think about:
[01:47:07] <Casper> - is hotdog a sanwitch?
[01:47:18] <Casper> - is cereals a soup?
[01:47:37] <Casper> and
[01:47:42] <Casper> is pizza a pie?
[01:55:48] <Jartza> no, pizza is flatbread :)
[01:56:22] <Jartza> and hotdog is a sausage
[01:56:33] <Jartza> it's just served inside bread
[01:58:28] <Casper> nite
[02:05:23] <Deskwizard> Casper: been looking at xeon stuff on ebay 'cause of you, it wouldnt cost me as much as I thought considering my modest requirements :) ty
[02:05:30] <Deskwizard> now... lets find money lol
[02:08:21] <N1njaneer> Casper: Nice lens!
[02:09:38] <N1njaneer> I need to grab a couple more fast Cine-Primes when budget allows.
[02:22:19] <WormFood> I got this battery yesterday, that is labeled as being an 18650, but it's slightly longer than normal, and doesn't properly fit anything I have that uses the 18650. Anyone know what's up with that? I'm thinking possibly different standards, or more likely someone mislabeling a different battery, to clear out stock.
[03:00:22] <nuxil> https://en.wikipedia.org/wiki/List_of_battery_sizes
[03:01:24] <nuxil> an 18650 is around 65 mm (2.6 in) long, but may be around 68 mm (2.7 in) long with an internal protection circuit
[03:02:56] <nuxil> WormFood, is that your case? it got an internal protection ?
[03:04:42] <theBear> mmm, often a "single standalone" modern battery/cell will come with a hidden "smart" pcb on one edge/end disguised as extra battery volume, vs ones you may have seen/found in multi-cell and/or poorly designed/regulated packs or things where a single (or worst case none at all) smart/protection pcb/circuit is covering the whole "battery" rather than one per cell
[03:05:38] <nuxil> WormFood, just put it in your vise and twist some until it fits :p
[03:05:40] <nuxil> jk
[03:09:29] <WormFood> Thanks guys. This one does appear to have a PCB at one end, so that would explain the difference.
[03:12:56] <WormFood> Yep, that is in fact the case. A little PCB on the bottom.
[03:14:46] <theBear> woohoo ! sidenote: often once you found tat little pcb, there are exposed some unbelievably precarious or risky or just plain hard to see/spot things, like perhaps a thin sheet of "paper" between two foil/sheety-metal sections which if shorted (across the TINY visible clearance/gap,) will be err, "very bad" from a battery working in the future/safety kinda pov
[03:16:08] <theBear> also if you decide for whatever reason to remove the pcb, be careful to leave some "real" metal on the battery side of where you cut things, cos often the exposed tabs/conductors coming outta the cell/bag itself are stupid stuff that won't solder and needs spot welding or will work horribly unreliably if you can somehow manage to at least clamp them between some conductors
[03:17:13] <WormFood> I've already removed the PCB, and the tabs are spot welded.
[03:20:46] <theBear> mmm, in which case (this is more reminding myself so the "nightmare" doesn't repeat EVER) you wanna be very careful not to stress those tabs 'cos if you do eventually one or more will "pop off" and you'll be stuck looking at where they used to be spot welded <grin>
[03:30:32] <WormFood> huh? The tabs I want to remove, so I can use this battery in a normal device.
[03:31:30] <Jartza> yay
[03:31:31] <Jartza> https://www.youtube.com/watch?v=qucJMObCUpI
[03:37:31] <theBear> WormFood, seriously AND you ain't getting what i trying to say ? oh, or perhaps you mean like a "traditional" battery, for example an AA or D, in a "battery holder" involving springs and pressure connections of somekind ... that would mean neither of us is mental :)
[03:39:31] <WormFood> Obviously I don't get what you're trying to say. This is designed just like a regular AA or AAA battery. The tabs spot welded onto each end, go to the PCB. Once I remove that pcb, I have no need for their tabs
[04:35:26] <nuxil> no more lsd for you Jartza :p
[04:35:39] <nuxil> what improvements did you make now ?
[04:44:32] <theBear> the male-female equality gap in western society, i improved the hell outta that thisafternoon, pretty chuffed
[04:44:42] <theBear> heh nah, i didn't change the world or society as we know it, not even a little bit
[04:44:47] <theBear> well, not today
[05:06:08] <Jartza> nuxil: well, there's 32 steps in the horizontal offset, so the sine wave looks better. also 64 "pixels" per row
[05:08:24] <Jartza> still ~200 bytes flash left, so next it's time to figure out some nicer effects
[05:15:51] * theBear wonders if that wavyness was intentionally and painstakingly coded in, or was a surprisingly "pretty" side-effect of some minor timing issue or typo in a formula somewhere :)
[05:17:24] <theBear> ooh, howbout grabbing a chunk of 200bytes of some rant by theBear@irc.freenode.net and just hiding it in there, so you can wonder many years later, if some poor fool ever stumbled across the hidden anti-wisdom you stashed there
[05:17:50] <theBear> that's the kinda trick that "keeps you young" after retirement, least, that's what i would guess
[05:30:10] <Jartza> theBear: well, the wavyness is called sine wave, and yes, it's intentional :)
[05:31:02] <Jartza> theBear:
https://drive.google.com/file/d/0B2dTzW9TMeBxWXNmQzZYSUhycEU/view
[05:31:21] <Jartza> the sot23-6 is the MCU generating that (on that red breakout)
[05:32:07] <Jartza> plus ~300 bytes of firmware
[05:32:56] <nuxil> 200 bytes should be enuf for a pong game :p
[05:33:15] <theBear> you might call it that, but in this household, this last few years, we call it long-unshielded-twisted-pair on very poor handrolled baluns running past ALL sorts of active mains lines, and more than a small possibility of aggravation via horrible and extreme groundloop caused by using another pair with nothing added for the power feed to that camera err, all that -makes-the-picture-a-bit-wavy-when-it-not-very-wavey ... hmm, that looks a bit long, but
[05:33:15] <theBear> whatever we call it, amounts to the same meaning :)
[05:33:48] <theBear> wtf, you can get micros in sot now ? what will they think of next ? sliced butter ? warm toast cutting thru knives ?
[05:34:56] <Jartza> yeah, that's called attiny5
[05:35:04] <Jartza> and only because nobody seems to stock attiny4
[05:35:18] <Jartza> the only difference between those two is that attiny5 has adc while attiny4 does not
[05:36:09] <theBear> heh, i should use my attiny something i forgot dip8's soon while they're still i dunno, less than 1000x the volume of their current equivalent/replacement model <grin>
[05:36:42] <Jartza> well yea. this was just for the kicks
[05:36:47] <theBear> heh, 3 or 4 exposed pins, they coulda lied about the adc and noone would ever have foundout cos there no pins to use for ti anyhow :)
[05:37:01] <Jartza> to see what I can get out from 6 pin, 32 bytes of SRAM and 512 bytes of flash
[05:37:12] <theBear> isn't kicks the only valid reason for programming micros or any kinda from-scratch electronics in the home ?
[05:37:20] <Jartza> and yea, that vga is driven out from 3 pins :)
[05:37:36] <Jartza> I disabled reset to gain 4th pin, but I use one pin for external oscillator
[05:38:03] <Jartza> theBear: well, I sometimes also do stuff because I need something :)
[05:38:14] <Jartza> and for learning
[05:38:37] <Jartza> this idea of attiny5 vga was born because I made this:
https://github.com/Jartza/octapentaveega
[05:38:45] <Jartza> and thought that attiny85 wasn't challenge enough
[05:38:55] <Jartza> nor 512 characters on screen out from 512 bytes of sram
[05:39:58] <theBear> hmmm, you mean like you "need some kicks to make the afternoon fly by" ?
[05:40:02] * theBear smiles
[05:41:11] <theBear> jeez, talk like that, you gonna be a contender for an alltime game-changing something like igor or abcmini are at least partly famous for (they both got more than one-note for their umm, pony show?)
[05:49:32] <Jartza> heh
[05:50:32] <Jartza> I just like small microcontrollers
[05:50:55] <Jartza> I get to fiddle enough with bigger ones at work
[05:52:22] <Jartza> but OctaPentaVeega I actually even use for stuff
[05:52:34] <Jartza> I'm going to install one in my car soon
[05:52:55] <Jartza> together with 7" monitor
[05:53:49] <Jartza> though monitor being chinese cheap'n'crappy it sucks a bit in showing 640*480 resolution, it only displays 31*16 characters :D
[05:57:31] <Jartza> the sine in that video is slow for purpose.
https://www.youtube.com/watch?v=87oO8uFKMBc
[05:57:42] <Jartza> because that fast sine looks crap when filmed with cell phone :)
[06:05:07] <theBear> and the analog video capture on my "server" is slow cos of age, therefore it's hard to be sure how fast the wiggles are wiggling most of the time <grin>
[06:29:53] <nuxil> Jartza, what do you plan on doing with it in your car ?
[06:30:39] <Jartza> it shows RPM and speed and temperatures and it can also be used as diagnostics display
[06:30:43] <Jartza> for GM ALDL
[06:30:50] <Jartza> because my car is so old it doesn't have OBD :)
[06:30:58] <theBear> all that from a wiggle i thought was a typo or matho ? impressive
[06:31:28] <Jartza> theBear: no, that'll be the octapentaveega :)
[06:31:42] <nuxil> obd ?
[06:31:49] <Jartza> on-board diagnostics
[06:31:53] <nuxil> oh
[06:32:00] <Jartza> like, every car made after 1995 has OBD port
[06:32:15] <Jartza> and mine is from 1994 :D
[06:33:17] <nuxil> how do you plan on getting the rpm?
[06:33:26] <Jartza> from ALDL
[06:33:56] <Jartza> that's GM's own system before OBD
[06:33:57] <Jartza> Assembly Line Diagnostic Link
[06:35:10] <nuxil> or alcl assome call it
[06:35:23] <Jartza> http://www.ws6transam.org/ALDL.html
[06:35:28] * nuxil reads wiki
[06:36:27] <nuxil> you driving a transam?
[06:36:48] <Jartza> nope
[06:36:49] <Jartza> :D
[06:36:54] <Jartza> Opel Astra
[06:37:01] <Jartza> wroom wroom
[06:37:29] <nuxil> automatic? or autolat as we call them :p
[06:40:24] <nuxil> my friend had a vw golf 96/97, its tacometer or whatever its called. once it reaced 300.000 Km it started at zero again. kind of a odd number to reset on.
[06:45:14] <theBear> maybe he just reversed for about 300,050km's on a day you weren't around, to prank you like :)
[06:45:53] <nuxil> no. :p its common on golf
[06:49:45] <theBear> that's what i woulda told yer if i had just driven backwards a few thousand kms too <grin>
[06:50:06] <nuxil> lol
[07:20:17] <julius> does anyone got some experience with rfm12 modules? i looked at three libraries for those...but they all look as if they blew their brains out
[07:20:44] <julius> this one looks "sane"
https://github.com/das-labor/librfm12 but the example documentation is stupid
[07:26:08] <theBear> i always found when i make sane libs for mostly personal use, that i'm in no mood to write sane docs, or really anything beyond the bare minimum remind-me-syntax kinda notes that i will need in the future, so i vote for that one
[07:33:02] <julius> yeah, but they wanted to show off and present it to other people
[07:36:25] <julius> it just makes no sense to me that if you upload your code you would not give the "novice" user a bit more help
[07:36:44] <julius> and include some simple code that can just be run, before being modified
[08:04:01] <theBear> pfft, you gave them access to your code, isn't that enough <grin>
[08:41:09] <julius> yes
[08:56:21] <julius> what does this do: c=(PINC&24)/8; ?
[08:56:27] <julius> its code for a avr
[08:56:51] <julius> apparently it should result in 0,1,2,3
[08:57:00] <julius> 0 or 1 or 2 or 3
[08:57:06] <julius> but how?
[09:05:41] <grummund_> same as -
[09:05:48] <grummund_> c = (PINC & 0x18) >> 3;
[09:06:29] <grummund_> or
[09:06:31] <grummund_> c = (PINC >> 3) & 0x03;
[09:26:55] <nuxil> explain why :p
[09:28:27] <grummund_> 24 is 00011000 binary; /8 is shift by3;
[09:29:07] <nuxil> hmm.
[09:29:20] <nuxil> so div by 8 alwayss shift 3?
[09:29:38] <grummund_> for unsigned type yes
[09:29:48] <nuxil> thanks
[09:29:59] <nuxil> learnt something new today :)
[09:30:25] <grummund_> if you mean shift use >> 3
[09:30:35] <grummund_> if you mean divide use / 8
[09:31:06] <grummund_> compiler will generate the same instructions but the code is clear to read
[09:31:13] <nuxil> yea
[09:37:20] <julius> thanks
[09:58:19] <flyback> http://www.banggood.com/20A-DC-Digital-Multifunction-Power-Meter-Energy-Monitor-Module-Voltmeter-Ammeter-6_5V-100V-p-996111.html
[10:02:44] <flyback> http://crcindustries.com/ei/product_detail.aspx?id=05103&S=Y
[10:02:45] <flyback> good shit
[10:03:09] <flyback> espically for blowing yrs of crap off some connector before you plugup etc
[10:03:19] <flyback> I use it every day in the IT field but also messing with electronics
[11:14:37] <julius> is the interal 8mhz clock on a atmega168 precise enough for the uart? at 9600bauds?
[11:25:37] <nuxil> i hate the term bauds. i like bps better, altho they are not the same. but bps is much easyer to understand than baud. you need to know x,y.. to calculate bps from a baud value
[11:27:36] <WormFood> julius, the internal clock drifts with temp. It may not be precise enough for the UART
[11:27:36] <nuxil> its confusing since multiple bits may be transmitted for 1 baud
[11:27:48] <WormFood> baud != bit rate
[11:27:52] <WormFood> they're totally different.
[11:28:31] <WormFood> at 300 baud, it's 300 bps, but 1200 bps is like 600 baud I want to say
[11:29:15] <WormFood> anyways, it drives me crazy, that atmel uses "baud" in their datasheets on the AVR. The AVR doesn't know shit about anything retlated to baud
[11:31:44] <nuxil> "at 300 baud, it's 300 bps,..." not entierly true
[11:32:16] <WormFood> I'm talking about a typical modem. Bell 202 and bell 212 standards are 300 bps/baud
[11:32:28] <nuxil> it highly depends on how many symbols per bit
[11:32:40] <WormFood> I just clarified my statement
[11:32:51] <nuxil> :)
[11:33:04] <WormFood> nuxil, google for "avr baud", and you'll see my page on the subject.
[11:33:57] <nuxil> oj nice page :)
[11:41:37] <julius> ive read that you can test your usb to serial converter just by connecting RX to TX and connecting to the device with a terminal program
[11:41:40] <julius> is that true?
[11:42:54] <N1njaneer> Of course. Loopback.
[11:43:26] <julius> i tried screen to connect to "me", but im not really sure how to send data
[11:43:30] <N1njaneer> Of course it won't test the baud rate and other parameters effectively since it's going to be a match, but it will see characters looking.
[11:44:53] <julius> ah, got something
[11:48:33] <julius> on linux i did run: cat -v < /dev/ttyS0 in one terminal, and echo -ne '\033[2Jasdsadasa' > /dev/ttyS0 in another
[11:48:40] <julius> but i dont get any output
[11:49:09] <julius> i connected the white and the green cable from the serial connector. the voltmeter says that black -> red are +5v
[11:49:54] <vpcd> julius, try cu(1)
[11:51:50] <studdentt> j #c
[11:55:49] <julius> cu says line in use :)
[11:59:09] <vpcd> i don't use linux so I am not really aware of the conventions there, but are you sure /dev/ttyS0 is your device? it seems to me that that is your PCs serial port and not your usb-to-uart device
[12:00:01] <LeoNerd> ttyS0 is a real serial port. A USB-UART bridge is likely named ttyUSB0
[12:00:05] <vpcd> on *BSD systems the usb-to-uart devices will show up as /dev/cuaU*
[12:00:45] <julius> oh yes, i changed that
[12:00:53] <julius> might be just symlinks
[12:01:14] <julius> dmesg says its "/dev/ttyUSB0"
[12:01:35] <julius> look at that, the system actually has a serial port
[12:03:02] <vpcd> probably it is the one on the motherboard but it is not a standard DB-9 connector so you didn't recognize it
[12:03:17] <grummund_> what type/make of usb-serial is it?
[12:03:46] <vpcd> julius, so did you try cu -l /dev/ttyUSB0 ?
[12:17:45] <julius> ups, theres a shortcut for leavin the channel...
[12:17:52] <julius> yes i did try cu. says: cu: /dev/ttyUSB0: Line in use
[12:18:18] <julius> if i disconnect the adapter it says "permission denied /dev/..." AND then it says: line in use
[12:18:20] <julius> kinda funny
[12:21:46] <vpcd> I am trying to implement my own USART library by following the datasheet (ATmega328P). however, I am having problems with the code examples, tables, and formulas given there. basically it all seems off and I can't get my code to work properly. here is my code:
http://pastebin.com/q0EdSJ3C
[12:24:31] <vpcd> when i set UBRR to 6 as given in the datasheet table for 1MHz clock then I will get a 'v' character 70% of the time but there will be many wrong characters too. and if I use a macro UBRR_VAL that I wrote using the formula also provided by the datasheet then I won't get a 'v' at all. UBRR_VAL(9600) expands to 5 as opposed to 6 so this is obviously a problem but then is the formula wrong?
[12:25:09] <julius> vpcd, im just looking into uart
[12:25:33] <julius> i know you read that before, but you should use a external crystal for communication (if you do not do already)
[12:26:25] <julius> #define BAUD_PRESCALE (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)
[12:26:35] <julius> thats the one i found, but couldnt test it yet
[12:28:33] <julius> just opened up my pl2303 converter, the smd resistors are all out of place. looks like it was soldered by hand....hello fake
[12:28:50] <julius> they dont allign properly to each other
[12:32:44] <vpcd> julius, that's pretty much the formula I use and you are right I don't use an external crystal so that may cause the many errors I get, but, why does this formula (as given in the datasheet) expand to 6 and the table given in the datasheet for my setup says it should be 5?
[12:34:16] <julius> UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1)
[12:34:32] <julius> this is from my favorite german avr site mikrocontroller.net, its a "official" posting
[12:34:56] <julius> how does your UBBR_VAL() function look like?
[12:35:07] <vpcd> as for your problem, is your user in the dialer or uucp group? if not, try joining one or both of those or just switch to root
[12:35:16] <vpcd> i posted a link to code so check it out
[12:35:29] <julius> i tried root, otherwise permission denied
[12:35:31] <vpcd> i would trust the product datasheet far more than something on the internet
[12:35:39] <julius> true
[12:35:45] <julius> ah, wait
[12:36:41] <julius> //usart_init(UBRR_VAL(9600)); this is commented out, is that right?
[12:36:59] <julius> ah, its the second one
[12:37:35] <julius> #define UBRR_VAL(baud) (FOSC/(16*(baud))-1) i would bet that the "baud" written in small letters is a problem
[12:37:53] <vpcd> it's not, the code works, the calculation is wrong
[12:38:29] <julius> sure? try BAUD
[12:39:20] <vpcd> yes...
[12:40:43] <julius> ok, just checking
[12:43:58] <vpcd> you are getting confused here because I defined "baud" as a macro formal parameter and BAUD is a preprocessor symbol. note how UBRR_VAL macro with argument is used in main to clear up the confusion :)
[12:45:06] <vpcd> so when UBRR_VAL(9600) is expanded, the "baud" inside will expand to 9600. I admit it isn't the most clear but I have my reasons to define it that way :)
[12:45:19] <julius> ah ok
[12:45:27] <julius> so you uncommented the line in main?
[12:45:34] <julius> line 35
[12:46:38] <vpcd> when I use that line then I get gibberish on my PC, implying that the calculation of UBRR is wrong. when I use the next line, then I get 'v's as expected but with quite some erroneous characters
[12:47:41] <vpcd> the UBRR value 5 is taken from the table given in the datasheet, my UBRR_VAL(9600) macro expands to 6
[12:47:51] <vpcd> this is what confuses me
[12:49:19] <julius> look what shows up when you type in "avr ubbr"
http://wormfood.net/avrbaudcalc.php
[12:49:29] <julius> WormFood, is actually here :)
[12:49:53] <julius> vpcd, does the datasheet use the same values?
[12:50:14] <julius> UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) <- in this one theres F_CPU and BAUD for example
[12:50:28] <julius> brb
[12:54:22] <vpcd> yes, the datasheet matches with tables given on the site. and the value UBRR=6 gives me a decent result, although with some errors. what puzzles me is why the formula given in the datasheet does not produce those same values? i.e. it gives me UBRR=5
[13:20:56] <vpcd> the issue was with the integer division and rounding. here is the macro that works and produces the same values as given in the datasheet tables #define UBRR_VAL(bd) ((uint16_t) ((FOSC / ((bd) * 16.0)) + .5) - 1)
[13:24:37] <vpcd> and the errors I get at 9600 baud with 1MHz clock are expected. the datasheet says that in this configuration the error rate is 7.5% which is just about what I get.
[13:26:42] <Deskwizard> let me see which one I use, its Dean's, the others always ended up giving me bad UBBR in a way or another some time
[13:27:06] <Deskwizard> uint16_t USART_UBBR_VALUE = (uint16_t) ((((F_CPU / 16) + (baudrate / 2)) / (baudrate)) - 1);
[13:27:31] <Deskwizard> he explains the why of it in his tutorials
[13:28:37] <Deskwizard> also, hurray, my damn USART code seems to be working hehehe
[13:28:49] <Deskwizard> id even add, FINALLY!
[13:29:30] <vpcd> thanks for the tip, I will check out his tutorial, didn't know about him since I have just started playing with AVRs and micros in general :)
[13:29:48] <Deskwizard> vpcd: pretty much the same here, been fighting USART for a week...
[13:30:04] <Deskwizard> vpcd: let me find you the linky
[13:30:14] <vpcd> i googled it already
[13:30:43] <Deskwizard> oh okay hehe :)
[13:31:09] <Deskwizard> and if you want to add ring buffers, read that one :
http://www.downtowndougbrown.com/2013/01/microcontrollers-interrupt-safe-ring-buffers/
[13:31:31] <Deskwizard> if you're smarter than me, it takes a minute to add lol
[13:32:01] <Deskwizard> if I managed to do it, so will you lol
[13:33:51] <vpcd> I will need something like that pretty soon so thanks for that too!
[13:34:13] <Deskwizard> np man, it took me ages to find something I understood about all this
[13:34:20] <Deskwizard> as I said, I got it wotking like 5 minutes ago hehe
[13:34:29] <Deskwizard> *working
[13:34:42] <Deskwizard> now I do I2C then I scan the cat as a reward lmao
[13:34:57] <Deskwizard> 'cause I deserve one.
[13:35:33] <Deskwizard> and now that I (we) know how to do ring buffers, all comm is going to be easier :)
[13:36:44] <Deskwizard> vpcd: FYI if you miss one byte once at first send, check your buffer size, just a tip ;)
[13:36:47] <vpcd> well, I have just made my first step with USART, i.e. sending a character to my PC, now I have to receive one on the micro and then I'll proceed with some more advanced stuff :)
[13:37:16] <Deskwizard> vpcd: isn't it great when it works for the first time :)
[13:37:30] <Deskwizard> then you try to send to and it goes to hell and you do "damn..." lol
[13:37:36] <Deskwizard> s/to/two
[13:38:15] <Deskwizard> I had dual buffering yesterday ... everything was being sent twice at some point lmao
[13:39:00] <vpcd> well, it is all learning!
[13:40:03] <Deskwizard> yep :)
[13:40:30] <Deskwizard> im quite glad its working now, it was a step curve in my case, i was getting a bit desperate hehe
[13:41:20] <vpcd> I know the feeling! it's what you get for being, or at least trying to be, a programmer :)
[13:41:38] <vpcd> but once you solve the problem, now that's what I call feeling accomplished! :D
[13:41:44] <Deskwizard> lmao yeah :)
[13:42:11] <Deskwizard> oh and fui, theres an AVR app note on USART if you havent read already, with code example and all, i think its 306, 307 or 304 i dont recall
[13:44:11] <vpcd> i'll check that out sometime soon. now I am trying to implement my own library of USART by just reading the datasheet and not really looking too much at other's code. I am quite enjoying the experience so far but I also get stupid bugs like the one with UBRR calculation that drive me nuts :)
[13:44:56] <cehteh> if that is already the hard part :D
[13:45:38] <julius> vpcd, 7.5% seems high
[13:45:53] <cehteh> btw someone suggested here to make the baudrate a little higher, i added a TXBOOST option for that to my uart config code
[13:46:01] <cehteh> 0.5% more
[13:47:05] <vpcd> cehteh, that's effectively the same as adding a .5 to the result of the formula provided in the datasheet
[13:47:19] <cehteh> yeah
[13:47:36] <cehteh> well no maybe .. dunno what formula you talk about
[13:47:43] <cehteh> just works here :D
[13:47:48] <julius> vpcd, so was the formula you used from the datasheet?
[13:48:05] <vpcd> #define UBRR_VAL(bd) ((uint16_t) ((FOSC / ((bd) * 16.0)) + .5) - 1)
[13:48:06] <cehteh> i use the static baudrate evaluation macros from avr-libc
[13:48:36] <cehteh> and i aways feel a lit guilty when using floats there
[13:48:44] <vpcd> that's the formula, I just added the + .5 and made 16 a float so that the division result will not be converted to int
[13:49:30] <cehteh> is uint16_t enough? i cant remember how many bits the prescaler has it was something odd for sure
[13:49:31] <vpcd> + .5 ensures the cast will round the number to the upper value
[13:49:50] <cehteh> and not enough for running 50 baud at 16mhz clock :D
[13:49:54] <Deskwizard> vpcd: yeah it drove me crazy too, worked, changed F_CPU, stopped working, it was a head bangeg
[13:49:57] <vpcd> and using floats is a non issue because the calculation is done by the preprocessor
[13:50:42] <vpcd> cehteh, UBRR register is 12 bit
[13:50:51] <cehteh> http://paste.debian.net/377499/
[13:50:56] <cehteh> thats what i use
[13:51:09] <cehteh> no floats ftw
[13:51:14] <Deskwizard> I was gonna say 16, good thing I checked the datasheet lmao
[13:51:48] <cehteh> ah yes changing F_CPU and clock prescaler bitten me too
[13:51:48] <julius> ah, my usb serial adapter works. you have to disable hardware handshaking for the port first
[13:53:34] <cehteh> only left to do here is the secondary queue, just started the stuff. idea here is to have a TXQUEUE which is tagged and stores data in binary rather plaintext. that will save a lot memory
[13:54:02] <cehteh> progmem strings will be queued there as pointer for example .. floats and integers as well
[14:04:04] <Krampus> Fie an foo on the datasheet for this LCD controller (ili9341). If you need extra signals for SPI, you're doing it wrong.
[14:10:02] <Deskwizard> :| and i broke it, lol
[14:13:44] <m3chanical> like, let the magic smoke out broke?
[14:23:37] <sebus> Got a silly question - I need to make algorithm to veify if there's a bad RAM cell. Would be enough to fill whole memory with 0's, then cheching it if it's 0 and doing same with 0x55, 0xAA and 0xFF patterns?
[14:23:55] <sebus> or theres a better solution?
[14:26:33] <learath> sebus: look at memtest
[14:26:54] <Krampus> sebus: check out the documentation for memtest86+. Moving inversions will hit pretty much everything.
[14:27:17] <nuxil> above my knowledge but would it not be better to use 1's instead, ? to ensure its set,? im thinking is a cell is broken it might be 0, and when you write 0 to it it seems to be ok.. but idk
[14:27:38] <learath> nuxil: inversions check for stuck 1, stuck 0, and sticky
[14:27:44] <learath> sticky? that's totally technical
[14:27:51] <learath> :P
[14:28:12] <Krampus> nuxil: You'll want to check for stuck at 0, stuck at 1, induced flips, addressing whargarbl, and data retention over time.
[14:28:28] <nuxil> ic
[14:29:05] <Krampus> nuxil: It gets more fun if memory is not a simple array. :)
[14:29:14] <julius> make says: error: #error "setbaud.h requires F_CPU to be defined" F_CPU is defined in the Makefile..is that not enough?
[14:29:33] <nuxil> in tha .c file
[14:29:50] <LeoNerd> You need to pass i5 ont ye commandlune
[14:29:56] <Krampus> julius: depends on what the Makefile is doing with it. It has to pass it to the compiler as -DF_CPU=<hojillahertz>
[14:29:58] <LeoNerd> Man my typing sucka
[14:30:01] <julius> something like: #define F_CPU 8000000 ?
[14:30:20] <nuxil> ye in yor main c file
[14:30:50] <LeoNerd> I usually use the -D commandline argument for that
[14:31:22] <julius> nuxil, does not work...it acutally was in there, i just missed it
[14:31:24] <julius> ok
[14:31:25] <sebus> learath Krampus - so I was close.
[14:31:44] <nuxil> upss
[14:32:44] <nuxil> is it in your .h file the error complains about
[14:33:23] <sebus> thanks guys, I'll try to implement this
[14:33:46] <Krampus> sebus: I actually ask a "how would you test a simply connected memory device on a microcontroller" as an interview question. I'd give you 85%. :)
[14:34:17] <julius> nuxil, the F_CPU problem went away when adding: CFLAGS += -DF_CPU=$(F_OSC) F_CPU=F_OSC
[14:35:11] <Krampus> sebus: (or whatever my handwavy pass is; basically if you have a comprehensive test, you rock. If you know some of it, that's pretty good, and if you know some of it but realize there's more, that's even better)
[14:35:33] <nuxil> nice. but you should not need to right? definging it sgould be enuf. it always work for me. i dont use te make file or thr -D argument
[14:35:45] <nuxil> but hey. i am a noob :p
[14:35:51] <LeoNerd> zero, christmastree, zebra are good enough for prettymuch any failure mode
[14:36:19] <sebus> Krampus things goes a bit more difficult. I am playing now with total garbage - z80 board with lot of RAM and also... one of my chips were bad and stuff didn't work as I expected
[14:36:23] <Krampus> nuxil: if you pass in -DFOOF=0xb00b on the command line, it's "the same" as if you did #define FOOF 0xb00b.
[14:36:49] <nuxil> sorry for my bad typing. my desk is full of crap. wires, a hot solder..
[14:36:52] <Krampus> nuxil: (with the command line taking precident)
[14:37:06] <LeoNerd> nuxil: if you do #define it in the .c file remember to do so /before/ you #include the .h file that wants it
[14:37:08] <nuxil> Krampus, ok i didnt know that :D
[14:37:20] <sebus> So for now I need to fit memtest algorithm within few byes that's available in cpu registers ;_;
[14:37:25] <julius> while looking for this: error: ‘UCSRB0’ undeclared (first use in this function) i found 3 avrfreaks postings with #include and a lot of free space...somehow the avrfreaks forum eats up the inlcudes
[14:37:30] <nuxil> LeoNerd, yeah.. its always at the top
[14:38:13] <Krampus> nuxil: I'm 'dumbing it down' because like all of it "this is how it works most of the time, but there's a million exceptions to learn. :)
[14:38:43] <Krampus> nuxil: it might also help if you keep in mind that when you #include <something.h>, the preprocessor is dropping it right into your source file at that point.
[14:39:03] <nuxil> ye, i know that
[14:39:23] <Krampus> nuxil: And the order of header files can matter, especially if it's taking some of its own values from a config.h or some such.
[14:39:48] <nuxil> Krampus, that makes sense
[14:40:00] <Krampus> nuxil: "help you visualize." I dunno, I explained it that way to a couple interns over the years and they all went "whoaaaaa" like it was some secret of the universe.
[14:40:25] <nuxil> hehe
[14:40:50] * nuxil continues soldering together his 48 bit (8x6) shift register(s)
[14:41:13] * Krampus debates fighting some more with a goofy SPI interface vs slapping patchum-slime on his roof.
[14:54:56] <julius> ok now all my make errors are sorted
[14:55:27] <julius> in the fuse calculator i can select: Divide clock by 8 internally; [CKDIV8=0] which seems to be on by default. does this mean that the chip is running with 1mhz instead of 8?
[14:58:54] <LeoNerd> CKDIV8 is enabled by default on AVR chips generally, yes
[15:02:28] <julius> ah, nice to know. flashing at "fast" with usbasp is much nicer+
[15:22:55] <julius> how would you look at the value in: #define BAUD_PRESCALE ((uint16_t) ((F_CPU / ((USART_BAUDRATE) * 16.0)) + .5) - 1)
[15:23:23] <julius> BAUD_PRESCALE, do you write that into a register or is there a better way?
[15:26:26] <cehteh> depending on hardware you sometimes have to split that up
[15:27:12] <cehteh> if you want to print that just to get the result you could just run some mockup through cpp
[15:30:22] <cehteh> the macros from setbaud.h do it also w/o float :S
[15:43:10] <julius> ok, theres some code looking like this: #ifndef F_CPU # error "setbaud.h requires F_CPU to be defined" #endif in the setbaud.h file. but i never used a .h file before
[15:43:48] <cehteh> huh?
[15:44:00] <cehteh> wel the setbaud.h is a bit special
[15:44:36] <cehteh> usually you just include headers at the start of your sourcecode, they should only declare stuff which is defined (implemented) elsewhere
[15:46:09] <cehteh> setbaud.h in contrast needs some configvalues defined (F_CPU and BAUD) and defines macros over these and, thats different with setbaud.h it could be used multiple times in one source for different baudrates
[15:46:15] <cehteh> thats explained in the docs
[15:46:49] <cehteh> you have to have F_CPU defined anyways for some other things as well
[15:47:41] <cehteh> dont you have that yet? then add that somehow to your code (best is to add it to CFLAGS+=-D_FCPU=... in a makefile imo)
[15:48:06] <cehteh> or use your own 'config.h' which you include at very first in every .c file
[15:49:08] <cehteh> http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html that example is pretty all
[15:49:24] <Deskwizard> talking about USART, anyone has time to tell me that they think about whatever I came up with ?
https://github.com/deskwizard/AVR_CodeReference
[15:49:33] <Deskwizard> I'd greatly appreciate :)
[15:50:32] <cehteh> what does that do?
[15:50:52] <Deskwizard> for now, not much, I just want you pro's opinion on the USART code
[15:51:43] <cehteh> looks like a lot code to me :D
[15:52:42] <cehteh> but i tihnk i doing it somewhat similary
[15:53:08] <cehteh> ah on a first glance i think i see a bug in your code
[15:53:17] <Deskwizard> see, thats precisely why I asked hehehe
[15:53:19] <cehteh> you store head/tail on circular buffers
[15:53:53] <cehteh> that wont work in some corner cases (you cant distinguish between an empty and a full buffer)
[15:54:06] <cehteh> better store head+length
[15:54:16] <Deskwizard> I see, I'll look into that, thanks :)
[15:54:40] <julius> cehteh, yes im using F_CPU defined in my .c file
[15:55:09] <Deskwizard> cehteh: that way I could check for overrun, yeah good point :)
[15:55:24] <cehteh> moment i can show you my implementation
[15:56:20] <cehteh> http://git.pipapo.org/?p=muos;a=blob;f=src/muos/lib/cbuffer.c
[15:56:39] <cehteh> no error checking in the lib/ stuff .. thats done a level higher
[15:57:25] <cehteh> also avoid modulo% .. just a if and substraction on overrun
[15:58:23] <cehteh> overrun -> wraparound
[15:58:41] <Deskwizard> aight, I'll keep that in mind... its because of the division being slower thing right? (ie. buffers divisible by 2 thing ? )
[15:59:39] <cehteh> divisible by 2 can be optimized by the compiler
[15:59:51] <cehteh> but this way it works with any length
[15:59:55] <cehteh> same speed
[15:59:55] <Deskwizard> yeah okay, I read avout that :)
[15:59:57] <Deskwizard> oh okay
[16:00:11] <Deskwizard> I'll go read and figure out and I'll bbl :)
[16:00:18] <cehteh> in ISR (USART_RX_vect) { you dont really need a temporary var
[16:00:51] <Deskwizard> wasnt sure if I did or not, doesnt matter since I only act on it once, correct ?
[16:00:57] <cehteh> RX_Buffer_add(UDR); .... but its a bit tricky how to handle errors there
[16:01:12] <Deskwizard> yeah, one step a a time :)
[16:01:51] <cehteh> i ended up with defining a bitfield with one bit per error code (i dont have much) this way errors can be passed from isr's
[16:02:05] <Deskwizard> I see ! good idea
[16:02:21] <Deskwizard> I would probably have used a flag and define different values as ERR_OVF and stuff like that
[16:02:56] <cehteh> well i have the scheduler runnning which handles errors at top prio
[16:03:04] <cehteh> (any left pending errors)
[16:03:13] <Deskwizard> I think the soft uart does error reporting like you mentionned... havent looked much into it yet I wanted to get the buffer working before adding it to soft uart
[16:03:29] <cehteh> and checking for an errorr also clears the error condition
[16:03:46] <Deskwizard> should I be handling the HW error flags while I'm at it ?
[16:04:21] <julius> i will take a look at this tomorrow, thanks for your time guys
[16:04:25] <cehteh> i do, but i want to make that conditional
[16:04:42] <Deskwizard> mkay
[16:04:44] <cehteh> for example when parity is not used then it doesnt need to be compiled in
[16:04:50] <Deskwizard> indeed
[16:05:26] <cehteh> otherwise it translates hw errors into my own error system
[16:07:29] <cehteh> also i have 2 buffers/queues each .. one for the ISR small circular buffer, holding bytes to be send or received
[16:08:00] <cehteh> and one bigger rx buffer which reads lines for example .. also allows linediting
[16:08:36] <cehteh> and (whats i am working on) the txqueue which stores things to be send in a more compact binary format
[16:10:11] <Deskwizard> nice :) as you can see, im clearly not there yet hehehe
[16:12:29] <cehteh> i didnt have time to continue past weeks .. will work on it soon
[16:12:53] <cehteh> the lineditor is ready, only the txqueue is missing, but that will be some work
[16:13:22] <cehteh> but i expect great memory (RAM) savings from that
[16:27:24] <keithbrown> Thank you all for you help last week! I was able to program the avr just waiting on the cc debugger to setup the ble chip!
[19:33:29] <Casper> Deskwizard: re: xeon: yeah, I also been surprised by it, they are cheap on ebay somehow... mainly because the market for them is small and they have alot of them
