Back
[01:10:35] <EI24> hi, have anyone worked doing assembly worked with a tft display?
[01:14:11] <Casper> I'm not that masochist :D
[01:33:59] <Mr_Sheesh> I usually get things working with C, then figure out what needs to be faster and mutate that into ASM, as needed; ASM isn't always needed if you do things well in C; Takes planning / thought up front
[01:36:23] <EI24> Casper: Ive heard that im a masoschist a number of times now haha
[01:38:46] <EI24> Mr_Sheesh: yes, ive tried some C examples, and they work, then i try to translate them into assembly, but the result is really messy
[01:39:16] <EI24> My screen have got all kinds of strange colors and patterns..
[01:42:14] <EI24> is there a way to translate avr C code into avr assembly? like in avr-gcc. I tried -S command, though it seems the output becomes x86 assembly
[03:09:08] <EI24> what value does the registers in register file have, initially when starting the MCU?
[03:29:45] <Tom_itx> EI24, that is given in the data sheet
[03:55:38] <EI24> Tom_itx: I looked through the datasheet, reading through the register file section, did not find anything. So i wrote a simple program that lit a LED if the intial value of a register was 0, which was the case
[04:08:52] <LeoNerd> ARGH ardu-fucking-ino
[04:09:12] <LeoNerd> The pin layout of the Micro (the only breakout I can find for a 32U4 at a reasonable price) is craaaaazy
[04:09:19] <LeoNerd> I think they just rolled dice to assign pins
[04:10:03] <LeoNerd> For no *readily* apparent reason, the USB CDC activity LEDs are hardcoded to PB0 and PD5, meaning I can't use those pins for my own purposes. Meaning I'm severely lacking in "clean" 4-bit wide port access anywhere
[04:10:42] <LeoNerd> Now I could just of course *not* run Arduino core code on the chip, but my entire reason for needing to do that is to get USB HID working easily
[04:14:38] <LeoNerd> Ooooh.. though the JTAG port is nice and neatly accessible as A0-A3...
[04:15:01] <LeoNerd> I wonder if anyone has any suggestions for a JTAG access tool for AVRs... Could just use my Bus Pirate I suppose
[04:19:31] <LeoNerd> http://www.amazon.co.uk/Download-Programmer-Emulator-Debugger-Atmega/dp/B00Q6ZLR2 huh.. GBP8 for this.. I wonder if it's any good
[07:41:35] <oal> Can I do something like "clr r16 \n sbi r16, CS10 \n out TCCR1B, r16"?
[07:41:42] <oal> I get "Invalid number"
[07:42:27] <oal> I want to set some named bits in the TCCR1B, and I write in assembly
[07:53:36] <Xark> I suggest using .S (i.e., -x assembler-with-cpp), and #include <avr/io.h>. Then you can do e.g." in r17,_SFR_IO_ADDR(SREG)"
[09:08:04] <oal> Xark, thanks
[09:12:43] <twnqx> who of you recommended those double mosfets to me...
[09:17:57] <e7p> I'm using a Xmega in my application and am wondering if they don't support reading out the OUT-registers of the pins. I want to read back what was written to that register previously but it does not seem to work even if the datasheet states that the bits of that register are R/W. reads out only as zero. Or am I doing something wrong?
[09:19:02] <e7p> Its just that I have code which is pretty complex and there are many cases where a I/O pin is toggled or put high or low and I just want to get back the current state of that particular pin
[09:21:42] <twnqx> not sure about xmegas, but pretty sure it works with regular avrs, or stuff like |= and &= wouldn't work
[09:22:23] <e7p> I think I found my fault. If PINnCTRL.PORT_INVEN_bm is set, OUT reads out inverted even if it is set the other way round. that way I read zeroes when the port was "active" but inverted.
[09:23:56] <e7p> a bit strange behaviour, but it is sufficient to just know that it must be inverted in software
[10:08:43] <oal> Xark, I found out I can just do ldi temp, (1 << CS12) | (1 << WGM12)
[10:09:03] <oal> Like in C. :)
[10:14:27] <LeoNerd> Hehe
[10:14:33] <LeoNerd> Yah; it's just a compiletime constant
[10:19:54] <oal> I'm using the simulator in Atmel Studio 6.2. I seem to have stumbled upon a bug
[10:21:04] <oal> I've set up an ISR to run every second, but it's run at just 3800 us in the simulator, then not again until 1 million us (1 second)
[10:21:35] <oal> Any ideas why it would fire that early?
[10:28:16] <learath> us or ms?
[10:30:10] <LeoNerd> Depends on the initial value of the counter surely?
[10:34:27] <oal> I clear TCNT1(L/H) right before setting TCCR1B (CS12 to get prescaler 256 and WGM12 to get interrupts when counter equals OCR1A)
[10:34:55] <oal> So the counter should be 0 when the clock starts ticking
[10:36:05] <oal> http://hastebin.com/ogasaxaqid.avrasm
[10:39:23] <oal> Weird. If I just launch it without any breakpoints except inside the ISR, it jumps to the ISR at 3800 us. If I manually step through the init, and through an infinite loop for a while (10-20 times), then hit play, it doesn't go to the ISR before 1 million us
[10:40:06] <oal> No code change... I guess I'll just ignore it then.
[11:07:40] <e7p> oal: maybe the internal prescaler is not reset at begin? could be definitely a problem that occurs only once at begin.
[11:08:56] <oal> e7p, maybe. I really have no idea :)
[11:10:56] <e7p> you may have to set the PSRASY bit of GTCCR to reset the prescaler. if this does not help, I don't have any ideas either.
[11:12:12] <e7p> (and do this at the very beginning as this resets also timer bits as far as I know)
[11:12:31] <LeoNerd> The state of the prescaler will control when the timer itself increments
[11:12:50] <LeoNerd> If you're resetting the timer count value to zero, the prescaler will affect exactly when that increments to 1, to 2, etc...
[11:13:34] <LeoNerd> But if you're wanting to count all the way up to ICR/OCRx, which is presumably some large number, then that exact offset won't have much of an effect
[11:20:13] <e7p> LeoNerd: that's what I'm also afraid of. but otherwise I can't explain why this happens only once at the start. Or it is simply a bug in the simulator which I also cannot preclude.
[11:21:05] <LeoNerd> Mm
[11:21:28] <oal> Not a big deal. I'm not going to put this code on actual hardware. I'm just preparing for my exam, and found it a bit strange. It's a pen and paper exam, so details like this isn't important
[11:22:10] <oal> But thanks for the help and suggestions :)
[13:57:47] <oal> Is there any particular reason why I have to set the high byte before the low byte on the output compare register?
[13:58:34] <oal> When I tried to set the low byte first, the high byte stayed 0 even after setting it
[13:58:35] <LeoNerd> Are you writing lowlevel ASM?
[13:58:46] <LeoNerd> The C compiler will take care of that for you
[13:58:51] <oal> Yes, I write assembly
[13:59:34] <oal> Exam preparation. I'd definitely write in C if I could :)
[13:59:40] <LeoNerd> Ah... then read carefully the various sections of the datasheet
[14:00:20] <oal> It seemed weird that it worked that way, but nothing surprises me about assembly anymore :p
[14:00:36] <LeoNerd> It's the hardware
[14:00:49] <LeoNerd> It's an 8bit CPU, 8bit data bus, so how do you "atomically" access a 16bit register?
[14:01:05] <oal> yeah, I realize that's impossible
[14:04:11] <LeoNerd> So the whole thing is done using a temporary register; when read/write the low byte, the high byte is transferred in the same direction via the TEMP register
[14:04:31] <LeoNerd> So, to read you'd read the low byte which causes the TEMP register to now contain the high byte.
[14:04:43] <LeoNerd> When you write, you have to have ensured the high byte is in TEMP first, so that when you write the low, that goes in too
[14:05:34] <oal> http://hastebin.com/oricuzimen.avrasm
[14:32:46] <abferm> Anyone have a good serial parser? I want to grab commands and doubles from a lufa virtual serial port.
[14:33:45] <LeoNerd> I tend to implement part of a state machine in the UART interrupt handler
[22:02:13] <chansdad> Hello...
[22:03:34] <chansdad> Any gurus awake?
[22:08:10] <Thrashbarg> chansdad: what's the quesion? No one's spoken in about eight hours
[22:09:06] <chansdad> Thrashbarg I am embarking on a journey to start a company in IoT space and wanted to interview couple of embedded systems developers ...
[22:09:25] <Thrashbarg> right. Well that doesn't really cover me :P
[22:09:33] <chansdad> awwww...
[22:09:42] <chansdad> whats your expertise ?
[22:10:11] <Thrashbarg> all sorts, though I'm not a profesional (yet)
[22:10:25] <chansdad> dont have to be ..
[22:10:29] <Thrashbarg> analog, digital, vacuum tubes
[22:10:53] <Thrashbarg> I hang out here because I can answer questions when I'm bored
[22:10:54] <chansdad> nice..
[22:50:44] <Vizir> is there any way to see why a microcontroller goes to reboot/bootloader after flashing my code and booting
[22:55:22] <Casper> Vizir: yes
[22:55:41] <Casper> there is a reset source flag in one register
[22:55:54] <Casper> that tell you which reset source got triggered
[22:56:16] <Casper> poweron reset, bod, reset pin and wdt
[22:57:08] <Vizir> hmm well, i know its my code. when i compile my code with an external library, it happens
[22:57:30] <Vizir> i remove the lib (i don't even have to call functions in it) from the Makefile, it works
[22:59:46] <Casper> stack overflow causing the code to do weird thing maybe?
[23:01:09] <Vizir> i doubt it... i'm using the teensy++ 2.0. and the teensy loader tells me that the hex file is only using 24% of the teensy's memory
[23:02:37] <Casper> the loader can only tell you the flash usage
[23:02:41] <Casper> not the ram usage
[23:04:07] <Vizir> hmm is there any way to check?
[23:05:48] <Casper> pen and paper
[23:06:10] <Casper> each function call eat up ram... I think it's 11 bytes
[23:06:42] <Casper> so if you call a function in a function in a function... then you're at 33 bytes of ram used just for the function calls, plus all the variables used
[23:07:56] <Vizir> ok. so that'd make sense if i was calling the functions. what if i am just compiling the files and linking them...
[23:08:57] <Casper> if no call, shouln't matter much, however, the lib may have some global variables
[23:09:03] <Casper> that eat ram even if not used
[23:09:34] <Vizir> yes it does, and instead of compiling all the source files, i only included the ones actually needed by the display