#avr | Logs for 2013-11-26

Back
[03:16:24] <Trieste> Hi, is it a bad idea to use a single timer and an interrupt handler which selects which pin to toggle rather than two timers for two-channel PWM?
[04:23:55] <ROMA> hello
[04:24:38] <Guest80874> i am playing with nRF24L01 chip and wanna ask some question to more advanced AVR users :)
[04:25:35] <Guest80874> as i understand then when i increase wireless chips distance - there is more and more bytes lost of errorous transmission
[04:26:03] <Guest80874> so theoretically transmission speed is decreased
[04:26:11] <Guest80874> am i wright?
[04:27:39] <Guest80874> i know something about antenas.. wavelenghts, capacitys and so on.. so i know nRF24L01 chip working range is dependent on electrical conductive objects that surrounds chips
[04:28:35] <Guest80874> i think i can make same soft, that shows best chip alligment to external conductive objects..
[04:29:53] <Guest80874> the working principle will be that one nRF chip send maximum data to other chip.. and receiver chip count data received in some ammount of time
[04:30:34] <Guest80874> more data reciver is received - the better works antenas on both chips
[04:30:41] <Guest80874> am i wright?
[04:31:06] <Guest80874> maybe someone do like that on wireless chips finetune?
[04:35:36] <Guest80874> maybe someone have some AVR code for this thing? ;P
[04:44:23] <Guest80874> also i don't understand maximum transmitting time for nRF24L01 = 4ms
[04:45:23] <Guest80874> what time i must wait to chip cool down after continuously transmitting data for 4ms?
[04:57:15] <Guest80874> ...silent people ...woodoo people
[04:57:47] <Guest80874> ok i also have Ping timeout
[04:57:51] <Guest80874> bye :)
[07:39:37] <Fornaxian> Trieste, it all depends on your specific requirements, project, and stuff.
[07:45:21] <Excheloony> Good Morning
[07:45:57] <Excheloony> Can someone suggest a good programmer for usb?
[07:51:05] <Fornaxian> yeah.
[07:51:11] <Fornaxian> let me find it
[07:51:43] <Fornaxian> http://tom-itx.dyndns.org:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[07:51:53] <Fornaxian> sold by Tom_itx right here in this channel.
[07:51:56] <Fornaxian> works real well.
[07:52:29] <Fornaxian> http://tom-itx.dyndns.org:81/~webpage/commerce/commerce_index.php
[07:52:42] <Fornaxian> I got the one in the pretty box.
[07:56:06] <Excheloony> lol,, ill look at it now
[07:56:12] <Fornaxian> http://hackaday.com/2013/11/26/laser-wire-stripping/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[07:56:13] <Excheloony> ty
[07:56:17] <Fornaxian> not related, but nifty.
[07:58:45] <Fornaxian> http://dangerousprototypes.com/2013/11/26/udp-bootloader-for-atmega328p-enc28j60/
[07:58:54] <Fornaxian> aaand, someone asked about this the other day.
[07:59:42] <Excheloony> whats the cable used for this,, mini or micro,, can't tell
[08:00:01] <Excheloony> looks like mini
[08:00:17] <Fornaxian> mini I think.
[08:00:40] <Fornaxian> bigger than my cellphone connection.
[08:00:40] <Excheloony> yeah,, i have plenty of those,, micro is scarce tho
[08:00:52] <Excheloony> ahh ok,, definitly mini then
[08:01:04] <Excheloony> doesnt come with tho right?
[08:01:14] <Fornaxian> nope.
[08:01:20] <Excheloony> :(
[08:01:25] <Fornaxian> if you talk to Tom_itx, you might get a bonus though.
[08:01:48] <Excheloony> hmm
[08:02:24] <Fornaxian> the software on it was developed by someone in here too,, abcminiuser
[08:02:29] <Fornaxian> not sure where he is at the moment.
[08:02:32] <Fornaxian> but he works for atmel.
[08:02:44] <Excheloony> ahh in Norway i believe
[08:02:54] <Excheloony> I was on here a whil;e back
[08:03:09] <Fornaxian> yeah...
[08:03:28] <Fornaxian> by "not sure where he is" I meant he isn't online in here at the moment.
[08:03:30] <Excheloony> I tried to use arduino as an isp,, :(
[08:03:37] <Excheloony> oh ok
[08:03:37] <Fornaxian> Tom_itx is located in the USA somewhere.
[08:03:52] <Fornaxian> but I think he ships international.
[08:04:01] <Excheloony> im in the us as well
[08:04:22] <Fornaxian> I've known people to use ardweenies to greater and lesser effectiveness as an ISP programmer.
[08:04:52] <Excheloony> yeah,, ide rather use studio to dev seeing how arduino has training wheels
[08:05:01] <Fornaxian> bah.
[08:05:04] <Fornaxian> vi for the win!
[08:05:09] <Excheloony> yeah?
[08:05:24] <Fornaxian> being as I don't run windows, I can't run atmel studio.
[08:05:31] <Excheloony> ahh
[08:05:40] <Fornaxian> so, I use vi,,or vim,, to write code...or sometimes kate.
[08:05:53] <Excheloony> i see
[08:06:19] <Excheloony> I just hate how limited arduino is as far as full chip access
[08:06:21] <Fornaxian> taught myself microcontroller programming about 10 years ago...still learning constantly too.
[08:06:28] <Excheloony> same here
[08:06:28] <Fornaxian> limited and bloated.
[08:06:32] <Excheloony> lol
[08:06:35] <Excheloony> yes
[08:06:52] <Fornaxian> http://i.imgur.com/8Ue0Vxj.jpg
[08:07:23] <Fornaxian> as I was saying last night, ardweeny is going the way of mickysoft...let's abstract the abstract libraries that abstract the hardware....
[08:07:23] <Excheloony> lol
[08:07:56] <Excheloony> what else does kinetic see
[08:08:10] <Excheloony> sorry kinect
[08:09:05] <Excheloony> still, i might get my nephew an arduino for christmas
[08:09:24] <Excheloony> just for the sake of getting him interested
[08:11:26] <Excheloony> anyway.. thanks for the info,, gotta get to work
[08:11:47] <Fornaxian> I would put him together a kit rather than an ardweeny.
[08:46:50] <malinus> Fornaxian, I think there is more abstracting going on then that :)
[08:47:54] <Fornaxian> malinus, probably.
[08:52:35] <Trieste> Fornaxian: DC motor speed regulation
[08:52:38] <malinus> Fornaxian, there should be an abstraction from programing. Like making something like visual basic on top of arduino.
[08:52:47] <Trieste> Fornaxian: is the application for the pwm
[08:53:00] <Fornaxian> Trieste, ok, that narrows it down,,,some..
[08:53:21] <Fornaxian> either method should work...again, depending on other factors, like hardware.
[08:55:01] <Trieste> Fornaxian: what kind of hardware specifically?
[08:55:18] <Fornaxian> motor driver.
[08:55:56] <Fornaxian> but, generally, either method should be ok if you can implement it on your particular microcontroller.
[08:56:38] <Trieste> the driver is an SN754410, if it makes any difference
[08:56:44] <Fornaxian> I've used individual timers and single timer method for both motor control and hobby stepper control.
[08:56:47] <Trieste> but okay then, thanks :)
[08:58:40] <Fornaxian> if the rest of your program is very processor intensive and time sensitive then it's best to use hardware pwm.
[08:59:44] <Trieste> I don't think it is, but even so, shouldn't the interrupts be fairly independent on the actual run of the program?
[09:00:06] <Fornaxian> they are independent, yes...but interrupts interrupt your program.
[09:00:25] <Fornaxian> so, if your program is very time sensitive you have to watch the number and frequency of interrupts.
[09:01:00] <Trieste> oh, right, I thought of it the other way around :)
[09:01:29] <Fornaxian> if you have a lot of things generating interrupts you might want to watch it too...
[09:02:04] <Fornaxian> usart interrupt might take a bit longer than you want and the timer interrupt for pwm might not get fired at the correct instant, causing the pwm to go wonky.
[09:02:20] <Fornaxian> hence the preference for hardware pwm.
[09:02:43] <Fornaxian> it will keep running no matter what the code is doing..
[09:45:37] <megal0maniac> xmegas arrived :)
[09:56:22] <Fornaxian> kewl.
[10:10:24] <megal0maniac> Now I don't know what to do because it's TQFP :P
[10:10:43] <Fornaxian> solder on some fine wires.
[10:34:09] <bss36504> megal0maniac: breakout boards are your friend
[10:53:08] <megal0maniac> bss36504: I actually have one, but my friend has it since we shared shipping :/
[10:55:03] <megal0maniac> But I might design one with the necessary caps and resistors and such
[13:18:24] <megal0maniac> I'm looking at getting a Dremel. Anyone here have one?
[13:22:00] <Fornaxian> yes
[13:22:16] <Fornaxian> both real dremel and other brands.
[13:33:28] <Fornaxian> my B&D has more torque than my dremel.
[13:33:35] <Fornaxian> but it gets hot faster.
[13:59:21] <bss36504> anyone ever used the Wiznet W5500?
[13:59:41] <Fornaxian> not I.
[14:00:09] <Fornaxian> I've only used the enc28j60
[14:01:33] <bss36504> how did it go for you?
[14:01:41] <Fornaxian> worked just fine for me.
[14:02:03] <Fornaxian> I had a breakout board for the chip and used the tuxnet ethernet stack.
[14:02:05] <Fornaxian> err
[14:02:11] <Fornaxian> the tuxnet tcp/ip stack
[14:02:14] <bss36504> My application requires pretty stable communication, and ethernet is one possibility I'm considering.
[14:02:53] <bss36504> not getting any google results for tuxnet
[14:03:20] <Fornaxian> sorry...tuxgraphics
[14:03:47] <bss36504> ah, thanks
[14:04:45] <Fornaxian> http://tuxgraphics.org/electronics/200901/avr-ethernet-realtime.shtml
[14:05:56] <bss36504> Essentially, I just want raw transfer. That link is very handy. I want a way to send literally bytes via ethernet and get them on the embedded platform.
[14:06:13] <Fornaxian> you want a UDP stack then.
[14:06:20] <Fornaxian> UDP reception.
[14:06:23] <bss36504> afk for a few. thanks for the help. I might hit you up later.
[14:07:06] <Fornaxian> or raw frames like that link uses.
[14:07:16] <Fornaxian> although, that is sending, not receiving.
[14:08:33] <Fornaxian> http://tuxgraphics.org/electronics/200702/article07021.shtml
[17:53:56] <ambro718> I have the following instructions: lds reg,TCNT+0; sbis TIFR1,TOV1; How's the timing here - is it possible that the second instruction sees the timer oveflow flag, but the first instruction received a pre-overflow TCNT value?
[17:55:46] <ambro718> I know, I'm crazy for optimizing single instructions :D
[18:00:56] <ambro718> yeah, looks like it can happen, "the TOV flag is set in the same clock cycle as TCNT becomes zero". So I have to re-read the TCNT when I detect overflow to make sure I get the post-overflow value.
[18:01:02] <twnqx> it's asynchronous, so not much you can do to guarantee it doesn't change
[18:01:59] <ambro718> sometimes CPUs implement some special delay semantics to allow doing such things race-free without special logic
[18:03:15] <N1njAway> Too long away. I missed you guys :D
[18:05:03] <twnqx> welcome back :P
[18:05:22] <ambro718> fortunately I just figured I don't need to do a full 16-bit read, then possibly another 16-bit read in case overflow is detected, but I can just read the low byte before the check, and re-read the low byte in the overflow handling (and then read the high byte just once)
[18:05:29] <ambro718> so I still saved one cycle lol
[18:06:14] <N1njAway> Just imagine if a million people each saved one cycle. I mean, we'd have a 1Mhz savings. :D
[18:08:01] <N1njAway> Did beaky port Linux to his ATTINY yet?
[18:08:31] <twnqx> lol
[18:08:46] <twnqx> guess i shouldn't tell him i'm in dubai next week :P
[18:09:04] <twnqx> though i want an AVR + programmer for some experiments. humm
[18:22:49] <Tom_itx> is beaky in dubai?
[18:25:31] <N1njAway> Beaky nests on the top of that tall tower out there :D
[20:51:59] <itemized> I'm having some issues parsing the datasheet for the Atmega644PV. I'm trying to see which pins support change interrupts. Is there something specific I should be searching for in the PDF?
[20:56:34] <Tom_itx> look at P2
[20:56:45] <Tom_itx> pin change or int0?
[20:56:55] <itemized> pin change
[20:57:03] <Tom_itx> one sec
[20:57:04] <itemized> I think I got it figured out. Looks like all of Port B supports it
[20:57:21] <Tom_itx> the interrupt is port wide
[20:57:48] <itemized> gottcha. Is it normal that a change interrupt would only be supported on one port?
[20:57:55] <itemized> Something about that seems strange to me
[20:58:08] <Tom_itx> what other chips are supported by that data sheet?
[20:58:42] <itemized> looks like just the ATmega644/V
[20:58:51] <itemized> and the ATmega644
[20:59:15] <itemized> there is a 1284, and a 2564, but they're not listed in datasheet
[20:59:29] <Tom_itx> 164 324 644 1284
[20:59:38] <itemized> http://www.atmel.com/Images/doc2593.pdf
[20:59:47] <Tom_itx> i got their whole library
[21:00:16] <Tom_itx> look on P2, any that say PCINT is pin change
[21:00:26] <Tom_itx> looks like most of them are
[21:01:29] <Tom_itx> i see at least 31 pins
[21:02:04] <itemized> Ah, I see.
[21:02:22] <itemized> Hmm. Must be an issue with my code. having issues with it on PC5 and PC4
[21:02:28] <Tom_itx> then you look at that particular port for the interrupt
[21:02:49] <Tom_itx> those are also jtag
[21:02:52] <Tom_itx> disable jtag
[21:03:04] <Tom_itx> TDI TDO
[21:03:48] <itemized> Yeah, I've got my JTAG header broken out, and am trying to reuse some pins while debugging.
[21:03:53] <itemized> (with an ISP)
[21:04:01] <itemized> just checked the fuses, yup, jtag is enable
[21:04:09] <itemized> s/enable/enabled
[21:04:18] <Tom_itx> give that a try
[21:04:20] <itemized> Thanks Tom_itx. It's getting late. :)