Back
[06:03:30] <ljc> hey, is there any way to test a timer within avr studio?
[06:03:44] <ljc> i'm trying to debug something but don't have a board with me
[06:04:11] <Jartza> run it in simulator
[06:04:23] <Lambda-Aurigae> avr studio and atmel studio they have a full simulator built in.
[06:04:36] <Lambda-Aurigae> beyond that, no clue how...it won't run on my computer.
[06:04:54] <Jartza> I installed windows to VM just to run atmel studio simulator
[06:04:59] <Jartza> when I was making my VGA-code
[06:05:16] <Jartza> because I needed to manually tune the synchronization timer :)
[06:05:50] <Jartza> the one, that fixes the jitter
[06:12:35] <ljc> hm maybe it's not set up right
[06:19:33] <Lambda-Aurigae> you have to compile a program and run it in the simulator.
[06:20:48] <ljc> i'm doing 'build' and then 'run'
[06:21:02] <ljc> that should work? or is there something i'm missing
[06:21:15] <Lambda-Aurigae> dunno...
[06:21:33] <Lambda-Aurigae> guessing you have to choose the simulator as your default device or something.
[06:24:37] <LeoNerd> Does anyone have a link/page/etc.. that describes in any detail what -flto actually *does* on AVR? I'm aware that the acroynm means "link-time optimisations", but what things actually are they?
[06:26:49] <cehteh> gcc manpages says
[06:27:19] <cehteh> basically it makes the objects much much bigger with lots of annotations and delays the optimization step to link time
[06:27:33] <cehteh> "the" .. some optimization steps
[06:28:03] <cehteh> or actually i think it puts the full internal rtl or whatever representation into the objects
[10:03:08] <lowin> Am I supposed to reserve memory buffers in .bss section like we do in x86? using avr-gcc
[10:03:17] <LeoNerd> ?
[13:22:44] <lowin> How come there is a subi instruction but no addi?
[13:24:10] <LeoNerd> You can do "add immediate" by subtracting a different constant
[13:24:20] <LeoNerd> ADDI 5 would be SUBI -5
[13:24:51] <LeoNerd> .. in practice I've no idea why they made SUBI the instruction; I'd have made ADDI natively and remarked "if you want to subtract a constant, just add its negation". Seems simpler
[13:24:58] <LeoNerd> But both approaches are equivalent
[13:26:55] <noqnio>
[13:27:26] <lowin> I just don't understand the underlying hardware that doesn't support both.. If there is a way to slip in an immediate into the alu unit for subtracting, why is it not possible to do the same for adding? isn't subtraction implemented on the same full adder as addition?
[13:27:56] <lowin> s/alu unit/alu/
[13:29:13] <noqnio> hey, i am having some problems compiling my code. I am including an .h file in main.c, and when i try "make" i get "undefined reference to 'functname'. How can i modify my makefile to link multiple files?
[13:29:47] <LeoNerd> compiling is not the same as linking
[13:29:58] <LeoNerd> #include'ing a .h file tells the compiler *about* your functions, that they exist.
[13:30:19] <LeoNerd> Separately the object file still has to be linked. I usually do that on AVR by just shoving all the individual .c files into one big avr-gcc line
[13:31:07] <noqnio> i tried that as well but avr-gcc complained that with my previous options (copy pasted make out line) it cant compile multiple files
[13:31:22] <noqnio> maybe i should just get over makefiles and learn gcc arguments some day
[13:32:09] <lowin> that reminds me, I used avr-gdb/simulavr to debug my code in the past, but how do I simulate input on the pins? and is there any easier way to read i/o register values other than reading their memory location in gdb?
[13:32:20] <noqnio> avr-gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files
[13:32:20] <noqnio> what does -c do?
[13:33:00] <lowin> noqnio, tells compiler to not link object files
[13:33:15] <noqnio> why would my makefile use that the
[13:33:16] <noqnio> n
[13:33:33] <noqnio> because it links them later?
[13:33:40] <LeoNerd> Maybe
[13:33:43] <lowin> Aren't you the one who wrote it in the first place?
[13:33:45] <LeoNerd> It's typical on larger software, yes
[13:33:59] <LeoNerd> Certainly on large desktop applications, you'd compile each .c into a .o individually, thne link them all at the ned
[13:34:00] <noqnio> do even people write makefiles? :D
[13:34:24] <LeoNerd> But I find that AVR programs are soooooo small in comparison to modern computers, that it's plenty fast enough just to compile and link all the .c files in one single step
[13:34:27] <lowin> Yeah I do that when I don't want to bother with auto tolls
[13:34:28] <LeoNerd> Which is what my makefiles do
[13:34:30] <lowin> tools*
[13:35:58] <antto> i compile from teh IDE
[13:36:12] <antto> codeblocks ftw
[13:36:14] <noqnio> # List C source files here. (C dependencies are automatically generated.)
[13:36:14] <noqnio> SRC = $(TARGET).c
[13:36:34] <noqnio> should i change it to SRC = $(TARGET).c,secondfile.c
[13:42:00] <LeoNerd> No idea. Depends what it does with that
[13:42:19] <noqnio> well it didn't work
[13:42:39] <noqnio> can you give me an example of a proper avr-gcc command?
[13:43:37] <lowin> avr-gcc -mmcu=atmega32 -o a.out 1.c 2.c 3.c 4.S 5.S ...
[13:44:33] <noqnio> ty
[13:44:36] <lowin> nobody knew anything about the debugging thing?
[13:44:54] <lowin> How do you guys debug your code?
[13:45:01] <LeoNerd> "for real" ;)
[13:45:12] <LeoNerd> Even on AVR, I find the carefully-placed print statement to be the best debug tool
[13:45:48] <LeoNerd> 32U4 has USB serial. real chips usually have a UART spare. If not, I have a transmit-only soft UART implementation I find good enough to attach to stderr for such use cases
[13:45:59] <lowin> where do I print to? I have like 8 clock cycles and using every single one of them
[13:46:22] <LeoNerd> Mmm.. I probably wouldn't be starting from there :)
[13:46:41] <antto> buy more clock cycles
[13:46:51] <antto> moar
[13:46:56] <lowin> 16mhz max ;_;
[13:47:25] <antto> then slow down time
[13:47:33] <antto> by changing the speed of light
[13:47:55] <lowin> guys.. seriously. there must be a way?
[13:48:20] <antto> debugging is always nasty for me
[13:48:47] <lowin> Ah screw it. I just have to finish writing the code and hope it works the first time.
[13:49:10] <lowin> Although the 100 something errors I got when I tried compiling it the first time suggests otherwise
[13:49:24] <antto> that's my favourite way
[13:59:00] <noqnio> so supposedly it says that .c dependencies are automatically generated
[13:59:20] <noqnio> shouldn't this mean that i only have to include my .h file in main then it should work?
[14:00:53] <LeoNerd> No
[14:01:13] <LeoNerd> It means that tge makefile knows which .c files need rebuilding when you change .h files
[14:04:30] <Jartza> hmmh
[14:24:06] <Jartza> lowin: there are multiple ways to debug avr apps
[14:24:13] <Jartza> either use UART and print out debug info
[14:24:38] <Jartza> the simplest option of course is to use leds to inform about different situations
[14:24:47] <Jartza> logic analyser helps a lot
[14:25:08] <Jartza> and for analog stuff, oscilloscope (well, sometimes helps with digital stuff too, as the digital signals might turn into "not so digital")
[14:25:34] <lowin> What I have is very time sensitive, hardware debugging is impossible. The only way to make it work would be simulation
[14:26:07] <Jartza> why it's impossible?
[14:26:18] * antto injects noise into Jartza's logic signal
[14:26:27] <lowin> Because i'm using time sensitive protocols?
[14:26:39] <lowin> Can't slow down hardware to debug it
[14:26:43] <Jartza> and that's exactly why you might need logic analyzer, like saleae
[14:27:01] <Jartza> what is the time sensitive protocol?
[14:27:33] <lowin> saleae sounds expensive..
[14:27:44] <Jartza> well, there are cheap-ass chinese clones
[14:27:45] <lowin> I'm working with usb, bit times are very strict.
[14:27:52] <Jartza> which of course is ripping away from saleae business
[14:28:02] <Jartza> which is why I bought original, to support them
[14:28:11] <Jartza> which usb
[14:28:38] <lowin> I really don't need anything too fancy, I just need to make sure my program works right. usb2 low speed protocol implemented using gpio
[14:29:04] <Jartza> what is usb 2.0 low speed?
[14:29:34] <Jartza> usb2 adds 480Mbit/s mode
[14:29:52] <lowin> uhh, I'm not sure I'm getting it right.. USB2 has 3 modes of speeds, is that not correct?
[14:29:54] <Jartza> usb1.0 low speed mode is 1.5Mbit/s
[14:30:19] <Jartza> well. usb1.0 defines "low speed" 1.5Mbit/s and "full speed" 12Mbit/s
[14:30:34] <Jartza> then usb2.0 added "high speed" mode of 480Mbit/s
[14:30:52] <lowin> Well yeah. and usb1 is deprecated. Every speed modes are directly in usb 2 specs
[14:32:43] <Jartza> it doesn't really state anywhere that usb1.1 is deprecated
[14:32:56] <Jartza> but so anyway
[14:33:03] <Jartza> you're using the "slow speed" mode
[14:33:09] <Jartza> which chip, which usb-stack?
[14:34:04] <lowin> I don't know how that's relevant, I'm using atmega32. I really just want something like avr studio in my university...
[14:36:11] <Jartza> I'm just wondering what you're trying to do and what is the problem
[14:38:25] <Jartza> anyhow, for slow speed usb, saleae has analyzer
[14:38:47] <lowin> Well.. full story. I'm doing a project for my micro processors course in uni, I'm implementing something that uses usb protocol to communicate with a computer.
[14:39:51] <lowin> I implemented the usb firmware myself, because using v-usb would defeat the purpose. Now I want to simulate the firmware without a $200 device just to make sure it handles basic usb commands correctly
[14:43:10] <Jartza> ah, so no hardware uab
[14:43:14] <Jartza> usb*
[14:44:09] <Jartza> well. I'm not aware of any simulator capable of running usb.
[14:45:10] <Jartza> doesn't your uni have any logic analyzers?
[14:46:48] <lowin> Maybe they do, I don't know. I can feed the usb commands by hand if I knew how I could change pin inputs in simulavr
[14:48:08] <Jartza> ahh, haven't really ever tried making "stimuli" for simulavr
[14:48:32] <Jartza> not sure it it works with simulavr. I know it's possible with simavr.
[14:51:05] <lowin> simavr.. never heard of it before. I'll give it a go tomorrow. thanks
[14:53:00] <Jartza> yeah, they have too similar name, IMO
[14:53:21] <Jartza> but simavr is the only simulator where there still seems to be some development
[14:53:50] <Jartza> all the others seem like abandoned projects
[14:53:59] <lowin> thats sad
[14:54:19] <lowin> tbh, I get a dying vibe from the whole avr community
[14:58:44] <Jartza> I don't
[14:58:59] <Jartza> but I'm getting dying vibe from beginners towards 8-bit
[14:59:23] <Jartza> I still think there's place for 8-bit mcus, but many people are gearing towards 32bit arm
[14:59:27] <Jartza> like cortex m-series
[19:08:30] <PoppaVic> whee!
[19:43:51] <carabia> Whee!
[19:45:29] <carabia> Can you do a double spi-bus analyzation on the saleae software? i.e. I think it won't parse signal values for you unless the CS defined for the bus is driven to enable
[19:46:22] <carabia> Oh nevermind. They are greyed out but apparently you can still define more buses
[19:46:33] <carabia> *to use the same inputs