Back
[02:03:45] <ferdna> is this the correct pinout?
[02:03:47] <ferdna> https://s-media-cache-ak0.pinimg.com/736x/fe/aa/fa/feaafaf10bf86605998d68782fbfc074.jpg
[02:04:09] <ferdna> 4321 | GND,D+,D-,5V
[02:04:48] <ferdna> this one is different:
[02:04:49] <ferdna> http://electrical4study.com/wp-content/uploads/2015/03/usb-pinout-.jpg
[02:05:05] <ferdna> 4321 | GND,D-,D+,5V
[02:07:15] <ferdna> according to this:
[02:07:16] <ferdna> http://pinoutsguide.com/SerialPortsCables/usb_cable_pinout.shtml
[02:07:39] <ferdna> 4321, GND,D+,D-,5V
[02:54:48] <abcminiuser> Anyone here with AS7 installed?
[02:58:32] * abcminiuser prods room
[12:39:32] * SM0TVI prods abcminiuser back and strikes dead air.
[20:07:27] <zer0ptr> why can't a MC just stop executing instructions when it has finished going through the instructions of a program?
[20:07:51] <Lambda_Aurigae> because it's not designed that way.
[20:07:58] <Lambda_Aurigae> same with pretty much every processor out there.
[20:08:13] <EvanR> you can issue a sleep instruction
[20:08:14] <Lambda_Aurigae> they keep executing until they hit a HCF command or equivalent which most don't have.
[20:08:28] <Lambda_Aurigae> HCF=Halt and Catch Fire
[20:11:55] <zer0ptr> Lambda_Aurigae: any particular reason they are designed that way? in say an x86 processer, if there is no instruction to execute, doesnt the control unit just wait for the next instruction? and keeps the instriction pointer in the same place
[20:12:09] <Lambda_Aurigae> no.
[20:12:17] <Lambda_Aurigae> it goes to the next instruction.
[20:12:24] <zer0ptr> if there is none?
[20:12:29] <Lambda_Aurigae> there is no way for it to just wait for the next instruction.
[20:12:36] <Lambda_Aurigae> there is always another memory location next.
[20:12:46] <Lambda_Aurigae> when it hits the end of memory it cycles back to the beginning.
[20:13:00] <zer0ptr> okay and it will just keep doing this regardless
[20:13:16] <Lambda_Aurigae> yes.
[20:15:10] <zer0ptr> hmm okay i guess it makes sense. follow that loop and have sleep and wakeup interupts to stop/resume execution as needed. thank you.
[20:18:25] <zer0ptr> what happens is the instruction pointer gets the address of data though and not an instruction?
[20:18:29] <zer0ptr> *if the
[20:19:34] <zer0ptr> just move on? or will bad things happen
[20:19:50] <Lambda_Aurigae> on an x86, it doesn't care.
[20:19:52] <Lambda_Aurigae> mostly.
[20:20:00] <Lambda_Aurigae> it's a von-newman architecture.
[20:20:10] <Lambda_Aurigae> so data and program space are all one big memory space.
[20:20:23] <Lambda_Aurigae> now, there are ways to protect memory so it won't execute.
[20:20:29] <Lambda_Aurigae> on an x86.
[20:20:32] <zer0ptr> okay but since avr is havard, that wont happen?
[20:20:36] <zer0ptr> *harvard
[20:20:47] <Lambda_Aurigae> on harvard, program and memory are separate spaces entirely.
[20:21:04] <Lambda_Aurigae> program and data.
[20:21:04] <EvanR> what if the instruction is invalid
[20:21:21] <Lambda_Aurigae> then you get a problem.
[20:21:28] <Lambda_Aurigae> but, define an invalid instruction.
[20:21:36] <EvanR> doesnt map to any opcode
[20:22:46] <Lambda_Aurigae> on avr, it executes as NOP
[20:22:57] <Lambda_Aurigae> on x86 you get an exception I do believe.
[20:24:10] <zer0ptr> Lambda_Aurigae: this exception is then handled?
[20:24:24] <zer0ptr> by some microcode i assume
[20:24:26] <Lambda_Aurigae> if you have a way to handle it, yes.
[20:24:37] <Lambda_Aurigae> I'm kinda weak on x86 though.
[20:24:40] <Lambda_Aurigae> would have to look it up.
[20:25:10] <zer0ptr> and this is too much overhead for the avr i assume
[20:25:18] <Lambda_Aurigae> different processor entirely.
[20:25:23] <Lambda_Aurigae> avr is just made that way.
[20:25:35] <Lambda_Aurigae> it's meant as a micro-controller...not a full fledged computer.
[20:25:41] <EvanR> no need for exceptions, just dont program wrong opcodes
[20:25:51] <Lambda_Aurigae> wrong opcodes just do nothing.
[20:26:03] <EvanR> the 8bit ones dont have division so
[20:26:13] <EvanR> no need for division by zero exception
[20:29:27] <renen_> I have a quick question about the xmega D4 series
[20:29:35] <Lambda_Aurigae> that's nice.
[20:29:56] <renen_> The Datasheet for 16D4 and 32D4 mention that TWI on port E is non-functioning.
[20:29:56] <Tom_itx> the quick answer is... NO!
[20:30:12] <renen_> This is for Rev. A/B
[20:30:39] <renen_> Nothing is mentioned for Revs. later than that - does that mean it's fixed ?
[20:30:54] <Tom_itx> does it say it's fixed?
[20:31:04] <Tom_itx> are we atmel?
[20:31:28] <renen_> Nothing is mentioned about it being fixed
[20:31:38] <Tom_itx> assume it is not then
[20:31:42] <renen_> OK
[20:31:47] <renen_> Thanks
[20:31:53] <Tom_itx> if they fixed it i'm sure they would want everyone to know
[20:32:01] <renen_> I guess :-)
[20:32:53] <renen_> The Errata for 64D4 and 128D4 doesn't mention anything about the same issue - can I assume that these devices don't suffer from the same error ?
[20:34:04] <renen_> This might be obvious, but I want to be sure before I purchase another device.
[20:34:44] <Lambda_Aurigae> I would send atmel support an email and ask.
[20:35:10] <renen_> Good idea.
[20:35:20] <Lambda_Aurigae> of course it is.
[20:36:26] <renen_> Let's see.
