Back
[02:14:40] <superware> I have a very simple external interrupt
http://pastebin.com/2ARLt7bG I have minimal asm knowledge but I must optimize it further, any idea?
[02:17:26] <Thrashbarg> superware: you might need to go to assembler if that's still not fast enough, but what optimisation flags are you using on the compiler?
[02:21:53] <superware> Thrashbarg: right, now with -O3
http://pastebin.com/ZpRGzqAx
[02:22:32] <Thrashbarg> any better?
[02:24:07] <Casper> superware: avoid -O3
[02:24:38] <superware> not yet. this is for an attiny2313 (SPI slave), which is connected to a atmega328 (master), that interrupt interferes with the SPI communication at certain speeds
[02:24:39] <Casper> usually it result in broken code (optimised out stuff) and big size
[02:25:05] <superware> well, the produced interrupt code is much smaller
[02:25:20] <superware> http://pastebin.com/ZpRGzqAx vs.
http://pastebin.com/2ARLt7bG
[02:25:29] <Casper> you got lucky
[02:26:36] <Thrashbarg> heh
[02:26:43] <superware> but does
http://pastebin.com/ZpRGzqAx asm makes sense?
[02:28:05] <Thrashbarg> superware: looks like you're missing a bit off the end of it. There's a jump to address 0x84 and it's not there
[02:29:54] <superware> right! sorry
http://pastebin.com/TA8fmfT6
[02:30:19] <superware> ok, it's longer, but thats ok, the question is whether it's faster :)
[02:30:53] <Thrashbarg> superware: looks good to me. It can be optimised further but you'd have to rewrite it in assembler. GCC adds a pile of overhead
[02:31:55] <Thrashbarg> you could try defining _encoder_count as a register too
[02:32:19] <superware> http://pastebin.com/2ARLt7bG is much shorter, how can I replace the C interrupt with the asm one? (AtmelStudio)
[02:32:42] <superware> how?
[02:33:10] <superware> it's uint16_t
[02:34:12] <Thrashbarg> add register to the declaring line, before volatile... Casper might know better :P
[02:34:18] <Thrashbarg> I'm better at pure assembler than C
[02:34:53] <superware> I want to include the interrupt in asm...
[02:35:55] <Thrashbarg> mm I'm thinking if you did that you'd still get the overheads
[02:36:58] <Casper> but do you really need that much optimisation?
[02:37:09] <superware> can I replace the C ISR(INT0_vect) { ... } with asm?
[02:38:11] <superware> Casper: yes, that interrupt interferes with the main() SPI slave communication as high (350kbps) speeds
[02:38:42] <Casper> why don't you use interrupt based spi?
[02:39:22] <superware> since that external interrupt is connected to a quadrature encoder output (channel A+B), the avr must not skip even one edge change
[02:39:31] <superware> or it will lose count
[02:41:25] <Thrashbarg> I'd solve that with more hardware ... hardware is always faster :P
[02:43:47] <superware> you are right, I had the main atmega328 doing the count, then I decided to "outsource" the count to an attiny2313 (more hardware), it's job is count the quadrature encoder output (x1 which is the slowest, not even x2 or x4) and respond to an SPI command to send back a 16 bit counter.
[02:44:55] <Thrashbarg> I was thinking something more like an external counter which responds immediately to the encoder. When an interrupt triggers, it reads from the counter and adds the difference to the variable
[02:45:15] <Thrashbarg> that's getting tricky though...
[02:46:47] <superware> if I add a delay in the master, between SPI bytes trasmissions, the slave is fast enough to respond
[02:48:02] <Thrashbarg> ok I thought the 2313 wasn't fast enough, or are you just trying to optimise it for a best case scenario
[02:49:25] <Thrashbarg> also if you're driving the code with an interrupt, your main ATMega should be able to handle it. Or have you tried that
[02:49:43] <superware> the t2313 is running at 20Mhz (max speed), the thing is since it's an SPI slave, it must respond to an SPI clk after a certain time, and I think that certain time is less than that external interrupt time
[02:50:41] <superware> Thrashbarg: the main atmega can't because the motor might spin very fast, resulting in dense quadrature output from the encoder.
[02:51:21] <superware> if you lose a quadrature change, you've lost count, there's no way to recover
[02:51:33] <Thrashbarg> ok sure, but it shouldn't drop cycles, it'd just slow down the main routine
[02:51:47] <superware> if it
[02:52:30] <superware> the atmega might execute another interrupt which takes more than a single quadrature change
[02:52:37] <Thrashbarg> ahh ok
[02:52:59] <superware> so I thought a dedicated t2313 running at 20Mhz must be enough :)
[02:53:41] <superware> but at certain SPI speeds the interrupt interferes with the main() SPI logic, which is also very simple btw..
[02:53:51] <Thrashbarg> yeah
[02:54:08] <Thrashbarg> you might be better off simply getting a dedicated quadrature encoder IC
[02:54:11] <superware> can you please help me translate that interrupt code to slim asm?
[02:54:48] <superware> you're right, I've ordered two types (one parallel, one I2C) weeks ago, haven't arrived yet :)
[02:55:39] <superware> I can do parallel between the atmega328 and attiny2313, but am trying to avoid it, will require 8+2+1 lines
[02:55:41] <Thrashbarg> ok
[02:56:31] <superware> do you think
http://pastebin.com/2ARLt7bG can be optimized?
[02:57:26] <Thrashbarg> can you try putting 'register' before 'volatile' on the first line and pasting it again?
[02:57:40] <superware> sure, a sec
[02:58:57] <superware> which optimization should I use?
[02:59:09] <superware> that one is -O1
[02:59:45] <Thrashbarg> ok use that
[03:00:40] <superware> "register name not specified for '_encoder_count'"
[03:00:55] <Thrashbarg> bah
[03:00:59] <superware> should be something like register uint8_t regVar asm("r13");
[03:01:39] <Thrashbarg> yup
[03:02:19] <superware> which register should I use? :)
[03:02:46] <Thrashbarg> I'd be surprised if it does anything useful. It needs to move from that specified register to r24/r25 to increment it, then move it back
[03:04:25] <superware> what about all those push and pop at the beginning and end of the code?
[03:05:03] <Thrashbarg> most of them are needed because they're registers used in the main routine
[03:05:15] <Thrashbarg> or should I say potentially used
[03:05:31] <Thrashbarg> it'd be easiest to write the whole firmware in assembler
[03:05:41] <Thrashbarg> that way you know what's going on
[03:33:04] <superware> is the "do" version correct?
http://pastebin.com/LxHZPeZP
[04:12:39] <superware> can an atmega328 read a PWM signal with hardware only? I mean without a capture interrupt flipping the edge selection...
[04:15:49] <Tom_itx> int0
[04:15:56] <Tom_itx> that's about it
[04:16:06] <Tom_itx> or pcint
[04:16:39] <superware> int0 might be even more complex than a timer input capture
[04:19:53] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/avr/atmega328/INT0/
[04:19:55] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/avr/atmega328/PCINT0/
[04:37:39] <superware> Tim_itx: this is basic external interrupt, it has nothing to do with PWM reading
[04:37:48] <superware> *capturing
[04:42:33] <Tom_itx> it does if you're *reading* a pwm signal
[04:43:48] <superware> but it will all have to be implemented in software, the Input Capture Pin does much of the work for you (but not all)
[04:44:37] <Tom_itx> well then you'll have to poll the pin and compare the bits
[04:44:46] <Tom_itx> which will take longer and more code
[04:45:32] <Tom_itx> int0 *is* the hardware method
[04:45:57] <superware> but it doesn't count, a timer does
[04:46:41] <superware> see
http://www.atmel.co.il/Images/doc8014.pdf
[04:48:17] <Tom_itx> you didn't say anything about counting
[04:48:32] <Tom_itx> <superware> can an atmega328 read a PWM signal with hardware only? I mean without a capture interrupt flipping the edge selection....
[04:49:42] <superware> reading a PWM signal means getting the ratio between the high time and low time in each duty cycle
[04:50:02] <superware> hence pulse (high time) width modulation
[05:09:49] <Daulity> how hard would it be to learn arm assembly
[05:10:14] <twnqx> as hard as anyx other
[05:11:38] <Daulity> i already know avr assembly, but it is kind of way different then the arm assembly i have seen so far
[05:12:14] <twnqx> oh, they all are. but still not that hard
[05:22:59] <PureSine> Daulity: depends on the level of your need. I do program with ARM assembly(as well as AVR) so I know a bit abut it. in my opinion it is much more complex than AVR assembly...
[05:23:48] <PureSine> ...if you need to write simple routines then it is not t that difficult but for larger routines it has quite steep learning curves...
[05:25:02] <PureSine> ...for example in ARM assembly each instruction can be modified to many many variations for example there is MOV and also you can modify it to MOVS that does another thing...
[05:26:08] <PureSine> ... so in a nutshell for simple routines (less than 100 lines) not much complicated but if you need to write bigger routines then you have to invest on it a lot of time
[05:27:06] <twnqx> but normally there's no point to use assembly beyond chip init or rare interrupt handlers, or is therE?
[05:28:46] <Daulity> well i want to kinda write a kernal and os in assembly :D (for fun)
[06:30:31] <malinus> Tom_itx, I think I've broke your programmer somehow. It still pop up as MkII when lsusb, but when I connect it, it first shows the normal red-green led, but after ~5sec the green led turns red too. And I can't seem to use avrdude with it. Any ideas?
[06:34:28] <malinus> Tom_itx, it's weired. it seems to randomly change between the two states (green-red, and red-red LED). When I'm trying to use avr-dude, it sometimes change to green-red, and let me flash once or twice in a row.
[06:34:44] <malinus> so there is definetly *something* wrong
[09:35:28] <tlvb> anybody got a good source for the atm12864d datasheet (ks0107/0108 based lcd) …the one I'm using (first google result, hebeiltd.com.cn) is inconsistent wrt the pinout versus the signals listed in the command table
[09:46:32] <tlvb> nvm, it seems to be as good as it gets
[12:00:26] <ivanshmakov> What are the cheaper SPI (or TWI) LCDs out there? I’ve learned interfacing Nokia 5110 (a cheap PCD8544-based LCD), and now wondering what other (similarly cheap) LCDs could I connect to an AVR MCU?
[12:08:05] <RattusRattus> ivanshmakov: MIKROE-495 £19.75 QVGA Color TFT
[12:08:17] <RattusRattus> http://uk.farnell.com/mikroelektronika/mikroe-495/display-protoboard-tft-320x240/dp/2281683
[12:08:56] <RattusRattus> but I am sure you may find cheeper.... but perhaps without longevity or data :-)
[12:10:46] <ivanshmakov> RattusRattus: Well, by “similarly cheap” I surely meant something within the £4 range… But thanks anyway, I may consider something like that for my ARM-based projects, eventually.
[15:07:03] <malinus> ivanshmakov, there is also the other nokia display with colors, should be similar in price. Also there are those 16x2 character displays
[15:08:38] <ub|k> great, now avrdude doesn't answer
[15:08:44] <ub|k> i think i've messed up the fuses
[15:08:55] <ub|k> but AFAIK it's not possible to disable SPI using SPI
[15:09:02] <ub|k> so, i wonder what's going on
[15:09:16] <malinus> ub|k, could be the clock :)
[15:10:39] <ub|k> malinus: what can i do about that?
[15:11:11] <malinus> did you change the clock source?
[15:11:43] <ub|k> malinus: i'm afraid i've accidentally set it to low freq crystal
[15:11:51] <malinus> uppps
[15:11:53] <malinus> :D
[15:12:13] <malinus> I'm not sure what to do actually, sorry.
[15:12:26] <ub|k> ok, thx anyway :)
[15:13:24] <ub|k> maybe i can get my arduino to generate a low freq pulse
[15:14:17] <malinus> I think you might need to do something like that, yes
[15:32:05] <ub|k> amazing...
[15:32:39] <ivanshmakov> malinus: Any specific Nokia LCD models for me to look for? The character LCDs I’ve seen were virtually all parallel interface ones. Besides, they weren’t all that cheap.
[15:35:30] <malinus> ivanshmakov, there is one for nokia 55xx? I think. It's color
[15:36:26] <malinus> ivanshmakov,
http://www.ebay.com/itm/Replace-Nokia-5110-LCD-1-44-Red-Serial-128X128-SPI-Color-TFT-LCD-Display-Module-/271422122271?pt=LH_DefaultDomain_0&hash=item3f3204e91f
[15:56:46] <ivanshmakov> malinus: ACK, I’ll check it out. Thanks!
[16:14:58] <ub|k> i'd really appreciate any tips on how to rewrite the fuses of an avr whose CKSEL has been accidentally changed
[16:30:39] <timemage> ub|k, changed to what?
[16:32:48] <ub|k> timemage: 1001
[16:32:53] <ub|k> (low freq xtal)
[16:33:24] <timemage> ub|k, and i take it you don't have a crystal.
[16:33:34] <ub|k> timemage: not a low freq one
[16:33:37] <ub|k> only 16MHz
[16:38:33] <timemage> ub|k, i'm looking for some more reliable info, but the basic idea is to feed a signal to xtal1. you have something else, anything else, that can produce a square wave?
[16:39:43] <timemage> ub|k, alternately, you can (iirc) use high voltage programming. i'm guessing most people who ask this don't have anything to do that handy.
[16:40:07] <ub|k> timemage: i don't
[16:40:13] <ub|k> yeah, i have an arduino
[16:40:32] <ub|k> low freq means what?
[16:40:35] <ub|k> 10 kHz?
[16:41:29] <timemage> ub|k, under 1 mhz it seems. i wouldn't bother going that fast.
[16:42:07] <timemage> ub|k, if you're doing isp programming you could feed it even a few khz. as long as you set the programming speed to the appropriate fraction of that.
[16:42:39] <ub|k> timemage: ok
[16:42:53] <timemage> ub|k, if you're trying to to program it through a serial bootloader, than your baud rate is going to be affected by the clock rate, so, it will be more tricky.
[16:44:32] <ub|k> great
[16:44:59] <ub|k> timemage: no, it's ISP
[16:45:13] <ub|k> great, my usbasp doesn't let me set the programming speed :/
[16:45:19] <ub|k> some stuff about the firmware
[16:45:33] <timemage> ub|k, hmm. i'm seeing "low" used in multiple ways. it seems it's intended for ~32khz crystals, which makes sense (to me)
[16:46:15] <timemage> ub|k, hmm, who makes it?
[16:47:21] <ub|k> timemage: it's this exact one
[16:47:24] <ub|k> http://www.dx.com/p/usbasp-usbisp-downloader-programmer-for-51-avr-157167
[16:47:28] <ub|k> chinese clone, i guess
[16:47:57] <Kev> even cheaper on ebay
[16:48:14] <Kev> i have 2-3 and they work great
[16:48:49] <timemage> ub|k, how did you make the determination that it wouldn't let you set the speed? other things carrying that "usbasp" seem to allow it.
[16:49:09] <Kev> http://www.ebay.com/itm/181378044570
[16:49:17] <ub|k> avrdude: warning: cannot set sck period. please check for usbasp firmware update.
[16:49:48] <Kev> i had to update the firmware with the latest usbasp
[16:50:04] <ub|k> Kev: how did you do that, if i may ask?
[16:50:30] <Kev> you're gonna have to have another programmer and short two pins on the one you want to update
[16:50:35] <timemage> ub|k, you'd probably be fine updating it. if you worried about that, you could try using the arduino as a programming. i've never done that though.
[16:51:20] <Kev> http://www.rogerclark.net/?p=702
[16:53:04] <Kev> obvioulsy easier if you have another (working) programmer
[16:53:27] <ub|k> Kev: no, i'll have to stick to the arduino, i'm afraid :/
[16:57:32] <ub|k> Kev: which pins am i supposed to short?
[16:57:57] <Kev> good luck :) should not be too hard with that tutorial though :)
[16:58:36] <Kev> eh a jumper header, J2 or J3 depending the board you have
[16:59:31] <Kev> it's connected on the reset pin of the mega on the programmer board
[17:00:05] <Kev> i think mines didn't even have a jumper header just two holes
[17:00:21] <ub|k> there are two holes
[17:00:23] <ub|k> saying "UP"
[17:03:19] <Kev> http://img.alibaba.com/img/pb/127/392/372/372392127_766.jpg
[17:03:26] <Kev> i have those
[17:04:00] <Kev> it's JP3 on the top edge near the usb connector
[17:04:51] <ub|k> Kev: this is mine:
http://openrcforums.com/forum/viewtopic.php?f=10&t=2162
[17:05:14] <ub|k> ok, that's it
[17:05:17] <ub|k> http://www.sciencetronics.com/greenphotons/?p=938
[17:06:14] <Kev> that's a weird looking mcu
[17:10:10] <Kev> ub|k, what kind of chip is that on the programmer ?
[17:10:26] <Kev> i mean i haven't seen any avr with 4 cut corners
[17:12:43] <Kev> oh my bad it's a mega8
[17:16:29] <ub|k> it's done :D
[17:16:32] <ub|k> thanks
[17:16:36] <ub|k> avrdude now accepts -B
[17:16:39] <ub|k> now
[17:16:48] <ub|k> on to un-bricking the atmega32
[17:21:11] <Kev> :)
[17:21:19] <Kev> oh, it' late
[17:21:22] <Kev> it's
[17:21:24] <Kev> night :)
[17:21:35] <ub|k> the minimum SCK frequency it accepts is 500 Hz?
[17:22:15] <ub|k> well, makes sense
[17:23:28] <malinus> oh wow. I didn't understand why my adc reading were so bad. But I forgot to set the adc clock prescalar :V
[17:23:45] <malinus> so it was probably running at like 10mhz haha
[17:24:03] <malinus> (I think the default is 2)
[17:30:29] <ub|k> :/
[18:17:43] <HTT-Bird> so...I'm still scratching my head as to why a LUFA-using device would be turning off and on its enumeration pullup repeatedly...
[18:18:37] <Tom_itx> what device / port / pin?
[18:20:07] <HTT-Bird> Tom_itx: this is actually a LPC11U35 (NXP's USB library is a LUFA port)
[18:20:43] <HTT-Bird> and it's the USB_CONNECT-bar pin (varies depending on package, but the LPC11U3x have a dedicated alternate function for controlling it)
[18:20:51] <HTT-Bird> it is low to turn the pullup on
[18:21:24] <HTT-Bird> in my case though, it pulses high for ~1ms at a 24Hz rate
[18:34:46] <ub|k> atmega32 fully working again
[18:34:48] <ub|k> thanks guys
[18:35:01] <ub|k> it took an arduino producing a square wave
[18:35:19] <ub|k> and avrdude/usbasp at 8kHz
[18:41:14] <Tom_itx> the clock must be 4x the spi rate
[20:17:31] <timemage> ub|k, =)
