#avr | Logs for 2015-02-20

Back
[07:09:37] <grey> N1njaneer: getting a new programmer was something I was thinking about, I don't know where you're seeing the atmel-ice for $40 though? it's $98 on digikey and $100 on ebay. Looks like atmel does sell a real AVRISPMKII for around $34, directly through their own website though
[07:43:51] <Tom_itx> grey, the bare board: http://www.digikey.com/product-detail/en/ATATMEL-ICE-PCBA/ATATMEL-ICE-PCBA-ND/4753383
[07:44:35] <Tom_itx> the whole kit: http://www.digikey.com/product-detail/en/ATATMEL-ICE/ATATMEL-ICE-ND/4753379
[07:48:31] <grey> shiny! Thanks Tom!
[09:46:21] <grey> can I use the AVR-ICE on other SoC/MCU's if they support JTAG? Or is it only for atmel chips?
[13:04:54] <jacekowski> grey: unlikely
[13:05:12] <jacekowski> grey: jtag specification is not great so jtag interfaces are unlikely to be compatible
[13:09:59] <N1njaneer> It really depends on what you are doing. If it's ARM, for instance, a JLink from Segger will connnect to and talk to all ARM parts regardless of model or supplier.
[13:10:56] <N1njaneer> The JTAG programmers from specific vendors, like Atmel, are lower cost because they are generally restricted by the manufacturer to JUST working on the particular manufacturer's parts.
[13:11:28] <N1njaneer> The Atmel SAM-ICE, for instance, is just a rebranded Segger J-Link which has been restricted to work with only Atmel's parts.
[13:11:36] <grey> fun,
[13:11:43] <grey> Okay, for $45~ that's fine,
[13:12:09] <N1njaneer> Yep, because the full ARM-platform J-Link from segger is closer to $600 :)
[13:12:23] <grey> just curious, I ordered a handful of Photon's from spark.io, and while I'm happy to use their firmware stack for now I might like the option eventually to change them up, they're based on an ST chip I believe
[13:12:27] <grey> hahah yeah
[13:13:07] <grey> I'll be happy doing the AVRs from scratch, and the photon's can keep running the spark.io stack for a long time I think
[13:13:36] <N1njaneer> AVR's are definately VERY nice parts.
[13:13:53] <tpw_rules> somtimes
[13:14:15] <N1njaneer> Though the M0+ SAM devices from Atmel are now at or below the price of most mid-range AVRs and beating the pants off them in the way of capabilities.
[13:14:39] <tpw_rules> how do mips compare?
[13:14:45] <N1njaneer> SAMD20/D21 are really moving in on AVR territory.
[13:14:55] <N1njaneer> MIPS = Meaningless Indicator of Processor Speed
[13:15:13] <tpw_rules> well like i like avr because pretty much everything is a cycle
[13:15:40] <N1njaneer> You really can't compare them, because its 8 vs 32 bit architecture, more compacted instruction set for ARM, caches, DMA, and 48Mhz core for SAMD20/21.
[13:16:23] <N1njaneer> compare them +directly
[13:16:23] <tpw_rules> is it real-timier? how is interrupt latency?
[13:17:27] <N1njaneer> Interrupts are generally MUCH faster on ARM because you don't have to save registers explicitly to the stack. There are multiple register modes that are engaged depending on the mode of the processor, etc.
[13:19:06] <tpw_rules> there must be some catch
[13:19:21] <N1njaneer> Not really.
[13:19:51] <N1njaneer> ARM is a significantly more complex architecture, and as such, was designed to minimize a lot of the overhead and challenges you get in to with lesser devices.
[13:21:40] <N1njaneer> For instance, with all of the peripherals and DMA accesses, you can just grab a chunk of data and throw it out the serial port automatically without wasting a billion processor cycles manually fetching from RAM, checking port status, writing registers - tons of loop invariant code motion. You hand off the task (or wait for it to receive a blob of data in from serial) and then wait for an interrupt
[13:21:40] <N1njaneer> to process the next chunk of data, etc.
[13:23:45] <jacekowski> tpw_rules: thing is, it's a cycle but it takes 1 instruction to do 32bit integer multiplication on ARM while it takes 8
[13:24:00] <tpw_rules> but how many times am i doing 32 bit integer multiplications
[13:24:11] <jacekowski> depends on your application
[13:24:39] <jacekowski> i'm just saying that ARM has a lot more power
[13:24:48] <N1njaneer> Significantly.
[13:25:26] <grey> N1njaneer: Maybe you could advise, the reason I grabbed the Photon's is to get "free" wifi, what's the best way to get an AVR or other atmel chip connected to a standard 802.11x network?
[13:26:10] <jacekowski> grey: ENC28J60 and wifi AP in client mode
[13:26:12] <grey> The photon's are using an ARM M3 architecture I believe, I'd assume Atmel has something in that class with the guts to interact with a wifi chip, but there's nothing with a wifi SoC yet is there?
[13:28:09] <grey> jacekowski: that is super duper uneappealing to me
[13:28:11] <aandrew> esp8266 is probably the closest you'll get
[13:29:14] <grey> jacekowski: it seems relatively complex and bulky, compared to how the photon is pairing an on-chip antenna with it's MCU
[13:31:01] <grey> the esp8266 looks okay, pretty high powered, but I like the simple interface
[13:32:42] <N1njaneer> grey: Easiest way would be to use a WiFi module chipset that you can talk to via serial from the AVR. I can reccomend both Digi International as well as Redpine, having worked with both. Most can implement the entire heavy lifting of the stack these days, so programming and implementation is extremely straightforward.
[13:33:25] <tpw_rules> yeah, the enc28j60 is cheap but outdates and requires a tcp/ip stack on the avr
[13:33:37] <tpw_rules> most things nowadays just do sockets over serial or spi
[13:38:37] <N1njaneer> We have the added complication because we generally have to lab-certify devices, which RF becomes an occasional challenge, so we tend to default to using pre-certified modules because it makes the end certification much easier knowing the manufacturer designed said module for product integration and the intention of the end integrating needing to test.
[13:48:01] <TheCommieDuck> Hey - am I right in assuming that sei() will set the global interrupt flag, and therefore any enabled interrupts will run/process/whatever?
[13:48:17] <TheCommieDuck> (It's what I'm getting from the manual, but I'd like to confirm it)
[13:50:36] <grey> N1njaneer: yeah, I'm guessing the photon can manage to be so cheap because they do the software heavy lifting?
[13:50:56] <N1njaneer> TheCommieDuck: Correct.
[13:50:57] <grey> The photon's $20~, the digi international xbee-wifi is $60 just for the wifi module
[13:51:32] <N1njaneer> Do you have a link to the photon?
[13:51:41] <grey> https://www.spark.io/
[13:51:59] <grey> more details on the hardware, http://docs.spark.io/hardware/
[13:52:26] <grey> whoops
[13:52:32] <grey> the second link is to the older version, the Core,
[13:52:41] <TheCommieDuck> Thanks :) And I'm re-reading the datasheet in case since I can't seem to find anything but, assuming this isn't board specific, would an interrupt change any output pins? This code turns an LED on, then calls the interrupt, then returns..but at no point is the LED I/O pin set to off. Not sure if it's some general property of interrupts I'm missing here.
[13:53:32] <N1njaneer> The cost difference is probably because Digi is in the business of selling modules which have passed RF certs and that are made for integrating in to products that need lab testing, versus essentially a hobbiest-level device.
[13:54:45] <grey> fair enough, I wouldn't have expected certification to make that much of a price difference but... I guess I should have
[13:55:17] <grey> the Photon is listed as being fcc/ce/ic certified too 
[14:13:20] <TheCommieDuck> yeah, I can't find anything that (commented out) stops the LED turning off o.0
[14:17:23] <N1njaneer> grey: Interesting.
[14:26:21] <TheCommieDuck> http://pastebin.com/y6XLq28H I can understand what's going on for most of it (PE4/5 are a scroll wheel, PB7 is an LED) but I still can't see where the PORTB &= ~_BV(PB7) or similar happens.
[14:30:28] <N1njaneer> How is the LED wired?
[14:30:46] <N1njaneer> If it's wired +5 to anode and AVR to cathode, then the LED will light when the port bit is zero.
[14:31:10] <N1njaneer> If it's wired GND to cathode and AVR to anode, then the LED will light when the port bit is set to one.
[14:31:51] <TheCommieDuck> N1njaneer: removing the nested for will result in a lit LED that stays on, so it's when the bit is set to 1.
[14:32:17] <TheCommieDuck> I think it's something about the interrupt that I'm unable to find in the manual or datasheet.
[14:32:39] <N1njaneer> That or is the timer routed to the output pin for auto-toggle, etc?
[14:34:24] <TheCommieDuck> Oh, I didn't consider it being hardware.
[14:36:21] <TheCommieDuck> it's enc_delta, which means it's part of the interrupts.
[14:36:35] <TheCommieDuck> (commenting it out means the LED is always set)
[14:39:13] <N1njaneer> Did that solve it, then?
[14:40:16] <TheCommieDuck> I'm trying to work out /why/ it's setting the pin to 0 and still digging around to see if there's something generic about interrupts setting pins to 0, but I can't find anything.
[14:42:12] <TheCommieDuck> (I'd rather understand this than just work with it, heh)
[14:42:31] <hypermagic> set the pin as output first ;)
[14:43:14] <TheCommieDuck> It is?
[14:53:12] <N1njaneer> Oh, just noticed
[14:53:16] <N1njaneer> PINB |= (1 << 7);/*_BV(PB7); /* toggle LED */
[14:53:22] <N1njaneer> That should not be PINB, that should be PORTB
[14:53:38] <N1njaneer> PINB is a read register for the pin INPUT status
[14:53:51] <N1njaneer> It's actually P(ort)IN-B
[14:53:58] <N1njaneer> But looks more like PIN-B
[14:54:09] <N1njaneer> Sorry should have caught that sooner :)
[14:54:24] <N1njaneer> That should fix 'ya
[14:56:39] <TheCommieDuck> N1njaneer: Ooh, thanks a bunch :)
[14:57:10] <TheCommieDuck> Now I wonder why setting that bit does anything.
[14:58:59] <N1njaneer> Which AVR part?
[15:00:16] <TheCommieDuck> Lemme go look at the datasheet first
[15:00:34] <N1njaneer> Setting PINx shouldn't actually do anything.
[15:00:42] <N1njaneer> It may be a read-only register.
[15:00:54] <Lambda_Aurigae> no pullups/pulldowns?
[15:00:55] <TheCommieDuck> Yep, it's read only.
[15:00:59] <N1njaneer> PORTx is used to turn on/off the pull-up resistors if the pin is set up as input
[15:01:06] <Lambda_Aurigae> yeah.
[15:01:08] <Lambda_Aurigae> ok.
[15:01:09] <N1njaneer> (via DDRx)
[15:01:16] <Lambda_Aurigae> too much work today.
[15:01:19] <N1njaneer> So probably undefined behaviour on the write :)
[15:03:07] <TheCommieDuck> Ooh, gotcha.
[15:03:21] <hypermagic> so, set data direction register mask for port as output, then set port bit mask to level, and the port will go high or low.
[15:03:28] <TheCommieDuck> Sounds like it's a typo from the lecturer that nobody has picked up on :P
[15:03:42] <hypermagic> you should also not (1 << 7)
[15:03:53] <TheCommieDuck> hypermagic: Yeah, that was a leftover from me debugging
[15:04:02] <hypermagic> you should do (1 << PB7) always
[15:04:25] <TheCommieDuck> just in case PB7 wasn't the constant I thought it was
[15:05:19] <hypermagic> it is, for the part
[15:07:31] <hypermagic> :) did you know he took all of these and more ? "beer, cigarette butts, grams of cocaine, Xanax, Valium, NyQuil, dextromethorphan (cough medicine) and marijuana." http://en.wikipedia.org/wiki/Stephen_King
[15:13:37] <N1njaneer> In any case, glad you got it figured out!
[15:33:05] <cart_man> Could someone please just look at this for me? I am still getting NACK no matter what I do -.- ....
[15:33:05] <cart_man> http://www.avrfreaks.net/forum/problems-implementing-twi-24aa32-eeprom-0
[17:20:52] <d-rock> In the Mega2560 spec sheet in the section on the ADC, the table on page 281 (26.8.1, ADMUX) says that high bits for REFS1 and REFS0 means "Internal 2.56V voltage with external capacitor at AREF". I'm using an Arduino board and from the schematic (http://arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf) I don't see a capacitor at AREF, so should I add one?
[17:39:11] <d-rock> NM, I found it in the schematics. It's connected to ground via a 100nF cap
[20:38:15] <hypermagic> <snowsurfer93> i am currently working on a binary bomb and need some help with phase 6. can anyone help?
[20:38:15] <hypermagic> <snowsurfer93> the code is in assembly and i cannot figure out what it is doing
[20:38:15] <hypermagic> <hypermagic> how much time is left?
[20:38:47] <hypermagic> <snowsurfer93> a few hours