Back
[00:02:05] <rue_more> tpw_rules, iirc, some registers occur more than once in the memeory space
[00:02:23] <rue_more> Casper, ln , the command?
[00:02:34] <Casper> the log
[00:02:37] <rue_more> like as in emulating a pc, on an avr?
[00:02:43] <rue_more> oh
[00:02:58] <rue_more> its less time than it takes for a hd44780 to refresh
[00:03:38] <Casper> on an attiny85 ? :D
[00:03:43] <rue_more> definitly
[00:03:52] <Casper> I'm actually concerned about the size
[00:04:14] <rue_more> I did a tripple stacked ugly trig function call on an avr, printing each result to an lcd, and the lcd couldn't keep up
[00:07:07] <Casper> T=1/((1/298.15) + 1/3380 * ln(R/10000)) and R = (adc*(5/1024))*((5/1024)/10000)
[00:08:24] <Casper> if I didn't screwed up that's it
[00:09:02] <rue_more> whats the unoptimized version?
[00:09:20] <Casper> that's the unoptimised one
[00:09:38] <Casper> just... all in float
[00:09:43] <rue_more> elbow(dist C, dist A, dist B){ // returns angle c
[00:09:43] <rue_more> return rad2deg(
[00:09:43] <rue_more> acos(
[00:09:43] <rue_more> ((double)SQR(A)+(double)SQR(B)-(double)SQR(C)) / ((double)2*(double)A*(double)B)
[00:09:43] <rue_more> )
[00:09:43] <rue_more> );
[00:09:47] <rue_more> }
[00:09:49] <rue_more> its not that?
[00:11:36] <rue_more> carefull
[00:11:45] <rue_more> T=1/((1/298.15) + 1/3 <-- maybe use 1.0
[00:11:58] <rue_more> and 5.0
[00:12:02] <rue_more> and 1024.0
[00:12:42] <rue_more> I'v run into issues where gcc threw in integers at inconvienient times
[00:13:11] <rue_more> well, 5/1024 reduces at compiletime to a constant
[00:13:15] <rue_more> possibly 0
[00:13:23] <Casper> yeah
[00:13:46] <Casper> I just need to remember how to code :D
[00:14:00] <rue_more> that seems like an odd formula, whats it?
[00:14:12] <Casper> ntc adc to temp
[00:14:17] <rue_more> oooh
[00:14:27] <Casper> oh I forgot to throw in the -273.15
[00:14:38] <rue_more> hmm
[00:14:59] <rue_more> how many bits are you looking to get out of the result?
[00:15:18] <Casper> the working range is about 20 counts...
[00:15:23] <rue_more> it might be a close call for an 8 bit lookup table
[00:15:29] <rue_more> uh
[00:15:36] <rue_more> then you only need a 5 bit lookup table
[00:15:40] <Casper> and yes, a LUT is interressing
[00:16:08] <rue_more> easier to calibrate too
[00:16:17] <Casper> but I may add more complicated stuff later on
[00:16:24] <rue_more> und its fast ya
[00:16:28] <Casper> calibrate what?
[00:16:33] <rue_more> the lookup table
[00:16:39] <Casper> no calibration required
[00:16:55] <Casper> shall be within 1% of the real temperature with no calibration
[00:17:01] <rue_more> your formula will be off, math always is, because it assumes the world is mathematically accurate
[00:17:04] <Casper> well, the ntc that's it
[00:18:56] <Casper> man in libre office calc... it look so ugly
[00:19:21] <Casper> A2 = adc value
[00:19:26] <rue_more> want copy of my command line calc?
[00:19:26] <Casper> B2=($H$7/1024)*A2
[00:19:38] <Casper> C2=B2/(($H$8-B2)/$H$9)
[00:19:52] <Casper> D2=1/(1/$H$6+(1/$H$4)*LN(C2/$H$5))
[00:20:01] <rue_more> it cant do log, but the source is there if you want to add function support
[00:20:07] <Casper> E2=D2-273.15
[00:20:22] <Casper> all in H are the constants
[00:21:17] <rue_shop3> its funny, if the 3d printer were my design, I would prolly have finished it by now
[00:25:01] <rue_shop3> ok, I have some eeprom to access
[00:25:51] <rue_shop3> nobody says if the libc routines always use byte offsets to the eeprom access functions or if they auto scale to the size of the datatype they are accessing
[00:27:20] <Casper> damn I so expect that code to not work...
[00:27:52] <rue_shop3> try it on a PC first
[00:28:11] <Casper> I'm worried about the float stuff
[00:28:34] <rue_shop3> is the default for the eeprom 0xFF?
[00:28:43] <rue_shop3> Casper, floats work fine
[00:28:52] <Casper> ntcres=((AREF/2^ADCBIT)*adcval)/((NTCVREF-((AREF/2^ADCBIT)*adcval))/NTCTOPRES)
[00:28:56] <rue_shop3> its only a problem on intel processors :)
[00:29:17] <rue_shop3> everyone else gets it right
[00:29:33] <rue_shop3> aew:( I'm too old
[00:33:41] <Casper> porta=1/((1/NTCTEMP)+((1/NTCBETA)*ln(((AREF/2^ADCBIT)*adcval)/((NTCVREF-((AREF/ADCSTEPS)*adcval))/NTCTOPRES)/NTCRES)))-273.15;
[00:37:33] <Casper> ISSHHHH COSTY!!!!
[00:37:37] <Casper> 4558 bytes
[00:37:52] <Casper> and I don't even know if it work
[00:43:23] <rue_shop3> 32 byte lookup table
[00:43:26] <rue_shop3> er, row
[00:43:41] <rue_shop3> wont be more than 1k
[00:43:47] <rue_shop3> not even if you try
[00:44:12] <Casper> actually will be 2k<
[00:44:17] <Casper> for the full table
[00:44:20] <rue_shop3> temp = tempLookup(ADC)
[00:44:24] <rue_shop3> you said 20 counts
[00:44:26] <Casper> but gonna implement only a subset of it
[00:44:31] <rue_shop3> you said 20 counts
[00:44:52] <Casper> yes, that's the interresting range, but might go wider
[00:44:57] <Casper> it's a refrigerator
[00:45:09] * rue_shop3 snorts at Casper
[00:45:27] <Casper> 719 = 4.03C
[00:45:49] <Casper> 738 = 1.99C
[00:46:34] <Casper> but
[00:46:50] <Casper> 756 = 0.01C
[00:47:20] <Casper> and 561 = 20.03C
[00:48:04] <Casper> so might go from 450 = 31.51C to 800=-5.09C
[00:50:57] <rue_shop3> 350 values, max is under 4096, so 16 bits per entry is enough, so thats 700 bytes
[00:51:18] <rue_shop3> fixed place 16 bit, /100
[00:52:41] <rue_shop3> signed 16 bit -320.00 to 320.00C
[00:53:06] <rue_shop3> you could even do /1000
[00:53:14] <rue_shop3> -32.000 to 32.000
[00:53:22] <rue_shop3> give you an extra place of accuracy
[00:53:40] * rue_shop3 pokes Casper
[00:54:00] * rue_shop3 chants "LUT. LUT. LUT. LUT."
[00:54:40] <Casper> yup
[00:54:47] <Casper> that's the path I'm actually going
[00:54:57] <rue_shop3> "hey there fred, whys it stable? LOOKUP TABLE, LOOKUP TABLE!"
[00:55:17] <Casper> I'm making a script to calculate the values
[00:55:23] <rue_shop3> "right said Ned. LOOKUP TABLE, LOOKUP TABLE"
[00:55:33] <Casper> and basically generate the table, so copy paste to the .c and that's it
[00:55:50] <rue_shop3> yea, make sure its in flash
[00:56:21] <Casper> adc value -> voltage -> ntc value -> ntc temp step 3 is done
[00:56:27] <rue_shop3> how the *&^&*^$) do I read the eeprom off a chip...
[00:56:40] <Casper> hmmm eeprom...
[00:56:50] <Casper> almost tempting to throw the lut there
[00:57:00] <rue_shop3> you cant
[00:57:02] <rue_shop3> its too small
[00:57:10] <Casper> 512 bytes
[00:57:17] <Casper> 256 values
[00:57:25] <rue_shop3> L.I.A.R.
[00:57:33] <Casper> that could fit
[00:57:52] <rue_shop3> you said you needed 350 range
[00:58:01] <Casper> could reduce
[00:58:19] <Casper> I basically need 0-10, more is better
[00:58:23] <Casper> 0-10C
[00:58:37] <Casper> ideally I want -5 to 15...
[00:59:04] <rue_shop3> I refuse to have further part of your project untill the design solidifies more
[01:00:07] <rue_shop3> -U eeprom:r:eedump.hex:i
[01:00:52] <Casper> hehe
[01:00:57] <Casper> hmm
[01:01:02] <Casper> is it possible that bc don't do log?
[01:01:30] <Casper> oh...
[01:01:34] <Casper> ln = l
[01:09:14] <Casper> ADC 512
[01:09:14] <Casper> 250.00000000000000408610 <=== nice
[01:13:43] <rue_shop3> heh
[01:14:08] <rue_shop3> I need to modify my calculator so I can specify the output number format
[02:00:41] <Casper> rue_shop3
[02:00:57] <Casper> static const __flash int16_t lookup[1024] = <==== hey that's auto generated!.... need the values now... :)
[02:04:02] <rue_shop3> :)
[02:04:25] <Casper> I'm almost there...
[02:04:34] <Casper> somehow I get spaces instead of comma...
[02:04:55] <Casper> g at the end of sed help
[02:05:51] <Casper> there we go
[02:06:49] <Casper> rue_more:
https://gist.github.com/5b9e217d35f96ba000d2
[02:07:15] <Casper> https://gist.github.com/15cc5ac07e31f219dbbd <=== the result
[02:07:48] * Casper wonders if there is an easy way to pretty it up
[02:10:46] <Casper> fold could do it, but would be nice with a fixed items per line...
[02:11:50] <Casper> one way is to split the line into an array, then look throught the array...
[02:32:17] <Casper> hey rue_shop3
[02:32:18] <Casper> wake up
[02:32:41] <Casper> https://gist.github.com/9ba39c4d3ebe1314cb32 <=== look!
[02:33:26] <Casper> next: to add command line parameters....
[02:36:28] <Casper> actually there is a small issue with it, but it's a detail
[02:36:38] <Casper> __flash is not valid for avr
[02:49:00] <rue_shop3> GOT IT!
[02:49:09] <rue_shop3> the byte order is backwards
[02:49:24] <rue_shop3> the msb is left into bytes
[02:49:38] <rue_shop3> there are 5 preceeding zeros
[02:49:43] <rue_shop3> 1 parity bit
[02:49:48] <rue_shop3> 8 facility bits
[02:49:56] <rue_shop3> 16 card number bits
[02:50:05] <rue_shop3> a parity bit and another 0
[02:51:14] <rue_shop3> now how the gimbal do they get 0001418506 from 021,42250
[02:55:34] <Casper> now check the pastie!<
[02:55:53] <Casper> https://gist.github.com/f57373c601c3a26ee470 and that one :D
[02:56:42] <rue_shop3> it looks a lot like the program they use for generating the reprap ntc tables! coool
[02:57:27] <rue_shop3> which I still cant get to work with a damn
[03:00:05] <rue_shop3> http://www.doorentryonline.co.uk/acatalog/Proximity-card-printable-1.html
[03:00:11] <rue_shop3> hahah these were $1ea from china
[03:02:29] <Casper> yeah quite possible
[03:02:46] <Casper> lots of stuff from china is now 10 times the price once other stores buy them
[03:05:04] <rue_shop3> What are the numbers printed on the fobs & cards?
[03:05:04] <rue_shop3> The EM chip inside each fob or proximity access card is pre-programmed with Hexadecimal number that provides an 18 digit number during the manufacturing process. The first 10 digit number is the Unique I.D number (U.I.D) and is printed on the fob
[03:05:15] <rue_shop3> wtf, there are...
[03:05:24] <rue_shop3> 6 nibbles on the cards
[03:06:17] <rue_shop3> 0xFFFFFF -->> 16777215
[03:06:48] <rue_shop3> hmm
[03:07:22] <rue_shop3> AHA!
[03:07:39] <rue_shop3> facility code 18, card number 26058
[03:07:58] <rue_shop3> aka, 0x12 0x65CA
[03:08:05] <rue_shop3> ada 0x1265CA
[03:08:15] <rue_shop3> aka 1205706
[03:08:27] <rue_shop3> 0x1265CA -->> 1205706
[03:08:32] <rue_shop3> ok!
[03:08:41] <rue_shop3> I understand now!
[03:16:08] <rue_shop3> ok, so
[03:16:20] <rue_shop3> the byte order is backwards, which is the fault of C, I think
[03:18:45] <Casper> man it's weird... tiny84 is 8 pins, 6 are used for programmation...
[03:18:59] <rue_shop3> :)
[03:20:45] <Casper> the 2 others are for the crystal
[03:20:55] <rue_shop3> my tiny13 board looks funny like that
[03:21:16] <rue_shop3> 8 pin chip, 10 pin programming header, 5 io lines, and the power
[03:21:19] <Casper> I'm actually wondering if I will have enought pins
[03:21:33] <rue_shop3> its just adc -> serial isn't it?
[03:21:41] <Casper> 2x ntc, 1 relay, 1 uart out, 1 in... 1 pin left...
[03:21:46] <rue_shop3> return 0x87654321;
[03:22:05] <Casper> that pin will be for the display...
[03:22:07] <rue_shop3> results in the memory sequence 0x21436587
[03:22:10] <Casper> software uart...
[03:22:36] <rue_shop3> so, what is human mauling and what is machine mauling
[03:22:56] <rue_shop3> the machine is reversing the bits
[03:22:59] <rue_shop3> they are sent...
[03:24:03] <codyps> rue_shop3: are you familiar with endianness? (avr, at least when used with gcc, is little endian). It's possible that isn't being taken into account
[03:24:26] <rue_shop3> well, I wrote the code, so :)
[03:25:06] <rue_shop3> the lsb comes in first, so I'm screwing that up
[03:26:30] <rue_shop3> ugh
[03:26:47] <rue_shop3> if they dont send the msb first, I cant or with one and shift
[03:40:12] <rue_shop3> it is msb first
[03:43:53] <rue_shop3> ok, well, I think I'm fine
[03:44:19] <rue_shop3> if I shift it 2 places right and mask with 0xFFFFFF I get the right stuff
[03:44:33] <rue_shop3> from there I can work with the 10 digit code on the key
[03:44:39] <rue_shop3> its 1:30am
[03:45:25] <rue_shop3> the eeprom code works
[04:36:17] <anasver> what is worse: incrementing and comparing an additional variable, or taking an already existing one and doing existing_var%10 == 0 ?
[05:19:51] <twnqx> anasver: modulo is expensive
[05:19:59] <twnqx> it's a division, after all
[05:23:39] <anasver> twnqx: i figured that, but how does it compare to creating an additional variable, and incrementing it?
[05:24:01] <twnqx> iirc there is no hardware divider in avr
[05:24:22] <twnqx> so my guess would be around 20 instructions for the modulo
[05:24:38] <twnqx> inc/compare/optional reset would be what, 3-4?
[05:24:59] <anasver> i see
[05:25:29] <anasver> so the modulo code looks nicer but is way worse
[05:26:00] <anasver> thank you
[05:26:51] <twnqx> as a simpel rule i'd avoid modulo/division when you need performance
[05:27:58] <anasver> it's in an isr so taking as few cycles as possible is the way of choice
[05:29:55] <anasver> can you also tell me what: "warning: -z relro ignored " means? I can't find anything avr-related when searching that error message.
[05:37:18] <Lambda_Aurigae> it means that relro does not work with your current compiler setup.
[05:38:01] <Lambda_Aurigae> it has to do with relocatable software and really, I don't see how it would be functional on an avr.
[05:38:11] <Lambda_Aurigae> it is used to harden software.
[05:38:26] <Thrashbarg> hum anyone familiar with BT.656 video IC's?
[05:38:48] <Thrashbarg> BT.656 being the protocol...
[05:39:15] <Lambda_Aurigae> that's a video streaming protocol is all I know.
[05:39:20] <Thrashbarg> yup
[05:39:23] <anasver> than this must be the ide trying to do stuff that isn't even useful -.-
[05:39:38] <Thrashbarg> hurray feature bloat...
[05:39:49] <Lambda_Aurigae> anasver, using atmel studio, eh?
[05:40:07] <Lambda_Aurigae> gotta love doing a hackjob on a hackjob.
[05:40:14] <anasver> Lambda_Aurigae: No. Code::Blocks
[05:40:22] <Lambda_Aurigae> aahh.
[05:40:26] <Lambda_Aurigae> never used that one myself.
[05:40:45] <Thrashbarg> if software were pies they'd all be considered unfit for human consumption because everyone and their dog have stuck their thumb in it
[05:40:45] <Lambda_Aurigae> kate is about as far GUI as I go with programming.
[05:41:19] <ecilop> kate - linux editor?
[05:41:28] <Thrashbarg> KDE? :P
[05:42:06] <Lambda_Aurigae> yeah..kate the kde linux text editor.
[05:42:24] <Thrashbarg> so what does the A stand for? Linux?
[05:42:29] <Lambda_Aurigae> mostly I use vim though.
[05:42:32] <ecilop> I use kate as editor for sources too in MATE, no KDE :-)
[05:42:59] <Thrashbarg> I use Notepad++ because I'm a Windows Weenie
[05:43:17] <ecilop> Using vim in graphical environment - full shit (as for me)
[05:43:27] <anasver> well i'll try and write a makefile myself, and compile it without the IDE. Maybe that'll fix it.
[05:43:44] <Thrashbarg> "without the IDE" sounds good!
[05:44:18] <Lambda_Aurigae> as for what the name stands for, no clue.
[05:44:29] <Lambda_Aurigae> vim in a console here.
[05:44:51] <Lambda_Aurigae> or in a console window usually actually.
[05:45:17] <Lambda_Aurigae> but my normal dev environment is on an older linux notebook with serial and parallel ports and I don't run a gui on that.
[05:45:34] <Thrashbarg> sounds painful
[05:45:43] <Lambda_Aurigae> works rather well for me.
[05:45:53] <Thrashbarg> assuming you're developing large programs which you probably aren't
[05:46:00] <Lambda_Aurigae> have it setup with virtual consoles.
[05:46:02] <ecilop> lightdm+mate = 512Mb of RAM is enough
[05:46:06] <Thrashbarg> I've got a 386 set up a the moment so I can program some old GALs :P
[05:46:28] <Lambda_Aurigae> mine is a p-4 and it can run a gui but I just chose not to.
[05:46:34] <Thrashbarg> yer
[05:46:53] <Lambda_Aurigae> I started programming on more limited systems 30ish years ago.
[05:47:06] * Thrashbarg looks at his Commodore 128D set up on the desk....
[05:47:07] <Lambda_Aurigae> it's nice having multiple consoles but not a necessity.
[05:47:09] <Thrashbarg> I think it wants me to play a game
[05:47:12] <Lambda_Aurigae> vic-20.
[05:47:17] <Lambda_Aurigae> hooked to the projector here.
[05:47:17] <Thrashbarg> hehehe
[05:47:59] <Thrashbarg> I burned Jupiter Lander to a ROM to play on my VIC-20 ... fun game
[05:48:03] <Lambda_Aurigae> pixels are 1cm across or bigger.
[05:48:06] <Thrashbarg> hahahaha
[05:48:12] <Lambda_Aurigae> omega race is my favorite.
[05:48:16] <Thrashbarg> yeah
[05:48:24] <Lambda_Aurigae> was my first cartridge game for the vic-20 when I was a kid.
[05:48:42] <ecilop> Lambda_Aurigae: p-4 is very powerful for developing on linux.
[05:48:51] <Lambda_Aurigae> ecilop, of course it is.
[05:49:04] <ecilop> GUI must be there
[05:49:04] <Lambda_Aurigae> my other laptop is an i5,,,also with linux.
[05:49:25] <Thrashbarg> a decent P4 is all you really need if you're running Linux...
[05:49:26] <Lambda_Aurigae> ecilop, I installed linux on the p-4 without any gui environment on purpose.
[05:49:28] <ecilop> use small DE-s, not huge kde
[05:49:51] <Thrashbarg> kinda interesting considering they're about 10 years old. If you said "all you need is a 486" 10 years ago you'd be laughed at
[05:50:35] <Lambda_Aurigae> this machine I'm on currently I do pretty much no dev on but it is a quad core amd with 16GB of ram...my gaming/play around machine.
[05:50:45] <ecilop> "640K ought to be enough for anybody"
[05:50:50] <Thrashbarg> heh
[05:51:00] <Thrashbarg> this machien is a Core2Duo with 4GB RAM
[05:51:00] <anasver> well that's because we're long past the point where computers became powerfull enough for modest standard applications
[05:51:08] <Lambda_Aurigae> hell, I have attinys more powerful than my first ibm compatible computer!
[05:51:09] <twnqx> noone should ever use those insanely inefficient P4s
[05:51:17] <Thrashbarg> anasver: yup
[05:51:22] <Lambda_Aurigae> twnqx, I use it because it was free.
[05:51:28] <twnqx> that's no excuse
[05:51:31] <Lambda_Aurigae> and it has serial and parallel ports on it.
[05:51:39] <twnqx> the power consumption is so insanely excessive
[05:51:45] <Lambda_Aurigae> and I like those interfaces.
[05:51:58] <ecilop> Today's applications need fu*&ing refactoring
[05:52:07] <twnqx> i have an athlon XP for that
[05:52:08] <Thrashbarg> twnqx: I'm thinking about setting up a dual Xeon server which is about ten years old :P
[05:52:21] <Thrashbarg> P4 based
[05:52:27] <twnqx> yeah, i also have a quad opteron lying around
[05:52:30] <twnqx> just eats 600W idle
[05:52:33] <twnqx> wanna buy it?
[05:52:34] <Thrashbarg> heh
[05:52:43] <ecilop> twnqx: how much?
[05:52:45] <Lambda_Aurigae> Thrashbarg, just recently got rid of 4 of those.
[05:52:59] <Thrashbarg> Lambda_Aurigae: yeah understandably...
[05:53:09] <twnqx> ecilop: it's a rackmount box with 32GB ram and 4 quadcore cpus
[05:53:12] <Thrashbarg> Lambda_Aurigae: this one used to be in a cluster for rendering graphics
[05:53:16] <Lambda_Aurigae> dual 3.6GHz P-4 Xeons with 4GB of ram each and quad scsi drives in a raid5
[05:53:16] <twnqx> i was wonderign what it's even worth :P
[05:53:51] <twnqx> and i am afraid my current 4770k is pretty close to it in performance :(
[05:53:54] <Lambda_Aurigae> twnqx, now that would be a fun machine...16 cores to futz with!
[05:54:05] <twnqx> what for
[05:54:12] <ecilop> Lambda_Aurigae: be careful with raid-5.
[05:54:13] <twnqx> i'll get a haswell-e in a month or two
[05:54:19] <Lambda_Aurigae> what was odd though was the p-4 xeons were faster than my first 2 64bit machines.
[05:54:23] <Thrashbarg> twnqx: kaboom!
[05:54:28] <twnqx> that has 8 cores + HT, so also 16
[05:54:31] <Lambda_Aurigae> ecilop, I know all about it...that's just how they were setup.
[05:55:06] <Lambda_Aurigae> they were given to me and I passed them on to a kid who loves old computers....
[05:55:14] <twnqx> lol
[05:55:18] <Lambda_Aurigae> the kid is autistic but brilliant with computers.
[05:55:33] <twnqx> i am stacking old computers...
[05:55:44] <Lambda_Aurigae> I'm slowly getting rid of my old stuff.
[05:55:54] <Lambda_Aurigae> just found an old powerpc mac...it won't power up though.
[05:55:57] <Thrashbarg> I'm slowly accumulating old stuff...
[05:56:06] <ecilop> I like "old" computers too... Am I autist?
[05:56:35] <Lambda_Aurigae> I keep my commodores and some old PC hardware, like the XT with the 10MB hardcard.
[05:56:42] <Thrashbarg> eya
[05:56:45] <Thrashbarg> yea...
[05:56:50] <Lambda_Aurigae> a 286, 386, and 486 for the fun of it..
[05:57:15] <Thrashbarg> I'd like a permanent place to set up my Amiga A1200, Dick Smith System-80 and Commodore 128D...
[05:57:28] <ecilop> Old software works more stable often .
[05:57:35] <Thrashbarg> yup
[05:57:42] <Lambda_Aurigae> I don't have any amiga hardware...still kicking myself for getting rid of the A2000-UX box all those years ago.
[05:57:42] <Thrashbarg> no fiddly OOP to get in the way
[05:57:53] <Thrashbarg> Lambda_Aurigae: ouuuch
[05:57:59] <Lambda_Aurigae> yeah.
[05:58:09] <Lambda_Aurigae> had to sell it to pay for food for the family kinda thing.
[05:58:21] <Thrashbarg> that's terrible :(
[05:58:30] <Lambda_Aurigae> was a sweet box too...processor speedup and a bridgeboard to boot!
[05:58:37] <Thrashbarg> nice
[05:59:05] <Lambda_Aurigae> so, really, 3 operating systems in 1 box.
[05:59:09] <Thrashbarg> my A1200 has a 33MHz 68030 upgrade in it
[05:59:10] <Thrashbarg> yea
[05:59:14] <Lambda_Aurigae> amigaOS, unix, and dos.
[05:59:22] <Thrashbarg> awesome
[05:59:23] <Lambda_Aurigae> that's what I had in the A2000-UX
[05:59:30] <Lambda_Aurigae> and,,,16MB ram!
[05:59:31] <ecilop> Can someone make a computer based on AVR atmega-s?
[05:59:38] <twnqx> why not
[05:59:42] <Lambda_Aurigae> ecilop, yeah, it's been done multiple times.
[05:59:51] <twnqx> take something z80 based and do it
[05:59:58] <Thrashbarg> twnqx: done that :P
[06:00:00] <twnqx> only prob is software
[06:00:01] <Lambda_Aurigae> I'm porting commodore basic to the AVR to build a retro computer.
[06:00:09] <twnqx> lol
[06:00:15] <Thrashbarg> Z80 running CP/M and an ATmega handling video, keyboard and a serial port
[06:00:18] <ecilop> they used powerful atmegas, not lowest atmega8 - 128..
[06:00:29] <twnqx> can't you just transpile 6502 code to avr code?
[06:00:31] <Lambda_Aurigae> atmega1284p here.
[06:00:45] <Lambda_Aurigae> twnqx, tried...it's not pretty.
[06:00:50] <Thrashbarg> twnqx: you'd need to write a 6502 emulator... yea
[06:00:55] <Lambda_Aurigae> they did some really funky things with data in the middle of code and all.
[06:00:57] <twnqx> harvard arch might become a problem
[06:01:08] <ecilop> It's interest to build on lowest atmegas with SMP..
[06:01:15] <twnqx> nah
[06:01:20] <Lambda_Aurigae> heck, an avr at 20MHz can emulate a 6502 vaster than the original.
[06:01:26] <twnqx> i would consider it pretty pointles, imho
[06:01:53] <twnqx> most annoying thing about AVRs is that they can't run code from RAM
[06:02:03] <Lambda_Aurigae> ecilop, for SMP, I would go with something 8052 based...as those often have external memory interfaces..
[06:02:05] <twnqx> which means you either have to flash everythinig
[06:02:07] <twnqx> or emulate it
[06:02:11] <Lambda_Aurigae> twnqx, I've been saying that for YEARS.
[06:02:39] <Thrashbarg> hArVaRd
[06:02:44] <twnqx> i wouldn't bother
[06:02:44] <ecilop> twnqx: emulating java :D
[06:02:58] <twnqx> highend avrs are as cheap as lowend arms
[06:03:02] <Thrashbarg> ecilop: yay lets make java MORE useless....
[06:03:30] <ecilop> Thrashbarg: java became a crap for last years
[06:03:39] <Thrashbarg> yep...
[06:03:48] <Lambda_Aurigae> I do love the 8052 chips for that external memory interface...external data ram or rom or memory mapped peripherals like the good old days....and/or external program memory.
[06:04:06] <Lambda_Aurigae> java started out crap...and has spread like an infection.
[06:04:25] <ecilop> Java-s first idea was good.
[06:04:39] <Thrashbarg> so was Pascal
[06:05:04] <ecilop> No. Idea of emulating virtual machine for bytecode
[06:05:07] <Lambda_Aurigae> PASCAL was the first compiled language I ever learned.
[06:05:25] <Thrashbarg> ecilop: UCSD Pascal did that
[06:05:38] <Lambda_Aurigae> on the apple-II
[06:05:43] <Thrashbarg> heh
[06:06:32] <Lambda_Aurigae> then took a step back and went FORTRAN on a mainframe with punch cards.
[06:06:39] <twnqx> pascal...
[06:06:50] <twnqx> i learnt it on the c128d running cpm
[06:06:59] <ecilop> Did pascal use transitional bytecode?
[06:07:02] * Thrashbarg looks at his C128D again...
[06:07:11] <Thrashbarg> ecilop: the p-System did yes
[06:07:24] * twnqx looks at his VICE
[06:08:00] <ecilop> fortran-77 :)
[06:08:35] <Lambda_Aurigae> we just called it FORTRAN.....no 77 at the time that I remember.
[06:08:45] <Lambda_Aurigae> and PASCAL and FORTRAN are supposed to be all capitalized...
[06:08:49] <Lambda_Aurigae> hehe
[06:09:05] <Thrashbarg> so is LASER
[06:09:11] <ecilop> I am newbie for that years. In school we learned turbo bascal.
[06:09:26] <ecilop> Sorry form my bad english language.
[06:09:30] <ecilop> *for my
[06:09:44] <Lambda_Aurigae> turbo bascal? is that like basic and pascal combined?
[06:10:09] <ecilop> No combines of programming language, only ide is like each other
[06:10:44] <ecilop> turbo Pascal
[06:10:50] <ecilop> sorry :)
[06:50:47] <anasver> well so now i'm working with a custom makefile and still getting the "/usr/bin/avr-ld: warning: -z relro ignored."
[06:51:05] <anasver> it happens while linking the whole thing
[06:51:50] <anasver> Parameters are:
[06:51:52] <anasver> Linking: main.elf
[06:51:53] <anasver> avr-gcc -mmcu=atmega8 -I. -gdwarf-2 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 -F_OSC=16000000 -MD -MP -MF .dep/main.elf.d main.o timer.o lcd-routines.o debounce.o --output main.elf -Wl,-Map=main.map,--cref -lm
[06:57:41] <ecilop> On what line of source that error?
[07:01:09] <anasver> Linking: main.elf
[07:01:11] <anasver> avr-gcc -mmcu=atmega8 -I. -gdwarf-2 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 -F_OSC=16000000 -MD -MP -MF .dep/main.elf.d main.o timer.o lcd-routines.o debounce.o --output main.elf -Wl,-Map=main.map,--cref -lm
[07:01:12] <anasver> /usr/bin/avr-ld: warning: -z relro ignored.
[07:01:14] <anasver> timer.o: In function `timer_init':
[07:01:15] <anasver> /home/andreas/Dokumente/Quellcodes/avr/Digitaluhr/timer.c:7: multiple definition of `msec'
[07:01:17] <anasver> main.o:(.bss+0x3): first defined here
[07:01:18] <anasver> timer.o: In function `timer_init':
[07:01:20] <anasver> /home/andreas/Dokumente/Quellcodes/avr/Digitaluhr/timer.c:7: multiple definition of `sec'
[07:01:21] <anasver> main.o:(.bss+0x2): first defined here
[07:01:23] <anasver> timer.o: In function `timer_init':
[07:01:24] <anasver> /home/andreas/Dokumente/Quellcodes/avr/Digitaluhr/timer.c:6: multiple definition of `min'
[07:01:26] <anasver> main.o:(.bss+0x1): first defined here
[07:01:27] <anasver> timer.o: In function `timer_init':
[07:01:29] <anasver> /home/andreas/Dokumente/Quellcodes/avr/Digitaluhr/timer.c:6: multiple definition of `hrs'
[07:01:30] <anasver> main.o:(.bss+0x0): first defined here
[07:01:32] <anasver> collect2: error: ld returned 1 exit status
[07:01:33] <anasver> make: *** [main.elf] Fehler 1
[07:02:00] <anasver> ecilop: though i can't find the spot where those double-definitions are supposed to be
[07:02:25] <ecilop> header file?
[07:02:48] <ecilop> look in included header files
[07:03:04] <twnqx> well, obviously once in main.c and once in timer.c
[07:03:21] <twnqx> but how are we supposed to guess if we don't have the source
[07:05:51] <anasver> http://pastebin.com/vZe7CaeH
[07:05:59] <anasver> here it is
[07:06:16] <twnqx> so you include the same var declration
[07:06:18] <twnqx> twice
[07:06:23] <twnqx> thus delcaring the same vars
[07:06:24] <twnqx> twice
[07:06:35] <twnqx> just as ecilop anticipated
[07:06:47] <twnqx> hint: you never delcare variables in a .h file
[07:07:25] <twnqx> #include is really textual replacement of the #include line with the content of the file
[07:08:02] <anasver> oh
[07:08:18] <anasver> but what about the #ifndef, wouln't that fix it?
[07:08:24] <twnqx> no
[07:08:30] <twnqx> it just prevents it inside a single .c
[07:08:38] <twnqx> for multiple inclusion into the same .c
[07:08:41] <twnqx> what you want
[07:08:48] <twnqx> is to declare them extern
[07:08:55] <twnqx> and then do evil magic in timer.c
[07:08:58] <twnqx> #define extern
[07:09:03] <twnqx> #include "timer.h"
[07:09:05] <twnqx> #udnef extern
[07:09:17] <twnqx> #undef extern obviously
[07:11:04] <ecilop> may I see timer.h ?
[07:11:14] <twnqx> it's at the bottom of the pastebin
[07:11:39] <anasver> what does that #define extern do?
[07:11:50] <twnqx> it repalce future occurences of extern with nothing
[07:12:01] <twnqx> replaces
[07:12:17] <ecilop> volatile uint16_t msec = 0;volatile uint8_t sec = 0;volatile uint8_t min = 0;volatile uint8_t hrs = 0;
[07:12:18] <twnqx> because just once you need to actually declare it
[07:12:20] <ecilop> I think that's bad idea to init variables in header file..
[07:12:39] <twnqx> true too
[07:12:55] <twnqx> probably won't work with extern declarations
[07:13:27] <anasver> alright then i'll just move the variables from the .h to the .c
[07:13:53] <twnqx> if you don't need to access them in main.c that will do
[07:14:00] <ecilop> And I use "volatile" very carefully. I prefer ATOMIC_BLOCK and _memoryBarrier()
[07:14:04] <twnqx> and would be the right thing to do
[07:14:14] <twnqx> lol
[07:14:29] <twnqx> that's a bit excessive :P
[07:14:46] <twnqx> the barrier only cares about ordering of instructions
[07:15:28] <ecilop> He needs "volatile" to use this variables in ISR and main procedure without problems..
[07:16:08] <ecilop> If program not big, he can use "register" for uint8_t
[07:17:07] <anasver> right the volatile was because the function printing the time needs access to those from the main function.
[07:17:41] <anasver> I'll probably won't make them register, so i can reuse the source code.
[07:18:02] <anasver> (In potentially bigger projects to come)
[07:18:18] <anasver> but thank you guys very much, now it works
[07:18:36] <anasver> still complaining about the relro thing, but finishing the build
[07:19:22] <ecilop> About "relro" I think that it's problem of your build avr-gcc
[07:20:07] <ecilop> On my "SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux" I have no "relro" messages from avr-gcc
[07:20:29] <ecilop> avr-gcc -v
[07:20:32] <ecilop> Using built-in specs.
[07:20:35] <ecilop> COLLECT_GCC=avr-gcc
[07:20:38] <ecilop> COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper
[07:20:41] <ecilop> Target: avr
[07:20:44] <ecilop> Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr
[07:20:47] <ecilop> Thread model: single
[07:20:50] <ecilop> gcc version 4.7.2 (GCC)
[07:28:39] <anasver> for now i'll just ignore that
[08:47:18] <MasterChief10> Hi
[08:48:57] <brabo> hi
[08:52:49] <MasterChief102> Truing to get data from GPS module via SPI, Master is AVR and the Slave is GPS. here is code
http://pastebin.com/0L75Mb1X , but it does nothing. checked with oscilloscope and there is even no pulse on SCK. what I did wrong?
[08:54:51] <MasterChief102> Do SPI can only receive data while transmitting other data?
[09:07:52] <twnqx> yes
[09:08:09] <twnqx> whenever you TX, you RX at the same time
[09:15:47] <Tachyon`> also, clocks.
[12:06:58] <Casper> it's funny
[12:07:26] <Casper> I'll have to do some more tests.. I can't beleive that 1 line take 4.5k of flash...
[12:08:48] <Casper> hmmm yeah something is wrong
[12:10:59] <Casper> ow well, let's wake up then investigate
[12:32:11] <Casper> ah AH I knew the yesterday size was wrong..
[12:32:18] <Casper> 1492 with the formula...
[12:32:33] <Casper> so the LUT is bigger... :(
[13:39:08] <StevenS> hi
[13:44:59] <StevenS> quick question, I found this library >>
https://github.com/adafruit/Adafruit_CC3000_Library << but it is designed for the arduino uno. Can that be somehow used for atmega32u2 with lufa bootloader
[13:45:02] <StevenS> ?
[13:45:14] <learath> probably.
[13:45:29] <learath> but you may need to fix/translate it.
[13:47:09] <StevenSS> bah internet died
[14:55:45] <Casper> interrest9ing, the tiny85 is more and more nicer the more I read about it :D
[14:56:27] <Casper> default RC is 8MHz, there is a PLL that can do x8 for the timers
[14:56:54] <Casper> and they talk about a pll /4 for the main cpu clock
[14:57:07] <Casper> meaning the cpu can run at 16MHz off the rc
[15:11:15] <Lambda_Aurigae> Casper, yup...and it can do vUSB without an external crystal too.
[15:11:23] <Lambda_Aurigae> most of the time anyhow.
[15:22:25] <Casper> look like it will be a good choice for this project
[15:22:41] <Casper> I will have JUUUUST enought pins
[15:22:54] <Casper> actually... I'm not sure...
[15:23:00] <Casper> I think I need 1 more...
[15:23:54] <Casper> Lambda_Aurigae: can you disable reset in software?
[15:24:02] <Lambda_Aurigae> no.
[15:24:05] <Lambda_Aurigae> only through a fuse.
[15:24:16] <Casper> ok...
[15:24:25] <Casper> and once it got disabled, can you somehow reenable it?
[15:24:28] <Lambda_Aurigae> once you do so then you need an HV serial or parallel(depends on the chip) programmer to reset it.
[15:24:39] <Lambda_Aurigae> a fuse doctor will reset it for you.
[15:24:46] <Lambda_Aurigae> very easy to make.
[15:24:50] <Casper> ok
[15:24:58] <Lambda_Aurigae> google for fuse doctor.
[15:25:12] <Casper> it's a "fancy" refrigerator control that I want to make
[15:25:13] <Lambda_Aurigae> the newest one does attiny and atmega...any of them that use spi will work with it...
[15:25:54] <Casper> need 2x ntc, 2x serial out, 1x serial in, 1x relay out... however I could most likelly go away with 1x serial out...
[15:47:13] <nullvibe> sounds about like what I need, except I just need something to downgrade spi to rs232 or ttl
[15:48:58] <nullvibe> of course, what I REALLY need is to just pay closer attention to what I'm buying. Ended up getting a batch of spi wireless modules when I'd intended to get the regular ttl version. but oh well. when life gives you lemons, you make lemonade, and when carelessness gives you spi, you learn a technology you've been avoiding
[15:54:02] <RikusW> nullvibe: spi is fairly simple
[15:54:10] <Casper> it's funny how gcc optimise out stuff...
[15:54:22] <RikusW> vary annoying...
[15:54:25] <RikusW> *very
[15:54:39] <Casper> it make guestimating the size of the program quite painfull
[15:55:38] <nullvibe> RikusW: simple for you, but probably not so much for me. The REASON I use ttl is because it's dead-simple electronics-wise
[15:55:59] <Casper> I first told the compiler that I was using an atmega8535 and redirected the result of the formula to portb
[15:56:25] <Casper> but now I set the right one... so need to set it in a variable... which ain't used anywhere so all is optimised out...
[15:56:48] <nullvibe> Casper: interesting. you really ARE a ghost. Can't tab-complete you :)
[15:57:00] <nullvibe> can clang build code for MCUs yet?
[15:57:01] <RikusW> nullvibe: ttl is not a serial protocol, its a logic family...
[15:57:39] <RikusW> or do you mean ttl uart output ?
[15:57:40] <nullvibe> RikusW: pull up, pull down, and so forth is easy logic to integrate into computer systems
[15:58:06] <RikusW> avr output is cmos btw
[15:58:49] <RikusW> i2c is complicated protocol wise
[15:59:06] <RikusW> serial (rs232) and spi is very simple and easy to use
[15:59:07] <nullvibe> like for instance this arduino relay shield. plug in a usb ttl module, rig up the output to one of the relays, and something as simple as 'dd if=/dev/zero of=/dev/ttyUSBn' turns it on for as long as the command is running
[15:59:38] <nullvibe> and yes, ttl in a uart sense. rs232 is messy since it doesn't guarantee it'll hold the line high/low
[15:59:59] <nullvibe> also messier to use because of the pole shift
[16:00:11] <RikusW> rs232 specifies 0=12V and 1=-12V
[16:00:29] <RikusW> use a max232 chip
[16:00:50] <nullvibe> in practice, it can be -13V to 13V, or so I'm told
[16:01:06] <RikusW> or lower like 5V
[16:01:16] <nullvibe> can't see wasting an extra ~$2 if I don't have to *shrug*
[16:01:38] <RikusW> on a single pcb there is no need
[16:01:49] <RikusW> if you use long cables you need the max2323 chip
[16:01:55] <RikusW> 232
[16:02:00] <nullvibe> there's a max232 build online that uses a couple caps and a pulldown resistor or something, but still extra complexity for no apparent use to me (yet)
[16:02:47] <nullvibe> think automation, especially home automation, among other things. mostly about controlling relays
[16:03:07] <RikusW> how long will the cables be ?
[16:03:23] <RikusW> you'll need to use rs232 or rather rs485 chips
[16:03:42] <nullvibe> that's why the usb dongle for testing
[16:04:10] <RikusW> I'm not sure how long unprotected avr io pins will last when connected to long cables
[16:05:05] <nullvibe> I'll have to keep that in mind when I get my head around using MCUs for this stuff
[16:08:38] <nullvibe> this little transceivers I have are fixed frequency, and I've been buying the ttl ones so that I can put them on the end of a ttl dongle and have a device I can push bits between systems over the air with
[16:09:46] <nullvibe> but it's mainly to embedded systems, which is the other problem. no spi, only ttl-based consoles, so ttl enters the equation anyway
[16:10:28] <RikusW> rather call it serial than ttl
[16:10:42] <RikusW> or uart
[16:10:46] <nullvibe> serial is a little too ambiguous
[16:11:29] <RikusW> rs232-ttl ?...
[16:11:29] <nullvibe> I'm just calling it what everyone else calls it *shrug*
[16:11:56] <RikusW> in #arduino ?
[16:12:37] <nullvibe> anyway, these little transeivers don't encrypt or error correct or anything, so I'm going to have add an MCU on both ends before I can move beyond the tinkering stage anyway
[16:13:04] <nullvibe> I don't use arduinos, so don't think I've ever been to that particular channel
[16:13:28] <RikusW> you'll have to send packets
[16:13:42] <nullvibe> can't see myself paying ridiculous markup for a prefab unit I can make myself without too much difficulty (or buy something prefab for cheaper that's an actual computer)
[16:14:46] <nullvibe> yeah. I thought about using some old 802.11b usb units, but they require fw to be loaded over usb at each power on, so not an easy option
[16:17:26] <nullvibe> I've been tinkering with msp430s here and there, but I don't think there's any way to squeeze enough umpf out of one of those to handle any notion of networking either, so there's also that
[16:20:52] <nullvibe> only thing I keep coming back to are various small mips socs with builtin wifi, but they're prohibitively expensive for some of the things I'm wanting to do. and yes, cable lengths are part of the problem
[16:22:57] <nullvibe> to keep the cable lengths short in the home automation context would require numerous mips socs, running $20+ a piece, or a homebrew shivaplug (since shivaplug is ancient arm and arm is a bitch in general)
[16:23:33] <RikusW> how about powerline networking ?
[16:23:51] <nullvibe> also prohibitively expensive
[16:24:04] <nullvibe> and not secure in the least
[16:30:19] <nullvibe> the powerlines here in the US supposedly lead to signals over powerline being filtered at the box outside, but that's not the case everywhere, and I don't trust crypto that's difficult for anyone to independently verify besides. So I'd still have to end up having something do an additional layer of crypto on top
[16:30:51] <nullvibe> I've just kind of been sitting here watching what's been going on to see if any of sparked any ideas ^_^
[16:49:40] <Casper> is peter fleury's uart lib still one of the best one? or there is other smaller better ones?
[16:52:22] <jacekowski> nullvibe: powerline networking is cheap
[16:52:43] <jacekowski> nullvibe: and works a lot better than wifi
[16:52:50] <jeremyabel> hey Casper
[16:53:14] <Casper> o/
[16:53:26] <jeremyabel> I don't know about any better uart libs, sadly
[16:53:36] <nullvibe> jacekowski: >$20 per unit is not "cheap" in my book. even >$10 wouldn't be
[16:53:39] <jeremyabel> I wrote my own usart one, but who knows how good it is :P
[16:53:56] <jeremyabel> are there any articles about best practices for low power avr opperation?
[16:54:16] <jacekowski> jeremyabel: set outputs/inputs to highZ and sleep as much as you can
[16:54:27] <jeremyabel> word
[16:54:58] <jeremyabel> like, if I'm sending stuff over USART maybe once every 5 seconds, I should sleep inbetween those?
[16:55:02] <jeremyabel> and reinit the USART each time?
[16:55:18] <jacekowski> yes
[16:55:20] <jacekowski> usart will stay initialised
[16:55:32] <jeremyabel> oh rad
[16:55:38] <jacekowski> 5s is ages
[16:55:47] <jeremyabel> yeah :P
[16:55:55] <jacekowski> what sort of clock frequency are you using
[16:56:03] <jeremyabel> 7.3728
[16:56:05] <jacekowski> slow clock also helps
[16:56:07] <jeremyabel> MHz
[16:56:13] <jeremyabel> yeah, that's the slowest I could go
[16:56:24] <jeremyabel> running a bluetooth module, requires 115200 baud rate
[16:57:01] <jacekowski> well, if you are running bluetooth then power consumption is obviously not an issue
[16:57:18] <jacekowski> nullvibe: have you thought about using bluetooth for your application
[16:57:27] <jacekowski> nullvibe: you can get bluetooth modules for peanuts
[16:57:42] <jeremyabel> jacekowski: I mean, it's an issue in that I'd like to keep it as low as I can, it's battery-powered, lipo
[16:57:50] <jeremyabel> bluetooth uses 45mA during transmission
[16:58:10] <jacekowski> jeremyabel: avr will be nowhere near that
[16:58:15] <jeremyabel> yeah, seems like it
[16:58:22] <jacekowski> jeremyabel: and if you sleep most of the time, it will be even less
[16:58:43] <jacekowski> nullvibe: you can get bluetooth modules for like $5 or less
[16:59:27] <nullvibe> was just talking about that in ##electronics a minute ago, and yes, it'd be perfect except that all bluetooth modules require spi, which requires a mcu to convert to ttl anyway
[16:59:50] <jacekowski> nullvibe: ???
[16:59:52] <jacekowski> since when
[16:59:59] <jeremyabel> the one I'm using is rs232
[17:00:20] <jacekowski> nullvibe: there is plenty of uart/serial modules around
[17:01:05] <jacekowski> https://www.sparkfun.com/products/12574 - expensive one though
[17:01:31] <jeremyabel> https://www.sparkfun.com/products/10823 is the one I'm using
[17:01:58] <jacekowski> http://www.hobbytronics.co.uk/egbt-046s-bluetooth-module?utm_source=google&utm_medium=googleshopping&utm_campaign=googlebase&gclid=Cj0KEQjwhLCgBRCf0fPH043IlJwBEiQAf8P8U3CljpGCG1gyy6dexpJSKshB8z0Pdx1Ym2OQiIUUiy4aAui08P8HAQ
[17:02:11] <jacekowski> £7.80
[17:02:16] <Casper> ah... peter fleury's lib don't work on tiny85
[17:02:23] <jacekowski> so probably $7.80 in the US
[17:03:00] <jacekowski> http://www.ebay.co.uk/itm/HC-06-30ft-Wireless-Bluetooth-RF-Transceiver-Module-serial-RS232-TTL-for-arduino-/281399133676?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item4184b205ec
[17:03:07] <jacekowski> £2.61
[17:03:14] <jacekowski> TTL and all the stuff you want
[17:05:48] <nullvibe> yeah. I love how they say rs232 ttl. It's like they're TRYING to confuse buyers :)
[17:06:34] <nullvibe> that's partially how I ended up with this spare box of spi fixed frequency transceivers. they spammed the listing with serial, ttl, spi, and lots of other loaded terms and I didn't read carefully enough to figure out which it was
[17:07:02] <nullvibe> I notice that these are all rs232, but I guess that's still better than spi, because at least it can be converted easily
[17:07:32] <nullvibe> even by me!
[17:07:35] <jacekowski> it's TTL
[17:07:42] <jacekowski> as in, 5V
[17:07:47] <Lambda_Aurigae> rs232 is fun and awesome but requires stable and known clocks at both ends.
[17:08:00] <jacekowski> Lambda_Aurigae: you've been lied to
[17:08:11] <Lambda_Aurigae> ok...for 2 wire rs232..
[17:08:30] <Lambda_Aurigae> yes, there is clocked rs232 but so few devices use that these days.
[17:08:36] <jacekowski> Lambda_Aurigae: i've ran 232 using random crystals from my drawer
[17:08:49] <Lambda_Aurigae> yes, but you know the frequency of those crystals.
[17:08:51] <nullvibe> jacekowski: I don't see any qualifiers indicating which it is exactly. the rs232 makes it suspect though
[17:09:02] <jacekowski> 10% mismatch is fine
[17:09:04] <Lambda_Aurigae> or you can autobaud and they run at a stable frequency.
[17:09:05] <jacekowski> nullvibe: it's TTL
[17:09:18] <jacekowski> Lambda_Aurigae: i've ran 232 using internal RC oscillator
[17:09:25] <nullvibe> usually when ebayers say that, they mean plain ole' db9 or db25 rs232 for computer use
[17:09:25] <Lambda_Aurigae> me too.
[17:09:35] <jacekowski> nullvibe: it's TTL
[17:09:41] <jeremyabel> running 232 using interal oscillator at this very moment!
[17:09:50] <Lambda_Aurigae> I usually do autobaud testing along the way running rs232 with internal rc oscillator.
[17:10:08] <jacekowski> nullvibe: arduino has no real 232
[17:10:31] <jacekowski> nullvibe: actually, it's 3.3V
[17:10:31] <Casper> anyone knows of a good lib that work on the tiny85?
[17:10:52] <nullvibe> yeah, I just saw the 3.3V. that's....obviously not (computer) rs232 :)
[17:10:58] <Lambda_Aurigae> I've also had the RC oscillator drift enough that rs232 stops working and has to be recalibrated...usually due to horrid power regulation.
[17:11:13] <Lambda_Aurigae> Casper, good lib for what exactly?
[17:11:20] <Casper> Lambda_Aurigae: serial
[17:11:23] <jacekowski> nullvibe: but it's 5V tolerant
[17:12:04] <Lambda_Aurigae> Casper, I'm sure fleury's usart lib will with minor mods.
[17:12:27] <Casper> yeah, don't feels like modding it :D
[17:12:31] <nullvibe> jacekowski: missing the crypto though. iirc, even where bt DOES have crypto, it's pretty weak
[17:13:02] <jacekowski> what are you trying to send?
[17:13:21] <Casper> setting menu and periodic status
[17:13:29] <jeremyabel> Casper: I could send you mine :P
[17:13:39] <Casper> need to receive some data too
[17:13:43] <jeremyabel> dunno if it'll work in the 85 though
[17:13:59] <jacekowski> nullvibe: crypto on BT is actually pretty strong considering the amount of data you need to break it
[17:14:03] <jeremyabel> oh you want C, not C++?
[17:14:08] <jacekowski> nullvibe: in relation to amount of data you are likely to send
[17:14:12] <Casper> C...
[17:14:18] <nullvibe> well, the idea is to be able to interface with embedded systems while completely assembled (for uboot, diagnostics, and whatnot -- possible sensitive passwords going over the line)
[17:14:20] <jeremyabel> yeah mine's C++
[17:14:34] <Casper> bbl, time to take a food nap...
[17:15:21] <nullvibe> also theoretically as an addon serial module (which WOULD be rs232) for remote console purposes in systems lacking BMCs or the possibility of adding a BMC
[17:16:02] <jacekowski> nullvibe: well, to break BT crypto you have to capture at least 4G-ish of data
[17:16:10] <nullvibe> either way, the persistent nature of the mod would require some method of resisting unauthorized tampering, and at this level, all I can imagine working is some form of crypto
[17:17:18] <nullvibe> I don't remember the particulars, but there were any number of exploits possible against bt as of a few years ago, and I'm sure it depends on which version of the spec the devices use too
[17:17:39] <nullvibe> bt chips like this could be using any revision since it's doing something pretty basic
[17:17:41] <jacekowski> nullvibe: exploits were against specific implementations
[17:17:54] <jacekowski> nullvibe: not the protocol itself
[17:18:00] <nullvibe> also no guarantee of encryption in bt since that's an optional feature rather than required
[17:18:38] <jacekowski> well, you might still be better off going for cheap BT module and adding your own encryption in small attiny
[17:19:06] <nullvibe> yeah, I know most of my options as far as shuffling the data, the mcu was the part I needed the help with ;)
[17:20:16] <jacekowski> another option could be just simple infrared optical link
[17:20:31] <jacekowski> through a ir transparent piece of plastic
[17:21:11] <jacekowski> requires physical access to the device
[17:21:40] <jacekowski> and it would be really cheap
[17:29:37] <nullvibe> los solutions aren't a good option here
[17:30:35] <nullvibe> especially knowing just how annoying the @#$@! finicky remotes and receivers for electronics devices are about positioning
[17:41:05] <nullvibe> jacekowski: anyway, finding a decent go-to mcu that's at the right cost-performance ratio is going to be key, even if not necessarily required for this project
[17:43:16] <nullvibe> I won't have that luxury with others, like self-disabling devices based on going outside of certain, defined gps coordinates, and diy gps recorder modules for tracking animal migration patterns, relay controllers/concentrators, etc
[17:43:53] <nullvibe> well, ok, that last one is pretty weak and I probably would, but you get the idea
[21:10:32] <StevenS> quick question
[21:10:59] <StevenS> if i change my atmega32u4 bootloader from the stock one (DFU i think) to the arduino one, can i change it back?
[21:22:42] <nofxx_> StevenS, if you have a programmer that can change bootloader A for B, why B for A wound be different?
[21:23:15] <nofxx_> StevenS, worry about fuses... only way you can actually 'brick' a chip
[21:23:15] <StevenS> well i don't understand fuses. are they not permanent?
[21:23:28] <nofxx_> bootloader != fuses
[21:24:15] <StevenS> ah i see
[21:24:30] <StevenS> well i'm gonna follow this >>
http://g11l.com/content/loading-leonardo-bootloader-adafruit-atmega32u4-breakout
[21:24:30] <nofxx_> StevenS, just need to be careful with the 'programming bit' , a fuse that disables SPI
[21:24:42] <nofxx_> StevenS, also don't disable reset! heh... reset and programming
[21:25:09] <nofxx_> StevenS, always use this:
http://www.engbedded.com/fusecalc/
[21:25:19] <nofxx_> double check... you'll be ok
[21:26:25] <StevenS> hmm, well that tutorial doesn't mention fuses at all (the ones that did have to do with a different chip and different bootloaders)
[21:26:43] <StevenS> this tutorial seems very straight forwared
[21:26:46] <StevenS> forward*
[21:28:11] <nofxx_> Steffanx, yeah, as I said, different beasts, by selecting your chip on the link I've gave you, you'll understand
[21:28:23] <nofxx_> which kind of stuff you tweak in fuse
[21:28:41] <nofxx_> mostly crystal, watchdog... low level stuff
[21:28:48] <StevenS> right right
[21:29:31] <StevenS> is that tweaking unavoidable?
[21:30:14] <nofxx_> you need to read yr fuses and compare
[21:30:59] <nofxx_> but again, that's not bootloader related, but project
[21:31:08] <StevenS> ahhh i see
[21:31:31] <StevenS> well tomorrow i'll go ahead with that tutorial
[21:31:49] <nofxx_> StevenS, projects that track time or communicate via USB/serial usually needs a correct crystal setup
[21:32:46] <StevenS> but the fuses that are currently set won't change with the bootloader right?
[21:32:50] <nofxx_> StevenS, so you get chip D and guy says you need fuse 0xFE... wtf? go to the calc... oh, it's crystal at 1mhz
[21:32:57] <nofxx_> translate that to your chip, and done
[21:33:20] <nofxx_> lot of ppl put just the hex... I think its a bad practice, better explain what you need
[21:33:25] <nofxx_> and provide some chips examples
[21:33:34] <StevenS> right now, i'm assuming the fuses are set fine because it's using an external xtal and usb communication is working fine
[21:33:53] <nofxx_> or have a clever makefile/rakefile that switches automatically
[21:34:06] <nofxx_> StevenS, you got it
[21:35:23] <StevenS> beauty, so the fuses should stay, i can put on the arduino bootloader, and put code on it use the arduino IDE. it will then run the arduino code
[21:35:52] <StevenS> sounds right?
[21:38:29] <nofxx_> StevenS, the process yup, the reason no... heh, doing that just for the upload button ide?
[21:38:47] <nofxx_> well ok, I'm a cmd guy.. so I would prefer the dfu/avr-dude directly way
[21:38:51] <StevenS> lmao no no
[21:39:12] <StevenS> there is a library for a wifi module i bought. porting it to avr seems overly complicated for a proof of concept project
[21:39:30] <nofxx_> StevenS, you can link the arduino libs on /usr/share
[21:39:39] <nofxx_> and still use make
[21:40:01] <StevenS> oh, meh. the issue is more trying to get this library working on my device.
[21:40:29] <StevenS> i wanted to stick with avr and dfu bootloader but it looks like such a daunting task
[21:40:37] <nofxx_> I see, well, good luck heh
[21:40:45] <nofxx_> its not... if you already have a makefile
[21:40:57] <nofxx_> just link the libraries, or copy to yr project folder
[21:41:27] <StevenS> wait... what
[21:41:37] <StevenS> i can use arduino libraries with avr?
[21:41:52] <StevenS> without changing the bootloader?
[21:42:02] <nofxx_> of course you can.. arduino is using avr-dude under the sheets
[21:42:18] <nofxx_> the bootloader doesn't make a difference
[21:43:07] <StevenS> :O!
[21:43:24] <StevenS> well this changes everything! i'm going to google it now
[21:43:27] <nofxx_> StevenS,
https://github.com/nofxx/avr_scaffold/tree/master/arduino
[21:43:47] <nofxx_> there's the original avr_scaffold too, with makefiles
[21:43:53] <nofxx_> mine is rewritten in ruby
[21:44:54] <StevenS> sorry but i have no idea what i'm looking at.
[21:45:19] <nofxx_> you use make/ Makefile right?
[21:45:36] <nofxx_> thats rake/ Rakefile .. hehe, but there's the original avr_scaffold project, search github
[21:45:41] <StevenS> nope, atmel studio
[21:46:02] <nofxx_> ah... not a clue about that, don't have windows
[21:46:14] <StevenS> understandable
[21:46:31] <StevenS> i put windows on this machine so i could use atmel studio anyways
[21:46:42] <StevenS> i have dual boot with gentoo ;)
[21:46:49] <nofxx_> sounds like a plan ;)
[21:46:56] <StevenS> i've never used it though to do any avr work
[21:47:34] <nofxx_> you'll need avrdude and arduino
[21:48:15] <nofxx_> emerge? long time... I like arch
[21:48:50] <StevenS> it's getting to the point where i've thought about switching over to arch
[21:48:59] <StevenS> ati drivers recently pissed me off
[21:58:01] <StevenS> hmm for now i think i'll just take my route
[22:30:08] <Casper> does anyone happend to have an uart lib compatible with the tiny85?
[22:44:52] <Casper> o.O wait..
[22:45:21] <Casper> does the tiny85 even have "standard" serial? or just synchronous 2 and 3 wires one????
[23:41:25] <brabo> just love to see a function that's a noop being "fixed" to return fail, cause well, it didn't do anything