Back
[00:43:30] <Vutral> nice r00t^home
[00:43:34] <Vutral> R0b0t1`,
[00:48:18] <rue_more> WormFood, I thought the baud calculator was made by furryfold
[00:48:23] <rue_more> <-f
[00:48:40] <rue_more> so if you made that, furry must have made the encoder genorator
[00:49:23] <WormFood> nope, the bit rate calculator on my page, was written 100% by me
[00:50:37] <WormFood> it's not that elegant, but it works
[00:51:17] <WormFood> I was thinking of adding the ability for people to add their own list of bit rate, or xtal frequencies
[00:51:49] <WormFood> do you guys think that'd be a handy feature to add? right now, you can only add one custom xtal or bit rate, which is added to the list
[00:52:08] <rue_more> the one thing I would ask
[00:52:39] <rue_more> is that if you put in a spec, it come up on the first row, alone, I dont care if the rest is there too :)
[00:53:00] <rue_more> I find myself searching for the oddball crystal I just stuck in
[00:53:09] <WormFood> so it comes up at the top, instead of the end of the list?
[00:53:18] <rue_more> I suppose its technically not good to use RF crystals for a microcontroller....
[00:53:22] <rue_more> yea
[00:53:35] <rue_more> so I dont have to scroll to find out its already in the defualt table
[00:53:37] <rue_more> :)
[00:53:45] <rue_more> which only happens 66% of the time
[00:53:50] <WormFood> ah, I see what you mean
[00:54:21] <rue_more> did you have it keep a history of cutom requests?
[00:54:48] <rue_more> http://www.ebay.ca/itm/10-pcs-14-7456MHZ-14-7456-MHZ-Crystal-Oscillator-HC-49S-/220967597746
[00:54:57] <rue_more> best I can find for value...
[00:55:22] <WormFood> I have the custom requests in the log files ;)
[00:55:45] <WormFood> I could extract what xtal frequencies people are manually entering, and add the popular ones to the list
[00:55:48] <Casper> WormFood: talking about your calculator, it miss some "important" frequency: low end RC oscillator speeds... 1 and 2MHz
[00:55:57] <rue_more> cool, whats the most popular freq/baud?
[01:04:34] <Casper> rue_more: wrong question, the right one is: what's the most popular custom one :D
[01:08:23] <rue_more> I want to know indepenantly what the most popular freq and baud is
[01:08:57] <Casper> the standard freq is displayed, so won't show in the logsd
[02:09:18] <WormFood> rue_more,
http://wormfood.net/bitrates.txt and
http://wormfood.net/clockrates.txt for the bit rates and clock rates people have entered
[02:09:31] <WormFood> that is pretty raw, I just extracted them fairly quickly
[02:09:42] <WormFood> the first number, is (if it wasn't obvious), the frequency
[02:09:55] <WormFood> that is also data collected from about 2 1/2 years
[02:12:33] <WormFood> 3.686400 <-- rather specific, with two extra zeros on the end...only 24 times....do people do that out of habit?
[04:29:38] <ROMA> hello
[04:29:50] <ROMA> what is a difference between portA and portB ?
[04:31:17] <Xark> ROMA: Different pins and memory address?
[04:31:44] <ROMA> Xark what mean different pins?
[04:32:04] <ROMA> say i have attiny2313
[04:32:08] <Xark> ROMA: Depending on the chip, different pins will be connected to different ports in the chip.
[04:32:12] <ROMA> there is only portb and portd
[04:32:25] <ROMA> why there is no porta ?
[04:32:49] <ROMA> now i purchease attiny261 and there is only porta
[04:32:53] <specing> because there are no PINS to connect to?
[04:33:15] <ROMA> me not understand
[04:33:21] <ROMA> portA have pins
[04:33:24] <ROMA> portB have pins
[04:33:28] <specing> the chip doesen't
[04:33:28] <ROMA> portD have pins
[04:33:41] <specing> or more correctly
[04:33:48] <specing> the package doesen't export them
[04:33:53] <ROMA> chip have pins for portA portB portD
[04:34:31] <ROMA> these is I/O ports/pins
[04:35:18] <ROMA> datasheet shows that pins is attached to portA or portB or portD
[04:35:43] <ROMA> i can programm every pin direection with these ports
[04:36:05] <ROMA> what is a difference between portA and portB?
[04:36:20] <ROMA> why some AVR have only portB but some only portA?
[04:38:46] <ROMA> some time ago i read something that ports output power is different or something like that but i am not remember anymore
[04:42:25] <ROMA> can anyone explain to me difference?
[04:43:09] <Xark> ROMA: There are all kinds of flavors. Mostly the differences are between families or package variations. Consult your datasheet for your exact part (for pins and ports). :)
[04:44:19] <ROMA> Xark dont understand..
[04:44:23] <ROMA> family is AVR
[04:44:36] <Xark> ROMA: There are many AVR sub-families.
[04:44:45] <ROMA> electrically all ports have same output/input properties?
[04:44:59] <ROMA> Attiny chips is one family?
[04:45:14] <ROMA> or what familys is under Attiny chips?
[04:45:27] <Xark> ROMA: However, there is no intrinsic or generic "difference" between (e.g.) PORTA and PORTB I am aware of (although there are specific differences on some parts).
[04:46:10] <Xark> ROMA: You need to consult the datasheet for your exact part to see.
[04:46:11] <ROMA> i just don't get whay some Attiny in same package have portA and some portB
[04:46:47] <Xark> ROMA: I am not sure they do, I think you may be confused. Link me the two pinouts that show that (or datasheets).
[04:48:07] <ROMA> ok
[04:48:09] <ROMA> whait
[04:48:47] <ROMA> http://www.atmel.com/Images/doc2588.pdf
[04:49:32] <ROMA> http://www.atmel.com/images/doc2543.pdf
[04:50:05] <ROMA> Xark i paste links.. so hwere is portA in attiny2313 and where is portC?
[04:50:30] <Xark> OK, same as 2313
http://hobby-electrons.sourceforge.net/components/ATtiny2313/ATtiny2313.png and here is 261
http://hobby-electrons.sourceforge.net/components/ATtiny2313/ATtiny2313.png I was looking at.
[04:51:20] <ROMA> now i saw portA in 2313
[04:51:39] <ROMA> but there must be difference
[04:51:55] <ROMA> because logically ports must be assigned alfabetically
[04:52:44] <Xark> ROMA: I suspect the reason they bring out different ports is because they have differing "special functions" (i.e., PWM etc.) that they think will be useful for the market segment they target each chip.
[04:53:23] <ROMA> that is more believeble
[04:54:00] <ROMA> Xark how much AVR types did you programming?
[04:54:11] <Xark> ROMA: For example, notice how the ports on the 261 have many more OSC (PWM) than the 2313 (which has a serial port instead).
[04:54:52] <ROMA> Xark i believe it is one of reasons.. But maybe there is more?
[04:55:19] <ROMA> how much AVR types did you worked with?
[04:55:33] <Xark> ROMA: Only a fraction of the ones available. 2313, 4313, Tiny45/85, 328, 644, 1284, 2560 (and a few Xmegas and AVR32s).
[04:55:59] <Xark> ...and a slew of USB varients etc. :)
[04:56:01] <ROMA> and you did not notice any electrical signal changes on all port types?
[04:56:36] <ROMA> or you allways trying to use only portB?
[04:56:40] <Xark> ROMA: I sure noticed special function changes. I needed a header file full of #ifdefs to make my code portable.
[04:57:03] <ROMA> i am ASM programmer
[04:57:39] <ROMA> but if i use only portX I/O function then there is no changes between A,B, C ,D?
[04:57:41] <Xark> ROMA: I had specific requirements for my ports (bit position and PWM osc), so it was a bit unusual. However, "electrically" I am not aware of any differnces.
[04:58:04] <ROMA> ok thank you :)
[04:58:34] <ROMA> i hope i will not burn portA because i use it instead of portB..
[04:58:54] <Xark> ROMA: If you are just using it for GPIO, I think they are all the same (but consult "electrical characteristics" for the last word - there are some very subtle differences - like if you re-use reset pin for GPIO).
[05:00:38] <Xark> ROMA: I was doing some video generation (for fun) ->
http://imgur.com/a/YmlWf/noscript#0 http://imgur.com/a/7xDXW and
http://imgur.com/a/JO4Cq
[09:06:00] <DanFrederiksen> do micros have ECC memory or some other feature to ensure stability over long periods?
[09:06:57] <Valen> not as far as i'm aware
[09:07:15] <Valen> i spose there might be some but I haven't heard of them
[09:08:17] <theBear> ecc is about shortterm memory stability
[09:08:40] <theBear> there are hardware watchdogs at some level(s) in many micros
[09:09:02] <theBear> that's the usual approach to unsupervised long term 'reliablitiy'
[09:09:06] <theBear> err, spelling
[09:09:25] <Valen> micros are also generally rather more robust than what your average ram will have
[09:10:08] <megal0maniac> Is it anything like regular NAND flash?
[09:10:15] <theBear> 'it' ?
[09:10:26] <megal0maniac> uC flash
[09:11:16] <theBear> mmm, various physical technologies are used, but yeah, it's 'just regular flash memory'
[09:11:36] <Valen> what I was meaning is its generally done on a larger feature size
[09:11:46] <Valen> so i'm guessing it'll be more "reliable"
[09:11:58] <Valen> http://perspectives.mvdirona.com/2009/10/07/YouReallyDONeedECCMemory.aspx has some info on dram
[09:12:13] <Valen> micros use sram which I'm thinkging will also be more robust
[09:12:17] <Valen> less "moving parts"
[09:14:05] <theBear> mmm, i'm not sure about reality, but one might 'argue' that dram is more reliable because it DOES get refreshed, where sram needs to 'stick' hardware wise
[09:16:44] <rue_more> hahaha I was wondering why ssh wouldn't work to one of the machines
[09:16:51] <rue_more> telnet 192.168.9.12
[09:16:56] <rue_more> think I figured it out
[09:19:09] <twnqx> and then there are micros whose only purpose it is to defeat watchdogs...
[09:19:09] <twnqx> http://imageshack.us/a/img824/2338/modsih.jpg
[09:19:26] <twnqx> the top chip is a micro to defeat the watchdog.
[09:20:55] <rue_more> .. wait, in an ECU!?
[09:21:15] <theBear> technically a processor of some kind should ALWAYS 'defeat' a watchdog, it's kinda how they work :)
[09:21:41] <tzanger> ??
[09:21:45] <rue_more> microsoft would use a watchdog as a multitasking element
[09:21:50] <tzanger> a watchdog should not be defeatable by its very design
[09:22:25] <theBear> a watchdog should do nothing until it stops seeing the anti-watchdog-trigger, if you will, i'd call that 'defeating'
[09:22:50] <tzanger> that's not defeating anything
[09:22:53] <theBear> rue_more, lol
[09:22:57] <tzanger> that's giving the watchdog what it wants to prevent a reset
[09:23:11] <rue_more> theBear, prolly to trigger explorer restarts
[09:23:21] <tzanger> but I just looked at your photo, it looks like you're adding something to pet the dog
[09:23:23] <theBear> if you consider a watchdogs purpose to reset things, it becomes defeating
[09:24:17] <Valen> my problem is if my code has no main loop
[09:24:21] <tzanger> the watchdog's purpose is to reset the system if the system is not executing code in a correct manner. If you're hacking the system and bypassing the wd then that is outside of spec, but I wouldn't call it defeating. per se
[09:24:22] <Valen> ie its 100% interrupt driven
[09:24:29] <tzanger> Valen: you should never pet the dog in the main loop
[09:24:51] <Valen> touching the watchdog in a timer interrupt feels pretty pointless
[09:24:55] <theBear> err, you mentioned a problem ?
[09:25:07] <tzanger> Valen: I typically set flags in the interrupts and have a kind of high level state machine that only pets the dog in the main loop if the conditions are met
[09:25:34] <Valen> My main loop often has nothing in it
[09:25:56] <Valen> I spose I could do as you say
[09:26:05] <Valen> and have the timer let the main loop run
[09:26:10] <megal0maniac> So what is that chip actually doing then?
[09:26:20] <Valen> its all interrupts and sleeping
[09:26:39] <tzanger> i.e. int1() { wdstate |= int1_bit; ... } int2() { wdstate |= int2_bit; ... } main() { while(1) { if (wd_state == magic_value) { pet_dog; wd_state = 0; }; ... }}
[09:27:05] <tzanger> that type of thing, you can get fancier if you want to tighten things up (say int1 is supposed to fire roughly 3x int2, you can use bit counters etc)
[09:27:22] <Valen> its a good system tzanger
[09:27:42] <tzanger> watchdogs are often misused
[09:27:49] <tzanger> or rendered ineffective
[09:28:13] <tzanger> I don't know how many systems I've seen that have in the main loop something like while(1) { ... pet_dog(); } which does nothing to ensure the system is actually doing what it should
[09:28:17] <Valen> thats my issue
[09:28:39] <Valen> yes some kind of "sanity check" before touching wdt is a good plan
[09:28:48] <twnqx> rue_more: you recognized the think on the picture? :>
[09:28:58] <tzanger> you can overdesign it too, but like anything it's about balance
[09:29:03] <rue_more> it looks like an ECU
[09:29:42] <twnqx> it is one.
[09:30:09] <twnqx> and without the $§"()§$ thing i can boot my own code from CAN \o/
[09:30:21] <twnqx> it kept interrupting the upload.
[09:30:25] <Valen> nasty
[09:30:31] <rue_more> heh
[09:30:33] <tzanger> messing with your ecu can cause some serious damage on cars with electronic valve timing
[09:30:37] <twnqx> lol
[09:30:48] <twnqx> i wouldn't even consider putting that thing back
[09:30:51] <theBear> if there's no ecu, then what runs the code ?
[09:31:06] <twnqx> and it's not from my car, just a similar one from ebay.
[09:33:56] <megal0maniac> Electronic valve timing is a thing??
[09:34:21] <megal0maniac> That's a potentially expensive firmware update :)
[09:34:39] * megal0maniac has a timing cam and a carb
[09:34:48] <theBear> if a ecu can't fiddle more than just firing time it's not gonna be very 'useful'
[09:34:59] <megal0maniac> And then a bike which doesn't even have valves :)
[09:35:13] <megal0maniac> theBear: I suppose. I just haven't ever thought about it like that
[09:36:58] <twnqx> well, this thing has a TON of stuff to drive
[09:37:56] <tzanger> electronic valve timing is pretty mch commonplace now
[09:38:10] <tzanger> my 14 year old Passat has it for chrissakes. :-)
[09:38:10] <Valen> i think you are perhaps talking at slightly cross purposes
[09:38:28] <Valen> one has a system that lets something vary the cam and hence the valve timing
[09:38:40] <Valen> the other uses solenoids to actuate the valves directly
[09:39:02] <tzanger> sure, you're either cam-driven which is safe or electronic which is not safe. :-)
[09:39:15] <tzanger> well on interference engines anyway
[09:40:45] <twnqx> camshaft adjustment for both camshafts with 6 modules, spark drive, pressure sensors and adjustment, purely electronic drive-by-wire, 4 lambda sensors, 2 heated catalysts
[09:41:34] <megal0maniac> twnqx: I have a CAN interface to the clocks/odometer/service light
[09:41:42] <megal0maniac> The rest is mechanics :D
[09:41:46] * twnqx laughs
[09:42:02] <twnqx> 27 ECUs. on 4 CAN busses and one MOST bus.
[09:42:09] <twnqx> plus various LIN and other subbusses
[09:42:32] <megal0maniac> What the hell car/plane do you have?
[09:42:46] <twnqx> audi a5
[09:43:01] <megal0maniac> That explains it
[09:43:18] <megal0maniac> The dashboard is essentially a cockpit
[09:43:34] <twnqx> right
[09:43:45] <twnqx> it has a dedictaed control unit for the light switch >_>
[09:43:57] <megal0maniac> Germans...
[09:44:15] <twnqx> i guess it's cheaper than running all the cables
[09:44:42] <twnqx> otherwise i wouldn't understand the decision
[09:45:33] <twnqx> hm do i still have that pic online...
[09:46:36] <twnqx> http://imageshack.us/a/img36/3438/baum1.jpg cable for engine controller -> engine components only
[09:46:49] <twnqx> not including a few sub cables to lambda sensors
[09:47:18] <megal0maniac> Daym!
[09:47:29] <twnqx> http://imageshack.us/a/img440/6312/baum2x.jpg fusebox and relais, again for engine only.
[09:48:29] <megal0maniac> Insane
[09:48:56] <megal0maniac> Although
[09:49:05] <megal0maniac> My bike does have a pretty cool feature
[09:49:14] <Valen> one would think canbus would eliminate most of the wires ;->
[09:49:30] <Valen> if you took it far enough
[09:49:33] <megal0maniac> The exhaust port height is varied by a servo depending on RPM
[09:49:34] <twnqx> it does
[09:49:43] <Valen> put the injector driver on the injector
[09:49:55] <twnqx> the red and white connectors are the only things that go to the inside
[09:50:00] <Valen> run power gnd and signal
[09:50:09] <Valen> i meant if you took it all the way twnqx
[09:50:29] <twnqx> i... would not to that
[09:50:41] <Valen> if its worth doing, its worth overdoing ;->
[09:50:44] <twnqx> latency and collisions could kill you there, even with TTCAN
[09:51:04] <Valen> if you were clever about it it could be ok
[09:51:21] <twnqx> actually
[09:51:35] <twnqx> they have one high voltage generator per spark plug right on the spark plug
[09:51:42] <twnqx> they are driven by 65VAC from the ECU only
[09:51:57] <Valen> presume you would run an internal timer and tell the injector what to do, IE inject Xmsec after the synchronisation pulse for a period of Y untill further notice
[09:52:14] <twnqx> heh
[09:52:31] <Valen> you could do it
[09:52:38] <Valen> if its worth it is another issue
[09:52:49] <Valen> best part is there would be 0 aftermarket parts
[09:52:51] <twnqx> i'd say reliability would go far down
[09:53:13] <Valen> possibly
[09:53:19] <Valen> (probbably)
[09:53:29] <Valen> was sposed to go up with the advent of can
[09:53:36] <Valen> anyway past my bed time
[09:53:43] <twnqx> hm
[09:53:47] <twnqx> afternoon nap sounds good
[09:54:38] <megal0maniac> rue_more: Since you're around, what prompted the change in channel topic?
[10:00:10] <tzanger> twnqx: holy shit which car si that?
[10:00:15] <tzanger> 27 ECUS??
[10:00:31] <megal0maniac> It's still an Audi A5 ;)
[10:01:04] <twnqx> with E being Electronic, not Engine
[10:01:12] <tzanger> that must have been a hell of a wreck if that's all that is left of it. :-)
[10:01:16] <twnqx> heh
[10:01:23] <theBear> probably shouldn't call it ECU then, being that ECU stands for engine control unit
[10:01:23] <twnqx> all stuff from ebay
[10:01:39] <megal0maniac> Terrible accident in twnqx's living room :D
[10:01:57] <tzanger> nice car though
[10:02:08] <tzanger> I have the poor man's audi... vw. :-)
[10:02:12] <twnqx> theBear: not sure, i found the acronym used for both, engine in particular and all kinds of other control units
[10:02:29] <tzanger> ECU means engine to me. but yeah they probably bastardized it
[10:02:39] <twnqx> tzanger: not much better, electronics everywhere too
[10:03:02] <theBear> mmm, just because an acronym is misused by random monkies here and there, doesn't change the universally accepted meaning
[10:03:03] <twnqx> a friend of mine developed the software for the latest golf's board computer
[10:03:37] <theBear> anyway, i been out of bed fer almost 4 hours, so i suppose it's bedtime.. have fun now
[10:03:52] <twnqx> theBear: generally ISO standards use it for both
[10:03:58] <twnqx> so...
[10:04:42] <theBear> well that really casts a shadow over ISO doesn't it ? if anything a standards organisation should understand the importance of maintaining standards and not confusing them
[10:04:45] <theBear> but i'm gone
[10:06:31] <twnqx> did any of you ever build a primary side switchmode power supply with power factor correction?
[11:28:24] <stanreg> Can you selectively disable/enable specific hardware interrupts from software? Eg: Enable INT0 while disabling the rest..
[11:28:49] <twnqx> yes
[11:28:56] <stanreg> Sexcellent
[11:39:13] <stanreg> I wanted to use 2 hardware interrupts to execute 2 different tasks, but only once every task before going back to sleep. In other words, I wanted to software-disable one interrupt at a time.. eg: During int0's execution, int0 is disabled and int1 is enabled.
[11:39:42] <stanreg> However, it looks like my chip (tiny45) only has one external interrupt :\
[11:39:51] <stanreg> I think there might be a workaround.
[11:41:47] <stanreg> Would it be possible to change the way the interrupt itself is triggered (either on a low or high) to discriminate the 'outside caller', and only selectively allow one at a time?
[11:46:23] <stanreg> Err, let's make this simpler. Imagine I have a {play} function and a {pause} function. When {pause} is executed, it can no longer be executed until {play} is, and vice-versa. So to discriminate and mask accordingly, using only one external interrupt, could one change the trigger conditions on-the-fly and properly execute play/pause according to outside low/high signal?
[11:48:40] <Tom_itx> one button would do both
[11:49:07] <Tom_itx> simple logic in the interrupt would fix it all
[11:52:17] <stanreg> Tom_itx, if I may rephrase: I have a 2-position switch. Let's say Play/Pause. Once either is executed, the uC should go to sleep (save battery), and only the opposite action should awaken it.
[11:54:02] <Tom_itx> interupt on both edges, problem solved
[11:54:39] <twnqx> uhhh
[11:54:39] <Tom_itx> half the 2 position switch wouldn't even need to be wired
[11:54:44] <stanreg> And selectively mask to avoid constant firing, nay?
[11:54:48] <twnqx> interrupt on both edges... nooooo
[11:54:55] <twnqx> don't. you have THREE states
[11:55:03] <twnqx> no button pushed, and either button pushed
[11:55:31] <Tom_itx> I have a 2-position switch.
[11:55:56] <twnqx> momentary or locking is the question
[11:56:00] <stanreg> lock
[11:56:40] <stanreg> likeso:
http://www.superdroidrobots.com/images/TAM-041-000.jpg
[11:56:57] <twnqx> then it might work, though you need deglitch
[11:57:07] <stanreg> deglitch?
[11:57:19] <Tom_itx> debounce
[11:57:29] * stanreg googles
[11:57:50] <stanreg> so a redundancy verification of the int state
[11:58:01] <stanreg> to take appropriate action (pause/play)
[11:58:09] <stanreg> PIN* state, rather.
[11:58:37] <twnqx> i - personally - would go with a 10khz timer interrupt
[11:58:55] <twnqx> sample the pin, if it changed and stays for 10 consecutive samples, assume switch is flipped
[11:58:58] <twnqx> something like that
[11:59:14] <stanreg> but, Tom_itx, if I were to simply enable INTs on both edges, wouldn't I also need to selectively one mask, then the other, to avoid the constant firing after one execution?
[11:59:26] <stanreg> one mask = mask one*
[11:59:31] <twnqx> it is edge triggered, not level triggered
[11:59:37] <stanreg> OUH
[11:59:40] <stanreg> Nice
[11:59:51] <twnqx> or well, programmable, at least for some
[11:59:57] <Tom_itx> just trip a var inside the interrupt
[12:00:28] <stanreg> Edge triggered sounds good. We don't want to awake unnecessarily. Battery!
[12:02:42] <stanreg> twnqx, your 10khz timer interrupt has what advantage over this ext interrupt solution?
[12:02:57] <twnqx> easier deglitch/debounce
[12:03:09] <twnqx> your switch will have a moment when neither position is connected
[12:04:05] <twnqx> but since it's just software... go to your edge triggered solution and check how good it works
[12:04:14] <stanreg> Gotcha :)
[12:04:31] <twnqx> could combine them both, enable timer after an edge detected
[12:04:32] <twnqx> etc
[12:07:36] <stanreg> Would delaying 250ms before sampling pin, within the interrupt, be a sound solution?
[12:10:26] <twnqx> nah
[12:10:41] <twnqx> far too long, or would you want a quarter second delay until your device reacts?
[12:13:34] <stanreg> Quarter a sec delay before reaction is fine; but in terms of deglitch, is this a safe way to do it?
[12:15:05] <twnqx> i could flip the switch more than once in that time :P
[12:15:40] <stanreg> hm, true that
[12:15:55] <tzanger> a quarter second for debounce?
[12:17:21] <stanreg> twnqx, on the other hand, the 'action' that takes place, eg: play, takes itself ~10 seconds to occur ... we're simulating keypresses on a camera to enable vid. recording, so perhaps a quarter sec ain't that bad?
[12:17:36] <stanreg> occur = finish execution.
[12:17:51] <twnqx> still
[12:18:00] <twnqx> don't set bad examples.
[12:18:04] <stanreg> hah
[12:18:20] <stanreg> Fine, what's a good value, in ms?
[12:18:57] <twnqx> figure out what works with your switch
[12:19:34] <stanreg> 'net says 50ms is pretty sound.
[12:42:18] <stanreg_> hmm, looking at the datasheet, there doesn't seem to be an option to enable interrupts on both edges. The closest thing is "Any logical change".
[13:07:36] <megal0maniac_afk> damn freenode being broken ;?
[13:07:38] <megal0maniac_afk> :/
[13:08:39] <Casper> blame script kiddy
[15:51:01] <OndraSter__> so
[15:51:02] <OndraSter__> what can I do
[15:51:04] <OndraSter__> with this?
[15:51:07] <OndraSter__> http://www.ipernity.com/doc/26252/4316824/in/keyword/339593/self
[15:51:20] <OndraSter__> it has got either "VIDEO IN" in coax form
[15:51:29] <OndraSter__> or videotex in in some DIN8
[15:51:37] <OndraSter__> inputs
[15:51:53] <OndraSter__> I have got nearly a whole roll of paper in so I can test it
[15:52:00] <OndraSter__> but.. what kind of input is it?
[15:52:06] <OndraSter__> I can't find a single information about it on the internet
[15:52:39] <OndraSter__> I might just hook up a wavegen to it and try running across frequencies to see if it catches something
[15:52:48] <OndraSter__> it has got 16k*4 DRAMs, 8 of those
[15:53:00] <OndraSter__> no idea how much it is supposed to print
[15:53:02] <OndraSter__> (pixels)
[15:53:33] <OndraSter__> (with 0.7Vpp input to begin with)
[16:02:00] <sabesto> OndraSter__: thermal printer?
[16:10:06] <h4x0riz3d> so how do you read the lock bits via usbasp?
[16:23:24] <beaky> helo
[16:23:54] <beaky> http://ideone.com/y2G0ld how do I improve my code?
[16:24:04] <OndraSter__> sabesto, but with weird inputs
[16:24:04] <OndraSter__> it hasn't got serial :D
[16:24:05] <OndraSter__> obviously
[16:26:27] <sabesto> might be some weird standard
[16:30:17] <OndraSter__> sabesto, well it has got "video in" which is coax and "videotex in" which is 8pin DIN
[16:30:17] <OndraSter__> I can't find a single information about this unit on the internet
[16:30:17] <OndraSter__> I found the chips to be from '86
[16:33:55] <OndraSter__> like I said, I will probably hook up a wave gen to it and see when the stuff will start changing :)
[16:33:58] <OndraSter__> although it might require some timing
[16:33:58] <OndraSter__> dang
[16:34:39] <OndraSter__> (to see where is hsync/vsync etc)
[16:36:18] <sabesto> maybe not related but:
http://hackaday.com/2011/05/22/shoehorning-rs-232-into-a-minitel-terminal/
[16:37:06] <sabesto> probed that videotex on powerup?
[16:39:21] <OndraSter__> probed?
[16:39:24] <OndraSter__> it is input.. :)
[16:40:46] <sabesto> ah, it said IN
[16:41:08] <sabesto> would try anyway
[16:48:56] <OndraSter__> sure I can
[17:01:20] <beaky> how do I upload my code to my machine?
[17:16:24] <Tom_itx> with tty
[18:36:09] <ambro718> when a timer reaches the TOP value and an interrupt is configured for this event, how does the timer proceed? Is there a timer tick corresponding to TOP or not? Can reading TCNT ever result in TOP?
[18:37:12] <jadew`> depends how fast it's going
[18:37:36] <ambro718> well the answer to the first question shouldn't depend on that
[18:37:45] <jadew`> it was for the second one
[18:37:56] <jadew`> the first question is particularly clear
[18:38:14] <ambro718> I mean the second question. Is there a tick for the TOP value?
[18:38:32] <jadew`> what exactly do you mean by that?
[18:38:33] <ambro718> i.e. does timer go TCNT-1 tick TCNT tick 0 tick 1 or TCNT-1 tick 0 tick 1
[18:39:09] <ambro718> s/TCNT/TOP
[18:39:11] <ambro718> lol...
[18:39:49] <jadew`> still doesn't make sense, the counter will change at the "ticks" defined by the prescaller
[18:40:03] <ambro718> yes, that's after the prescaler
[18:40:35] <jadew`> if you're asking if the ISR will be triggered before the counter reaches TOP just so you get to run stuff at the exact moment, no
[18:40:43] <ambro718> so what is it? does TCNT ever reach TOP and keeps that value for tick duration, or does it wrap around before?
[18:41:05] <ambro718> well this is not about the ISR actually.
[18:41:10] <ambro718> just about what TOP means.
[18:41:44] <jadew`> ah, I see what you mean
[18:41:57] <jadew`> you want to know if it's [0, TOP] or [0, TOP)
[18:42:03] <ambro718> yes :)
[18:42:24] <jadew`> well, IIRC TOP is defined as FF in most places, so yeah :)
[18:42:34] <ambro718> huh?
[18:42:44] <jadew`> FF = 255, so it's reachable
[18:42:53] <jadew`> it wouldn't make sense NOT to stay at 255
[18:43:18] <ambro718> so, if TOP=255, the interrupt will happen every 256 ticks, right?
[18:43:25] <jadew`> yes
[18:43:31] <ambro718> okay that makes sense, thanks
[18:43:39] <jadew`> and it wouldn't happen when TOP is 255 for OVF interrupts
[18:43:48] <jadew`> it would happen after the incrementation
[18:43:53] <jadew`> because that's when it overflows
[18:43:58] <jadew`> when it goes from 255 to 0
[18:46:13] <ambro718> now the question about the interrupt: is there a guarantee that the interrupt happens before any other code can see the timer wrap around?
[18:47:09] <ambro718> or could the interrupt happen some time later
[18:47:10] <jadew`> if the interrupts are enabled, yeah, it should happen before any other code
[18:47:20] <jadew`> unless!
[18:47:29] <jadew`> unless another interrupt is running at that time
[18:47:34] <ambro718> yeah, that's what I taught :D
[18:47:45] <ambro718> okay, thanks for the help :)
[18:48:16] <jadew`> np :)
[22:22:43] <ambro718> is that just me being stupid or is there something broken in avr-gcc and uint32_t arithmetic?
[22:24:54] <Valen> as a general rule its you being stupid
[22:25:09] <Valen> generally
[22:37:21] <ambro718> unfortunately it's the compiler that is broken
[22:38:14] <ambro718> uint32_t x = 65526; x += 10; // now, x != 0, even though it should be
[22:53:21] <ambro718> well, I meant to say UINT32_C(65526), but yes, seems broken
[22:54:13] <Casper> ambro718: what do you get?
[22:54:28] <Casper> 65536? if so, the compiler is working fine
[22:54:34] <ambro718> Casper: I don't know yet, but not 0. I'm trying to get serial to work.
[22:54:49] <ambro718> can I check some other way? maybe examine the object file?
[22:55:26] <Casper> uint32 is 32 bits... with an upper limit at 4294967295
[22:55:27] <ambro718> Casper: it's supposed to result in 0, because unsigned integer arithmetic is modular in C, no undefined behavior on "overflow"
[22:55:48] <Casper> you're thinking about uint16
[22:56:08] <ambro718> no, it's like that for all unsigned integers, you can read the C standard if you wish (I have)
[22:56:22] <Casper> read it again, you misunderstood it
[22:56:34] <r00t^home> all integers are 0, even without an overflow occuring? :D
[22:57:40] <Casper> uint8 ... 253 254 255 0 1 .... uint16... 65534 65535 0 1... uint32... 4294967293 4294967294 4294967295 0 1 ...
[22:58:02] <ambro718> hm yes...
[22:58:14] <ambro718> wait, then it's something else broken, lol
[22:58:56] <Casper> all what is broken is your code
[23:07:03] <ambro718> okay, the problem was in another part of the code.
http://ideone.com/jtDfWn
[23:07:09] <ambro718> I don't see any sense in this
[23:07:47] <ambro718> with the broken version, there's also 2k more code in the hex
[23:08:34] <Casper> learn about cast
[23:09:05] <Casper> 1.0 may not cause the compiler to use float
[23:09:18] <ambro718> hmm... so next_time is being converted to float and the addition being done in float, right?
[23:09:34] <ambro718> yes that explains it, thanks
[23:09:50] <Casper> not sure exactly, would need to check more, but I'm too tired
[23:09:58] <Casper> and not enought code, so hard to say
[23:13:25] <ambro718> yeah I just checked C11, x+=y is defined as x=(x+y) except the double evaluation of x and something else
[23:13:59] <ambro718> man, that's just evil...
[23:14:11] <ambro718> any sane person would expect the float would first be converted than added
[23:15:56] <Casper> well, you explicitelly said that your variable is an integer
[23:16:07] <Casper> why would the compiler work with float then?
[23:21:55] <ambro718> Casper: I was adding a float to an integer, and x+=y is defined as x=(x+y) as far as types and conversions are concerned
[23:22:15] <ambro718> and when you add a float and an integer, the integer is converted to a float then the addition is done in floats
[23:22:35] <ambro718> which messed up my uint32_t I was adding to due
[23:24:39] <Casper> next_time += (float)(1.0 / (1.0 / (F_CPU / 1024))); ← that probably work
[23:25:18] <ambro718> Casper: no, it doesn't lol. You need to cast it to uint32_t not float
[23:25:42] <ambro718> Casper: that was the whole problem that the right operand was float, this caused the uint32_t on the left to be converted to float and lose bits
[23:25:44] <Casper> if you cast to uint32_t then it will do it as an integer
[23:25:56] <ambro718> which is what you probably need :)
[23:26:12] <Casper> if you want the math to work, you need to do the math as float
[23:26:37] <ambro718> Casper: consider that it is not possible to represent the entire uint32_t range in a float
[23:26:41] <Casper> btw, if you want to round the number, add 0.5
[23:27:04] <Casper> you might then need to use the other, bigger float, that I forgot how it's named :D
