Back
[01:01:14] <flapz> moin.
[01:01:59] <flapz> AVR Studio lets you step through your code, and debug it (using the avr dragon). But it's only for windows. Is there a avr debugger for linux ?
[01:04:59] <N1njaneer> Probably just GDB.
[01:05:52] <N1njaneer> AVR Studio is one of the best IDE's for toolchain ease of use and debugging that exists. Believe me, I've used just about all of them at this point. :)
[01:06:14] <N1njaneer> And it's FREE - can't beat that.
[01:06:25] <N1njaneer> It's truly worth installing Windows for :)
[01:06:38] <N1njaneer> (Or trying to get it to run under Wine, which I'm curious if it would work)
[01:06:42] <flapz> Ok I'll throw windows on VirtualBox and just forward the serial port
[01:06:53] <flapz> It might crash under wine.
[01:07:00] <N1njaneer> I'd give that a try.
[01:07:28] <N1njaneer> Also, if you are doing your own hardware, you should invest the $30 in an ATMEL-ICE, as it will program and debug ANYTHING in both the AVR and SAM (ARM) series of parts :)
[01:07:40] <N1njaneer> And it's USB :)
[01:08:11] <N1njaneer> And now after having suffered IAR Workbench for the last few hours, I'm off! Night all. Good luck, flapz! Let me know how it turns out.
[01:08:28] <flapz> yup thanks.
[01:44:23] <virtuald> why is it only for for windows? they should get with the times.
[06:31:03] <aandrew> AVR-gcc is the times
[06:32:53] <LeoNerd> Mmm?
[06:46:45] <Lambda_Aurigae> atmel doesn't want to be like microchip who has a multiplatform IDE.
[06:47:26] <Lambda_Aurigae> and atmel studio will not run under wine. I got an older version to install but it locked up and died constantly.
[06:47:31] <Lambda_Aurigae> the new one is even worse.
[06:48:58] <ecilop> I do not need "avr studio" under linux.
[06:50:14] <ecilop> Newest "avr studio" (v 6.x) is monster with M$ .NET crap
[06:52:03] <ecilop> Requirement of "visual studio" for avr... silly thing ever
[06:53:15] <ecilop> "avr studio" 5.19 - last usable IDE from Atmel
[06:56:35] <Lambda_Aurigae> I have never "needed" avr studio.
[06:56:40] <Lambda_Aurigae> it was fun to play with back in the day.
[06:56:51] <Lambda_Aurigae> when I bothered to have a windows install around.
[06:57:25] <Lambda_Aurigae> but I never got anything done with avr studio..nor atmel studio.
[06:57:41] <LeoNerd> I tend to run with vim+make+avr-gcc
[06:57:44] <ecilop> IAR - good propietary IDE for M$ Win
[06:58:03] <ecilop> kate + avr-binutils + avr-gcc
[07:00:32] <Lambda_Aurigae> kate or gedit or mousepad or vi
[07:00:39] <Lambda_Aurigae> or edlin in a pinch.
[09:10:48] <rue_more> nedit rules
[11:07:35] <Jartza> 18:43 < Jartza>
https://github.com/Jartza/homebrew-avr
[11:07:35] <Jartza> 18:43 < Jartza> if someone is brave, that can be tested ;)
[11:07:35] <Jartza> 18:44 < Jartza> it's my first-ever homebrew, so it might burn your computer and cause holocaust
[11:07:38] <Jartza> 18:44 < Jartza> might be done really stupidly, but anyways... if someone wants compiler that supports attiny841
[11:08:53] <LeoNerd> Wouldn't it be easier to install Linux in a VM and run the Linux gcc-avr? ;)
[11:33:39] <tpw_rules> hmm. i snhould have used that in my project
[11:35:17] <tpw_rules> i want an attiny that can do usb host
[11:35:21] <tpw_rules> actually
[11:35:29] <LeoNerd> Too slow
[11:35:52] <tpw_rules> does that one support the 16mhz fast pll?
[11:37:14] <LeoNerd> You need 12MHz for USB, or rather.. some high multiple thereof if you want to host
[11:37:47] <LeoNerd> The tinies can only do low-speed USB at 1.5MHz because 12/8=1.5
[11:38:22] <tpw_rules> huh, no it doesn't have the 16mhz clock like the 85 (afaict)
[11:38:54] <LeoNerd> The 841?
[11:38:56] <tpw_rules> yeah
[11:39:13] <LeoNerd> The 841 is *basically* just an 84, only with two UARTs, real SPI and a real slave-only(??!!!) I2C module instead of the single USI
[11:39:36] <tpw_rules> did the 84 not have the fast rc clock either?
[11:40:01] <tpw_rules> if i wanted usb host, i'd probably need to do a dual-processor system anyway. being slave on two different busses is difficult
[11:40:06] <LeoNerd> Yah
[11:40:40] <tpw_rules> have you ever had an snes?
[11:41:18] <d-rock> Is the differential ADC mode on, say, an attiny useful for replacing an instrumentation op-amp, or should I just stick with the in-amp for better noise reduction? I know enough electronics for simple circuits but reading the datasheets on in-amps indicates a lot of complexity
[11:42:06] <LeoNerd> in-amp?
[12:05:39] <vsync> guess he means the op amp
[12:06:00] <vsync> or op amps, in his intrumentation amp
[12:06:39] <vsync> i'm too lazy to read, but i'll just say it greatly depends on your application
[13:22:58] <Jartza> hmmh
[13:23:12] <Jartza> seems my homebrew rule is borken
[13:47:17] <Jartza> well. now it might work.
[16:46:17] <aandrew> what's the atmel programming "mode" which is described as "in system programmable via SPI port" in the datasheet?
[16:46:20] <aandrew> is that just ISP
[16:46:42] <aandrew> trying to figure out whether to use ICSP10, PDI or TPI on this olimex prgrammer :-)
[16:47:17] <N1njaneer> Yes, that's SPI
[16:47:33] <N1njaneer> Though with the addition that it needs to also associate the reset signal to get it in to SPI programming mode
[16:47:43] <aandrew> right ok
[16:47:48] <N1njaneer> Are you designing something?
[16:48:12] <aandrew> no, I have an attiny25 that was being... problematic with the old olimex programmer I had
[16:48:18] <N1njaneer> Oh, okay :)
[16:48:20] <aandrew> it works fine with the dragon but I don't like using that if I don't have to
[16:48:44] <N1njaneer> Just spend $30 and get an ATMEL-ICE and you're good for every AVR and SAM-ARM part out there :)
[16:50:04] <aandrew> atmel ice is $80 on digikey
[16:50:21] <aandrew> avr-isp-mk2 is $36
[16:51:35] <aandrew> ah I see
[16:51:39] <aandrew> pdi is xmega-specific
[16:51:43] <N1njaneer> ISP-MK2 is now EoL and no longer avaliable
[16:51:48] <aandrew> tpi is 6-in tiny specific
[16:51:55] <N1njaneer> ATMEL-ICE is avaliable as the raw PCB version for $30
[16:51:56] <aandrew> isp is mega/tiny > 6pin
[16:52:04] <aandrew> N1njaneer: I'm not seeing that on digikey
[16:52:39] <N1njaneer> DigiKey: ATATMEL-ICE-PCBA-ND, sorry, $40 :)
[16:53:07] <aandrew> hm, I am blind
[16:53:12] <aandrew> er no, $52.71 (CAD)
[16:53:13] <N1njaneer> And if you can tell me what "-ND" means in a DigiKey part number, you get a huge cookie and $1M in Monopoly monies.
[16:53:19] <aandrew> I used to know this
[16:53:35] <N1njaneer> That's fun trivia!
[16:54:07] <aandrew> I used to say "new device" but I think it's something about pricing
[16:54:27] <N1njaneer> The latter.
[16:55:13] <Jartza> well
[16:55:22] <Jartza> now I got 2 leds blinking on attiny841
[16:55:25] <Jartza> https://github.com/Jartza/homebrew-avr
[16:55:34] <N1njaneer> Specifically it stands for "No Discount" but since it's on ALL parts these days it's actually pretty meaningless :)
[16:55:49] <N1njaneer> Jartza: Congrats!
[16:55:49] <Jartza> that was a bit of a challenge, but at least that homebrew-formula "works for me"
[16:55:56] <Jartza> N1njaneer: thanks :)
[16:56:14] <Jartza> I even made a video :D
https://www.dropbox.com/s/fohwq1eukh8rwiq/1424212053.mp4
[16:56:59] <N1njaneer> Looks promising!
[16:57:36] <Jartza> well, avr-gcc now recognizes attiny841 as mcu and the code compiles and led blinks. at least something is working.
[16:57:55] <LeoNerd> :)
[16:58:07] <Jartza> and same time I also got updated avr-gcc, libc and binutils, which is nice
[17:05:32] <Jartza> it seems no fuse calculator supports that part yet
[17:23:51] <Jartza> well, timer also works
[17:53:10] <awozniak> I'm having trouble setting up a timer on an atmega2560, and could use a second pari of eyeballs. code at
http://pastebin.com/ZupHY3K5
[17:53:18] <awozniak> *pair
[17:59:04] <N1njaneer> awozniak: Have you turned on global interrupts with an sei?
[17:59:11] <N1njaneer> Else your interrupts won't be firing :)
[17:59:20] <awozniak> good thing to double check. =)
[17:59:41] <awozniak> You're not an ingress player in San Luis Obispo, are you?
[18:00:37] <N1njaneer> I am not, I'm in Cleveland, OH :)
[18:01:30] <awozniak> That helped, Thanks N1njaneer
[18:01:57] <N1njaneer> Sure thing! Sometimes it's the little thing easy to overlook! :)
[18:03:21] <N1njaneer> +things
[18:08:43] <vsync> Jartza: quality videos as always. you truly deliver. much obliged.
[18:09:53] <N1njaneer> I wish I could post more videos of the stuff we work on here, but unfortunatly a lot of it's under NDA :(
[18:10:20] <N1njaneer> I'll just have to find more stuff I CAN post :)
[18:10:43] <N1njaneer> I'll also do some ustreams here if people would find it interesting.
[18:11:18] <vsync> Jartza could you also provide extensive documentation (i really need some interesting reads while taking dumps), and preferably a novel and sell me the film rights to said masterpiece
[19:07:50] <scrote> moin.
[19:08:33] <scrote> I ordered an atmega328p from sparkfun and I can't program it with my arduino uno like I can with the other dip package that came with the uno.
[19:09:07] <Tom_itx> the other one probably has their bootloader in it
[19:09:21] <Tom_itx> the sparkfun one is blank
[19:09:33] <Tom_itx> (like they all should be)
[19:13:41] <scrote> Oh so I have to up load a bootloader first?
[19:13:53] <Tom_itx> if i were guessing, yes
[19:14:08] <Tom_itx> you need an ISP programmer for that
[19:14:24] <scrote> Can I upload a bootloader through the uno shield?
[19:14:26] <Tom_itx> and knowledge of bootloader fuses etc
[19:14:40] <Tom_itx> i'm not sure you can set the fuses with it
[19:14:57] <scrote> If I have an ISP programmer, then a bootloader is redundant. right?
[19:15:57] <scrote> Is a bootloader like a typical sketch?
[19:16:31] <Tom_itx> in answer to the first q, yes
[19:16:47] <Tom_itx> a bootloader isn't a sketch
[19:16:53] <scrote> ok
[19:17:13] <scrote> that explains why you need a speciffic device to upload one (the avr programmer).
[19:20:45] <Tom_itx> scrote read atmel's app note 109
[19:20:53] <Tom_itx> pretty sure that's the one...
[19:21:15] <aandrew> so is "arduino compatible" really just an mega8 with a specific bootloader?
[19:21:40] <Tom_itx> that's it.
[19:21:42] <N1njaneer> Yep.
[19:21:49] <vsync> arduino compatible is
[19:21:49] <Tom_itx> not mega8, mega328
[19:21:51] <Tom_itx> etc
[19:22:05] <N1njaneer> aandrew: And the Arduino bootloader is generally just an implementation of STK500 communications protocol.
[19:22:38] <vsync> holy shit --
[19:22:40] <vsync> stk500
[19:22:49] <vsync> biggest fail there ever was
[19:22:56] <vsync> burn it burn it with fire
[19:22:58] <N1njaneer> We build custom "Arduino" boards here for customers regularly - we just load the Arduino bootloader on and away it goes.
[19:23:00] <vsync> and kill it dead
[19:23:00] <aandrew> vsync: why's that?
[19:23:28] <N1njaneer> BUT we've managed to sway them to using Atmel Studio directly and putting on the Big Boy pants in recent months, because they realize the shortcomings Arduino has :)
[19:23:39] <aandrew> hm
[19:23:46] <vsync> hahah
[19:23:58] <N1njaneer> And gee... ACTUAL debugging?
[19:24:08] <vsync> atmel studio, integration and debugging vvvveeery nice
[19:24:08] <N1njaneer> That's what I never got about Arduino, among other things.
[19:24:16] <vsync> ASF, really huge pile of dogshit
[19:24:36] <N1njaneer> People who are programming simple stuff for the first time are the ones that REALLY need the ability to single-step code. And Arduino has no way to do that.
[19:26:34] <N1njaneer> ASF is a nice foundation to give you working examples and some documentation, but it's far from a panacea to all your problems. It CAN get certain things up and going quickly (like attaching to an SDCARD and allowing you to use normal file functions to manipulate the files) but that can be a curse if you hit a glass ceiling with functionality and need to dig deeper :)
[19:27:05] <scrote> Well I put the dip on the breadboard. I just use the uno to upload sketches.
[19:27:06] <vsync> most of it seems bloat as fuck
[19:27:21] <N1njaneer> I've found ASF to be FAR more useful when dealing with Atmel's SAM parts, where it's 10x more complicated to set up peripherals than on AVR.
[19:27:31] <vsync> N1njaneer: yeah. same.
[19:27:41] <N1njaneer> vsync: It's absolutely bloated, because they've written the stuff to be able to target too many part series.
[19:27:57] <vsync> yeah
[19:28:02] <N1njaneer> It's why on many thing I've taken the core of what's in the ASF and basically distilled it down in to my own libraries that make it a lot simpler.
[19:28:15] <vsync> yeah. i'm working on doing so myself
[19:28:37] <N1njaneer> I also dislike the fact that ASF doesn't play well with C++ -- ASF is all in straight C and USUALLY there aren't problems, but you occasionally have to do some tricks in dealing with calling ASF functions from C++
[19:29:18] <vsync> I'm not working with powerful enough chips that i'd have a clear advantage of that, I think
[19:29:37] <N1njaneer> I find C++ useful from an organizational standpoint for embedded stuff, even just from the aspect of being able to have methods and data wrapped unambiguously with objects, even if you're never using C++'s fancier functionalities.
[19:30:01] <vsync> buuuutttt it ends up being bloatier than c
[19:30:17] <N1njaneer> It really depends on what you are doing.
[19:31:04] <N1njaneer> C works for very simple stuff, but when you start having to deal with multiple instantiations of things, you suddenly have to start manually passing around context information between common functions, rather than referring to functions and methods that are attached directly to the objects.
[19:32:05] <N1njaneer> i.e. with a nicer serial port library, you can just do a "Serialport portA, portB;" and then portA.init(UART1, 38400); and portB.init(UART2, 38400); or whatever
[19:32:13] <N1njaneer> And then deal with portA and portB seperately
[19:32:42] <N1njaneer> Versus having to have a common set of serial port functions in straight C, then manually pass around a context instance to work with them, etc.
[19:33:29] <N1njaneer> You can also start to use run-time compositing of functionality, too, so you can write a FIFO seperately, then attach the FIFO handler directly to the serial port objects if it makes sense for a particular application, etc.
[19:35:01] <N1njaneer> I've just found the C++ notation to considerably lessen the buden of mentally managing everything going on, and if you are using a code-aware IDE, you get the helpful hints of what functions and methods are avaliable when you have an object pulled up. You just dewll after the "." or "->" and things like Eclipse, Visual Studio, and IAR/Kiel will give you a drop-down of what's avaliable to do. Versus
[19:35:01] <N1njaneer> having to go dig through header files, etc. :)
[19:35:11] <N1njaneer> Anyhow, gotta find what works for you. I'll get off my soapbox now XD
[19:39:35] <N1njaneer> vsync: What I'd love to do in my infinite spare time is to create a very nicely documented set of C++ classes for interacting with all of the peripherals in the SAM4 series of parts, which is what I'm spending a majority of my time developing on these days.
[19:39:58] <N1njaneer> I've started doing that slowly based on the ones that I specifically need to work with, though, as the application needs arise.
[19:40:06] <vsync> infinite. interesting
[19:41:23] <N1njaneer> And my infinite I mean non-existant.
[19:41:25] <N1njaneer> +by
[19:41:48] <N1njaneer> i.e. if someone's not paying me to do it, it generally doesn't get done. :)
[20:11:20] <tpw_rules> N1njaneer: i think you'd need to be very careful about how this ends up being compiled out
[20:11:50] <tpw_rules> oh, aren't sam all arm-based?
[20:14:10] <N1njaneer> Correct.
[20:14:33] <tpw_rules> oh okay. because i was always suspicious of trying to do c++ on a part with 2K ram
[20:14:49] <tpw_rules> have you used any of the cortex m0s?
[20:14:50] <N1njaneer> I use C++ on AVR's semi-regularly.
[20:15:19] <N1njaneer> Yes, SAMD20 and Nordic's NRF51822 thus far in M0/M0+
[20:15:33] <tpw_rules> is it possible to do a usb host on them?
[20:15:57] <N1njaneer> Host, or OTG?
[20:16:06] <vsync> at least on the D21 you can
[20:16:19] <tpw_rules> what's the difference? not quite familiar
[20:16:28] <N1njaneer> Yes, SAMD21 has USB on it.
[20:16:52] <tpw_rules> are there any 8/12 pin chips with USB?
[20:17:07] <N1njaneer> tpw_rules: Do you want to plug a device in to the D21 (like a USB keyboard) or do you want to plug the D21 in to a host PC to work AS a keyboard, etc.
[20:17:09] <vsync> atmel's stuff sucks for USB
[20:17:20] <vsync> you are better off looking at microchip for that
[20:17:23] <tpw_rules> i want to plug in a usb keyboard or mouse (not at the same time)
[20:17:24] <N1njaneer> vsync: Howso? I've not had any problems with it.
[20:17:32] <vsync> N1njaneer: yeah but the variety
[20:17:33] <aandrew> vsync: curious why you hate stk500 so much
[20:17:55] <N1njaneer> tpw_rules: Yeah, you'd have to implement USB as a host or possibly as OTG
[20:17:57] <vsync> aandrew: it's a clusterfuck, and i've had problems with certain avrs with it
[20:18:31] <N1njaneer> tpw_rules: Confirmed on datasheet that SAMD21 will do both host and peripheral modes :)
[20:18:43] <aandrew> fair enough, I don't have as much experience with it so I was curious
[20:19:30] <N1njaneer> vsync: I have thousands of devices out there using ATMEGA32U2's on a HID interface and haven't had any problems with them. :)
[20:19:55] <tpw_rules> what's the smallest device with host?
[20:19:55] <N1njaneer> Dean's LUFA libraries can also take away much of the heavily lifting, especially for implementing CDC's
[20:20:14] <tpw_rules> i'm currently using an attiny85 with ps/2 keyboards or mice and i'd like something similar
[20:20:18] <N1njaneer> tpw_rules: You should be able to use an ATMEGA32U2 if you really wanted to.
[20:20:24] <vsync> exactly, but microchip even offers USB on DIP. And i'm 110% sure you can prototype a slow usb on veroboard
[20:21:09] <tpw_rules> and i also need very very low interrupt latency
[20:21:13] <tpw_rules> vsync: have a part in mind?
[20:21:23] <N1njaneer> Generally no one uses DIP in the production world anymore, though, so it's not a primary concern for the chip vendors :)
[20:21:34] <tpw_rules> i want something small and cheap
[20:21:38] <N1njaneer> And that's why you can always get adapter break-out boards, too, if you really need it. :)
[20:21:38] <vsync> i don't think we were talking mass production at all
[20:21:48] <tpw_rules> 32 pins is many pins
[20:21:50] <vsync> N1njaneer: yeah, but bulky
[20:22:02] <N1njaneer> DIP is bulky :)
[20:22:03] <vsync> and adapters are actually quite expensive
[20:22:10] <vsync> not for prototyping, no
[20:22:16] <vsync> if you need it done _today_
[20:22:24] <vsync> and can't wait for that board patch from china
[20:22:59] <N1njaneer> That's what BareBonesPCB.com is for -- single day board turns for cheap :)
[20:23:10] <N1njaneer> At least if you're in the US
[20:23:17] <vsync> yeah.
[20:23:27] <vsync> for europe, a single day turn wouldn't be cheap
[20:23:37] <vsync> the shipping would be insanely high
[20:24:10] <tpw_rules> N1njaneer: that datasheet for the 32u2 has a ps/2 block but no info in the data sheet?
[20:24:20] <N1njaneer> Else I cheat - I have an old Phasor printer here I got off eBay. I have 5 mil FR4 copper sheets sitting here. I just do the layout and send straight to the printer, run the board through, put in the etchant bath. You have an SMT-ready board done in about 10 minutes if you can get everything on to one layer :)
[20:24:45] <aandrew> N1njaneer: apcircuits is similar in Canada
[20:25:09] <N1njaneer> But generally everything else I just send as barebones if we really need a quick turn, or else it's all 4 layer anyhow and I use 66each.com from Advanced and have them in a week.
[20:25:43] <aandrew> almost all my boards come from Hackvana now
[20:26:10] <N1njaneer> tpw_rules: PS2 is easy enough to just implement bit-bang if you have to.
[20:26:19] <N1njaneer> Lemme look at the datasheet
[20:26:21] <tpw_rules> yeah, but i was wondering why it was there
[20:26:27] <tpw_rules> it's under usb and connected to the usb lines
[20:27:12] <N1njaneer> What page?
[20:27:28] <tpw_rules> on the block diagram at the front
[20:27:35] <tpw_rules> page 3
[20:27:43] <N1njaneer> Oh yeah I see that
[20:28:27] <tpw_rules> but i can't find any reference to SDATA or PS/2 in the rest of the document
[20:29:39] <tpw_rules> i mainly just want something with not as many darn pins
[20:30:03] <N1njaneer> Yeah, that's weird. My guess is that it might have been a remnant from a copy/paste when Atmel was putting the datasheet together.
[20:30:15] <tpw_rules> what sort of interrupt windows are there? i need to be able to interrupt within a few cycles
[20:30:37] <tpw_rules> even if we're in the usb portion
[20:30:47] <N1njaneer> Interrupts will usually service within a few clock cyles on AVR architecture.
[20:31:11] <tpw_rules> well yeah. but i know that v-usb has long portions in which interrupts will not be serviced because the usb engine is busy
[20:31:18] <vsync> http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC16F1454
[20:31:19] <N1njaneer> Though obviously depends on what you are doing :)
[20:31:23] <vsync> 14 pins
[20:31:36] <tpw_rules> i dunno, pics always kinda disgusted me
[20:31:56] <N1njaneer> tpw_rules: But since it's a dedicated USB peripheral, the hardware takes over the heavy lifting vs bit-bang USB, which I am dubious of even meeting the standard.
[20:32:03] <tpw_rules> yeah
[20:32:07] <tpw_rules> well v-usb is device only
[20:32:20] <N1njaneer> tpw_rules: I have the same feelings toward PICs :)
[20:32:39] <tpw_rules> i've worked with SX chips before and programming them in assembly was horrid
[20:32:50] <vsync> it's like anal sex, at first it hurts, then you'll learn to love it
[20:33:00] <N1njaneer> Atmel REALLY has a good thing going, honestl.
[20:33:01] <vsync> and shut up about assembly, there's no need for that -
[20:33:06] <tpw_rules> anal sex where you can only use 1/4 of the hole at once
[20:33:13] <vsync> tpw_rules: idiot.
[20:33:21] <tpw_rules> it is for my project. why do you think i'm so concerned about interrupt timing
[20:33:32] <tpw_rules> maybe they've fixed it
[20:34:20] <N1njaneer> I have had to suffer MSP430, SiLabs EM3587 (Cortex M4) and Nordic NF51822 with various toolchains and frameworks through this latest project. The hardware isn't too bad (save for MSP430) but the toolchains are absolute garbage compared to Atmel Studio. And IAR is $5K for the license!
[20:34:28] <tpw_rules> like ugh just memory map the stack plx
[20:35:05] <N1njaneer> (51822 also being Cortex-M0)
[20:35:19] <tpw_rules> "there are up to 80 bytes of gpr in each data memry bank"
[20:35:20] <tpw_rules> ojasdfoija
[20:35:21] <vsync> IAR is awesome, I hear
[20:35:27] <tpw_rules> so they didn't fix it
[20:35:27] <N1njaneer> IAR is rubbish
[20:35:38] <vsync> Sure.
[20:35:49] <vsync> atmel's where its at?
[20:35:54] <vsync> it's
[20:36:04] <N1njaneer> Dean put it best on here a while ago: "If I could pay a licensing fee to never have to use IAR again, I would gladly pay it."
[20:36:13] <tpw_rules> i don't know if even the 48 mhz pic will be fast enoough
[20:36:24] <tpw_rules> considering it's not 1mips/mhz and the memory banking is so weird
[20:36:25] <Tom_itx> heh
[20:36:38] <vsync> tpw_rules: i'm really wondering wtf is it that you're doing?
[20:36:54] <N1njaneer> vsync: Having used/suffered a half-dozen different embedded toolchains thus far, yes... Atmel Studio is above and beyond the best out there by far. AND FREE.
[20:36:55] <hackvana> Greetings folks. aandrew, thanks for the shout :-)
[20:36:59] <tpw_rules> this is gonna sound really dumb but you know mario paint? i'm making a device so you can use a computer mouse instead
[20:37:29] <tpw_rules> but the problem is once the snes asserts its lines, you have maybe 5 cycles even at 16mhz to get data out
[20:37:30] <vsync> and you don't think a 48mhz pic runs fast enough? =D
[20:37:39] <vsync> Sure.
[20:37:50] <vsync> i think you need x86 for that. for sure.
[20:37:54] <N1njaneer> tpw_rules: Just do some dedicated hardware assist if necessary, or a second processor.
[20:38:20] <tpw_rules> i thought the pic was 4 cycles per insturction though
[20:38:29] <tpw_rules> i have it working great with ps/2 and an attiny85
[20:38:36] <N1njaneer> Or adventerous and write a state machine in an FPGA to handle all that communications :)
[20:38:51] <vsync> low pin count, fpga, does not compute
[20:38:59] <tpw_rules> well yeah but then the end result isn't like one $2 chip and a couple bypass caps
[20:39:08] <N1njaneer> Then use a CPLD :)
[20:39:15] <tpw_rules> it's still not
[20:39:19] <N1njaneer> Sometimes you can't always get what you want without tradeoffs :)
[20:39:36] <tpw_rules> vsync: that pic says "FS device" speed? i need host
[20:39:45] <tpw_rules> "USB (ch, speed, compliance) 1, FS Device, USB 2.0"
[20:39:47] <N1njaneer> I would just use a SAMD21 and call it good. Tiny part, lots of speed.
[20:40:21] <N1njaneer> Could even get an Atmel SAMD21 XPlained dev board and hack it on that first :)
[20:40:36] <tpw_rules> where can i buy raw chips? how much are they
[20:41:20] <tpw_rules> oooh, the dev board has one user yellow LED!
[20:41:23] <N1njaneer> SAMD21 is typically $3-$5/ea in single quantity form.
[20:41:30] <tpw_rules> oh, that cheap? hm
[20:41:42] <N1njaneer> DigiKey, Mouser, Arrow, etc.
[20:41:46] <tpw_rules> is it possible to work with it on a linux toolchain?
[20:42:14] <N1njaneer> gcc fully supports ARM, so you could if you really wanted to. But it's worth just using Atmel Studio.
[20:42:34] <tpw_rules> ehh. maybe
[20:42:55] <tpw_rules> i may have to give that a more detailed look. it does look pretty schmick
[20:42:58] <N1njaneer> Because you tell it the chip you want to use and it automatically builds the project and adds all the stubs, and you just add code.
[20:43:16] <N1njaneer> And with a $40 USD ATMEL-ICE you get the full USB connectivity, code upload, debug, etc.
[20:43:22] <N1njaneer> AND IT WORKS EVERY DAMN TIME.
[20:43:25] <tpw_rules> well yeah but i'm cheap :(
[20:43:32] <N1njaneer> I can't say the same for ANY other toolchain I've ever used.
[20:43:34] <tpw_rules> i'm using a usbtiny for the avrs
[20:43:39] <tpw_rules> mine works pretty perfectly
[20:44:16] <tpw_rules> i've also got a simulator set up so i can single-step with a previous logic capture from the snes
[20:44:25] <tpw_rules> i don't think that's possible with atmel studio ;)
[20:44:25] <N1njaneer> Dude, that's the cheapest you'll ever get. Free toolchain which is second to none and a $40 full-blown JTAG ICE programmer. Versus $5K for and IAR/Kiel seat, plus $500 for a decent SEGGER interface :)
[20:45:16] <tpw_rules> what is IAR anyway?
[20:45:17] <tpw_rules> or segger
[20:45:22] <tpw_rules> is that pic stuff?
[20:45:29] <N1njaneer> The ATMEL-ICE will also target every AVR and every SAM via ISP, SWD, JTAG, DW, etc
[20:46:06] <vsync> however, e.g. the KIEL compiler blows gcc out of the water
[20:46:35] <N1njaneer> tpw_rules: IAR Workbench (
https://www.iar.com/) is a well-respected toolchain, Segger (www.segger.com) makes the backend of practically every professional JTAG interface on the market.
[20:47:07] <N1njaneer> vsync: Of course, because Keil *IS* ARM, written by the same guys who define the actual processor architecture :)
[20:47:09] <tpw_rules> vsync: does it $5k blow it out of the water?
[20:47:22] <N1njaneer> And you'll pay for that benefit :)
[20:47:30] <vsync> tpw_rules: no.
[20:48:23] <N1njaneer> TI is about the closest in similar style, as Code Composer Studio is TI's toolchain for MSP430 and their DSPs. They make the hardware AND compiler, so they work well together. CCStudio is AMAZINGLY impressive on their high-performance DSPs, but again, you'll pay $5K for it.
[20:50:23] <N1njaneer> Atmel licensed Visual Studio's IDE from Microsoft, which is arguably one the best in the way of overall IDE feel, code-context awareness, overall project management, and rock-solid stability. Atmel then married on avr/arm-gcc and gdb on the back end and then added the entire ASF on top of that to boot. It works and compiles and uploads and debugs perfectly EVERY time. No other toolchain I've worked
[20:50:23] <N1njaneer> with even comes close. Like, if it says "Eclipse hosted" stay very, very, very far away.
[20:50:43] <tpw_rules> well i'll take that into consideration. sounds like i have a lot more work to do. i may need to make this multiprocessor...
[20:50:44] <N1njaneer> And of course Atmel Studio is 100% free. :)
[20:51:31] <N1njaneer> I am happy to speak highly of products I like, and there are honestly very few. It works the best for what I need it to do, and I've had to suffer the alternatives.
[20:51:44] <N1njaneer> I've searched to find the "toolchain that pisses me off the least" and that would be Atmel Studio :)
[20:51:55] <tpw_rules> making it multiprocessor just seem sto slimy and cheaty :( i'm gonna be at like 1% utilization average but need the cycles
[20:51:56] <N1njaneer> It's still not perfect, but it sure is damn close!
[20:52:07] <tpw_rules> seems too*
[20:52:20] <N1njaneer> tpw_rules: Then just do multiprocessor. If you can justify the need, the decision isn't a bad one to make.
[20:52:57] <tpw_rules> well this is a limited run hobbyist product. i'm not even selling it, it's quasi-contract for a friend
[20:53:17] <tpw_rules> so making it more expensive is tough. ps/2 mice and keyboards work fine and are atill relatively readily available
[20:54:01] <tpw_rules> i mean if you're the type of person who's got an old super nintendo and a flash card for it, you probably have an old pc too
[20:54:27] <tpw_rules> hahah i like these block diagrams "HIGH SPEED BUS MATRIX"
[20:55:24] <N1njaneer> tpw_rules: On which part?
[20:55:35] <tpw_rules> just glancing thru the sam21 sheet
[21:03:33] <N1njaneer> Yeah, that's pretty aptly named.
[21:04:00] <N1njaneer> There's a lot of internal bus magic that allows peripheral access concurrency for DMA transfers and things that buys a lot of speed.
[21:47:24] <Topy44> hi
[21:47:46] <Topy44> anyone around with any experience using LUFA?
[21:47:56] <learath> Loofa?
[21:48:25] <Topy44> i am trying to use it on an atmega32u4 with the CDC module
[21:48:37] <Topy44> and trying to wrap my head around the usb stuff...
[21:49:48] <Topy44> in the documentation for USB_USBTask() it mentions that when the INTERRUPT_CONTROL_ENDPOINT token is set USB_USBTask() does not need to be called
[21:50:18] <Topy44> however there is also CDC_Device_USBTask(), which should be called before USB_USBTask()
[21:50:33] <learath> That's awesome :)
[21:51:05] <Topy44> and i am confused if i still need to call either one of them or not
[21:51:29] <Topy44> and why they even exist - shouldn't all usb stuff be interrupt-driven?
[21:51:40] <Topy44> my understanding of usb is...very loose
[21:52:42] <tpw_rules> Topy44: though i haven't read any of it, it probably means that you must set up the interrupts and call the appropriate functions when they happen
[21:53:34] <tpw_rules> they must have examples, look at those
[21:54:34] <Topy44> the CDC example is quite simplistic unfortunately, doesn't really help all that much
[21:54:49] <Topy44> i got the basics working now, though it took me something like 3 days...
[21:55:41] <Topy44> (and an atmega32u4 randomly blew up for absolutely no reason... no idea what happened there...)
[21:55:53] <tpw_rules> heh. you'll have to wait for somebody more experienced then
[21:55:56] <Topy44> as in it literally exploded, though the pcb seems to be just fine
[21:55:59] <learath> 9 times out of 10 it's "a fuse got set"
[21:56:04] <learath> wait. it assploded?
[21:56:05] <learath> how?
[21:56:21] <Topy44> well thats the thing. everything seems fine. i replaced it and the board works.
[21:56:29] <Topy44> i have absolutely no clue what happened
[21:57:00] <Topy44> i prepared myself for hours of debugging the board (its my own design and hasn't been built before)
[21:57:11] <Topy44> but... it works now...
[21:57:52] <Topy44> and the other avr worked too, then i left it to sit there for a few minutes, and when i wanted to continue working on it it didn't react - and i noticed that half of it was missing :)
[21:58:13] <tpw_rules> oh. did you short it out and blow the die up? i've done that before
[21:58:21] <Topy44> haven't touched it
[21:58:23] <Topy44> it just sat there
[21:58:26] <tpw_rules> pro tip: don't short transistors
[21:58:29] <Topy44> heh
[21:58:43] <tpw_rules> i got a transistor shell in the eyebrow
[21:58:47] <Topy44> anyway, using a current limited psu now, don't want it to blow up again :)
[21:59:02] <Topy44> already blew 2 of them (first one was my own fault)
[21:59:09] <Topy44> and those buggers are expensive
[21:59:17] <tpw_rules> i blew one up by bad programming
[21:59:46] <tpw_rules> and since it had wasted so much of my time, i decided to see if when AVR said the HVPP voltage was 12V, they actually meant 120
[22:00:20] <Topy44> yeah same here - typo in the pin definitions, set a pin as output that was pulled down by a big fet...
[22:00:21] <Tom_itx> did they?
[22:00:44] <Topy44> couple amps went through the avr for a few ms, and bye bye :)
[22:01:01] <tpw_rules> Tom_itx: it certainly caused the ready LED i attached to become illuminated
[22:01:02] <tpw_rules> so i think yes
[22:01:16] <Topy44> i really should have added current limiting resistors to all inputs
[22:01:30] <Topy44> but yeah. lazy. board is too full already anyway.