Back
[01:58:35] <l9> is it just me or are aqariums awsome?
[05:08:58] <malinus> Would it be durable to connect a uC to the ethernet and make your own TCP/IP stacks? Like without any IC's or anything. I think an atmega should be able to handle it, right?
[05:10:57] <twnqx> depends
[05:11:18] <twnqx> if you can live with major limitations and not fully implementing the protocoll - yes
[05:11:35] <twnqx> i can't quite see how a mega could handle a segmented 64kB tcp packet :P
[05:11:57] <blathijs> malinus: I think NooM in #arduino made his own TCP/IP stack for the enc28jsomething chip
[05:12:37] <malinus> blathijs, yeah that is pretty durable. I just wish to know if anyone ever made it for a 8-bit uC.
[05:12:48] <blathijs> malinus: And every library for that chip will have a TCP/IP stack, since the chip isn't doing any protocols
[05:12:49] <malinus> blathijs, I'm gonna ask him some questions though :)
[05:13:25] <malinus> twnqx, I don't even need any prococolls. I just want to be able to do some simple "raw sockets" :)
[05:13:35] <twnqx> you said tcp/ip...
[05:13:43] <twnqx> but yes, you can do that
[05:14:04] <twnqx> i have some 8port telnetable power outlet that uses a Z80 :P
[05:14:51] <blathijs> malinus: But are you interested in the TCP/IP stack, or do you want to do the physicial layer using bitbanging without any PHY chip?
[05:15:31] <malinus> blathijs, I want to do the physical layer, that's where my interest is. Everything else can be done from my desktop anyway.
[05:16:23] <twnqx> forget it
[05:16:33] <twnqx> that's too much analog magic
[05:16:49] <malinus> twnqx, really? I've done usb, spi and uart. how bad can it be :)?
[05:17:10] <twnqx> it is analog
[05:17:17] <twnqx> differential line signalling
[05:17:44] <twnqx> so ok, you could go with some opamp driven stuff for levels
[05:18:06] <twnqx> no idea how the sampling points lie
[05:18:24] <malinus> yeah okay. I didn't even consider that this would actually be the biggest issue. urgh:
https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair
[05:18:26] <twnqx> and how fast it has to be, iirc it uses some 8b/10b NRZI
[05:19:35] <twnqx> you could maybe get away with BNC cabling and implementing CSMA/CD :P
[05:20:51] <blathijs> malinus: So then you're not really interested in TCP/IP at all, more ethernet :-)
[05:24:03] <malinus> blathijs, it's just the naming. I assumed that TCP/IP = internet protocol suite , which ethernet is a part of :)
[05:25:11] <twnqx> it is not
[05:25:30] * twnqx started ethernet with IPX exclusively
[05:27:23] <twnqx> also, all layers are interchangeable, you can have TCP/IP without ethernet as well as ethernet without TCP/IP :P
[05:28:27] <malinus> that is true. In my definitions the ethernet is still a (or rather - can be) part of the link layer of the internet though.
[05:28:38] <malinus> not sure if that is right though !
[05:28:55] <blathijs> malinus: I know, but naming things (especially in questions) is important, so I like to point out errors to prevent future misunderstanding :-)
[05:29:21] <twnqx> it is not
[05:29:33] <blathijs> malinus: I think most of the core of the internet doesn't actually use ethernet
[05:29:33] <twnqx> if ethernet was that relevant, dial-up wouldn't have worked
[05:30:00] <twnqx> in the early days you would have E1/T1, E3/T3, OC3/STM! etc all without ethernet in the core
[05:30:07] <twnqx> OC3/STM1*
[05:30:39] <twnqx> or ATM. to the desktop, even, instead of ethernet
[05:30:55] <twnqx> luckily that died.
[05:31:06] <malinus> blathijs, twnqx I know that ethernet is only one of many possible link-layers (DSL is another one), but it still is in the link-layer of the internet. But I guess your point is, that ethernet doesn't necessary have to be part of the internet and the other way too.
[05:31:32] <malinus> or what?
[05:31:37] <twnqx> exactly. all layers of te ISO/ISO are interchangeable.
[05:31:54] <twnqx> you can replace IP with IPV6 or even IPX or appletalk
[05:32:21] <twnqx> UDP/TCP as layer 4 protocols are barely the most commonly known, not the only ones
[05:32:43] <malinus> I guess it was just my wording, that made it sound like ethernet was THE link layer, while it's only one of many possibilities.
[05:32:46] <twnqx> ethernet is one of the many layer 2
[05:33:17] <malinus> twnqx, but UDP/TCP is still like idk. 99% of all internet?
[05:33:23] <twnqx> does that matter?
[05:33:55] <malinus> well only in the sense what one would probably prefer when choosing the trasport protocol ?
[05:33:56] <twnqx> and probably more like 95 or so
[05:34:33] <twnqx> choice of l4 protocol only depends on requirements like reliability and latency
[05:34:40] <blathijs> malinus: My point wasn't that there's also DSL and dialup etc. but that I think a large portion (perhaps the largest) of the internet backbones don't run ethernet, but things like ATM :-)
[05:34:57] <twnqx> ATM is dead, for good
[05:35:19] <OndraSter_> is it?
[05:35:23] <OndraSter_> I use atm... sometimes
[05:35:42] <twnqx> the majority of core lines runs 10gbit ethernet wdm as layer 0.5 or so these days
[05:36:13] <twnqx> (in the western word, still SDH in many others)
[05:36:16] <twnqx> world*
[05:36:43] <malinus> okay, just to clear it up for the noob: what comes out of my home-router is ethernet though, right?
[05:37:03] <twnqx> most likely
[05:37:16] <twnqx> OndraSter_: ok, so sometimes ATM is undead :P
[05:38:58] <OndraSter_> do we both mean the winning lotery machine? (You enter your PIN, hope that it is correct and if it is, you get money)
[05:39:49] <twnqx> lol
[05:40:20] <OndraSter_> and on that bombshell, it is time to go to school. "Automata and gramatics"
[05:40:35] <twnqx> gah
[05:40:42] <twnqx> you remind me that i watch too much top gear
[05:40:46] <OndraSter_> :D
[05:40:47] <malinus> heh exactly
[07:53:34] <zump> What's the deal with qtouch? atmega32u4 says no HW qtouch, but the user guide has lists libraries for it. possible or not?
[08:39:38] <theBear> generally if something is supported in hardware you don't need a library for it, you just set a couple bits the right way, like turning on pwm or using a usart, and what's a qtouch ?
[08:39:45] <theBear> dammit, get gone, now i'll never know !
[08:40:20] <theBear> i mean, maybe in arduino land where you got libs for writing a byte to a port, but not in the real world :)
[08:43:46] <megal0maniac_afk> theBear: Not sure if you saw, but the DNS funniness was due to /tmp filling up >.<
[08:48:40] <theBear> yeah, supergay dlna hehe that rhymes
[09:06:27] <megal0maniac_afk> Yeah, stupid server.
[09:58:13] <kdehl> Has anyone of you guys tried those cheap Bulgarian 6502 clones?
[09:58:19] <kdehl> CM630P.
[09:59:02] <kdehl> I just ordered two, and they're claimed to work well.
[10:40:03] <beaky> hello
[10:40:13] <beaky> i am controlling multiple switches with my avr
[10:40:28] <carabia> good for you
[10:40:32] <beaky> with my avr's pwm. howd o i make sure that if both my pwms have the same duty cycle they stay on for the same periods?
[10:40:38] <beaky> like in sync?
[10:40:48] <beaky> and not go out of phase
[10:42:31] <l9> why have pwms in two diffrent avrs?
[10:43:17] <beaky> one avr
[10:43:34] <beaky> the attiny
[10:43:54] <l9> by code
[10:46:49] <l9> new too avrs?
[10:48:50] <l9> abcminiuser: could pwm channels on a attiny ever get out of sync by counting the ticks on the internal clock?
[10:50:36] <abcminiuser> Youwah?
[10:50:46] <abcminiuser> As in you're manually adjusting multiple channels?
[10:50:55] <abcminiuser> Could be a sync delay if the timer is asynchronous
[10:52:09] <l9> but normally pwm channels are in sync right?
[10:53:42] <beaky> yes i am manually adjusting pwms in code
[10:53:58] <beaky> for a mission critical real time embedded application
[10:54:14] <beaky> if they go out of sync things there might be short
[10:55:00] <l9> :) good too see you again abcminiuser :) gtg
[10:55:22] <abcminiuser> Yes, hardware will stay in sync
[10:55:25] <abcminiuser> Cheers :)
[10:55:31] <abcminiuser> But manual adjustment might cause issues
[10:55:43] <beaky> ah
[11:09:18] <mdorenka> is there something like ticks() on the AVR processors?
[11:09:29] <mdorenka> something that tells me how long the MCU is runnung?
[11:09:35] <mdorenka> or do i have to implement that by hand?
[11:10:26] <theBear> err, ticks is just an abstraction of a timer
[11:16:49] <mdorenka> ok so i have to use a timer that increases a variable on overflow?
[11:18:02] <kdehl> I'm planning to make a VGA signal generator with an AVR, is it very important that the resistors have low tolerance?
[11:18:13] <megal0maniac_afk> Yip. You can also use a prescalar, or compare match instead of overflow for varying degrees of accuracy
[11:18:33] <kdehl> Um. I just realized that it just affects the colors, not the functionality. Rubberducking ftw.
[11:18:43] <kdehl> Or am I wrong?
[11:18:46] <megal0maniac_afk> kdehl: Even 10% resistors can be within 1% of their rated value. It's a manufacturer tolerance, not an operation one
[11:19:08] <kdehl> Yeah.
[11:19:19] <megal0maniac_afk> *operational
[11:19:58] <kdehl> I could always measure them too, and take the most exact ones I find.
[11:20:18] <kdehl> I was just thinking whether I should buy some super-low tolerance resistors before I embark on this project.
[11:20:33] <kdehl> Screw it. If blue becomes a little red, so what. Heh.
[11:21:23] <megal0maniac_afk> If you're doing it like this:
http://quinndunki.com/blondihacks/wp-content/uploads/2012/03/VGASignal_Sch.jpg
[11:21:45] <kdehl> Another question thouigh: the timing is very important, they say. Do I have to use an external clock source too?
[11:21:46] <megal0maniac_afk> Then it's just a ratio. You can measure them and pair ones with similar error %
[11:22:03] <megal0maniac_afk> kdehl: Definitely
[11:22:06] <kdehl> Rubber ducking again, the internal clock is 8 MHz, which is not enough anyway.
[11:22:10] <kdehl> Okay.
[11:22:29] <kdehl> megal0maniac_afk: And yeah, that's pretty much the way I indent to do it.
[11:22:35] <kdehl> http://operationalsmoke.blogspot.se/2013/03/experimenting-with-avr-micros-and-vga.html
[11:22:38] <megal0maniac_afk> I recommend the mega644p. It takes well to overclocking
[11:22:56] <megal0maniac_afk> Since most implementations ask for a ~25mhz clock
[11:22:59] <kdehl> I have a bunch of 1284ps though. I think I'll try with those first.
[11:23:29] <megal0maniac_afk> Should work fine, but some people have had issues.
[11:24:31] <kdehl> Okay, that's good to know.
[11:26:00] <N2TOH> kdehl, Linger tech makes some nice programable oscillators that work via i2c or SPI
[11:26:34] <kdehl> N2TOH: Now that sounds nice!
[11:26:55] <kdehl> Damn, I'm on such a bad connection here (on a train), I can barely use a web browser.
[11:27:09] <megal0maniac_afk> kdehl: Ah, my bad. The mega644 non-p version. The uzebox uses one at 28.61818mhz and they reported problems with UART on the p version
[11:27:47] <kdehl> megal0maniac_afk: Noted!
[11:28:03] <N2TOH> http://www.linear.com/product/LTC6903
[11:29:28] <kdehl> N2TOH: Can yuo get those cheap off ebay?
[11:30:23] <N2TOH> IDK, I ordered samples
[11:31:50] <kdehl> Heh.
[11:32:08] <N2TOH> now you can pick any speed you want
[11:32:27] <N2TOH> I would store the speed in the eeprom
[11:32:55] <kdehl> That is really awesome.
[11:33:11] <N2TOH> it might get interesting when the compiler can handle speed changes while running the code
[11:34:51] <kdehl> That guy uses a timer interrupt each VSYNC and does everything in there. That sounds insane to me, isn't it better to time HSYNC, otherwise you'll be in an interrupt like 90 % of the time...
[11:35:04] <kdehl> https://docs.google.com/file/d/0B0xy5kkwitunTmpxVjZfY2Jtd00/edit?usp=sharing
[11:35:32] <megal0maniac_afk> My understanding is that HSYNC would fire 90% of the time
[11:36:48] * megal0maniac_afk should look into this
[11:37:42] <megal0maniac_afk> I was asked about making on-air lights for studios using a cheap flat panel display and a uC. To display a green screen or red screen, and maybe a logo, wouldn't be too tasking for a mega328
[11:38:28] <kdehl> No, I must have gotten it wrong. The interrupt is fired once every 32 µs. That's gotta be HSYNC...
[11:38:38] <kdehl> Otherwise you'd have a refresh rate of 31250 Hz. Heh.
[11:39:05] <kdehl> Not likely.
[11:41:32] <megal0maniac_afk> Could use an xmega and drive video signal with the event system. :)
[11:42:52] <kdehl> Heh.
[11:43:24] <kdehl> I wonder how a 286 CPU would compare to a 1284. Would I be able to make higher a VGA resolution?
[11:43:44] <kdehl> Probably not, they're usually less than 20 MHz.
[11:43:52] <specing> but they are 16-bit
[11:44:11] <kdehl> Hm.
[11:44:19] <kdehl> I might get higher color resolution then.
[11:44:21] <specing> Well
[11:44:24] <megal0maniac_afk> Wow...
[11:44:33] <kdehl> But could I actually increase the pixel count?
[11:44:34] <specing> Take a Cortex-M4
[11:44:47] <specing> cortex-m4 can go up to 100MHz
[11:44:55] <megal0maniac_afk> xmega can do 4nS resolution PWM
[11:45:41] <kdehl> Nah, 1284p should be sufficient for anyone.
[11:45:50] <kdehl> And anything.
[11:46:01] <megal0maniac_afk> Thats 128mhz pwm
[11:46:13] <kdehl> Heh. Nice.
[11:46:28] <Tom_itx> hopefully not for motor pwm
[11:46:35] <Tom_itx> would fry it
[11:47:05] * Tom_itx just walked in
[11:47:38] <megal0maniac_afk> I think I'll use that
[11:48:06] <megal0maniac_afk> It's also almost 1/4 the price of 1284. Although only 32kb flash
[11:48:19] <megal0maniac_afk> Tom_itx: We're talking VGA
[11:48:49] <megal0maniac_afk> And now I'm considering taking the multitude of examples of VGA on megas, and moving it to xmega, using the event system
[11:49:15] <N2TOH> how much s/RAM in the M4?
[11:49:28] <megal0maniac_afk> M4?
[11:49:33] <megal0maniac_afk> Oh, cortex
[11:49:34] * kdehl gotta get off the train.
[11:55:09] <megal0maniac_afk> OndraSter: VGA signal generation using xmega PWM, relying heavily on the event system. 3 static images. Doable?
[11:55:25] <Tom_itx> why not?
[11:55:42] <megal0maniac_afk> Well it's mainly a question of using the event system
[11:56:01] <Tom_itx> it's far mor flexible than the other 8bit avrs
[11:56:33] <Tom_itx> once you get a handle on it
[11:57:09] <megal0maniac_afk> I'm almost certain that a red and green screen will be cake to display. Not sure if you can do an image without CPU control
[11:58:13] <megal0maniac_afk> The main issue with megas and VGA is the clock speed, and the fact that you use most of the CPU cycles on generating the signal. Not much room for anything else
[11:58:39] <megal0maniac_afk> OndraSter is supposed to know, though :P
[11:59:14] <N2TOH> what about vector displays?
[12:00:50] <megal0maniac_afk> N2TOH: Well we'd be using cheap LCD flat panels
[12:08:08] <beaky> http://www.atmel.com/images/doc2558.pdf
[12:08:25] <beaky> is this a good way to implement pid
[12:10:58] <megal0maniac_afk> beaky: One thing at a time
[12:11:19] <megal0maniac_afk> Have you completed 300 projects already or are you jumping all over the place?
[12:11:38] <beaky> i still havent done anything
[12:11:42] <megal0maniac_afk> And it's an Atmel appnote. So it's a good way of doing things
[12:11:56] <megal0maniac_afk> beaky: Settle down and DO something
[12:15:51] <Tom_itx> megal0maniac_afk, i thought xmegas had pll driven clocks
[12:17:03] <megal0maniac_afk> Tom_itx: They do. There's a 2mhz base clock and PLL (DFLL?) multiplier
[12:17:24] <Tom_itx> so how fast can you clock them?
[12:18:03] <megal0maniac_afk> Spec says 32mhz. OndraSter had it blinking LEDs at 80mhz. And the high resolution extension (which can drive PWM) can run at core x4
[12:18:26] <megal0maniac_afk> Peripherals probably wouldn't hold up at 80. And USB definitely wouldn't like it
[12:18:36] <megal0maniac_afk> But no fire :)
[12:25:38] <beaky> what is a PLL? my attiny seems to have it
[12:26:16] <beaky> the attiny has lots of stuff not on the mega328p :D
[12:27:46] <N1njaneer> http://en.wikipedia.org/wiki/PLL
[12:28:28] <beaky> so it basically doubles my clockspeed
[12:28:35] <beaky> wow that is awesome
[12:29:56] <antto> i got a peice of code related to setting up a timer with variable period (used as a tempo) .. the code originates from atmega162, but when it runs on atmega2561 - it breaks when it goes half way
[12:32:50] <beaky> why doesn't the ATmega328p have a pll
[12:32:58] <beaky> while the attiny85 does
[12:33:02] <antto> i mean, it originally goes as low as 20 beats per minute, but when running the same code on the 2561 - it can't go lower than ~40, the timer stops happening or something
[12:46:28] <beaky> how do i reset the firmwrae on my avr dragon
[12:50:30] <RikusW> reset it ???
[12:50:36] <RikusW> do you mean upgrade ?
[12:50:39] <bss36504> Why do you need to do that?
[12:50:50] <bss36504> It upgrades automatically
[12:50:58] <RikusW> can that even be done ?...
[12:50:59] <bss36504> in Atmel studio at least.
[12:51:08] <RikusW> or downgrades too
[12:51:21] <RikusW> unless you have my special AS4 hack that allows wrong version fw
[12:51:31] <bss36504> There *might* be a manual upgrade option, but not like a re-flash option or anything
[12:51:34] <RikusW> and it appears to work
[12:51:39] <beaky> i think my dragon's firmware is buggy
[12:51:52] <beaky> becasue it runs slower than my avr isp
[12:51:58] <RikusW> why ?
[12:52:05] <bss36504> of course it's buggy, its the dragon AMIRIGHT guys?
[12:52:09] <RikusW> it is indeed slower
[12:52:12] <beaky> maybe because i am pluging it to usb and its drawing too much current?
[12:52:18] <bss36504> no
[12:52:33] <beaky> but it used to be way faster
[12:52:34] <RikusW> no bugs, its a cheap programmer from atmel
[12:52:42] <RikusW> blame studio
[12:52:47] <beaky> but my avr ispmkii is cheaper and also 10x faster
[12:53:00] <RikusW> mkii clone ?
[12:53:07] <beaky> actual one
[12:53:18] <beaky> it came in a box with a robot picture and AVR logo
[12:53:35] <beaky> it is the real deal :D
[12:53:41] <RikusW> even the lufa clone is faster
[12:53:50] <RikusW> why get 'n dragon and mkii ?
[12:54:20] <abcminiuser> RikusW, ouch
[12:56:09] <beaky> i got the mkii but i couldn't get it to program, so i got the dragon and got it working, but then i found out my mkii was working all along
[12:56:09] <beaky> lufa clone?
[12:56:09] <bss36504> beaky: Well for one, the mkii is cheaper because it's not a debugger as well.
[12:56:09] <beaky> maybe debuging comes in handy/''
[12:56:09] <beaky> also high voltage programing when i inevitably brick my chips
[12:56:09] <RikusW> abcminiuser's LUFA mkii clone that runs on USB AVR
[12:56:09] <beaky> wow
[12:56:09] <RikusW> beaky:
https://sites.google.com/site/megau2s/
[12:56:09] <bss36504> RikusW: I was just taking a jab at the Dragon, I didnt mean it though :P
[12:56:11] <RikusW> I do have a dragon too (still working fine too)
[12:56:17] <beaky> the dragon is not bad
[12:56:32] <RikusW> I built my own STK500 clone
[12:56:44] <beaky> wow how do i make one
[12:56:45] <RikusW> and then JTAGICE mki clone too, including debugging
[12:57:03] <beaky> isn't it illegal to build clones maybe atmel might sue
[12:57:10] <RikusW> no idea :-P
[12:57:20] <RikusW> beaky: the jtag is open source
[12:57:23] <megal0maniac_afk> I think abcminiuser would know by now :P
[12:57:26] <beaky> wow didnt know
[12:57:30] <RikusW> you can load it onto any avr
[12:57:36] <RikusW> *my jtag...
[12:57:50] <megal0maniac_afk> And debug any one of 5 very old devices :P
[12:57:51] <RikusW> even serial only ones too
[12:58:02] <RikusW> or hack AS4 or avarice
[12:58:13] <RikusW> it does work on new AVRs unlike the original
[12:58:18] <megal0maniac_afk> At least avarice is open source
[12:58:20] <beaky> only old ars use jtag?
[12:58:22] <bss36504> heck, even an arduino can act sort of like a mkii
[12:58:44] <RikusW> beaky: there is a slight difference in programming protocol between old and new
[12:58:52] <abcminiuser> It's a clean-room implementation, so there's no firmware infringement
[12:58:56] <megal0maniac_afk> bss36504: Are you talking about the "Arduino as ISP" sketch?
[12:58:59] <abcminiuser> I haven't seen the official tool code
[12:59:00] <RikusW> there is like 6 or 7 old ones...
[12:59:10] <abcminiuser> The protocol is open, so there's no issue
[12:59:17] <beaky> ah
[12:59:46] <RikusW> megal0maniac_afk: time to hook up the salea to PDI debug :-P
[12:59:56] <RikusW> its just synchronous serial
[13:00:07] <bss36504> megal0maniac_afk: yes, but I get that it's solely designed to load the bootloader onto another mcu
[13:00:22] <bss36504> hence the "kind of" part
[13:00:30] <megal0maniac_afk> bss36504: Well if you're using a 32u4 based Arduino, then you get get a very nice implementation :)
[13:00:52] <RikusW> megal0maniac_afk: where ? as part of Arduino ?
[13:01:20] <megal0maniac_afk> RikusW: Yeah, there's a sketch which turns your Arduino into an ISP programmer, using some obscure protocol iirc
[13:01:24] <bss36504> megal0maniac_afk: I have not played with the leonardo enough to know.
[13:01:34] <RikusW> that failed on my U2S port...
[13:01:45] <megal0maniac_afk> RikusW: yeah, it's icky.
[13:01:51] <RikusW> the ISP sketch just wouldn't work
[13:02:30] <megal0maniac_afk> bss36504: There are STK500 programmer implementations that run on the mega328, so there are better ways to do it
[13:03:07] <megal0maniac_afk> Heck, you can have a mega328 with an LCD screen and a full menu interface read .hex files from an SD card and program devices without even using a computer
[13:03:41] <megal0maniac_afk> bss36504:
http://mdiy.pl/uprog-maly-szybki-przenosny-programator-avr-z-sd/?lang=en
[13:03:59] <bss36504> yes, but an STK500 costs a shit ton more than an arduino. Besides, I'll stick with my JTAGICE3, I was just pointing out another alternative for beaky.
[13:04:02] <megal0maniac_afk> Technically, you could implement that on an Arduino. Although you wouldn't use the IDE at all ;)
[13:04:26] <l9> Tom_itx has a good programmer :P haha
[13:05:11] <RikusW> Tom's is the LUFA clone
[13:05:33] <megal0maniac_afk> Except the hardware is purpose built to be a programmer
[13:05:39] <RikusW> I even loaded it onto my U2S boards to play around with PDI/TPI
[13:08:50] <redacting> I am trying to run the bi-directional DC motors on the
http://learn.adafruit.com/adafruit-motor-shield/ using assembly but I am lost on sending a single 0bit or 1bit. Does anyone know of a tutorial for programming the motor shield in assembly?
[13:10:03] <N1njaneer> That is more an Arduino-specific question for that shielf, you may want to try in #arduino, unless you want to do it from a lower-redatcing: level with the standard Atmel AVR peripherals
[13:10:07] <RikusW> redacting: you mean turning on or off a bit on a port ?
[13:10:13] <N1njaneer> Er sorry, type-o
[13:10:26] <N1njaneer> redatcing: That is more an Arduino-specific question for that shielf, you may want to try in #arduino, unless you want to do it from a lower-level with the standard Atmel AVR peripherals
[13:10:31] <redacting> They sent me here
[13:10:34] <N1njaneer> God I can't type today XD
[13:10:52] <N1njaneer> redacting: Ahh crap, you pressed 3 for AVR support :)
[13:10:59] <redacting> I did!
[13:11:08] <redacting> But I forgot 1 for English
[13:11:21] <megal0maniac_afk> BURN
[13:11:23] <N1njaneer> Do you have the schematic for the shield to know what PORT pins you need to turn on/off?
[13:11:40] <N1njaneer> Arduino has macros for setting up and toggling pins, or you can just use the direct AVR methods.
[13:11:50] <redacting> I know it's PORTB and PORTD
[13:12:08] <RikusW> http://tom-itx.dyndns.org:81/~webpage/
[13:12:22] <RikusW> there should a guide on bit manipulation
[13:12:29] <N1njaneer> In essence there are three registers associated with any ports -- DDRx, OUTx, and PINx -- direction, output, and input respectively
[13:12:35] <megal0maniac_afk> http://tom-itx.dyndns.org:81/~webpage/avr/c_bits/bits_index.php
[13:12:55] <N1njaneer> And yeah, those two links so I don't have to type out too much and can eat my lunch XD
[13:13:02] <redacting> http://pastebin.com/5jKJDmqr Lines 82-104 is what I'm having issues with
[13:13:10] * redacting looks
[13:14:05] <N1njaneer> Beaky: Did you let the smoke out yet today? :)
[13:14:15] <megal0maniac_afk> Ooh, RikusW you're up :P
[13:14:19] <megal0maniac_afk> AVR ASM
[13:14:33] <RikusW> C should suffice ;)
[13:14:49] <megal0maniac_afk> RikusW: No, the pastebin link is ASM
[13:15:06] <redacting> I wish, class homework; hence asking for a tutorial and not the answer :p
[13:15:45] <RikusW> DDIRD ??
[13:15:48] <RikusW> DDRD ....
[13:16:36] <N1njaneer> DDDOITYOURSELF
[13:17:02] <N1njaneer> Er DDIY is what I meant :D
[13:17:03] <megal0maniac_afk> N1njaneer: They give beaky too much homework
[13:18:12] <redacting> Not too much, they just don't tell us what we need to know to finish it
[13:18:30] <N1njaneer> megal0maniac_afk: Oh, did they want him to port Linux to an ATTINY again?
[13:19:57] <bss36504> whats the max sink current on a pin?
[13:20:07] <megal0maniac_afk> daaaaaaaaaaaatasheeeeeeeeet
[13:20:19] <megal0maniac_afk> 40mA I think, 200mA per port max
[13:20:23] <bss36504> im opening it, yeesh, just looking ro a quick answer.
[13:20:28] <bss36504> for*
[13:20:28] <megal0maniac_afk> :)
[13:20:36] <RikusW> 200mA combined
[13:20:50] <N1njaneer> megal0maniac_afk: Sounds about right, though I think it's a bit lower per port.
[13:20:52] <RikusW> or rather 200mA for Vcc
[13:21:14] <megal0maniac_afk> I think sink/source are the same
[13:21:18] <bss36504> Well that should be plenty, thanks for the quick info, rather than making me scroll all the way to the electrical specs
[13:22:20] <N1njaneer> bss36504: Use the ToC for ninja-like fast access to Information You Need Now!
[13:22:38] <megal0maniac_afk> N1njaneer: My brain has that
[13:22:46] <megal0maniac_afk> Except the info is often wrong
[13:22:50] <megal0maniac_afk> Or not there
[13:22:58] <bss36504> my ToC has null pointers...
[13:23:03] <N1njaneer> megal0maniac_afk: I wish my brain had a DMA peripheral honestly.
[13:23:04] <bss36504> my brain-ToC that is
[13:23:18] <N1njaneer> Though sometimes there is DMA from my subconscious right to my mouth, and I talk a lot
[13:23:43] <RikusW> lol
[13:25:08] <N1njaneer> Man, I have 100 fresh CR2032 3v batteries here. I wonder if I could stack them all up in a coin wrapper and make a C-size looking battery that has enough voltage to shock you XD
[13:25:34] <RikusW> 30 to 50 V maybe ?...
[13:25:36] <megal0maniac_afk> Given the price of those, I wouldn't recommend it
[13:25:57] <RikusW> have any of you seen the super 9V stack on youtube ? :-)
[13:26:04] <RikusW> probably 200 or so....
[13:26:07] <RikusW> and sparks
[13:26:08] <megal0maniac_afk> Otherwise high freq osc, like a camera flash
[13:26:24] <N1njaneer> megal0maniac_afk: In the quantities I buy them they're quite inexpensive. :)
[13:26:41] <megal0maniac_afk> Or a 3rpm 220VAC motor, and turn it
[13:26:48] <megal0maniac_afk> From a microwave
[13:27:14] <N1njaneer> megal0maniac_afk: From DigiKey they're .28 each, dropping to .1925 at qty 100
[13:27:18] <N1njaneer> DO NOT BUY FROM STORE
[13:27:26] <N1njaneer> OMG they charge like $4 each
[13:27:39] <megal0maniac_afk> Yeah, I've paid ~$2 before
[13:27:55] <N1njaneer> RikusW: We did that many years ago, actually, and lit some 120V lamps.
[13:28:16] <megal0maniac_afk> Okay okay, maths time. No more procrastination
[13:28:18] <megal0maniac_afk> Bye
[13:28:55] <megal0maniac_afk> (If my nick is megal0maniac_afk and I'm being active, you know it's procrastination :)
[13:28:58] <N1njaneer> RikusW: We had them in wireless microphones, and we'd always yank the batteries as soon as you get a LOW light since you can't have them dying during shows. So you'd wind up with a HUGE box of half-dead ones
[13:29:17] <RikusW> heh
[13:29:26] <megal0maniac_afk> N1njaneer: That's why we use beta58s in shows :D
[13:29:28] <RikusW> and you could resist...
[13:29:43] <megal0maniac_afk> (wired)
[13:31:02] <RikusW> +n't
[13:53:52] <antto> changing the timer prescaler causes some sort of a glitch?
[13:53:59] <antto> TCCR3B
[13:54:29] <bss36504> What part? What type of glitch?
[13:54:41] <antto> like a delay
[13:55:25] <abcminiuser> RikusW, have you tested my programmer on an XMEGA?
[13:56:04] <bss36504> antto: I think it doesn't lock in the new prescaler until the next system clock edge, so maybe you'd see a tiny glitch there..
[13:57:03] <antto> system clock <- do you mean the clock at which the whole mcu runs at?
[13:57:59] <bss36504> yeah
[13:58:09] <antto> then i guess not
[13:58:21] <antto> i'm talking about a glitch which i'm able to perceive
[13:58:36] <bss36504> since Fcpu (system clock) feeds both the prescaler input and the logic that controls it, it could only ever sync to that, but like I said, tiny glitch.
[13:58:49] <bss36504> can you by chance show a scope capture of the glitch?
[13:58:58] <bss36504> and what mcu are you using?
[13:59:00] <antto> no, don't have a scope
[13:59:05] <antto> atmega2561
[13:59:11] <bss36504> so how do you know there is a glitch?
[13:59:30] <bss36504> Oh wait, you're wondering if there is one at all, not why you have one.
[13:59:33] <antto> the code is using timer3 to generate a tempo clock
[14:00:01] <antto> for a musical instrument
[14:00:19] <antto> the tempo is adjustable
[14:00:21] <bss36504> Oh, well max glitch would be one Fcpu clock, so it will be basically unnoticeable without a scope, and even then, it would be hard to pin down.
[14:00:39] <bss36504> you should be just fine.
[14:01:00] <antto> when the tempo is above 38 - the code happens to always use prescaler /8
[14:01:24] <antto> and then, changing the tempo is smooth
[14:01:46] <bss36504> right, but the point here is, even IF there is a glitch, there is probably no more or less overall jitter in the signal than when the pwm is running freely
[14:01:54] <antto> but from 38 and slower - the code falls into another case where it was originally using prescaler /16
[14:02:50] <antto> but that didn't work on the 2561 since it turns out it doesn't have /16 and /32 prescalers (the code was originally written for atmega162 which does have them)
[14:02:58] <antto> i commented out those two cases
[14:03:26] <antto> so now, the code for 38 and lower falls into the case with prescaler /64, which is present on the 2561
[14:03:51] <bss36504> it would depend on your fcpu frequency, the width of your counter, and the prescalers available. you may have to tweak the code to work better.
[14:03:56] <antto> but there is a short audiable glitch in the first moment when it switches to that
[14:04:15] <N1njaneer> antto: What kind of bpm rate do you need to vary it over?
[14:04:18] <antto> short == 1 second roughly
[14:04:32] <antto> N1njaneer 20 to 300 BPM
[14:04:45] <antto> it was possible on the 162
[14:05:06] <N1njaneer> antto: Kind of taking a random stab here as I was reading over your application here, but another way you can approach it is to keep the timer fixed at a rate and generate the event yourself on a second counter
[14:05:09] <bss36504> 2561 is a heck of an upgrade from a 162.
[14:06:04] <bss36504> N1njaneer: I would think some sort of real time interrupt would work well (unless thats what you said, in which case we are on the same page :) )
[14:06:22] <antto> the thing uses interrupt
[14:06:25] <N1njaneer> For instance, set the timer to interrupt/tick every millisecond, then vary the final tick as a function of x number of milliseconds elapsed, etc. That way you are only changing the single varible that the ticks are compared to, rather than mucking with the counter directly.
[14:06:40] <bss36504> yes, that ^
[14:06:59] <antto> that won't be precise for faster tempos
[14:07:18] <N1njaneer> Then increase granularity of the tick interrupt.
[14:07:26] <N1njaneer> For 300bpm, that is one tick every 200ms
[14:07:40] <antto> i thought that was why they chose to use a timer in the first place
[14:07:48] <N1njaneer> For 20 bpm that is one tick every 3000ms
[14:07:50] <antto> N1njaneer there is a small detail
[14:08:04] <bss36504> Think of how fast a single clock cycle is? Like ns. You can do literally millions of things in 1 second, I dont think incrementing a variable will produce any noticeable drift.
[14:08:05] <antto> the bpm is divided into 48 then
[14:09:23] <N1njaneer> You need to subdivide the bpm rate by a factor of 48 more?
[14:09:40] <bss36504> I don't think having a RTI at 1ms with some sort of stored variable being incremented will produce any noticeable glitches or drifting.
[14:10:23] <N1njaneer> bss: No it won't, because the hardware settings are constant at that point. You are effectively producing kind of a software PWM at that point that you can smoothly vary :)
[14:10:35] <N1njaneer> Start with the resolution you need to obtain in timing and rate and work it up from there
[14:10:54] <N1njaneer> brb - Arrow FAE with goodies
[14:11:28] <bss36504> exactly my thoughts.
[14:11:36] <antto> http://codepad.org/HyHiw4w8
[14:11:43] <antto> this is the function
[14:12:00] <antto> i've commented-out the two prescalers which are not available in the 2561
[14:13:00] <bss36504> Right, but this uses (I assume, since i dont have the init code for the timer) an output compare channel to create a really large period PWM. Instead, use a constant 1ms real-time interrup routine that does the output toggling in software.
[14:14:43] <antto> SIGNAL(SIG_OVERFLOW3) { TCNT3 = timer3_init2; timer3_init2 = timer3_init; }
[14:15:11] <antto> oh, i think i see what could be a problem there
[14:15:12] <megal0maniac_afk> abcminiuser: Why do you ask?
[14:15:14] <antto> lemme try something
[14:17:12] <bss36504> antto: That wont even compile anymore. SIGNAL is depricated. Look here:
http://nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
[14:17:32] <megal0maniac_afk> abcminiuser: Will it even work?
[14:17:43] <abcminiuser> Someone on 'Freaks says it can't program EEPROM
[14:17:45] <abcminiuser> But works for me
[14:17:56] <bss36504> antto: You want ISR(TIMER3_OVF_vect)
[14:20:21] <RikusW> abcminiuser: only mega
[14:20:37] <megal0maniac_afk> abcminiuser: I get "unsupported arch for this LUFA configuration file" on compile
[14:20:42] <RikusW> but pdi did work
[14:20:49] <megal0maniac_afk> But I probably have to make board files or something for it first :/
[14:20:52] <abcminiuser> Not running the programmer on an XMEGA
[14:20:58] <megal0maniac_afk> Oooooh
[14:21:00] <abcminiuser> But connecting to an XMEGA for programming
[14:21:10] <megal0maniac_afk> Okay :) Yes, it works
[14:21:17] <abcminiuser> I can read/write EEPROM fine with it, but he swears it's broken
[14:21:17] <megal0maniac_afk> But haven't actually tried eeprom
[14:21:33] <abcminiuser> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1109829#1109829
[14:22:38] <megal0maniac_afk> Ah, that's what prompted the 2mhz thing
[14:23:06] <antto> bss36504 found the bug.. i was double-buffering the init value for the timer.. that's why it glitched when the prescaler changed
[14:23:19] <antto> now it goes below 38 and smoothly
[14:23:28] <bss36504> great, glad to hear it.
[14:26:15] <megal0maniac_afk> abcminiuser: Just read and wrote back the eeprom with the U2S (m32u2) as host and x256a3u as target. No issues here
[14:26:27] <megal0maniac_afk> Using 130901 stable
[14:26:32] <abcminiuser> Me too, so what the hell
[14:29:19] <megal0maniac_afk> I'm using an older toolchain, but it's rock solid
[14:30:34] <megal0maniac_afk> "2lostkiwis" Is he from NZ? :D
[14:42:37] <antto> bss36504 well, now there are other problems x_x
[14:43:30] <mike_papa> Hello. I have a problem with dissapearing simulator in Studio 6.1 SP2. I've just installed terminal expantion, and simulator is gone. I tried uninstalling terminal, but it didn't show up again. Projects setting are good, cause I used sim just before installing terminal. Any ideas what's going on?
[14:45:34] <bss36504> antto: whats happening now?
[14:46:56] <antto> i can't even begin to explain
[14:47:21] <bss36504> that...doesnt help
[14:47:34] <bss36504> compiling errors?
[14:47:39] <antto> no, no
[14:47:50] <antto> problems at higher tempos now
[14:48:16] <bss36504> Not the right speed? Speed jitter? Something else?
[14:48:49] <antto> glitch, jitter, and even goes into a crazy state where it totally f*cks up and needs to be rebooted :/
[14:49:08] <bss36504> alright, well that is odd.
[14:49:22] <antto> what were you suggesting as an alternative?
[14:49:49] <antto> one of the original comments in the code was "fix me! use CTC mode" <- i don't quite get what it means
[14:50:23] <bss36504> I was suggesting you do the tick in software. Make a real time interrupt that triggers, say, every 1ms, then just have some sort of count variable to decide whether or not to turn on/off the output pin.
[14:51:25] <bss36504> I would read, word for word, the entire chapter on Timer 3.
[14:52:17] <antto> 1ms resolution :/
[14:52:50] <bss36504> on what, your timer? Whats your clock frequency?
[14:52:55] <antto> i already have one of the interrupts happening at 1ms for another purpose
[14:53:07] <bss36504> so just tag along on that...
[14:53:55] <antto> but, at 300BPM, 48 ticks
[14:55:08] <bss36504> gonna be honest here, I have no concept of what BPMs should be in # of ticks.
[14:55:19] <bss36504> either way though, it should be possible.
[14:55:53] <antto> for 1 beat, i gotta generate 48 clock ticks
[14:55:59] <antto> equally spaced
[14:56:07] <bss36504> http://www.dvfugit.com/beats-per-minute-millisecond-delay-calculator.php
[14:59:19] <antto> according to my calculations.. with a period of 4ms, i get 312.5BPM
[14:59:34] <antto> and at 5ms i would get 250BPM
[14:59:38] <antto> that's terrible
[15:00:00] <bss36504> so make the tick shorter.
[15:01:15] <antto> the old code is able to have the tempo change with increments of 1
[15:01:45] <bss36504> But this type of implementation is differnet than the old one.
[16:06:02] <bss36504> Who wants to help with a bizarre problem?
[16:07:01] <bss36504> It would appear that my Atmega32U2 is incapable of sinking 90µA
[17:06:16] <Tom_itx> bss36504 which port?
[17:08:37] <bss36504> I fixed it, I was being a dummy.
[17:08:47] <bss36504> thank you though.
[17:09:01] <Tom_itx> i was gonna say PORTC on either the U2 or U4 has reset on it
[17:09:58] <Tom_itx> try running a blinky on that sometime :)
[17:10:31] <Tom_itx> yes, PC1
[17:59:07] <OndraSter> Tom_itx is fighting a 2-headed dragon. She cuts his head off, but the dragon grows 4 heads. She cuts them off, he gets 8 heads. Then 16. Then 32. Then 64. Then 128. And then he dies with zero heads, because he was just an 8bit dragon!
[18:05:32] <Tom_itx> :(
[18:07:07] <OndraSter> s/she/he
[18:07:11] <OndraSter> no idea why I wrote she lol
[18:18:39] <Tom_itx> no idea why you wrote any
[18:19:15] <OndraSter> :(
[18:37:04] <Valen> lol
[18:37:25] <Valen> OndraSter: well I thought it was funny
[18:38:12] <OndraSter> at least somebody
[18:39:28] <antto> what is this "CTC" thing?
[18:39:46] <OndraSter> counter mode
[18:40:19] <antto> ah, found it
[18:40:21] <Valen> its good
[18:51:03] <antto> so there is again a prescaler with that
[18:52:02] <Valen> prescale all the things!
[18:56:28] <ambro718> nomal mode rules!
[18:57:26] <ambro718> just work with intervals in modular arithmetic for timekeeping, no need for clearing the timer.
[18:58:11] <antto> i have some glitches
[18:58:55] <antto> i need to have the timer running and be able to change its period a lot
[18:59:05] <antto> that includes changing the prescaler
[18:59:32] <ambro718> actually I run all the 6 timers synchronized (up to 1 tick), and use each output compare unit for its own purpose
[19:00:27] <ambro718> antto: use normal mode and just change the amount of time you add to your next_time variable
[19:01:14] <darsie> How long wolud it take to compute a sha256 hash of 128 bytes with a 20 MHz avr?
[19:01:45] <antto> ambro718 TCNT3 = x; <- this value?
[19:02:46] <ambro718> uint16_t target = TCNT1 + something; // wait for it... while ((uint16_t)(TCNT1 - target) >= UINT16_C(0x8000)); target += something_else; // go wait for it again...
[19:03:09] <ambro718> it's interesting how many people aren't aware you can use timers like this
[19:03:19] <antto> i'm not looping, i use an interrupt on overflow
[19:03:48] <ambro718> well you can use output compare interrupts the same way...
[19:04:23] <antto> ehm "i use.." was wrong, i meant that the code uses it
[19:05:14] <antto> so is that "normal mode" or "output compare" ?
[19:05:45] <ambro718> no reason you couldn't use both, and doing so is probably the most generally useful way to use a timer
[19:06:08] <ambro718> just replace the while loop in the above code with setting up an output compare interrupt
[19:07:29] <ambro718> on the other hand, you do need to be careful when doing that, in case your target time is in the very near future or even in the past
[19:07:58] <ambro718> if you set the OC to a time which has just passed, it'll take a long time until the interrupt actually happens
[19:08:07] <antto> i need to be able to change the timer period while it's running often
[19:08:41] <ambro718> yes, you can "simulate" that by just starting to add a different increment to "target"
[19:09:21] <antto> i mean changing the prescaler too
[19:09:49] <ambro718> OCR = target = TCNT1 + 100ms; <wait for ISR> ... : target += 200ms; OCR = target;
[19:09:50] <antto> because the range in which it should be able to go covers like at least /8 and /64
[19:10:06] <ambro718> why do you think you need to change the prescaler?
[19:10:26] <antto> i don't know
[19:10:42] <ambro718> is 16 (or 8) bits too little for your time intervals?
[19:10:54] <antto> that's my conclusion from staring at the algo for calculating the timer in the current code
[19:12:03] <ambro718> if 16 bits is not enough, you can extend the bitness in software with overflow interrupt.
[19:12:33] <ambro718> but you need to be careful when reading the clock, because timer can overflow between reading the high bits and reading tcnt. Like so,
https://github.com/ambrop72/aprinter/blob/master/aprinter/system/AvrClock.h#L98
[19:12:37] <antto> roughly 4 to 64ms period is the range i want to cover
[19:14:04] <ambro718> 32bit timer with prescaler 3 (/64) and F_CPU=16MHz gives you up to 2.38 hours relative intervals
[19:14:44] <antto> is there a 32bit timer?!
[19:14:50] <ambro718> no
[19:14:55] <antto> :~(
[19:15:08] <ambro718> you can make one in sofrware based on a 16- or 8- bit timer. Like I have.
[19:15:21] <ambro718> keep a "uint16_t offset;" which you ++ from the overflow ISR
[19:15:34] <ambro718> and to read the time use the algorithm I pointer to above
[19:15:58] <ambro718> that one is free from race conditions
[19:16:09] <ambro718> (replace AMBRO_LOCK with ATOMIC_BLOCK or whatever)
[19:18:14] <ambro718> once you implement that right you usually don't need to worry about prescaler... just chose the lowest that gives satisfactory precision, and the resulting range of the 32bit timer is probably enough. Even then, nothing is stopping you from going 64bit.
[19:18:55] <antto> i think it never needs to use the /1 prescaler
[19:19:26] <ambro718> what are you doing that would need such precision in timing !?
[19:19:35] <antto> mostly falls in the /8, and /16 (but i don't have /16 on this atmega)
[19:19:56] <antto> ambro718 a tempo clock
[19:20:37] <antto> currently i'm switching the prescaler, and having some glitches
[19:20:58] <ambro718> so don't switch the prescaler and do it as I suggested
[19:26:02] <antto> http://codepad.org/h4R4l7wl
[19:26:35] <antto> F_CPU is 16MHz
[19:26:50] <antto> min and max tempo are 20, 300
[19:28:53] <ambro718> where is your atomic block when setting tempo_prescaler2 and timer3_init ?
[19:29:22] <antto> ouch?
[19:29:22] <ambro718> have you never wondered what happens if the ISR executes just between assigning timer3_init and tempo_prescaler?
[19:31:56] <antto> timer3_init and tempo_prescaler are set from the change_tempo() functions which are only ever called from within that do_tempo() function which happens on the interrupt
[19:32:43] <ambro718> it's not obvious what this code is doing, and it's incomplete
[19:33:11] <ambro718> do_tempo() doesn't exist, and change_tempo() and change_tempo2() aren't called from anywhere
[19:33:44] <antto> they are called from inside do_tempo() which is rather big and ugly
[19:33:56] <ambro718> well there's your problem!
[19:34:11] <ambro718> make it nice, then it may be easier to find the problem
[19:34:22] <antto> make it nice?
[19:35:14] <antto> with big and ugly i meant that the code in do_tempo() was written by me and is specifically not nice to look at
[19:35:28] <antto> and that's why i didn't include it in the paste
[19:35:37] <ambro718> what are you trying to do with all this prescaler magic? isn't your goal just to execute an interrupt at predetermined times?
[19:35:53] <antto> predetermined - no
[19:36:12] <ambro718> but still, when one ISR executes, you can compute the next time when it should execute
[19:36:18] <ambro718> right???
[19:36:45] <antto> change_tempo() is called to compute the period of the timer
[19:37:05] <antto> it accepts tempo as BPM (integer in range 20 to 300)
[19:37:20] <ambro718> try not to think of periods an overflows. Instead, think just about when the ISR should execute.
[19:37:41] <antto> it's the same thing
[19:41:19] <antto> well, will the CTC mode be more suitable for changing the timer period frequently, including in big range (involving having to also change the prescaler back and forward) ..?
[19:41:20] <Valen> you want between 20 and 300 bpm, I'd just make the timer fire off at say 100Hz then use the ISR to increment a counter
[19:41:38] <Valen> much simpler conceptually so it'll have less bugs ;->
[19:42:00] <ambro718> antto: here's how I'd do it...
http://codepad.org/a7MBdjkU
[19:42:21] <ambro718> antto: you're free to continue casting spells with your prescalers, but I can't help you with that :/
[19:42:36] <ambro718> and, again, if 16bit is not enough range, extend to 32bit in software
[19:42:42] <Valen> set the count to value wherever, then set a flag or do the thing in the ISR
[19:43:03] <Valen> changing prescalers and the like I'd only do if i was *really* cpu bound
[19:43:34] <antto> cpu bound?
[19:43:42] <Valen> running out of clock cycles
[19:43:48] <antto> i had no idea what a prescaler is yesterday
[19:44:03] <Valen> yeah, I strongly suggest setting it to a fixed rate and leaving it
[19:44:31] <antto> setting it to fixed rate?
[19:44:32] <Valen> then take a look at this
http://www.romanblack.com/one_sec.htm
[19:44:50] <Valen> set your prescaler to get say a 100hz interrupt rate, then do your BPM thing in software
[19:45:39] <antto> you mean at like a resolution of 100Hz?
[19:45:52] <Valen> i mean make the interrupt fire at 100hz
[19:46:00] <antto> that's so wrong
[19:46:06] <Valen> set the prescaler, and top value so the ISR fires at 100hz
[19:46:12] <ambro718> what I did in my pseudocode won't drift either, as long as your prescaled timer frequency is divisible by your desired period
[19:46:23] <Valen> how is it wrong?
[19:46:30] <antto> today someone else also suggested having a 1ms interrupt and generating my bpm from there
[19:46:55] <Valen> you will note a theme to the suggestions being made by people who have done it before ;-P
[19:47:31] <antto> but i will not be able to have 300bpm then
[19:47:34] <antto> nor 299
[19:47:36] <Valen> why not?
[19:47:40] <Valen> of course you would
[19:47:46] <Valen> 300 bpm is 5 hz
[19:48:11] <antto> because with 1000Hz resolution, 4ms period == 312.5 BPM
[19:48:28] <antto> 5ms == 250 BPM
[19:48:53] <Valen> so do the bressenham method
[19:48:54] <antto> Valen when i say BPM, i need to generate a 24ppqn clock at that rate
[19:49:00] <antto> that means 300*48
[19:49:10] <Valen> is this music?
[19:49:14] <antto> yup
[19:49:24] <antto> a dinsync clock, if it rings a bell
[19:49:42] <Valen> so do the bressenham method
[19:50:20] <Valen> 0 net error
[19:50:43] <antto> hm..
[19:51:02] <Valen> (11:29:07) Valen: then take a look at this
http://www.romanblack.com/one_sec.htm
[19:51:03] <antto> that's like having a jitter
[19:51:29] <antto> if you mean bressenham as in the line drawing algorithm, i get the idea
[19:51:30] <Valen> you will always have jitter
[19:51:44] <Valen> at some point its low enough not to matter
[19:51:58] <antto> yes, but at 100Hz we're talking about 10ms jitter
[19:52:06] <Valen> so make it 1000hz
[19:52:09] <antto> 10ms is aweful
[19:52:24] <antto> yes, that would be the minimum
[19:52:41] <antto> i'll think about this
[19:52:59] <Valen> you can do it by changing prescalers and the like on the fly, its just complex, I'd be looking to see if somebody else has already implemented it
[19:53:09] <Valen> or doing a fixed clock tick
[19:53:27] <Valen> and only then writing my own magic prescale and top changing voodoo
[19:53:44] <Valen> don't get me wrong, if you did write such a thing, make it a sexy lib and people will use it
[19:54:25] <antto> if it wasn't obvious from my paste, change_tempo() calculates 2 periods for shuffle
[19:54:34] <antto> they have to alternate
[19:54:40] <antto> so it's quite nasty
[19:54:59] <antto> yet the overal BPM must be kept
[19:55:19] <antto> and the shuffle (swing) amount is adjustable too
[19:57:50] <ambro718> antto: why don't you like my solution with output compare interrupt? It gives you total control of when you want the interrupt to fire, without having to change the prescaler.
[19:58:19] <ambro718> and you can easily make it not drift so long as you have a proper quarts frequency
[19:58:48] <antto> i don't know how that works at all
[19:59:04] <ambro718> antto: have you read about output compare interrupts?
[19:59:22] <antto> i was staring at the code the whole day, reading the datasheets and wondering wtf is this with the prescalers
[20:00:13] <ambro718> do so, and also keep in mind that that they work even when the timer overflows. Timer overflowing is actually irrelevant if you only measure differences between time.
[20:01:50] <seldon> ...as long as it doesn't overflow more than once.
[20:02:03] <ambro718> seldon: huh?
[20:03:11] <ambro718> if I'm at TCNT1=64000 and set OCR1A=TCNT1+10000, I will still be interrupted in 10000 ticks, even if that is past the overflow.
[20:03:38] <seldon> I hope I'm not missing an important part of the conversation. If you remember the timer value at any two points and take the difference, it will be correct only as long as the timer overflowed at most once, otherwise it will be % max_timer_value.
[20:04:37] <ambro718> seldon: but as long as you keep your events "around the current time" (not too fat in the past and not too far in the future), it works
[20:04:50] <antto> in my case, the period goes like 500000 ticks with the /8 prescaler
[20:05:08] <antto> ehm, scratch the prescaler
[20:05:10] <Valen> I wonder if he could set the prescaler somewhere near close then just fiddle top to get enough range
[20:05:52] <ambro718> seldon: sure, setting OCR1A=TCNT1+70000 will produce unexpected results. If you need to wait for so long, you need a timer with more bits...
[20:06:28] <ambro718> ...which you can make yourself by using the overflow interrupt
[20:06:33] <seldon> Or afterscale.
[20:07:50] <seldon> That is to say, ISR(foo_vect) { static unsigned afterscaler = AFTERSCALER_INIT; if(--afterscaler == 0) { afterscaler = AFTERSCALER_INIT; actual_work_tm(); } }
[20:08:04] <antto> ambro718 how is this output compare interrupt mode refered to in the datasheet, can't find it
[20:08:31] <ambro718> antto: I'm pretty sure they're called "output compare". Look for registers starting with OCR
[20:09:42] <ambro718> antto: chapter "16-bit Timer/Counter1", section "Output Compare units"
[20:09:59] <antto> "The Output Compare units can be used to generate interrupts at some given time. Using the Output Compare to generate waveforms in Normal mode is not recommended, since this will occupy too much of the CPU time." <- ?
[20:10:24] <Valen> oh you mean a PWM output?
[20:10:41] <ambro718> yeah they mean PWM, for custom stuff it's perfectly fine
[20:10:48] <Valen> do *everything* in hardware lol
[20:11:08] <ambro718> even PWM with output compare and normal mode is fine as long as your PWM frequency is not too high
[20:11:30] <Valen> just dont fire off an interrupt on it and you can do whatever you want
[20:11:48] <Valen> I am doing one at the moment thats kinda close i guess
[20:12:00] <antto> i need to call this big fat do_tempo() function at that period
[20:12:37] <Valen> using 16 bit timer 1, I have OCR1A set to 20, then I change the top value to put out pulses with a big frequency variance but with a fixed on time
[20:12:51] <ambro718> antto: do it in an output compare interrupt, and have it compute the amount of time after the next output compare should execute. Again, see my pseudocode
http://codepad.org/a7MBdjkU
[20:12:54] <Valen> so i can run a stepper motor at wildy varying speeds with no cpu overhead
[20:13:27] <Valen> yeah, run in CTC mode, vary top, calculate how much you want top to be each time you call it
[20:13:38] <Valen> if top < max then set top to difference
[20:14:30] <antto> ambro718 i would still need to adjust the prescaler, right?
[20:14:51] <Valen> IE work out how many cpu cycles you want to call your next interrupt in, then just count those in the ISR, set top to whatever (as long as its more than some minimum away) and call your function
[20:15:17] <ambro718> antto: OCR1A and next_time are set to 100. Then at TCNT=100, the ISR executes, and they're set is set to 200. Then to 300. And so on... When to change the tempo, just start adding a different amount.
[20:15:17] <Valen> and no prescaler mangle
[20:15:38] <antto> Valen "how many cpu cycles the period should be" that is calculated in change_tempo()
[20:15:41] <ambro718> antto: again, no, you don't ever need to change the prescaler.
[20:16:15] <ambro718> to change the period of the output compare ISR firing, change add_time....
[20:16:39] <Valen> then all you need to do is subtract how many cycles have elapsed since the last isr, see how many are left
[20:17:13] <Valen> if its more than the max value of the timer then just set the TOP value (or OCRnA) to however many cycles you need to wait
[20:17:18] <antto> what kind of variable will that be then?
[20:17:20] <antto> 16bit?
[20:17:31] <Valen> i dunno, depends on how it all works out
[20:17:49] <antto> because my period doesn't fit in 16bits
[20:18:06] <ambro718> so extend the precision to 32 bits
[20:18:10] <Valen> so use a 32bit variable, to hold the number of clocks to go
[20:18:18] <Valen> when it fits into 16 you are done
[20:18:51] <Valen> set a flag to say "this is the final isr for this period" then set top to whatever
[20:19:04] <antto> (F_CPU*60) / (tempo * 48)
[20:19:09] <antto> this basically
[20:19:12] <ambro718> it's pretty easy to make yourself a 32 bit timer. Set up overflow ISR to increment a 16-bit high part of the timer, and use a proper race-free algorithm when reading the timer (which I already showed you)
[20:20:54] <antto> at tempo 20 it's 1000000, at tempo 300 it's 66666
[20:21:13] <carabia> too many 6's
[20:21:36] <antto> there were more but i truncated them
[20:26:25] <ambro718> antto: if the time of a single beat in 300 bpm doesn't correspond to an integer number of timer ticks, but a minute does, you can still avoid drift by tracking individual minutes
[20:32:32] <ambro718> something like this...
http://codepad.org/Pi8Vq5WD
[20:33:59] <ambro718> if TICKS_IN_MINUTE / beat_count is not an integer the individual beats will drift, but that will be corrected every minute
[20:35:36] <ambro718> you can even reduce theat drift by knowing that beat_time(i)=minute_time+i*beat_ticks (where beat_ticks is the proper mathematical value), and using fixed point arithmetic to compute that
[20:36:13] <ambro718> or floats, but only crazy people use floats in ISR
[20:37:10] <inflex> Indeed O_o
[20:39:46] * Valen has
[20:39:53] <Valen> but then i am crazy
[20:41:01] <ambro718> well mostly your uarts randomly start dropping bytes
[20:49:04] <inflex> Valen: you crazy little bastard :p
[21:18:57] <antto> i must be able to generate all BPMs between 20 and 300
[21:19:15] <antto> not to mention that i want to have swing on top of that
[21:19:58] <antto> Valen had a good point with the bresenham's algo
[21:41:51] <Valen> inflex: it was a full floating point PID loop to boot
[21:42:33] <Valen> whats the name of the cat5 type tester that actually puts high speed signals over the line to qualify it?
[21:56:40] <inflex> lan tester?
[22:00:07] <Valen> one of these i think
http://www.ebay.com.au/itm/Fluke-Microtest-Penta-Scanner-350-CAT5-Cable-Tester-W-2-Way-Injector-MOD-8-/291002867452?pt=US_Cable_Testers&hash=item43c11f5efc&_uhb=1
[22:29:56] <carabia> stopped reading at fluke
[22:32:29] <inflex> and why is that?
[22:33:26] <carabia> $$
[23:15:59] <n17ikh> Valen: a time-domain reflectometer
[23:17:37] <Valen> no, that just looks for breaks, these actually put signals over the line to check it
[23:23:04] <carabia> googloid is strong with this one
