Back
[00:37:54] <megal0maniac> jaggzt: If you have to ask that, then you definitely want ClassDriver ;)
[02:01:28] <jaggz> 0000................
[02:01:50] <jaggz> megal0maniac: thanks.. yeah, brand new to mcu's
[03:24:41] <ecilop> I have some problem with FTDI 232 (UART) under linux
[03:25:31] <ecilop> atmega16 with 16MHz quartz. 9600 bod.
[03:28:03] <DO9XE> tell us more ecilop :)
[03:31:52] <ecilop> First greeting message from atmega received ok
[03:32:07] <ecilop> Sorry for my pooer english
[03:32:49] <ecilop> Atmega have indicator, and shows received from uart message
[03:33:33] <ecilop> Start -> greeting message on uart to PC -> listening uart -> duplicating message from PC on indicator
[03:34:33] <ecilop> On PC I press any digits, and <enter>. When Atmega sees <enter> code it begins duplication on indicator
[03:35:18] <ecilop> "duplicated" string echoes from atmega to PC by uart too
[03:35:54] <ecilop> "Echoes" have many errors. Atmega can not see <enter> often
[03:38:03] <ecilop> UART wires length less than 250mm
[03:38:20] <DO9XE> check your clock settings and baud settings.
[03:38:47] <DO9XE> http://wormfood.net/avrbaudcalc.php
[03:39:01] <ecilop> If clock and baud is wrong -> First greeting message must be wrong. But it's ok..
[03:40:12] <ecilop> I probed to use internal RC at 8MHz. All repeated
[03:40:50] <ecilop> I tried to use another baudrate... have same errors too
[03:41:46] <ecilop> I think that linux have some bug using ftdi 232 on transmit from PC
[03:44:44] <DO9XE> well, the internal RC ist not the best clock for serial :D
[03:45:10] <DO9XE> I never had problems with linux (ubuntu, arch) ant the ft232
[03:45:13] <ecilop> But greeting message received fine
[03:45:27] <ecilop> Only first byte can be damaged
[03:45:50] <DO9XE> do you use "sudo screen /dev/ttyUSB0 9600"?
[03:46:02] <ecilop> no
[03:46:05] <ecilop> putty, or minicom
[03:50:16] <ecilop> I see new symptom
[03:51:14] <ecilop> After many <enter>s -> atmega not seen any <enter>. I restart atmega, and have no greating message
[03:52:00] <ecilop> After restart clinet program (putty, minicom,screen) I see greeting program again
[03:52:22] <ecilop> no greeting messages without resterting client program.. some bug in linux
[03:53:35] <ecilop> I make 2 restarts repeatly -> 2 greetings messages. After third restart -> no greeting message!
[03:54:09] <ecilop> If I restart client program -> always greeting messages
[03:54:16] <ecilop> some bug in linux
[03:56:00] <ecilop> SMP Debian 3.2.65-1+deb7u1 x86_64
[03:57:33] <ecilop> I will try putty on windows :)
[04:07:20] <DO9XE> or just try the screen comman d:P
[04:07:30] <ecilop> I tried
[04:07:34] <ecilop> same thing
[04:08:01] <ecilop> without kill and restart screen no greeting messages
[04:09:05] <ecilop> start screen -> start atmega -> greeting message -> restart atmega -> greeting message -> restart atmega -> !no any messages!
[04:09:51] <ecilop> If restart screen (or another terminal client program) before restarting atmega -> always greeting message
[05:36:24] <ecilop> In windows putty have not "freeze" with restarts
[05:54:08] <vsync> wtf is up with the latest atmel usb installer
[05:55:14] <vsync> oh nevermind
[07:10:50] <Cyberian> Hi, I received code for an ATxmega128A1U to maintain. First thing I tried was compiling the exisiting code and it fails with "'DACA_TIMCTRL' was not declared in this scope". Was this register renamed?
[07:15:58] <Tom_itx> the data sheet would know for sure
[07:16:17] <Tom_itx> along with the device io.h file
[07:18:23] <Cyberian> that's my problem atm, I have current datasheets and no metion of a timctrl register, whereas on the web I get results for it. It has something to do with refresh timing. I'm wondering why did it compile with an earlier version of atmel studio and now i have errors.
[07:20:44] <Lambda_Aurigae> sounds more like a scope issue than it not being there at all.
[07:21:04] <Lambda_Aurigae> beause it appears to be the DAC A timer control register.
[07:22:01] <Lambda_Aurigae> SFR memory location 772
[07:22:51] <Lambda_Aurigae> at least, according to the avr_libc source.
[07:23:28] <Cyberian> ok, now i need to find out what this location is named now
[07:25:38] <Lambda_Aurigae> looking.
[07:25:51] <Lambda_Aurigae> it's not in the regular datasheet..it is in the xmega AU manual apparently.
[07:26:59] <Cyberian> i have the manual open, it seems to be a reserved register now
[07:27:13] <Cyberian> between EVCTRL and STATUS
[07:29:09] <Cyberian> hope i can just skip setting this no longer needed register
[07:29:25] <Lambda_Aurigae> interesting.
[07:29:58] <Lambda_Aurigae> it's definitely missing from the datasheets but exists in the source for avr_libc...might be an older source.
[07:30:08] <Lambda_Aurigae> http://avr-libc.sourcearchive.com/documentation/1:1.6.2.cvs20080610-1/iox64a1_8h-source.html
[07:30:18] <Lambda_Aurigae> yeah....source archive..
[07:30:23] <Lambda_Aurigae> used to be there.
[07:31:19] <Cyberian> I compared it to
https://github.com/vancegroup-mirrors/avr-libc/blob/master/avr-libc/include/avr/iox128a1u.h (which also seems old). hopefully skipping it during initialization now works as before
[07:31:52] <Lambda_Aurigae> well, would love to stay and play but time for worky.
[09:12:15] <tpw_rules> anybody played with simavr before?
[09:13:11] <tpw_rules> i have a file with input states at specific times and i want to attach it to a core and record the output states of the rest of the pins
[09:17:27] <tpw_rules> my code relies on external interrupts, pin change interrupts, and just reading PIN. can i somehow centralize that and have it query the pin states every cycle?
[10:02:48] <vsync> Hmm.
[10:03:05] <vsync> the sam d21 xplained kit does not seem to want to work
[10:03:47] <vsync> windows installs "EDBG" drivers, but in atmel studio under device programming it does not detect any programmers
[10:04:17] <vsync> and my understanding is that atmel studio should detect the usb board automatically and show it, or something along those lines
[10:29:42] <vsync> aaaand finally it works
[10:29:57] <vsync> didn't take more than an afternoon to fuck around with it, to get it even talking to atmel studio
[10:30:00] <vsync> wowzers.
[10:30:09] <vsync> i love software "engineers"
[10:30:14] <vsync> much fucking engineering
[11:49:25] <jaggzt> if I'm using LUFA with a 32u4, what are my options to get some debug info from the device to my computer?
[11:49:44] <jaggzt> currently I'm setting it up as a keyboard and mouse device
[11:49:53] <jaggzt> I need some "debug" channel though
[12:36:46] <Lambda_Aurigae> jaggz, CDC...virtual serial.
[12:36:53] <Lambda_Aurigae> jaggzt, too
[14:02:33] <Martin90> hellp
[14:02:52] <Martin90> if I want to use ADC in atmega8 micro, where should I look for code ?
[14:03:03] <Martin90> I can't see anything in datasheet
[14:03:36] <Martin90> sure I can google the subject but I want the oryginal resource
[14:06:45] <LeoNerd> Datasheets dont typically have code examples
[14:07:51] <vsync> orygynel resurze lok fer pornhub
[14:08:01] <Martin90> so how can I figure out how to initialize ADC for example ?
[14:08:13] <Martin90> Datasheet say nothing about code
[14:08:50] <vsync> http://lmgtfy.com/?q=atmega8+adc
[14:10:11] <Martin90> shouldn't it be specified in doc . datasheet
[14:10:41] <vsync> well it is. figure out the relevant registers
[14:10:49] <Martin90> google while great may be source of possible scam code
[14:11:11] <vsync> you live in russia or another old soviet country - this is understandable
[14:11:36] <vsync> datasheet while great may be source of possible scam code
[14:11:50] <vsync> now, go do something constructive and start reading up about all the registers
[14:12:03] <vsync> or deal with the possible scam code
[14:12:11] <vsync> you only have two options, pretty much
[14:17:19] <jerware> is USART synonymous with UART ?
[14:17:49] <Tom_itx> sortof
[14:18:11] <Bright> an USART can do synchronous as well as asynch communications
[14:40:27] <Martin90> PORTD = 0x00; -> what is port D ? 0x00 set it for what ?
[14:40:40] <vsync> that's scam code!
[14:40:51] <Martin90> why ?
[14:41:03] <RikusW> it simply sets all pins to 0
[14:41:04] <vsync> you still failed to read about the registers?
[14:41:19] <Martin90> read where ?
[14:41:24] <vsync> the fucking datasheet
[14:42:09] <Martin90> RikusW, thanks
[14:42:27] <vsync> it sets all the port d pins to 0...
[14:42:29] <Martin90> PORTD = all pins ?
[14:42:47] <RikusW> Martin90: that is if you also set DDRD = 0xFF; for output
[14:43:12] <RikusW> each bit is one pin
[14:43:16] <RikusW> D0 - D7
[14:43:37] <RikusW> DDRD controls the direction, 1 for output
[14:43:46] <Martin90> hmm I have some difficulties understanding this
[14:43:46] <RikusW> PIND is to read the pin status
[14:44:04] <Martin90> DDRD is some macro right ?
[14:44:07] <RikusW> you simply use it as any other variable
[14:44:21] <RikusW> DDRD is a location in "memory"
[14:44:41] <RikusW> its a pointer actually
[14:45:02] <Martin90> mhm, but what you mean by "it basicly set port to 0 " what the 0 means in this case ?
[14:45:52] <RikusW> PORTD = 0x44; will set D6 and D2 to 1 all the other bits to 0
[14:46:30] <RikusW> == PORTD = (1<<PORTD6)|(1<<PORTD2);
[14:46:56] <RikusW> using hex is shorthand on the ports
[14:47:13] <RikusW> but using actual bit names on other registers is highly recommended
[14:48:23] <Martin90> ok but, 0x44 in hex stand for what ?
[14:48:27] <jacekowski> 44
[14:48:29] <jacekowski> 0x44
[14:48:31] <Martin90> it;s a port adress right ?
[14:48:36] <jacekowski> no
[14:48:43] <jacekowski> it's a value that will be set in that port
[14:48:57] <jacekowski> PORTD is an alias to register location
[14:49:03] <jacekowski> so it sets register PORTD to 0x44
[14:49:21] <Martin90> 0x44 in decimal is 68 what about it ?
[14:49:23] <jacekowski> and then every bit in that register is actually a single I/O pin
[14:49:52] <jacekowski> so if that specific bit is set to 1 then it's I/O pin is going to be high
[14:50:21] <Martin90> voltage on it
[14:50:30] <jacekowski> yes
[14:51:18] <Martin90> I don't get this one "PORTD = 0x44; will set D6 and D2 to 1 all the other bits to 0"
[14:51:27] <jacekowski> yes
[14:51:29] <Martin90> how it can set all ports at once
[14:51:39] <jacekowski> it's a single port
[14:52:09] <jacekowski> open the data sheet
[14:52:20] <Martin90> I have
[14:52:27] <jacekowski> on page 3 there is a block diagram
[14:52:32] <Martin90> 0x12 (0x32) PORTD PORTD7 PORTD6 PORTD5 PORTD4 PORTD3 PORTD2 PORTD1 PORTD0 63
[14:52:59] <Martin90> yes I see what about it ?
[14:53:11] <jacekowski> so basically, what happens
[14:53:26] <jacekowski> most of those blocks are mapped to registers
[14:53:46] <Martin90> mhm
[14:53:49] <jacekowski> so for example PORTD is mapped to 0x12
[14:54:03] <Martin90> PD0 - PD7 = PORTD ?
[14:54:07] <jacekowski> yes
[14:54:30] <Martin90> PORTB ?
[14:54:38] <jacekowski> same
[14:54:53] <jacekowski> so when you do PORTD=0x44 then ALU sends 0x44 to hardware block responsible for PORT D
[14:54:54] <Martin90> PB0 - PB7 ?
[14:54:57] <jacekowski> yes
[14:55:21] <RikusW> each port got 8 bits
[14:55:23] <jacekowski> PORTD hardware then splits that 0x44 into individual bits
[14:55:39] <RikusW> all or most of them are connected to external pins
[14:55:41] <Martin90> PD0 is one port ?
[14:55:45] <jacekowski> Martin90: no
[14:55:48] <RikusW> one bit
[14:55:49] <Martin90> one bit
[14:55:50] <jacekowski> Martin90: PORTD is one port
[14:55:58] <jacekowski> Martin90: PD0 is one pin in that port
[14:56:10] <jacekowski> PORTD has 8 pins
[14:56:19] <Martin90> so 0x01 - 0x44 ?
[14:56:24] <jacekowski> no
[14:56:32] <RikusW> Martin90: read the header for the avr and you'll quickly see
[14:56:39] <jacekowski> RikusW: i doubt that
[14:56:49] <RikusW> 0xFF is 8 hex bits all set to 1
[14:57:13] <RikusW> Martin90: in the header #define PD5 5
[14:57:29] <LeoNerd> jacekowski: Seeing does not necessarily imply understanding
[14:57:32] <RikusW> PORTD is set to the address of the PORTD register
[14:57:42] <Martin90> io.h ?
[14:58:00] <RikusW> io.h includes the proper part header
[14:58:06] <RikusW> depending on the avr you use
[14:58:32] <Martin90> ok thanks you I am going to study the subject as for now thanks for help ;]
[15:16:58] <LeoNerd> RikusW: My HVSP boards arrived...
https://twitter.com/cpan_pevans/status/565674460020482049
[15:17:14] <RikusW> :)
[15:23:37] <aandrew> LeoNerd: hahaha
[15:23:41] <aandrew> I have some boards like that
[15:23:48] <aandrew> nothing like deabugging a few components on a PCB
[15:24:50] <LeoNerd> Yah..
[15:24:58] <LeoNerd> I think I'll have to order myself a metre strip off eBay
[15:27:32] <aandrew> that's an interesting board; do you have more info on it?
[15:27:38] <aandrew> i.e. is it something "public" ?
[15:27:49] <LeoNerd> Sure
[15:27:55] <LeoNerd> Er... what you want to know?
[15:28:02] <LeoNerd> (I'll be selling it on Tindie presuming it works)
[15:28:33] <aandrew> well it looks like an HVSP programmer but I don't see an atmel device on it... what's it do?
[15:29:47] <LeoNerd> It's half of a programmer
[15:30:01] <LeoNerd> The other half is
https://www.tindie.com/products/leonerd/avr-hvsp-programming-bus-pirate-adapter/
[15:30:27] <LeoNerd> That second board is the actual "put chip in" part of the programmer. you can use that with a bus pirate (sloooow), *or* with any luck, my new board will run it a lot faster, as an STK500 clone
[15:30:45] <Bright> do you sell much off tindie, LeoNerd?
[15:31:01] <aandrew> aha
[15:31:30] <aandrew> I have a couple of things I should get up on tindie
[15:32:41] <LeoNerd> Bright: So far I have made.. umm... Lets see... Zero sales. :)
[15:32:53] <LeoNerd> But then I'm only offering two things that are both rather special-case
[15:33:59] <LeoNerd> However, hopefully once I can offer the adapter+controller combo, someone might actually want one
[15:36:03] <LeoNerd> aandrew: also, the Atmel chip on it is the tiny841; the small 14pin thing up in the top corner. that's the controller
[15:36:08] <aandrew> aha
[15:36:13] <aandrew> what's the TI chip?
[15:36:14] <aandrew> I think it's TI
[15:37:57] <LeoNerd> 74HC595
[15:38:06] <LeoNerd> Shift register that has control of Vtg, Vprg and the 6 LEDs
[15:40:46] <LeoNerd> I -could- have used a single chip but then I'd be up at something like a mega88 which is then either DIP (nooo), or QFP and I didn't fancy soldering that
[15:42:17] <aandrew> so how does that replace a bus pirate?
[15:42:23] <aandrew> I'm confused
[15:43:04] <malinus> bj
[15:43:15] <malinus> *bus pirate seems kinda nice, actually
[15:43:35] <aandrew> is the tiny running vusb or ?
[15:44:00] <aandrew> I'm not a fan of bus pirate myself. it's not bad in a pinch though
[15:45:47] <LeoNerd> The bus pirate is a generic "usb attached multi-protocol debug tool" thing
[15:45:58] <LeoNerd> You talk custom protocol to it, it can then talk I2C, SPI, bitbang, etc..
[15:46:21] <LeoNerd> I wrote a custom program to drive the Bus Pirate into bitbanging the lines required to talk HVSP. So you can use bus pirate to talk to that first board of mine
[15:46:48] <LeoNerd> But that's annoyingly slow, and custom; avrdude won't do it. and you need a bus pirate. So... the second board has a UART on and "looks like" an STK500, but only talks HVSP
[15:47:03] <LeoNerd> The upshot being, that you can now use plain ol' avrdude -c stk500hvsp -p ....
[16:27:45] <vsync> can't seem to be able to even get this simple usart example work on the sam d21 xplained
[16:28:59] <vsync> it should use the "edbg" cdc, and i have the drivers installed
[16:30:21] <N1njan33r> Most of those should run straight out of the gate.
[16:33:01] <vsync> i'd imagine that aswell
[16:33:20] <jaggz> can someone explain this arduino leonardo micro issue to me? (it uses an atmega32u4). You have to connect to the board first at 1200 baud which somehow triggers bootloader mode?
[16:33:40] <jaggz> avrdude is still telling me "ser_recv(): programmer is not responding"
[16:33:43] <vsync> my understanding of this is that it listens the edbg cdc and echoes the input straight back
[16:35:48] <jaggz> people are using scripts, usually in python, like this to reset:
https://github.com/sudar/Arduino-Makefile/blob/master/bin/ard-reset-arduino
[16:37:15] <vsync> the default config seems to config 4 "pins", apparently, i wonder if it uses some kind of a rts/cts thingy
[16:40:19] <LeoNerd> Opinions: Should I clear the CKDIV8 fuse with avrdude, or should I have my program set the clock divider back to 1 on program startup? What's "nicer"?
[16:40:52] <N1njan33r> I prefer to set fuses exactly how they should be used for the application, but that's just me :)
[16:42:04] <LeoNerd> Doh! Also I forgot to set the fuses for external crystal <.<
[16:45:42] <LeoNerd> Hrm.. none of the useful online fuse calcs. have the tiny841
[16:48:06] <Jartza> LeoNerd: ohh, I got 10 attiny841s too, useful much?
[16:48:10] <jaggzt> Here's the output of avrdude, if it helps anyone help me..
http://www.pasteall.org/56684
[16:48:42] <Jartza> haven't tried them yet, but they have uart, spi and i2c slave... last one seems a bit odd, though :)
[16:49:45] <vsync> N1njan33r: is there some extra magic required to get the uart working through the EDBG?
[16:52:11] <aandrew> LeoNerd: that's pretty smart! so is it just a logic level UART on the attiny?
[16:52:39] <LeoNerd> aandrew: Yah
[16:52:46] <LeoNerd> I have it connected to a PL2303 cable
[16:52:50] <LeoNerd> They're £1 off Amazon :)
[16:53:17] <aandrew> gotcha, that was what was confusing me, STK500 is USB and I didn't see the USB interface
[16:53:36] <aandrew> yeah I destroy PL2303 boards on sight
[16:54:20] <aandrew> FTDI for me, or hopefully sooner than later my PICJUG board
[17:04:02] <LeoNerd> I like the PL
[17:15:40] <vsync> pl2303 works, just don't use the latest drivers
[17:18:43] <vsync> the virtual com usart seems to work. yay.
[17:21:57] <LeoNerd> I just use the ... er.. ehatever the Linux kernel does
[17:22:05] <LeoNerd> It's a standard CDC
[17:35:58] <LeoNerd> Hrm.. How accurate should I expect the timing on a crystal + attiny841 UART + PL2303 ?
[17:36:39] <LeoNerd> I've set it at 115200baud, using a 14.7456MHz crystal. If I write a long stream of the ASCII char '0', about one in 100 of them (in a nicely reliable repeating pattern) comes out corrupted
[17:37:12] <LeoNerd> And my logic analyser's "autobaud" detector claims a rate of 117kBaud
[17:37:55] <LeoNerd> But that's.. waaaay off. That's 2 in 117; so around 2% error.. a crystal should be around 10ppm - 0.001% error at most
[17:39:34] <Xark> LeoNerd: Have you tried
http://wormfood.net/avrbaudcalc.php
[17:40:12] <LeoNerd> The baud register is set right; really :)
[17:40:23] <LeoNerd> If it wasn;t this would be waaaaaaaaaay off
[17:41:03] <Xark> LeoNerd: Well, with that crystal it should be "perfect", so perhaps your crystal source is off?
[17:41:22] <LeoNerd> At 14.7456MHz / 115.2kBaud the value is 7. 8 or 6 would utterly fail to work
[17:41:33] <LeoNerd> Yeah, that might be so... :/
[17:41:56] <LeoNerd> It;s a brand new crystal from Farnell, so I'd hope it would be good
[17:42:55] <LeoNerd> Any possibility my board layout upsets it? One trace is longer than the other
[17:44:42] <Xark> I doubt it. Also, remember the PC receiving crystal (and logic analyzer) have their own error.
[17:45:29] <LeoNerd> True... hmmm
[17:45:37] <LeoNerd> But still,... 2%. :?
[17:45:56] <LeoNerd> My test board on breadboard was waaaaay better
[17:46:26] <Xark> Do you know the tolerance on the xtal you are using?
[17:46:30] <vsync> well, crystals have an error margin specified in the datasheets...
[17:46:50] <vsync> yeah
[17:47:41] <LeoNerd> I'll look it up.,.
[17:49:47] <Xark> LeoNerd: I will also mention, if you sent back-to-back characters, *eventually* even a tiny timing difference on rx/tx will cause corruption. Often you need a small pause every N characters. As a test, you can have tx use 2 stop bits and see if this fixes your problem.
[17:50:41] <Xark> (buffers are not infinite, e.g., in FTDI chip).
[17:50:43] <LeoNerd> Ahhhh, yes fair point
[17:51:10] <LeoNerd> This was a trivial while(1) uart_putc('0'); loop
[17:53:38] <Xark> LeoNerd: I spent several days experimenting with this on a FPGA, so I speak from experience. I finally added "auto rate compensate" and that (effectively) fixed it (timing the TX "bit time" on the fly), but you don't have that option. I got it working at 2Mbps without loss (on huge test file). The FPGA used FTDI also.
[17:54:15] <LeoNerd> Mmmm, nice
[17:55:50] <Xark> The problem is trickier if you send and receive back to back, like echo. So I just added a teensy delay every so often. :)
[17:55:52] <N1njan33r> Xark: As long as you have a long enough marking state between occasional characters so the UART's RX state machine can resynchronize to the starting bit you shouldn't get compounding error. But I would agree that yes, without that pause, VERY long blocks have a small chance of getting out of synch.
[17:56:31] <N1njan33r> between +back to back characters occasionally
[17:56:40] <LeoNerd> Well, the real STK500 protocol has much back and forth handshaking so it will hopefully be fine
[17:56:45] <Xark> N1njan33r: Yep. As I mentioned eventually a buffer will overflow with no "slack time". I was able to see this on logic analyzer capture.
[17:57:18] <Xark> LeoNerd: Yes, echo is "special case" (worst case).
[17:58:04] <N1njan33r> Xark: Are you sure it's an overflow caused by UART receipt vs the ability of the software to handle the long rate of data?
[17:58:04] <LeoNerd> Right
[17:58:17] <LeoNerd> Well,.. I guess I'll try putting my real STK500 clone code on here and try it out with avrdude :)
[17:59:28] <N1njan33r> i.e. loading and unloading a FIFO at near full rate so eventually the FIFO overflows because the software is just fractionally behind on the unload rate vs the load rate, so sustained periods where the FIFO is not completely emptying will eventually cause it to fill and then overflow.
[17:59:38] <LeoNerd> Oh this isn't overflow
[17:59:56] <LeoNerd> This is every so often a char gets corrupted. I'm not quite sure what to; my terminal just displays it as a U+FFFD replacemnet char
[18:00:01] <LeoNerd> So I'm guessing some high byte
[18:00:16] <Xark> N1njan33r: Actually, you are right, I misremembered. The "inevitable" failure is only on back-to-back send with echo (not only receiving). With back-to-back echo, TX clocks mismatch will eventually get too big.
[18:00:41] <N1njan33r> Cool, just curious on that :)
[18:00:58] <LeoNerd> Oooh :)
[18:01:01] <LeoNerd> It works :)
[18:01:19] <LeoNerd> I mean... avrdude got as far as "successfully" reading a device signature of all zeroes. most likely because I don't have the other board attached
[18:01:24] <LeoNerd> But it started up, did the signon, etc...
[18:01:37] * LeoNerd gets other board
[18:02:30] <N1njan33r> I've done extensive FPGA work with writing UARTs from scratch and such that need to handle high-data-rate transmissions for applications with literally with 24/7/365 data passing through them without dropping characters, so I've had to dive deep in to some weirdities at times. Like the dreaded clock-domain-crossing-metastability-gotchas you can occasionally have to deal with, and you get a single
[18:02:31] <N1njan33r> bit upset after minutes to hours of running :)
[18:03:34] <N1njan33r> That's frustrating because the error is entirely probability based, and the only way you get 99.9999% confidence is by letting it run for extended periods of time. :)
[18:03:40] <N1njan33r> But I digress :)
[18:06:41] <LeoNerd> Hrm.. it sortof works. I suspect some slight upset of timing or soldering maybe...
[18:06:49] <Xark> Yeah. I did have (IIRC) two layers of FF even on simple UART inputs. However, the meta-instability probability is still non-zero. :)
[18:12:10] <LeoNerd> http://uk.farnell.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=15001&langId=44&urlRequestType=Base&partNumber=1611751&storeId=10151 30ppm they claim
[18:15:37] <N1njan33r> Xark: Generally the problem comes from doing clock-domain crossing. As long as you buffer the signals coming in via a => assignment by a clock is which running at least 2x faster (usually a LOT faster for async, like 16x) than your highest signal rate of interest of the clock signal generally won't suffer metastability issues or race conditions.
[18:16:37] <N1njan33r> Or at least I've found that it pretty much solves the problems. I have to do FPGAs as SPI-bus target fairly often.
[18:17:32] <N1njan33r> Useful if you can source the FPGA's clock from the same source as the device which is transacting with it since you'll never have any weird phase drifts :)
[18:18:07] <N1njan33r> And you can compensate phase offsets using the DCM's if need be.
[18:19:43] <N1njan33r> LeoNerd: I had an application we worked on that used a 50ppm quartz oscillator, but that was GPS-disciplined. The FPGA discipline stage was more than accurate enough to let you see the error term readily change when breathing hot air on the quartz oscillator. It was kind of wild. 50ppm error comes to 4.32 seconds over a 24 hour period.
[18:20:16] <LeoNerd> Heh
[18:20:22] <LeoNerd> Yeah; this measured error looks like ~2%
[18:20:23] <N1njan33r> But in this application the timing was precise enough that you could see the quartz rate drift by a few ppm just by breathing on it :D
[18:20:53] <LeoNerd> nice
[18:24:06] <jerware> My program stays on this line, while(Serial.available() == 0); even though I keep sending it data with this program from an other atmega328p,
http://codepad.org/Nd0NvOpt
[18:27:05] <N1njan33r> I need to hire more people!
[18:27:35] <LeoNerd> *grin* Reallynow?
[18:37:31] <theBear> legally and practically i'm unemployable, but surely to you that just sounds like a challenge
[18:44:58] <Bright> N1njan33r: i can write verilog and i need a job :D
[18:45:59] <Lambda_Aurigae> I can write verilog, vhdl, C, assembly, and the names of several other programming languages!
[18:48:29] <aandrew> N1njan33r: aren't the start and stop bits enough to ensure rx edge detect for retiming on each char?
[18:49:02] <N1njan33r> aandrew: Generally yes, or at least they should be on a reasonable UART.
[18:49:34] <aandrew> LeoNerd: are you checking the rx status to make sure you're not trying to use an errored char?
[18:50:39] <N1njan33r> aandrew: The place you can get in to trouble is if you have continuous back-to-back characters without a stop in the marking state which is at least the length of a character, ideally the length of two to be safe, because if you pick up in the MIDDLE of a transmission (i.e. the async receiver sees a data bit as a start bit) then the whole system will go out of whack and usually have trouble
[18:50:39] <N1njan33r> synchronizing until you get a pause.
[18:52:19] <aandrew> N1njan33r: hmm, good point... I wonder if you can skirt that by stating the start of a transmission must have 3 word times of inactivity or something
[18:53:43] <LeoNerd> aandrew: I;m just outputting a constant, I'm not reading at all
[18:54:02] <N1njan33r> aandrew: Many serial standards will force periods of inactivity in order to specifically allow for this. DMX-512A is a good example, as it's a continuous back-to-back streaming of data characters, but requires a minimum 88us break and then a minium mark-after-break timing before actual data transmission occurs. This serves to both provide out-of-band signaling for start of packet, as well as to
[18:54:03] <N1njan33r> allow for time for all receivers to successfully resync.
[19:20:12] <jerware> My program stays on this line, while(Serial.available() == 0); even though I keep sending it data with this program from an other atmega328p,
http://codepad.org/Nd0NvOpt
[19:24:21] <Casper> ... duino...
[19:29:01] <N1njan33r> jerware: Yeah, hard to say on that one. Could be lots of things wrong. The joys of debugging Arduino. :)
[19:29:45] <N1njan33r> Generally, though, "!Serial" would not work, though, since "Serial" is an object.
[19:30:27] <N1njan33r> You would have to call a method or function on it, like your "Serial.available() == 0" above
[19:31:47] <N1njan33r> while(!Serial.available());
[19:32:16] <N1njan33r> i.e. loop until serial is received
[19:32:47] <N1njan33r> Also, you will need to actually receive the serial to clear the condition.
[19:33:10] <N1njan33r> On Arduino you can flush the rx buffer by doing "while(Serial.read() != -1);"
[19:34:17] <N1njan33r> So you'd want to add that inside of your code once it detects the serial data being received, else it will just keep firing continuously at the first piece of serial data that arrives.
[19:34:42] <N1njan33r> Make sense?
[19:36:34] <jerware> Serial.available() returns if there's something to return. Not if its port is ready to send. Correct?
[19:37:12] <jerware> should the recipient atmega flush the rx buffer at the beginning of the program ?
[19:45:05] <N1njan33r> Serial.avaliable() returns the number of bytes in the RX buffer, so 0 means nothing there.
[19:46:03] <N1njan33r> while(!Serial.avaliable()) is equivalent to while(Serial.avaliable() == 0) -- it will loop as long as the return value of .avaliable() is zero -- i.e. no bytes waiting to be received
[19:46:06] <jerware> According to my logic analyzer, I'm sending "Hello Serial". But the recieving atmega isn't reading it.
[19:46:45] <N1njan33r> You CAN flush the receive buffer as good measure, but if the program is starting up cleanly anyhow it will already be zero'd out, or should be, from the library initializing.
[19:47:38] <N1njan33r> jerware: Clamp the logic analyzer to the RX pin at the chip and verify you are actually seeing the serial data physically make it to the RX pin to rule out external problems and confirm it's a chip configuration or code issue.
[19:48:00] <N1njan33r> jerware: Depending on the AVR used, some have multiple serial ports, so make sure you're reading the correct one.
[19:49:12] <jerware> atmega328p rx pin is pin#2
[19:49:28] <N1njan33r> Which device package?
[19:49:47] <jerware> from the uno. arduino on a breadboard.
[19:50:26] <N1njan33r> Are you reading at the Arduino pin, or the physical pin on the ATMEGA328P?
[19:51:08] <N1njan33r> It's Pin #2 on the DIP version of the part, but pin 30 on the TQFP version, etc.
[19:51:44] <N1njan33r> Also
[19:52:08] <jerware> yes, the rx pin physically gets the string.
[19:52:40] <N1njan33r> Arduino uses the TX/RX pins for bootloader code upload, so make sure you don't have any conflicts with the programmer :)
[19:52:45] <jerware> this dip only has 28 pins
[19:53:19] <N1njan33r> Yes, the 328P is avaliable in DIP28, and well as SMT28 and 32 pin :)
[19:53:28] <N1njan33r> Just wanted to rule out being on the wrong pin :)
[19:54:00] <N1njan33r> Also, I would make sure your code is actually running.
[19:54:10] <N1njan33r> Put a print at the top to tell you that it's started up, etc.
[19:54:43] <N1njan33r> Since there is also only one serial port on the part, do you have that split off appropriately?
[19:55:08] <N1njan33r> i.e. if you are receiving on the RX pin, then only the TX pin should be going to your terminal.
[19:55:42] <jerware> I've flashed led's to make sure it started up. That's how I narrowed down that it's blocking on while(Serial.available() == 0);
[19:55:51] <jerware> for ever polling.
[19:56:01] <N1njan33r> What are you outputting the text to?
[19:56:19] <jerware> it's atmega to atmega. tx -> rx
[19:56:30] <jerware> 2 on the same breadboard.
[19:57:07] <N1njan33r> And you are watching the TX pin on the same chip, then, to see if it transmits?
[19:57:34] <jerware> yes. I'm watching the tx pin, from the 2nd dip's rx pin. I can see the data.
[19:58:12] <N1njan33r> No, I mean the TX pin from the 2nd part that you also watching the RX pin on
[20:00:20] <N1njan33r> Because how else would you know that your code is actually doing what it's supposed to? :)
[20:03:31] <jerware> you mean print out what it recieves?
[20:03:36] <N1njan33r> Yes.
[20:03:37] <jerware> as a debug statement ?
[20:03:49] <N1njan33r> Well, how are you monitoring the actual chip?
[20:03:57] <jerware> Well it's before it recieves anything if it's blocking on Serial.available()
[20:04:07] <jerware> It never becomes available.
[20:04:28] <N1njan33r> Where is it printing out to? A console, etc?
[20:04:38] <jerware> I'm montitoring the actuall chip by using LED's to determine which line it craps out on.
[20:05:04] <N1njan33r> Post the code?
[20:05:13] <jerware> It lights an LED on while(serial.available() == 0); but no LED is lit after that line.
[20:05:58] <N1njan33r> Pastebin the code
[20:07:54] <jerware> http://codepad.org/o6kVQto5
[20:07:59] <jerware> Thats the rx side.
[20:09:12] <N1njan33r> How are you dumping code in to the device?
[20:10:03] <jerware> via the uno
[20:10:32] <N1njan33r> Are you pulling the chip out and physically placing it in to a breadboard?
[20:10:41] <jerware> yeah.
[20:10:44] <jerware> for both chips.
[20:10:50] <N1njan33r> Okay, so there should be no pin conflicts.
[20:11:07] <N1njan33r> Are you providing clean power and making sure there are 0.1uf's at the power pins?
[20:11:31] <jerware> those capacitors ?
[20:11:37] <jerware> yes.
[20:11:39] <N1njan33r> Also, be aware that you will have a problem with your code in the while loop.
[20:11:57] <jerware> being ?
[20:12:40] <N1njan33r> You will either need to provide a delay after the while(Serial.available() == 0); to ensure the entire line of text gets in (very hack'ish) or else you need to trap on a disctinct and unique character, like a carriage return at the end of the string.
[20:12:59] <N1njan33r> Else you will only get one or two bytes of the string read in by the time Serial.readBytes(buff, buffersize); runs
[20:14:02] <jerware> how long of a delay?
[20:14:13] <jerware> well the thing is, I'm never making it past the while(Serial.available() == 0);
[20:14:17] <N1njan33r> Enough that the string of text gets in.
[20:14:18] <jerware> it's an infinate loop.
[20:14:30] <N1njan33r> Which is why I said you'll eventually have a problem once you get the current issue solved.
[20:14:36] <N1njan33r> I can't see any reason this shouldn't be working.
[20:15:48] <N1njan33r> You've also tried placing the green() after the while() line as well, and verified that it never turns on?
[20:20:59] <jerware> correct ---^
[20:23:58] <jerware> I'm commenting out the infinate loop, and just doing a delay(130)
[20:32:09] <N1njan33r> There could be something odd in the Arduino code for serial port processing. You can also comment out the serial port setup commands and do a (PIND & 0x01) to check the physical state of the GPIO pin input as to what it's receiving, to make sure the chip is in fact seeing your data.
[20:33:39] <jerware> I can do serial communication on the same chip. But not chip to chip.
[20:34:05] <jerware> like this
http://codepad.org/zZy7GHdD
[20:35:45] <jerware> I figured it out. Now I can do serial from chip to chip
[20:35:59] <jerware> I took out the int main() and replaced it with begin() loop()
[20:36:29] <N1njan33r> Oh, yes. You can thank Arduino for that.
[20:36:57] <N1njan33r> Sorry, I completely forgot that, as I don't believe it enables interrupts until just before it enters begin()
[20:37:07] <jerware> lol. well thanks for you time dude.
[20:37:08] <N1njan33r> I was about to say that it sounded like interrupts were off :)
[20:37:19] <N1njan33r> Glad you figured it out!
[20:38:09] <N1njan33r> Come to think of it, when I had to do some Arduino code for a client, I think that same thing had hung me up in a different capacity :)
[20:38:35] <N1njan33r> But hey, at least we checked a bunch of other stuff, too.
[20:39:03] <N1njan33r> And again, I would consider revising your receive code to build the buffer and look for sentry bytes on the message for ease of parsing.
[20:39:15] <jerware> What if I not used an uno. Perhalps an other programmer, such as the dragon. would I still need begin() & loop() ?
[20:39:41] <N1njan33r> Not if you are NOT using Arduino. Then the while(1) loop would go in main() as you have it.
[20:39:48] <N1njan33r> But that's the toolchain, not the hardware.
[20:40:12] <jerware> So in otherwords, avrdude and avr-g++ mandates being() and loop() ?
[20:40:21] <jerware> err begin()
[20:41:01] <benbergman> I'm breadboarding a project with at ATmega32u4 and experiencing some weirdness
[20:41:30] <Tom_itx> the 2nd word of your statement is probably your problem
[20:41:32] <N1njan33r> jerware: No, that's ALL Arduino library stuff.
[20:41:48] <benbergman> it is a custom keyboard and I had it partially working (was reading keys and sending correct key presses over USB)
[20:42:00] <benbergman> Tom_itx: I'm using a 32u4 dev board
[20:42:08] <benbergman> from adafruit
[20:42:44] <Tom_itx> breadboards are noted for failures ...
[20:42:50] <benbergman> the problem I'm having is, when I went to add some i2c code, it seems to have messed up my dev board
[20:43:08] <benbergman> I swapped out the dev board for a spare and reverted my code and it is working again
[20:43:17] <benbergman> reverting the code on the original board did not help
[20:43:50] <benbergman> the issue experienced with the problem board is incorrect key codes sent to computer
[20:43:58] <benbergman> it seems to still be reading from the keys just fine
[20:44:43] <benbergman> the keymaps are stored in PROGMEM
[20:45:06] <jerware> I want to flush my serial buffer at the end of the loop. How do I do that?
[20:45:56] <N1njan33r> jerware: To flush the RX buffer use "while(Serial.read() != -1);"
[20:46:02] <aandrew> read (and discard) until the call says nothing's left
[20:46:12] <jerware> oh yeah. Just read it out.
[21:41:40] <jerware> can you have both loop() and eventSerial() in the same program? Or is it one or the other. Not sure if they execute in paralell.
[21:42:22] <jerware> err serialEvent()
[21:42:58] <N1njan33r> eventSerial() is probably driven via interrupts, so it should be fine. Again, that's all Arduino-specific.
[21:52:54] <jerware> Serial.println("green"); // Appends a CR and LF. How do I not do that?
[21:53:03] <jerware> I want to print("foo");
[21:53:12] <jerware> not "foo" and a bunch of crap
[21:55:53] <aandrew> LeoNerd: where did you find the stk500 serila protocl?
[21:56:00] <aandrew> wow lysdexic typist
[21:56:02] <Xark> jerware: Remove the "ln".
[21:56:06] <aandrew> LeoNerd: where did you find the stk500 serial protocol
[21:56:17] <N1njan33r> jerware: What aandrew said :)
[21:59:25] <aandrew> N1njan33r: actually it was Xark :-)
[22:07:31] <jerware> serialEvent() never gets called.
http://codepad.org/lylQ5G5I
[22:07:43] <jerware> I'm sending it data.
[22:10:51] <Xark> jerware: It only calls serialEvent after loop returns. Try reducing that delay.
[22:12:04] <Xark> jerware: To see why, here is Arduino "main" function ->
http://hastebin.com/ufiwuyihib.coffee
[22:13:30] <Xark> jerware: serialEvent is mostly crap/hack. Better to just poll serial.available() IMHO. :)
[22:13:59] <jerware> So keep everything in loop() ?
[22:14:22] <Xark> jerware: You can let loop return if you want (and have it be your main loop).
[22:14:46] <Xark> However, serialEvent is the one thing that "cares" about what you do in loop. If you don't use it, no reason to return.
[22:15:17] <Xark> (You will be an eensy bit faster too :) )
[22:40:59] <benbergman> I've posted some more details for my issue in the avrfreaks forum:
http://www.avrfreaks.net/forum/32u4-partially-working