Back
[04:08:24] <uskerine> Hi, how do you define ISRs in the source? Is it needed to include __interrupt? __interrupt void Timer0_CompareA_interrupt( void );
[04:09:24] <uskerine> I mean in the declaration, the "prototype" you include at the beginning of the source
[04:11:44] <Tom_itx> uskerine, example:
http://tom-itx.no-ip.biz:81/~webpage/how_to/atmega168/mega168_led_blink_int_index.php
[04:13:11] <uskerine> Tom_itx there is no declaration of functions there
[04:13:27] <uskerine> shouldn't be a declaration? -like in C for other platforms-
[04:14:03] <Tom_itx> in the interrupt.h
[04:14:30] <Tom_itx> that's all you need
[04:15:23] <Tom_itx> different asm example:
http://tom-itx.no-ip.biz:81/~webpage/avr/tiny10/test/tn10_pwm_test.asm
[04:15:23] <uskerine> I have seen also calling the ISR like this: __interrupt void Timer0_CompareA_interrupt( void )
[04:15:51] <uskerine> no, I am looking for C examples
[04:18:03] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/avr/atmega328/INT0/
[04:18:04] <uskerine> http://www.atmel.com/webdoc/AVRLibcReferenceManual/group__avr__interrupts.html
[04:18:04] <Tom_itx> another
[04:18:59] <uskerine> seems easy
[04:19:00] <uskerine> thanks
[04:22:18] <uskerine> what is the difference between TIMER0_COMPA_vect and TIMER0_COMPB_vect ?
[04:29:42] <uskerine> are cli() and sei() implemented in <avr/interrupt.h> too?
[04:38:37] <uskerine> Tom_itx following <avr/interrupt.h> how do you enable/disable individual interrupts? any handy macro or something like that?
[10:45:02] <uskerine> if interrupts are disabled (globally), will an incoming interrupt that arrives (for example, from timer comparison) will be raised once global interrupts are enabled? (like the interrupt flag is activated and attended once interrupts are enabled)
[10:46:48] <LeoNerd> Yes, that's the entire point
[10:47:08] <LeoNerd> You can CLI/SEI around small blocks of code that need to be atomic,a nd any interrupts you missed in the meantime will come later
[10:48:13] <uskerine> Thanks, that's why I am trying to do, but unfortunatelly still struggling to get TIMER1 interrupt working
[10:50:57] <uskerine> LeoNerd does this code seem fine to you?
[10:50:58] <uskerine> http://pastebin.com/iWz3SyxL
[10:51:12] <LeoNerd> Ugh pastebin.com :(
[10:51:45] <LeoNerd> Also no, don't do that
[10:51:58] <LeoNerd> If you disable *indivdual* interrupts then they're disabled, entirely
[10:52:04] <LeoNerd> Use the CLI/SEI sequence
[10:52:14] <uskerine> the first step is the initialization
[10:52:17] <uskerine> then I enable it
[10:52:35] <uskerine> but I never reach the ISR
[10:53:36] <LeoNerd> you didn' call sei() anywhere
[10:53:42] <LeoNerd> I don't think.. Hard to tell because you didn't shwo much code
[10:57:01] <uskerine> sei() is called
[10:57:14] <uskerine> I just pasted the relevant part I understand it is needed to enable TIMER1 interrupt
[11:45:58] <uskerine> found that TIMER1 is different, that equivalent toTIMER0 is TIMER2
[11:46:13] <uskerine> and that prescaler uses TCCRxB
[12:02:01] <uskerine> shall ISR: DISABLE_TIMER0_INTERRUPT(); or CLEAR_TIMER0_INTERRUPT(); ?
[12:02:43] <uskerine> or in different way: #define CLEAR_TIMER2_INTERRUPT( ) ( TIFR2 |= (1 << OCF2A) ) what does this do?
[12:11:36] <awozniak> Using a mega2560, trying to generate PWM. I'm using fast PWM mode. It seems that, even when OCRnA is zero, I still get a very brief (one clock cycle) pulse. Is this normal/expected?
[12:18:16] <awozniak> I guess it is, "If the OCR0A is set equal to BOTTOM, the output will be a narrow spike for each MAX+1 timer clock cycle."
[13:45:39] <Flipp__> is there a way to get avrdude to only erase the memory space it's going to be writing to?
[13:45:46] <Flipp__> and not the whole chip?
[13:46:16] <RikusW> not that I'm aware of
[13:46:27] <RikusW> in bootloader mode you can erase page by page
[13:46:53] <RikusW> not when using isp, then you can only do a full erase
[13:47:04] <Flipp__> yup. was just trying to only program my main program without wiping the bootloader every time
[13:47:18] <Flipp__> RikusW: cool, thanks. that seems to align with what I was seeing using an isp
[13:47:18] <RikusW> use the bootloader ?
[13:47:39] <Flipp__> RikusW: erm... bootloader isn't quite ready yet... heh...
[13:47:43] <Flipp__> still working on that part :)
[13:47:46] <RikusW> ah
[13:48:00] <RikusW> which chip ?
[13:48:06] <Flipp__> mega2560
[13:48:26] <Flipp__> trying to write a small stk500v2-based program-over-bluetooth
[13:50:00] <RikusW> I did an all asm stk500v2 over serial and usbcdc
[13:51:09] <RikusW> avrdude and stk500v2 isp for bootloading is broken it uses the wrong MULTI command instead of the proper ones...
[13:51:28] <RikusW> I suggest you use stk500v2 HVPP when interfacing with avrdude
[13:51:48] <RikusW> I did both isp and hvpp protocols in my bootloader
[14:56:43] <mark4> anyone here familiar with the xmega interrupt vectors?
[14:57:03] <mark4> im looking at the documentation(s) for a device and i thought i understood the vectors but obviously not
[14:57:54] <mark4> one of their documents gives a interrupt vector base table. with the reset vector being at offset 0, the OSCF_INT_vect being at offset 2
[14:58:29] <mark4> then everything from there on is a peripheral interrupt base so a peripheral with more than one interrupt will have more than one vector
[14:59:22] <mark4> ok nvm i got it, i was not seeing enough space for the USART vectors between the various base addresses but my eyeballs were miscalibrated
[14:59:30] <mark4> i DO understand them lol
[14:59:48] <mark4> wish the hell theyu would publish a complete vector table, not a scatterbrained fragmented table
[15:11:16] <specing> look into the startup file
[15:11:30] <mark4> ?
[15:11:36] <mark4> what startup file.. :)
[15:12:06] <mark4> i was looking at the uart vectors and not seeing enough space for 3 vectors from their base bcause i was looking in the wrong place is all
[15:12:28] <mark4> each usart has 3 interrupt vectors from their base address
[15:17:07] <mark4> im trying to see exactly how many interrupt vectors there are on this xmega. i think im going to need to count by hand every interrupt vector associated with each peripheral one at a time
[15:17:32] <mark4> oh. that peripheral has 3 interrupt vectors... add 3 to the total.. on to next peripheral/whatever
[15:17:49] <N1njaneer> mark4: FYI, XMEGA and AVR32 is a dead-end with Atmel as per them, if you are just starting in to developing with them. Suggestion is to either stick with AVR, or jump to ARM.
[15:18:18] <N1njaneer> XMEGA/AVR32 were a stop-gap before they got all the ARM stuff fully in motion
[15:19:19] <mark4> they end of lifed yet?
[15:19:37] <N1njaneer> No, they just aren't putting much effort in to developing the products further
[15:19:44] <mark4> why do they not have "do not use for new projects"
[15:19:51] <N1njaneer> Atmel doesn't readily EoL parts
[15:20:05] <LeoNerd> Oh, XMEGA as well?
[15:20:25] <N1njaneer> I'm just telling you what their internal focus is as to what series of parts they are planning on actively developing moving forward.
[15:20:37] <LeoNerd> Hrm
[15:21:10] <mark4> i dont care if they activly develop xmega, i have an xmega device thats going to be around and supported by them for a long time
[15:21:23] <mark4> im not going to be using their software tools or even their libraries on it
[15:21:42] <N1njaneer> SAM (ARM) is really the main focus of everything they are developing, since the price-points on the SAM stuff are generally less than AVR/XMEGA/AVR32 for equivalent or better functionality.
[15:22:03] <mark4> arm is not an embedded device
[15:22:06] <mark4> period
[15:22:12] <N1njaneer> Do as you wish.
[15:22:13] <mark4> i dont think atmel is giving up on embedded
[15:22:48] <aandrew> lol
[15:22:51] <aandrew> this again
[15:23:00] <aandrew> arm is not an embedded device in what sense?
[15:23:24] <N1njaneer> aandrew: Clearly opinion of context :)
[15:23:38] <mark4> in the same sense that an 6 core I7 is not an embedded device
[15:23:50] <mark4> a 6 core I7 even
[15:23:51] <aandrew> ARM Awhatever sure, that's more CPU than MCU
[15:24:01] <aandrew> but ARM Cortex M0-M4 is most decidedly MCU
[15:24:04] <N1njaneer> ARM A yes, Cortex series no
[15:24:24] <N1njaneer> You're not going to run arbitrary applications on an M0+ :)
[15:24:56] <mark4> just because its a labotomized arm core doesnt make it an embedded device
[15:24:58] <aandrew> right, which is why I find the statement "ARM is not a microcontroller" to be false
[15:25:10] <aandrew> mark4: so what makes an embedded device embedded them?
[15:25:11] <aandrew> then?
[15:25:45] <N1njaneer> aandrew: Opinion I think. And again, who cares? :)
[15:25:55] <mark4> you can embed a lga2011 I7 running 4.7ghz with 64 gigs of ram... does that make the I7 an embedded device?
[15:26:01] <aandrew> because the industry (and if you've really got 30y experience as you claim) then you already know that it's generally regarded as something with a bunch of peripherals all rolled into one die and "one stop shopping" kind of system
[15:26:07] <aandrew> mark4: don't be stupid
[15:26:41] <aandrew> mark4: either try to have an intelligent conversation or move on. throwing out ridiculous comparisons is troll behaviour
[15:27:24] <specing> "embedded" != soldered
[15:27:25] <mark4> arm is a micro processor, not a micro controller
[15:27:40] <aandrew> mark4: again, what makes a microcontroller a microcontroller?
[15:27:49] <N1njaneer> What about a mini-computer? Or a mainframe? Or a supercomputer?
[15:27:51] <aandrew> why is a PIC32MX a microcontroller but not an ARM Cortex M0?
[15:27:55] <specing> mark4: arm is a part of your body. If everything is okay, you have two.
[15:27:59] <N1njaneer> Can't make a supercomputer out of an FPGAs, clearly.
[15:28:09] <N1njaneer> Or GPUs.
[15:28:18] <specing> N1njaneer: What is a "supercomputer"?
[15:28:25] <N1njaneer> GPUs aren't CPUs, so we can't use them for anything not "graphics"
[15:28:27] <aandrew> or how about AVR32? what makes AVR32 a microcontroller but not a Cortex M0?
[15:28:40] <N1njaneer> specing: My point exactly.
[15:28:41] <specing> N1njaneer: bitcoin isn't graphics
[15:29:00] <N1njaneer> specing: See 'sarcasm' :)
[15:29:20] <mark4> N1njaneer, GPUs are better at FPU than FPUs :P
[15:29:32] <aandrew> wow really
[15:29:41] <mark4> according to nvidia
[15:29:49] <N1njaneer> specing: This is a main reason why CUDA exists :)
[15:30:21] <aandrew> I'm asking according to you, and I'd really like you to respond to why Cortex-M0 isn't a micro but PIC32 or AVR32 is
[15:30:25] <specing> mark4: you are comparing baskets of apples vs a few apples
[15:30:46] <mark4> specing, i dont do floating point anything, im just quoting nvidia lol
[15:31:28] <mark4> aandrew, uarts, spi, i2c, all those other nice peripheral devices built into the core... does the M0 have all those peripheral devices built into its core?
[15:31:37] <aandrew> mark4: absolutely yes
[15:31:54] <mark4> what peri[pherals does it have built in? i was not aware of that
[15:32:04] <aandrew> mark4: have you looked at a Cortex M series CPU or are you just thinking that all ARM is the same?
[15:32:16] <aandrew> mark4: all of them you listed and more
[15:32:31] <aandrew> (depending on the specific vendor, of course)
[15:32:58] <mark4> aandrew, im not a fan of the M series, im not realy that much of a fan of the A series either tho but A > M
[15:33:06] <mark4> i did port my arm32 forth to thumb2 tho
[15:33:28] <mark4> runs on my beagleboard xm and now on this raspberry PI2 at work
[15:33:36] <aandrew> well no A != M is a much better way to state it; they're like comparing an i7 to an AVR which is probably where your confusion is coming from
[15:34:17] <mark4> not really, not unless the i7 also contained all the atmel opcodes :)
[15:34:29] <aandrew> but while I agree with your assertion that ARM A-series isn't what I'd consider a microcontroller, they *also* have UARTs, I2C, SPI, PWM, timers, etc. on-chip
[15:34:32] <mark4> arm cores have arm32 opcodes and thumb/thumb2. M cores have only the thumb/thumb2 opcodes
[15:34:39] <N1njaneer> Can someone tell me the point of even discussing this?
[15:34:42] <aandrew> mark4: what?
[15:34:52] <aandrew> that isn't true at all
[15:34:55] <mark4> the M cores do not have the 32 bit arm opcodes
[15:35:08] <mark4> the ARM mode. it only has THUMB/Thumb2
[15:36:10] <mark4> with the arm encoding every opcode is conditional. only certain opcodes are conditional in thumb2, thumb2 uses ifelse block
[15:36:15] <Roklobsta> maybe microcontroller traditionally refers to 8 or 16 bit MCus. Though these days 32 bit is just as apt.
[15:36:18] <aandrew> actually you are correct there, I misunderstood your original statement
[15:36:21] <mark4> which can only condition 4 consecutive opcodes
[15:36:26] <aandrew> N1njaneer: lack of anything better to discuss? :-)
[15:36:37] <Roklobsta> i am glad to see the end of 8 bit
[15:36:44] <mark4> 8 bit will never die
[15:36:57] <Roklobsta> maybe i am scarred from 8051
[15:37:01] <aandrew> oh there's no end to 8 bit, and there are still some 4-bit CPUs kicking still
[15:37:06] <mark4> i LOVED the 8051
[15:37:11] <Roklobsta> it's a turd
[15:37:15] <mark4> nec75x ? eep
[15:37:29] * RikusW still got a few 6052's around..
[15:37:30] <mark4> Roklobsta, whose 8051s have you used?
[15:37:45] <mark4> intel/dallas?
[15:37:46] <N1njaneer> aandrew: I suppose so. It just doesn't seem to produce anything useful as a result beyond a bunch of dickwaving based on what people have experience with. So I guess I'll chalk it up to "entertainment value discussion" :)
[15:37:56] <mark4> look at the si labs 8051s
[15:38:05] <aandrew> I kind of enjoy waving my dick tbh...
[15:38:37] <Roklobsta> mark4: i am specifically referring to silabs. I did an employed project with one at 100MHz. fucking nightmare.
[15:39:15] <Roklobsta> C->8051 asm is super bloat.
[15:39:34] <aandrew> 8051s will never die. they're buried in a LOT of USB devices as the SIE
[15:39:39] <Roklobsta> the project needed 16 or 32 bit cpu simply because the code was so heavy.
[15:39:53] <aandrew> and yes, some companies will push code forward to faster and faster 8051s rather than port
[15:39:56] <aandrew> it's crazy
[15:39:58] <mark4> Roklobsta, i liked them :)
[15:39:58] <Roklobsta> aandrew: only because 8051 patents are xpoired and there is a massive legacy.
[15:40:53] <mark4> actually intel abandoned the 8051 patents before they expired... or so i heared
[15:40:58] <Roklobsta> it was so heavy the stadard stack blew out. had to resort to even slower large memory mode. total arse.
[15:41:04] <mark4> i.e. they end of lifed their 8051 production before their patents expired
[15:41:31] <mark4> Roklobsta, question: what language were you writing for those 8051s?
[15:42:12] <Roklobsta> Tasking C compiler
[15:42:26] <mark4> yea. some things should just never be done. like writing C for an 8 bit device
[15:42:40] <mark4> developing embedded applications in C is like opening a can with a rock
[15:42:44] <mark4> -- Ron Oliver --
[15:42:45] <aandrew> it's not THAT bad but yes, it can get a little silly
[15:43:02] <mark4> and tasking c was piss poor compared to keils
[15:43:22] <Roklobsta> to taskings credir they issued quick patches for the compiler chain bugs i found
[15:43:55] <mark4> keil also had the best arm development suit at that time. till ARM bought them and ordered them to shitcan THEIR tools and put the Keil name on the awesomely shitty arm development suite
[15:45:11] <mark4> i think for a while si-labs 8051s were the only devices that could write to flash while running out of flash :)
[18:33:50] <dutra> Hi, I am trying to use the avrfix library, but I I'm getting "undefined reference to `lmullkD'". I think the library is found, because if I try changing -lavrfix to something else, it complains that it can't find the library. Has anyone used avrfix before?
[18:39:41] <Lambda_Aurigae> http://stackoverflow.com/questions/18549526/undefined-references-to-functions-in-linked-avrfix-library-using-avr-gcc-compile
[18:40:11] <Lambda_Aurigae> there appears to be a fix there.
[18:44:23] <dutra> Lambda_Aurigae, I saw that, but it appears that it is a fix for c++. My project is in C.
[18:57:33] <dutra> Lambda_Aurigae, If I copy avrfix.h and avrfix.c to my project, I also get undefined reference to lmullkD. But, if I copy them, and #define LMULLKD, it compiles. Do you know how that would translate to link with the library?
[19:12:43] <Tom_itx> is 'D' supposed to be caps?
[19:14:11] <dutra> This is declared in avrfix.h: extern _lAccum lmullkD(_lAccum, _lAccum);
[19:50:37] <anonnumberanon> hi
[19:51:11] <anonnumberanon> man from the output of the accelerometer and gyroscope pid controller, how do I adjust the power to both motors on one axis of my quadcopter
[20:42:23] <N1njaneer> Whew, 44mm tape feeders are pricey
[21:20:46] <dutra> Well, avr-gcc 4.9 supports fixed point math with _Accum and _Fract. You just have to compile it with --enable-fixed-point
[21:21:35] <Casper> that will make an huuuuuge difference with avr!
[21:37:18] <arcangelo> Hello
[21:42:02] <ColdKeyboard> Does anyone have SPI interface library for FATFS that I can use as diskio?
[22:00:12] <Tom_itx> elm chan does
[22:00:31] <Tom_itx> http://elm-chan.org/fsw/ff/00index_e.html
[22:27:36] <N1njaneer> ColdKeyboard: Atmel has a nice one in the ASF :)
[22:28:43] <N1njaneer> ColdKeyboard: Will target SDCards as well as can be used with flat SPI flash, and RAM if you have enough.
[22:29:27] <ColdKeyboard> Alright, I'll try it. Thanks