Back
[05:15:54] <uramhoaH> abcminiuser, are you the batman?
[05:16:27] <abcminiuser> Youwah?
[05:18:02] <uramhoaH> i got this olimex avrispmk2, and afaiu it's largely based on your work, correct?
[05:20:15] <uramhoaH> ..if not entirely
[05:28:42] <abcminiuser> Yeah, it uses my firmware
[05:28:50] <abcminiuser> And yes, it doesn't work in AS7 at the moment
[05:29:23] <uramhoaH> so, you're the batman indeed
[05:29:57] <uramhoaH> i dont use atmel studio
[06:01:24] <uramhoaH> yesterday i was trying it out in atmel studio 7, and it worked (tho the chip i was tring to program didn't work)
[06:02:12] <uramhoaH> but imma uninstall this shizz cuz it's just.. too full of nopes
[06:30:30] <Lambda_Aurigae> have to say it, but, mplabX is better than what I've seen of atmel studio 7.
[06:30:47] <Lambda_Aurigae> not by a whole lot, but,,
[06:36:15] <uramhoaH> equally bad IMO
[06:36:34] <Lambda_Aurigae> well, mplabX has one major advantage over atmel studio.
[06:36:36] <Lambda_Aurigae> it runs on linux.
[06:36:43] <uramhoaH> tho i still think mplab takes more time to start
[06:37:54] <uramhoaH> now that i use avr again, programming the hex onto the chip seems instant
[06:38:08] <Lambda_Aurigae> hehe.
[06:38:29] <Lambda_Aurigae> I just wish there were an avr32 in a dip package.
[06:38:56] <Lambda_Aurigae> I've grown rather fond of pic32 chips in dip package.
[06:43:03] <uramhoaH> i wish there were thru-hole packages of everything ;P~
[06:43:13] <Lambda_Aurigae> yeah, me too.
[06:43:25] <Lambda_Aurigae> but, alas, some people don't like those of us with shaky hands.
[06:44:46] <Xark> Lambda_Aurigae: Seems like AVR32 ship has sailed. I got one of these, but doubt I'll do much with it ->
http://www.aery32.com/
[06:45:35] <Lambda_Aurigae> yeah..I have an stk1000 with avr32 on board.
[06:45:44] <Xark> Too bad, seemed a reasonable instruction set.
[06:45:53] <Lambda_Aurigae> I find the pic32mx270f256b to be much more functional overall.
[06:46:04] <Lambda_Aurigae> yeah...the pic32 design was nice but it never went anywhere.
[06:46:36] <Lambda_Aurigae> it got overrun by the arm processors.
[06:46:56] <Xark> ARM seems to be dominating. I thought PIC32 was doing "okay" but not spectacularly (whereas AVR32 is "dead").
[06:47:38] <Lambda_Aurigae> pic32 has a niche market...somewhere between pic/avr 8bit and the full high speed arm chips.
[06:48:25] <Lambda_Aurigae> the pic32mx270f256b is nice in the dip package with usb/usb-otg, 256K flash, 64K sram, and the ability to execute code from sram.
[06:48:58] <Xark> Yeah,
[06:49:02] <Lambda_Aurigae> I just started laying out a simple compiler for it
[06:49:09] <Xark> I have some MX250 DIPs
[06:49:20] <Lambda_Aurigae> to write in a C subset and compile code to run from sram...
[06:49:28] <Lambda_Aurigae> the compiler has to run ON the pic32.
[06:49:44] <Lambda_Aurigae> OK..gotta flit.
[07:29:38] <uramhoaH> atmel studio doesn't want to completely uninstall its things
[07:30:28] <uramhoaH> and does some very shady things
[07:32:21] <Xark> uramhoaH: It is based off of invasive Microsoft Visual Studio, so expected. :)
[07:35:46] <uramhoaH> got this atbackend.exe running two instances on windows startup
[07:36:16] <uramhoaH> and it currently has 4 instances.. and that's after i uninstalled the shiz
[07:36:39] <Xark> ...the cloud is your friend...don't fight it. :)
[07:37:14] <uramhoaH> and there is a hidden folder with a bunch of exe files with names like "a45bbb6.rbf"
[07:37:34] <uramhoaH> and binaries are by atmel, not M$
[07:37:37] <uramhoaH> shaaady ;]
[07:38:30] <Xark> Trying to capture your Microchip password, no doubt. :)
[07:38:44] <uramhoaH> i don't have such things
[07:39:31] <Xark> Then what could possibly go wrong? ;-)
[07:40:22] * Xark hasn't upgraded, Atmel Studio 6 was traumatic enough...
[07:58:05] * twnqx used atmel studio once
[07:58:14] <twnqx> to get proof of concept screenshots of reading back atmel chips.
[08:07:20] <uramhoaH> i installed it yesterday cuz i was running out of ideas why the avrispmkii+xmega isn't working
[08:07:30] <uramhoaH> and someone told me to try with atmel studio
[08:07:47] <uramhoaH> who was it.. some evil person it must have been
[08:14:44] <flutterbat> is professional development even possible without atmel studio?
[08:15:01] <flutterbat> im talking about all the debug features
[08:16:04] <flutterbat> vim+makefil+avrdude is all nice and good. but the debugging is a nightmare
[08:20:34] <uramhoaH> bugs? who writes bugs
[08:20:39] <uramhoaH> we don't
[08:21:28] <uramhoaH> if something doesn't work - blame the chip/programmer/5volts/cosmos/god/etc
[08:22:24] <cehteh> one pin, one LED thats your debugging output. if you need more you failed :D
[08:48:04] <LeoNerd> I usually manage to achieve quite a lot of debug with an LA, a spare pin or two, or a UART console...
[08:48:32] <Tom_itx> LA has fixed any problems my led couldn't handle
[08:48:32] * LeoNerd also intending to get around to working on dW one day
[09:02:44] <uramhoaH> LA?
[09:16:52] <|DM|> Theres nothig stopping you from using debugwire yourself
[09:17:30] <|DM|> Also its possible to use a single pin + a single interrupt to step through your code, in circuit, one by one
[09:18:13] <|DM|> Because avr allows an opcode to complete its execution before an interrupt takes over
[09:19:10] <cehteh> just impractical to debug timing errors
[09:20:39] <cehteh> i am thinking about adding a 'linux' target to my projects which compiles the code under linux, needs stubs for hardware emulation. but at least the logic can be debugged much easier this way
[09:24:38] <uramhoaH> in my case, i can simply open my project under linux and compile it
[09:25:17] <uramhoaH> codeblocks/avrgcc/avrdude .. it's all there
[09:25:45] * uramhoaH doesn't like makefiles
[09:31:20] <Jartza> evening
[09:49:22] <uramhoaH> evening was not declared in this scope
[09:50:59] <cehteh> uramhoaH: compile it as linux program you can run from command line i meant
[09:51:43] <uramhoaH> wut
[09:52:01] <uramhoaH> run the thing on teh comput0r?
[09:52:06] <cehteh> yes
[09:52:17] <uramhoaH> but that's.. so wrong
[09:52:22] <cehteh> why?
[09:52:34] <cehteh> thats truely portable then :D
[09:53:11] <cehteh> i meant only for debugging the logic, with stubs for the hardware parts
[09:53:24] <uramhoaH> well, i guess.. it depends on what the code is supposed to be doing
[09:53:47] <uramhoaH> if it doesn't deal with external circuits and modules - fine.. but then.. why avr in the first place
[09:55:01] <uramhoaH> ah, i've made some small console apps to test certain algos since i couldn't test them yet on the uC
[09:55:39] <uramhoaH> like.. algos for detecting spi eeprom size, and sorting data in an eeprom with minimum number of rewrites
[09:56:16] <uramhoaH> that's not fun
[09:56:44] <cehteh> thats the idea
[09:57:17] <uramhoaH> but.. it's never exact, unless you can sorta simulate the avr somehow
[09:57:23] <cehteh> debug the logic on the pc, provide stubs for hardware things you cant easily test/emulate
[09:57:50] <cehteh> nah, hardware stuff needs to debugged on the hardware of course
[09:58:01] <uramhoaH> well, you can compile the main(), but how about the interrupts?
[09:58:08] <cehteh> there are some simulators,
[09:59:41] <cehteh> implement stubs for that on demand, signal handlers, ... but interrupts are somewhat hardware bits, thats not what i aim for
[10:00:02] <Jartza> there are lot of simulators
[10:01:06] <Jartza> simulavr, simavr, the one with atmel studio etc...
[10:02:40] <uramhoaH> oh lord, i forgot to sei()
[10:06:51] <|DM|> oh my, I forgot to remove -nostartfiles from my makefile before sei()
[10:16:02] <Jartza> oh my. I didn't forget anything
[10:25:19] <Haohmaru> you did
[10:25:28] <Haohmaru> you forgot to encourage people
[10:25:47] <Haohmaru> u know what that means, dontcha?
[10:33:38] <Haohmaru> PMIC.. peripheral module interrupt control?
[10:33:40] <Haohmaru> dayum
[10:34:25] <Haohmaru> oh no, programmable multilevel interrupt controller
[10:34:39] <Haohmaru> so sei() isn't enough
[10:34:53] * Haohmaru intensifies
[10:39:17] <Haohmaru> yey.. interrupt-based, buffered usart working on le xmega
[12:34:22] <majkrzak> Hi, do you know any avr simulator that is able to simulate uart?