Back
[00:47:03] <ravon> clixxIO: Interesting. I have written my own for our product.
[00:47:22] <ravon> clixxIO: I'll definitely keep an eye on yours
[00:47:49] <clixxIO> ravon: Thanks. What's your product?
[00:48:31] <ravon> clixxIO: Vehicle monitor, alarm and logger (
http://exqbe.com)
[00:49:50] <clixxIO> nice
[00:51:24] <clixxIO> there were a few c++ issues to solve
[00:51:25] <ravon> clixxIO: Will yours stay open source?
[00:51:29] <clixxIO> yes
[00:52:14] <clixxIO> The C++ proof of concept was completed this week. Next week I plan to bring in all the AVR code
[00:52:31] <ravon> clixxIO: It may be that yours work just as well for our needs. In that case I'll tag along and help.
[00:53:12] <clixxIO> That would be great.
[00:53:36] <ravon> btw, I use FastDelegate for the callback mechanisms. That way it's easy to attach data to the callbacks without much overhead.
[00:54:14] <clixxIO> clixx_io@googlegroops.com is my google-group
[00:54:58] <clixxIO> https://groups.google.com/forum/#!forum/clixx_io
[00:55:40] <clixxIO> I'm just using a C style of callback because things need to work on some basic processors like the Attiny as well
[01:15:44] <clixxIO> hi hackvana - stranger
[04:26:22] <carabia> clixxio - ruby on rails coming to an avr near you!
[04:53:59] <clixxIO> Hi carabia: I've heard that, but I'm not into Ruby
[04:54:18] <clixxIO> I thought it was ARM
[04:56:19] <jadew`> lol ruby on rails on avr? wth is the purpose of that?
[05:02:30] <carabia> jadew`: i dunno. i guess the same as with python and the rest
[05:02:32] <carabia> 8)
[05:03:38] <amee2k> ruby on avr sounds like ruby on snails :>
[05:03:49] <superware> I'm building a dc motor controller with PWM input for motor position/angle, utilizing a two channel encoder. For that I need a 16 bit timer for PWM input, two 8 bit timers for encoder inputs, PWM output for motor, an interrupt for homing signal and ADC for current sensing. Will an atmega8 be enough?
[05:04:26] <jadew`> superware, check the datasheet
[05:05:15] <clixxIO> I suggest going with a bigger chip right from the start - you'll have room to 'grow'
[05:05:36] <superware> well, I need it to be as small as possible
[05:05:50] <superware> it seems an extra 8 bit timer for the motor control is needed, right?
[05:05:54] <amee2k> based on the peripherals list, sounds like it. but i'd at least go with a megaX8 intead of the plain 8
[05:06:03] <superware> why?
[05:06:24] <amee2k> the peripherals have slightly different features
[05:07:11] <amee2k> it'll be pin and code compatible up to a mega328 if you run out of memory, and iirc they run up to 20MHz
[05:07:13] <superware> the atmega8 has 3 PWM outputs, does it mean one per timer? (one 16 and two 8)
[05:08:07] <superware> I think 8k of flash is enough
[05:08:50] <amee2k> on a megaX8, you have two 8 bit and one 16 bit timer, each with two PWM channels
[05:09:06] <superware> and atmega8?
[05:09:09] <amee2k> but some PWM channels overlap with the SPI pins
[05:09:45] <amee2k> mega8A has two on the 16 bit timer, and one on an 8 bit timer i think
[05:10:00] <amee2k> it still has two 8 bit timers, but one doesn't have PWM
[05:11:10] <superware> PWM is only output, right?
[05:11:47] <amee2k> yes-and-no... some timers have a "capture pin" where it'll store the counter value and fire an interrupt... thats handy for measuring pulse widths precisely
[05:13:05] <superware> great, so the 16 bit timer can be used for PWM position input in capture mode
[05:13:45] <amee2k> on a megaX8 the 16 bit timer has it... no idea about the mega8A since i rarely use it
[05:14:00] <amee2k> its the "ICPn" pin usually
[05:14:08] <superware> atmega8: "One 16-bit Timer/Counter with Separate Prescaler, Compare Mode, and Capture Mode"
[05:14:43] <amee2k> since pin names are kinda systematic, comparing the pinout diagrams can show interesting stuff. like "OCnx" are PWM channels and the 'n' shows which share the same timer
[05:15:37] <amee2k> my favorite MCU for small time stuff is a mega88... its easily available in DIP for prototyping, reasonably well featured and not too expensive
[05:15:52] <superware> let me check
[05:16:39] <amee2k> if i need smaller, its usually attinyX4, if i need larger its mega16 or mega32
[05:17:00] <superware> the datasheet doesn't show DIP
[05:17:17] <amee2k> o.o
[05:17:57] <amee2k> on a megaX8?
[05:18:14] <superware> yes
[05:18:32] <amee2k> i've got one on my desk here
[05:18:34] <amee2k> http://vm197.cugnet.net/~amee2k/sandbox2/megaX8.png
[05:19:51] <superware> megaX8A... A
[05:19:53] <superware> ok
[05:20:57] <amee2k> oh, okay... i tend to leave off the "stuff at the end" >_>
[05:25:00] <superware> please tell me what's the features I need for one 16 bit PWM input (motor position input), two 8 bit PWM inputs (two channel encoder to detect motor position + direction), PWM output (for motor control, I guess it can be 8 bit), ditigal interrupt from homing signal and an ADC for current sensing. thanks.
[05:26:59] <amee2k> as i said i think the mega8 should have the features, but i'd go for an 88 or 168 because it has slightly more features... that could come in handy and make the software easier
[05:27:28] <amee2k> and they cost like 3 bucks... not much of a loss if you need to upgrade later because something doesn't work out >_>
[05:31:59] <superware> what's timer compare mode vs. capture mode?
[05:33:06] <antto> ++timer; if (timer == value) { boohoo(); }
[05:33:13] <antto> that should be "compare"
[05:34:36] <superware> so I can set a desired value and have an interrupt signaled?
[05:37:32] <antto> yeah
[05:38:02] <antto> haven't read about the capture mode
[05:41:16] <superware> it seems there's "Output Compare Mode" and "Input Capture Mode" :)
[06:57:20] <superware> antto: thanks
[11:44:01] <Brittany_> Apparently among every student that tried to set up USART RX Interrupts, nobody could get an interrupt handler running.
[11:44:22] <Brittany_> I'm starting to feel like there's either something really obscure we're all missing, or that the interrupts aren't properly implemented on the 644p.
[12:00:15] <ambro718> Brittany_: show your code.
[12:01:00] <ambro718> there's also option 3. there's something really obvious you're all missing ;)
[12:28:58] <BullSherd> Wow, Google is making really strange things
http://goo.gl/YEkaMA
[12:28:59] <BullSherd> funny haha xD
[12:45:35] <Brittany_> ambro718 : I just included the code that relates to the interrupt management.
[12:45:36] <Brittany_> http://pastebin.com/n9NqAH4a
[12:46:11] <Brittany_> All set for USART0
[12:46:27] <Brittany_> Interrupt is generated by a host program compiled separately.
[12:46:46] <Brittany_> And sent through a USB cable that acknowledges RX and TX to the embedded platform.
[12:48:43] <ambro718> give me a minute
[12:48:46] <Brittany_> Amusingly, the host DOES communicate and receive information back from the program.
[12:48:59] <Brittany_> It just doesn't generate the interrupt, even when trying to just print something with the interrupt handler.
[12:50:57] <ambro718> the interrups setup seems correct to me
[12:51:29] <Brittany_> http://i.imgur.com/ioHY54X.gif
[12:51:56] <ambro718> the same BAUD_PRESCALE value works without interrupts?
[12:52:31] <Brittany_> I took part of the code from a suggestion someone gav eme on here.
[12:52:34] <Brittany_> What do you mean?
[12:54:23] <ambro718> Brittany_: are you aware you're supposed to read UDR0 in the interrupt, else the interrupt will keep firing?
[12:55:04] <Brittany_> No. But the interrupt isn't firing at all.
[12:55:38] <ambro718> if your RX interrupt neither reads UDR0 nor disables itself, once it fires for the first time, it will keep firing, and no other code will run (that includes your main code)
[12:56:18] <ambro718> so while you may think it isn't firing at all, it's possible the truth is the exact opposide ;)
[12:56:36] <Brittany_> well, the main code is still running and printing values from the ADC.
[12:56:57] <Brittany_> but you're saying in the handler, I should be reading from UDR0 then disabling?
[12:57:48] <ambro718> you should either read UDR0, *or* disable the RX interrupt
[12:58:21] <ambro718> the latter you do if for whatever reason you don't want to process any more received data
[12:58:41] <ambro718> reading UDR0 will clear the RX interrupt flag, allowing other code to execute
[12:58:42] <Brittany_> for me, I'm literally waiting for someone to press enter, and that's all.
[12:58:49] <Brittany_> There's no test statement.
[12:59:14] <ambro718> just do: UDR0; in the ISR
[12:59:29] <Brittany_> But I don't think the interrupt is occurring, otherwise I'd expect it to print contents from the interrupt, and not the main loop.
[12:59:31] <Brittany_> Thanks. :)
[12:59:53] <ambro718> what do you mean "print contents from the interrupt"?
[13:00:05] <Brittany_> I had a printf statement in the interrupt code earlier to test it
[13:00:13] <ambro718> don't do that
[13:00:44] <ambro718> you should not use printf in interrupts, it's not interrupt-safe (hell can occur if the interrupt starts doing a printf while main is already doing a printf)
[13:01:32] <ambro718> remove that printf and just work with the flag you already have. Set up the main loop to print something when it detects the flag.
[13:02:15] <Brittany_> this would probably explain why earlier I was getting QHITQ£4tfqinw4gtnq3io4ngq3in4gionq34 as my print out.
[13:02:32] <Brittany_> I'll go connect up and try this once more.
[13:03:29] <ambro718> I also recommend that you do the UBRR calculation with proper rounding, like this:
http://ideone.com/M96D1R
[13:03:48] <ambro718> (UBRR= what you call BAUD_PRESCALE)
[13:04:39] <ambro718> it could be your effective RX baud rate it too much off from the desired due to the round-to-zero thing you're doing
[13:04:48] <ambro718> in the division that is
[13:06:02] <ambro718> (generally to add rounding to X/Y you change it to (X/Y)+0.5, or when not dealing with floats, to (2X+Y)/(2Y)
[13:13:17] <Brittany__> this still isn't going.
[13:13:43] <ambro718> have you tried doing the UBRR calculation as I suggested?
[13:14:11] <Brittany__> I've popped that in there.
[13:14:28] <Brittany__> what should I be doing after getting the uint32_t ubrr value?
[13:14:50] <ambro718> UBRR0H = ubrr >> 8; UBRR0L = ubrr;
[13:15:13] <ambro718> UBRR = Usart Baud Rate Register (I think the datasheet calls it that way)
[13:15:15] <Brittany__> hm
[13:15:20] <Brittany__> I get an integer overflow in expression warning.
[13:15:38] <Brittany__> for calculating 'd'.
[13:15:44] <ambro718> oh, add a cast (uint32_t) before the baud
[13:15:53] <Brittany__> haha, thanks, sorry.
[13:16:43] <Brittany__> it's not working out, hm.
[13:17:13] <ambro718> so let's try killing the interrupt and reading from main loop
[13:17:20] <ambro718> can you paste your entire code?
[13:17:30] <Brittany__> the main loop runs.
[13:17:35] <Brittany__> sure. sorry it's very ugly.
[13:17:55] <ambro718> then the first thing to do is cut it down to the bare essential which demonstrates your problem
[13:18:19] <Brittany__> http://pastebin.com/GhUrEUuj
[13:18:20] <ambro718> just the USART setup, the interrupt, and a main loop which checks the flag
[13:23:34] <ambro718> something like this
http://pastebin.com/pz8XPen4
[13:24:07] <ambro718> the cutting down that is
[13:26:00] <Brittany__> works.
[13:26:12] <ambro718> prints "CHECK" the moment you send something?
[13:26:39] <Brittany__> yep
[13:26:44] <Brittany__> and doesn't break out of check, haha.
[13:27:01] <ambro718> so then there is not problem ;)
[13:27:41] <ambro718> now you add code and see at which point it breaks :D
[13:28:05] <ambro718> (note I changed the int flag to uint8_t)
[13:28:15] <ambro718> no need to have it any wider than 1 byte
[13:45:34] <Tom_itx> is cmd[] stored in ram?
[13:45:41] <Tom_itx> how much ram do you have?
[13:47:55] <Tom_itx> mmm seems you got her on the right track at least
[18:34:13] <carabia> hello
[21:08:03] <Lambda_Aurigae> http://dave.cheney.net/2014/01/23/avr11-simulating-minicomputers-on-microcontrollers
[21:08:31] <Lambda_Aurigae> pdp-11 on an avr
[21:24:40] <dxtr> Fascinating
[21:24:51] <dxtr> My interrupt is resetting the system
[21:28:52] <Casper> stack overflow or unhandled interrupt
[21:39:57] <dxtr> Casper: The interrupt is literraly an empty function
[21:40:59] <dxtr> literally
[21:41:13] <dxtr> Now I'm toggling an LED but it still resets
[21:41:21] <Tom_itx> WDT
[21:41:33] <Tom_itx> also
[21:41:43] <Tom_itx> some chips have reset brought out to a pin
[21:41:58] <Tom_itx> toggling the pin can _will_ cause a reset
[21:42:52] <dxtr> Hmm.. It's getting late. Better check this tomorrow
[21:42:58] <dxtr> or, well, later today :)
[21:43:12] <dxtr> Thank you for your time, though!
[21:43:57] <Tom_itx> atmega32U2 PC1
[21:43:59] <Tom_itx> have a look
[21:44:30] <Tom_itx> ask me how i know :D
[22:07:04] <Casper> dxtr: if you used the wrong interrupt name then gcc will not give you a warning, it will silently compile
[22:07:29] <Casper> dxtr: but when the interrupt come, it will look for the non-existing function...
