Back
[04:36:36] <LeoNerd> I'm willing to bet there's at least a few members of eevblog around here. I've just registered an account, and it doesn't seem like it sends me emails when someone replies to any of my posts. Any way I can configure that?
[06:50:23] <mzbotr> Could the atmega32u4 found in those arduino micros work as an impromptu jtag debugger?
[06:52:05] <mzbotr> Or are the analog inputs only good for a JTAG debugger to connect to the device?
[06:55:21] <Lambda_Aurigae> it's a jtag device, not a jtag host.
[06:55:30] <Lambda_Aurigae> what you would have to do is write a jtag host software for it.
[06:55:49] <Lambda_Aurigae> or find one..I'm sure there is one or three out there somewhere.
[06:56:03] <Lambda_Aurigae> remember that jtag is not always the same across different platforms.
[06:56:20] <Lambda_Aurigae> and you have to have the specific jtag software for the hardware you are trying to work with too.
[06:59:11] <mzbotr> Sounds like atmel could mess things up with trade secrets here...
[06:59:54] <Lambda_Aurigae> yeah.
[07:00:21] <mzbotr> well, so much for that. guess I'll just need to buy a JTAG debugger for OCD like normal people.
[07:00:36] <mzbotr> do you have any good reccomendations?
[07:01:14] <Lambda_Aurigae> I've never used jtag on an avr...never saw any need....128K flash, 5K lines of C code at best..if I can't debug without a hardware debugger I need to find another hobby.
[07:01:29] <Tom_itx> the new atmel programmer does jtag and it's fairly cheap
[07:02:18] <mzbotr> it's actually a mips router that I want to use the JTAG interface on. need to fuss around and clear some passwords for a hidden account.
[07:04:13] <Tom_itx> then you'll need their proprietery jtag for whatever chip they use
[07:04:30] <Tom_itx> http://www.digikey.com/product-detail/en/ATATMEL-ICE-PCBA/ATATMEL-ICE-PCBA-ND/4753383
[07:04:40] <Tom_itx> fwiw, atmel's do all programmer
[07:04:49] <Tom_itx> bare board ^^
[07:05:01] <Tom_itx> http://www.digikey.com/product-detail/en/ATATMEL-ICE-BASIC/ATATMEL-ICE-BASIC-ND/4753381
[07:05:04] <Tom_itx> board and case
[07:05:13] <Tom_itx> http://www.digikey.com/product-detail/en/ATATMEL-ICE/ATATMEL-ICE-ND/4753379
[07:05:16] <Tom_itx> board case and wires
[07:05:16] <Lambda_Aurigae> the physical jtag interface is common....and there are some standard jtag commands on the somewhat standard jtag protocol...however, every manufacturer has its own proprietary extension to that.
[07:06:04] <Lambda_Aurigae> geezus..they are proud of their cables.
[07:06:43] <Tom_itx> uh huh
[07:07:21] <Lambda_Aurigae> will stick with my Tom_itx programmer and my old parallel port stk200 programmer..
[07:07:39] <Tom_itx> it doesn't work under 7 i found out
[07:08:00] <Lambda_Aurigae> which doesn't?
[07:08:06] <Tom_itx> studio 7, mine doesn't
[07:08:11] <Lambda_Aurigae> oh.
[07:08:13] <Lambda_Aurigae> no problem for me.
[07:08:13] <Tom_itx> i'm sure the other one doesn't either
[07:08:18] <Lambda_Aurigae> studio 7 doesn't run on linux.
[07:08:32] <Tom_itx> studio 7 doesn't run. it crawls
[07:08:56] <Lambda_Aurigae> it doesn't even squirm on linux.
[07:09:03] <Tom_itx> my brain can process code faster than it can
[07:09:16] <Lambda_Aurigae> that's how I do most of my debugging anyhow..
[07:09:53] <Lambda_Aurigae> I know what I wrote, I know how I want it to work, I look at the code and step through it one instruction at a time and make changes so it works.
[07:10:23] <Lambda_Aurigae> it's how I've done programming since the 80s on the apple-II and commodore vic-20.
[07:10:44] <Tom_itx> mine was a c-64 portable
[07:11:17] <Lambda_Aurigae> I couldn't afford one of those.
[07:11:25] <Tom_itx> i finally gave it to the mailman
[07:11:27] <Lambda_Aurigae> apple-II at school and vic-20 at home.
[07:11:31] <Tom_itx> his kid wanted one
[07:11:34] <Lambda_Aurigae> still have that vic-20.
[07:11:46] <Lambda_Aurigae> and another..and a c-128 and multiple c-64 boxes.
[07:11:48] <Lambda_Aurigae> and they work.
[07:11:54] <Lambda_Aurigae> and I still play games on them.
[07:18:06] <Tom_itx> thermal nuclear war?
[07:18:14] <Lambda_Aurigae> no.
[07:18:20] <Lambda_Aurigae> omega race is my favorite.
[07:18:27] <Lambda_Aurigae> and I have a lunar lander cartridge too.
[07:18:33] <Tom_itx> made me thing of that movie..
[07:18:41] <Tom_itx> k
[07:19:00] <Lambda_Aurigae> Would you like to play Global Thermonuclear War?
[07:19:07] <Lambda_Aurigae> War Games rocked.
[07:19:08] <Lambda_Aurigae> for the time.
[07:19:19] <Lambda_Aurigae> now I gotta download and watch it dangit!
[07:19:26] <Lambda_Aurigae> did you know there is a sequel?
[07:19:30] <Tom_itx> no
[07:19:44] <Lambda_Aurigae> there is...not quite so good but still watchable in the same genre a the first.
[07:19:56] <Lambda_Aurigae> WOPR goes up against a modern computer and beats it.
[08:19:59] <Korsi> hello. I have a problem that i can compile and upload a program on windows and linux but on windows the uploaded programm size is threetimes the size of linux uploaded and it does not work
[08:20:05] <Korsi> on linux it works
[08:20:42] <Korsi> also avr gcc generates elf on linux and raw binary on win
[08:21:28] <Korsi> commands i use: avr-gcc -mmcu=attiny861 some.c -I./ -Os -DF_CPU=8000000UL
[08:21:35] <Korsi> avrdude -c avrisp -p t861 -B3 -P /dev/ttyUSB0 -b 19200 -U flash:w:a.out
[08:22:10] <Korsi> any ideas why they behave differently on different platforms?
[08:22:28] <DO9XE> is it gcc and avrdude on both platforms?
[08:22:48] <Korsi> winavr is apparently same thing? i assumed
[08:22:49] <DO9XE> and do you use something like avrstudio on windows?
[08:23:11] <Korsi> no i downloaded winavr from sourceforge
[08:23:33] <DO9XE> hmm, simply just using linux might not solve the problem but linux ist also a bit cooler ;) :D
[08:23:57] <DO9XE> I never coded on windows. isn't there a gcc for windows?
[08:24:23] <Korsi> winavr is avrgcc for windows i read
[08:24:47] <Korsi> i use linux but im working in a team with win users:)
[08:25:09] <mzbotr> for windows atmel studio is probably better imo, cross compiling on windows is just horrible.
[08:25:38] <mzbotr> you do not want to compile your own cross chain, 80% of them typically fail
[08:25:41] <DO9XE> hmm :/ teach them linux? :) for dev-works it is much better :) especially for avr-dud commands :D
[08:26:31] <Korsi> yeah i know and im trying to teach:D
[08:29:21] <DO9XE> use a wip ;) :D
[09:52:03] * gorroth is all linux all the time
[09:52:19] <gorroth> last year, i was using windows though, because i was working at roblox
[09:52:27] <gorroth> makin' videogames
[09:53:07] * RikusW is using Mint all the time
[09:53:19] <RikusW> (with the rare reboot to win7)
[09:53:28] <RikusW> (or xp vbox)
[09:54:24] <gorroth> i don't reboot
[09:55:16] <gorroth> i might setup a vmware system for some games sometime. i have a good system for it
[09:55:30] <gorroth> but then again, i hope valve gets all sorts of good games into linux
[09:55:37] * gorroth plays CS:GO mostly right now
[09:55:57] <RikusW> VirtualBox is nice to use
[09:57:13] <RikusW> I've even setup osx in it
[09:57:33] <RikusW> iATKOS_ML2
[10:58:45] <Lambda_Aurigae> Korsi, never seen anybody upload an a.out file.
[11:15:55] <Lambda_Aurigae> generally you want to create a .hex file and upload that.
[11:27:22] <SM0TVI> Anyone know if the inputs of the comparator in an AVR can be shared with ADC inputs (basically, I need both functionalities)?
[11:27:56] <LeoNerd> If they're on the same pins, sure
[11:27:58] <LeoNerd> I do that
[11:28:09] <LeoNerd> 'tiny84; the two AIN pins are also available to ADC
[11:28:24] <Lambda_Aurigae> you just set the functionality to one or the other and go with the flow.
[11:28:34] <SM0TVI> LeoNerd: I meant as letting both the comparator and the ADC do their thang.
[11:28:54] <LeoNerd> Yup
[11:28:57] <Lambda_Aurigae> I'm betting one or the other at a time...have to look at the datasheet and see.
[11:29:03] <LeoNerd> Nope, both can work
[11:29:08] <Lambda_Aurigae> LeoNerd, they can both run at the same time, eh?
[11:29:13] <LeoNerd> Both the anacomp and the ADC have fairly high-impedence inputs
[11:29:17] <Lambda_Aurigae> well, I guess they are both analog.
[11:29:39] <SM0TVI> What's the input resistance of the comp, is it comparable to the ADC (100M)?
[11:29:40] <LeoNerd> I use that arrangement to have a bunch of resistors on an analog divider chain, acting as a 1-of-N set of buttons
[11:30:00] <LeoNerd> The anacomp interrupt tells me that the voltage level has crossed the threshhold, so now I cna use the ADC to read *which* button was pressed
[11:30:10] <Lambda_Aurigae> sweet.
[11:30:12] <LeoNerd> But I don't have to constantly poll the ADC just to ask if any button is pressed, becaus eit'll be on the other side when it's idle
[11:30:13] * SM0TVI will have (ADC0 + AIN-) and (ADC1 + AIN+) connected together then.
[11:30:15] <LeoNerd> So battery :)
[11:30:53] <SM0TVI> Basically, I will be voltage monitoring, and want to interrupt on polarity toggle, as well as have the possibility to take snapshots of the voltages on the pins.
[11:30:58] <LeoNerd> That plus charlieplexing gave me 4 buttons and 6 LEDs with only 4 GPIO pins between them, because that's all I had left
[11:31:19] <Lambda_Aurigae> charlie is a sick twisted individual too.
[11:31:28] <LeoNerd> :)
[11:31:35] <LeoNerd> But soooo useful on pin-constrained ATtinies
[11:31:44] <LeoNerd> (ATtinys? ATs tiny?)
[11:31:51] <LeoNerd> ((How do you pluralise "ATtiny"?))
[11:32:05] <Lambda_Aurigae> attinies.
[11:32:12] <LeoNerd> "ATtiny chips"
[11:32:13] <Lambda_Aurigae> attiny's for singular posessive.
[11:32:13] <SM0TVI> ADC0 will be the 2.5Vbias, ADC1 voltage sense (±250V thru instru op and resistive divider), ADC will be an AC coupled input biased @ 2.5V.
[11:32:24] <SM0TVI> LeoNerd: Attinies?
[11:32:36] <SM0TVI> ADC3*
[11:35:31] * SM0TVI notes the application is a telephone circuit with DTMF detection & generation.
[11:42:10] <Jartza> evening
[11:43:50] <SM0TVI> LeoNerd: You could use a schmitt trigger input for the same purpose as well, especially if your app is the mic switch of the type you have on an android headset :P
[15:35:34] <day> how do the atmega counter work? Are they simply synchronous flipflop counters?
[17:40:02] <gorroth> something is a little messd up with the code i've written. i can send msb/lsb, and i can directly echo them back to the PC, but then when i put them in a uint16_t and then try to pull them out and send them back, the LSB seems to have the high bit set
[17:40:10] <gorroth> driving me crazy trying to solve this, but i'll just have to keep working at it
[17:40:13] <gorroth> because i have other code that works fine
[17:40:28] * gorroth grumbles
[18:54:39] <Lambda_Aurigae> day, they are counters. you set them up and start them and they count..and they overflow and cause interrupts if you set them right and they make things happen..I suggest reading the datasheet..it's all in there.
[22:47:48] <gorroth> damn it; i can't figure this thing out! sometimes, when i use the uart to send 0x00 back to the PC, the PC reads it as 0x00. other times, it reads it as 0x80. and it's not random. it's happening in very particular areas of my AVR code, but i don't know why
[22:47:56] <gorroth> i've got an external crystal and all
[22:48:13] <gorroth> and baud rates are within the range that i should only get 0.2% error
[22:49:08] <FrankD> gorroth, an extra bit being shifted out somewhere? show your code
[22:49:50] <gorroth> hang on a sec
[22:52:22] <gorroth> avr side is at
https://github.com/grimwm/avr/blob/bootloader/bootloader.c, and the pc side is at
https://github.com/grimwm/avr/blob/bootloader/hexuploader.c
[22:52:28] <inflex> gorroth: is that with an xtal? If not, then it's a 0.2% error on top of a 10% RC clock variance
[22:53:04] <gorroth> inflex: it is just a crystal connected to both xtal pins and a couple caps
[22:53:13] <gorroth> i can use my "uart echo" program with no problems
[22:53:38] <inflex> okay, does it seem to lose track after a sequence of data?
[22:54:11] <inflex> If so, just put a small pause between each character perhaps
[22:54:44] <gorroth> inflex: yeah, i sent a whole set of hex data, and it was fine'ish... but i'll try a pause
[22:54:54] <gorroth> i just tested my uart_echo on the device again and typed really quickly from minicom
[22:55:08] <gorroth> and i noticed that after about 20-30 keystrokes, it started losing track
[22:55:14] <inflex> yep
[22:55:22] <Casper> gorroth: does your avr have a full swing oscillator option in the fuses?
[22:55:25] <gorroth> i guess i had never tested it that far out before
[22:55:33] <gorroth> Casper: yeah, with slow ramp up
[22:55:37] <gorroth> that's how i set it
[22:55:40] <inflex> doesn't have to be much of a pause
[22:56:04] <gorroth> yeah, i'll give that a try
[22:56:18] * gorroth has hope :)
[22:58:18] <gorroth> inflex: might i ask how much time you would recommend? is 100ms kind of a way too high a number?
[22:58:21] <gorroth> or justa bout right?
[22:58:34] <FrankD> 100ms is pretty long
[22:58:42] <FrankD> id go with 1-10ms
[22:58:50] <gorroth> i'll start with 10ms then and work my way down
[22:58:52] <gorroth> thanks
[22:59:31] <FrankD> work your way down after 1ms, even thats a long time
[23:00:45] <inflex> ja, I usually only end up with 4~5 nop's
[23:01:09] <inflex> but of course, depends on what clock rate your AVR is at :)
[23:01:25] <gorroth> it's at 8 mhz
[23:02:16] <gorroth> the same thing is happening; it just takes a while longer to see it thanks to the sleeps
[23:02:38] <FrankD> so its probably not clock drift
[23:03:00] <FrankD> sounds like an issue with your code.. are you sure youre sending 0x00?
[23:03:17] <gorroth> yeah, i hard-coded that value. i also hard-coded the avr to send back 0x00
[23:03:20] <gorroth> but maybe i'll do this
[23:03:23] <FrankD> hmm
[23:03:26] <gorroth> i'll break down the code to do basically nothing
[23:03:31] <inflex> Try sending 'U' character over and over
[23:03:35] <gorroth> and i'll see if it just echos my crap back
[23:03:39] <gorroth> okay
[23:03:44] <inflex> That should produce a very nice square wave
[23:03:48] <gorroth> good idea inflex ; i'll modify my code to do that
[23:03:56] <gorroth> i'll just echo it back
[23:03:59] <inflex> (not sure if you've got a scope/DSO
[23:04:15] <gorroth> unfortunately, i don't
[23:04:19] <inflex> np.
[23:04:26] <gorroth> i only started getting into this stuff not so many weeks ag
[23:04:27] <gorroth> ago*
[23:04:30] <FrankD> having the MSB set kinda implies not clock drift, unless the byte you send before it has its LSB high
[23:04:47] <inflex> I like it when you can have AVR talking to AVR via serial, then it doesn't matter what rate you use, so long as they're both setup the same
[23:04:49] <FrankD> hard to read a high if its low anyway :D
[23:06:57] <gorroth> FrankD: i take it you're looking at my code, and that's why you're talking about lsb/msb?
[23:07:11] <FrankD> nope
[23:07:18] <gorroth> oh :)
[23:07:21] <FrankD> too tired to interpret someone elses code :D
[23:07:25] <gorroth> hehehe
[23:07:27] <gorroth> no problem
[23:07:35] <FrankD> too tired to interpret my own code.. :)
[23:07:39] <gorroth> my code has crap in it anyway that i didn't really expect you guys to take the time to go through
[23:07:59] <FrankD> i saw a goto
[23:08:00] <FrankD> i got scared
[23:08:03] <gorroth> yeah
[23:08:19] <gorroth> i did that and violated my code's virginity
[23:09:11] <gorroth> well, you guys have been very helpful; thanks
[23:09:15] <FrankD> gorroth, whats in uart.h?
[23:09:41] <FrankD> and is the preceding byte when you get 0x80 have its LSB set high?
[23:09:44] <gorroth> FrankD: just some stuff to make it easier to setup the uart device. currently it only supports uart0
[23:10:02] <gorroth> FrankD: no, in the byte before that, it is a 0x00
[23:10:15] <gorroth> the "total" 16-bit value i'm trying to send in this case is 0x0000
[23:10:29] <FrankD> then theres basically no way its clock, serial isnt like ethernet.. if you have low low, its low low
[23:10:31] <gorroth> i know it is 0x00, because i echo it back to the pc, and the pc double checks
[23:11:08] <gorroth> well, i'm going to break it down into something manageable... like only sending the "length" and "data" bytes across
[23:11:16] <FrankD> can you share uart.h?
[23:11:20] <gorroth> then taking that out and sending only the "address" bytes across
[23:11:31] <gorroth> FrankD: yeah, it's all on the github there
[23:11:35] <FrankD> also for receive stuff you should write an ISR and buffer it
[23:11:40] <FrankD> its giving me a 404 when i try to go to it
[23:11:53] <gorroth> FrankD: i'm going to write an ISR; i just haven't gotten to it yet
[23:11:54] <gorroth> oh
[23:11:56] <gorroth> one sec
[23:11:57] <FrankD> so id write a ring buffer receive routine
[23:12:02] <FrankD> instead of blindly waiting for data
[23:12:15] <gorroth> https://github.com/grimwm/avr/tree/bootloader -- current branch i'm on
[23:12:26] <gorroth> yeah, i will do that
[23:12:35] <gorroth> i'll store about 64 bytes i guess
[23:14:45] <FrankD> i have a feeling it has to do with transmits/receives overlapping
[23:15:22] <gorroth> overlapping?
[23:15:44] <FrankD> yea im not sure how AVRs work with the single register for RX/TX
[23:15:58] <FrankD> but i thought it was bit shift
[23:15:59] <gorroth> btw, i see this issue when i send 0x00, echo it back, send 0x00, echo it back (0x80 now)
[23:16:18] <FrankD> you just send 0x00, then send 0x00 from the other side twice?
[23:16:30] <gorroth> yeah, i think it is, with a bufffer of 1 byte over the register
[23:17:02] <gorroth> on the pc, i send 0x00, then read it back, send 0x00, then read it back. on the avr, i'm doing basically the opposite
[23:17:17] <FrankD> and no other serial transactions are taking place?
[23:17:41] <gorroth> correct. my program is single-threaded, and no other processes are running that use the tty
[23:17:53] <FrankD> very odd
[23:18:02] <FrankD> o.O
[23:18:23] <gorroth> i do use O_NONBLOCK, but my serial.c function wraps that up and makes it look like blocking. i was going to change it away from non-blocking actually, since i'm not using it in the manner it was intended
[23:18:28] <gorroth> i can try that first
[23:18:50] <FrankD> yeah if you want blocking just dont set O_NONBLOCK
[23:18:56] <FrankD> i wouldnt wrap it in anything to make it block :D
[23:19:31] <gorroth> i wasn't originally going to use blocking
[23:19:54] <gorroth> but for my use cases, i just want blocking; so, i'm gonna change it :)
[23:20:11] <FrankD> :)
[23:20:16] <gorroth> when i come back to the controller thing, i'll probably go back to non-blocking
[23:20:45] <FrankD> and yes, my latest AVR program does the same thing you do with reads, i dont use an ISR :P
[23:21:07] <FrankD> i havent written for AVR8 in years, i always used to implement ISRs with ring buffers
[23:22:10] <FrankD> https://github.com/fdimitri/Atmel-JFET-Tester/blob/master/JFET%207.0%20Firmware/main.c <-- a little ugly :D
[23:22:10] <gorroth> yeah
[23:22:27] <gorroth> i basically took my current uart code straight from the datasheets
[23:22:33] <gorroth> they have samples in it
[23:22:46] <FrankD> hehe yeah
[23:23:03] <FrankD> gorroth,
http://www.frank-d.info/%C2%B5c-prototype-jfet-vpidss-tester-part-5-designing-a-slightly-better-tester/ <-- the hardware is messier than the code, and unfortunately broken
[23:23:16] <FrankD> i dont mind having bad boards, it just sucks that im going to have a ~2 week turnaround to get new ones
[23:23:26] <gorroth> cleaner than my hardware!
[23:23:34] <gorroth> but i have no shots/diagrams of mine yet
[23:23:37] <FrankD> maybe if you ignore the errata
[23:23:37] <FrankD> :p
[23:23:59] <FrankD> like making an SOIC24 pad for an SOIC20 chip
[23:28:40] <gorroth> hehe
[23:28:44] <gorroth> alright, i have to go to bed
[23:28:50] <gorroth> i'll do a little more testing and then pass out
[23:28:53] <gorroth> i have to wake up eary
[23:28:55] <gorroth> early
[23:29:00] <gorroth> thanks again for the help, all
[23:32:28] <gorroth> must be something specific to how i send these stupid 2-byte addresses though, because i just pumped the entire hex file (minus the address info) to the avr, and it echo'd everything back like a boss
[23:32:37] <gorroth> so i'm just doing something really stupid and subtle
[23:32:44] <gorroth> alright, goodnight :)
[23:33:29] <FrankD> night man :) msg me tomorrow if you need a second eye
[23:33:33] <FrankD> ill be awake
[23:57:03] <gorroth> okay...
[23:57:42] <gorroth> if i send two bytes to the avr, and it receives them and stores them somewhere and then echoes both of them back, the first byte i read is good, and the second byte is always wrong by the same amount (i've tested this with a loop of 25 times)
[23:57:46] <gorroth> but
[23:58:02] <gorroth> if i send a byte, and then read it back from the uart on the pc before sending the next byte, everything is fine
[23:58:51] <gorroth> i dont' know why the avr is having problems when i send it two bytes before i read anything back on the pc, or if it's having problems when i have the avr send two bytes