Back
[01:18:51] <mark4> anyone here use avr studio 5 or do we all still use avr studio 4?
[01:19:06] <mark4> im not a huge fan of m$ development tools personally
[01:19:19] <tlvb> avrgcc here
[01:19:53] <inflex> vim + avrgcc here
[01:20:12] <mark4> i tried the beta of as5 and uninstalled it within 3 minutes lol
[01:20:22] <mark4> i then reported about 20 bugs for as4
[01:20:42] <tlvb> sounds that the total outcome of trying as5 was positive then :)
[01:20:52] <mark4> heh it was an education :))
[01:21:13] <mark4> but it WAS the beta so they probably had not had enough of a chance to build in REAL suckage yet
[01:21:24] * tlvb was thinking of the bug reports, devs need them
[01:21:32] <tlvb> I HAVE BUILT STUFF:
http://solstorm.doesntexist.com/leo/projects/clockv2/img3/board.jpg
[01:21:43] <tlvb> brace for ugly soldering though
[01:21:51] <mark4> nice color :)
[01:22:08] <tlvb> mark4: that is the one available from dorkbotpdx
[01:22:09] <mark4> yea ern, that IS fugly soldering lol but those are small devices
[01:23:08] <mark4> http://www.adafruit.com/products/330 <--- this is going to be my next purchase
[01:23:11] <inflex> scrub it down and it'll look a LOT nicer - most of the "ugly" is just flux
[01:23:12] <tlvb> small devices + soldering iron tip not made for smt soldering + soldering iron tip is a bit worn out
[01:23:46] <inflex> but yeah, there's also plenty of no-enough-flux joints there too
[01:24:36] <tlvb> I only have regular soldering thread ...or what it is called, no extra flux (I should have gotten some from the latest mouser order I put in)
[01:24:37] <mark4> http://www.amazon.com/gp/product/B005D5SR3Y <--- i also just bought one of these
[01:24:41] <mark4> this is the smexy!
[01:24:52] <inflex> those are neat
[01:25:20] <mark4> i told my boss at work he REALLY need to buy all his engineers one of these.
[01:25:32] * tlvb glances at his huge-ass 54503 scope
[01:25:39] <mark4> lol
[01:26:00] <tlvb> I recently had to haul it some 5km ...and I don't have a car
[01:26:14] <mark4> how did u get it there?
[01:26:21] <tlvb> took it on the bus :)
[01:26:25] <mark4> lol
[01:26:30] <mark4> where are u from?
[01:26:34] <tlvb> sweden
[01:26:47] <inflex> 5km... that's like 1/2 way across the country for you guys
[01:26:52] <mark4> cool. ive been to norway
[01:26:58] <mark4> cute chix :)
[01:27:02] <tlvb> heh
[01:28:11] <tlvb> inflex: maybe in the east-west directions, not north-south though
[01:28:43] <mark4> i grew up in england but was born and now live in the united states. my fave quote is....
[01:29:08] <mark4> the biggest difference between the united states of america and england is that the english think 200 miles is a long way and the americans think 200 years is a long time
[01:29:33] <tlvb> haha
[01:29:42] <mark4> is da troof!
[01:37:00] <tlvb> considering time as a spatial dimension, it is just a matter of rotation
[07:59:49] -niven.freenode.net:#avr- [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff:
http://freenode.net/faq.shtml#gettinghelp
[08:12:48] <Tom_itx> !thislog
[08:12:49] <tobbor> This one:
http://rueshouse.dyndns.org:82/~ircjunk/irclogs/html/%23avr-2011-11-20.html
[08:44:10] <inflex> lo there tobbor
[08:44:15] <inflex> oh damnit,I mean Tom_itx
[10:34:19] <vectory> rmreconns
[10:34:24] <vectory> oop
[10:40:05] <Tom_itx> hey inflex
[10:51:04] <rue_bed> Tom_itx, so look slike I'm putting in a dk order
[10:51:14] <rue_bed> should I get some m32u4?
[10:51:35] <rue_bed> oh, you said you have u2
[10:51:37] <rue_bed> ?
[10:51:54] <rue_bed> I'z gonna say, if I do, what package should I get
[11:17:18] <ben1066> Hey
[11:17:43] <ben1066> So Ive got an atemga8 and I try to open it in device flasher in avr studio 5
[11:17:44] <ben1066> yet it says
[11:17:45] <ben1066> No supported device matches device signature (0x1C 0x93 0x07)
[11:18:18] <ben1066> well, technically its an 8a
[11:18:44] <rue_house> hmm what version of studio?
[11:19:09] <ben1066> 5
[11:19:23] <ben1066> 5.0.1163
[11:19:50] <rue_house> ok, who in here uses studio, cause I dont...
[11:19:55] <ben1066> and both studio and my avrisp mk2 is up to date
[11:20:40] <ben1066> Ok what the hell.....
[11:21:03] <specing> ben1066: Have you tried using avrdude?
[11:21:06] <ben1066> I just turned it off and on again, suddenly the signature changed from 0x1C to 0x1E and it works....
[11:21:43] <ben1066> OH WOW, im lucky I didnt fry it, I connected it to 7v, before the voltage reg
[11:22:57] <ben1066> avrs seem pretty tolerant :p
[11:23:15] <ben1066> not that id purposely do it...
[11:24:03] <rue_house> I can testify they dont survive 12V
[11:24:07] <rue_house> but pics do...
[11:24:17] <ben1066> well 7v seems to be ok
[11:24:27] <rue_house> I'M NOT SUGGESTING THAT MAKES PICS WORTH ****
[11:24:30] <ben1066> I mean, i was USING an atmega168 at that voltage :p
[11:24:40] <rue_house> yike
[11:24:49] <specing> rue_house: PICS survive because they have nothing inside
[11:24:52] <ben1066> i only just realised, it was for like, 10 mins :P
[11:25:33] <ben1066> i guess when they work from 1.8-5v
[11:25:43] <ben1066> thats a bigger range than the 2v over I was doing :p
[11:27:02] <Tom_itx> rue_house if you can get tqfp get it if you want one
[11:27:02] <ben1066> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=79696&start=0 fun to read :p
[11:27:14] <Tom_itx> if you want one of these boards you need qfn for the U4
[11:27:27] <Tom_itx> and all the other stuff
[11:27:54] <Tom_itx> rue_house i have U2 and U4
[11:28:13] <ben1066> Is there any easy way to prototype the usb avrs?
[11:28:28] <ben1066> Since they are all smd breadbording is....not easy
[11:28:37] <Tom_itx> ben, yes what one do you want?
[11:29:30] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/boards/USB_Breakout/USB_Breakout_index.php
[11:29:34] <Tom_itx> there's a U2
[11:30:00] <ben1066> Hmm..looks nice
[11:30:20] <rue_house> tom, keep a channel open, I'm gonna get back to that question in a bit
[11:30:38] <rue_house> what shte diff between the 324 and the 32?
[11:30:41] <rue_house> I cant find it
[11:30:42] <Tom_itx> rue_house, i'm gonna run to the store in a bit but i'll be here after that
[11:30:48] <rue_house> k
[11:30:52] <Tom_itx> i'm not sure about that one
[11:30:57] <ben1066> looks a bit like the teensy
[11:31:07] <Tom_itx> it's supposed to
[11:31:36] <ben1066> Are the 32u2 and 32u4 pin compatible?
[11:31:44] <Tom_itx> no
[11:31:50] <Tom_itx> U4 is bigger
[11:31:51] <ben1066> Nope, just noticed :)
[11:31:59] <Tom_itx> 44 opposed to 32?
[11:32:02] <Tom_itx> i forget
[11:32:04] <rue_house> ooo
[11:32:08] <rue_house> no I found it
[11:32:18] <ben1066> yea
[11:32:30] <Tom_itx> those are 15
[11:32:32] <Tom_itx> ea
[11:33:01] <ben1066> the only thing I wish it had was an isp header, but I can live without :P
[11:33:04] <rue_house> the 324 vs 32, the 324 has 6 pwm, more pin change interrupts, an extra uart (or two?) ...
[11:33:25] <Tom_itx> ben1066, you program them with the usb
[11:33:29] <rue_house> and the 324 is 20Mhz
[11:33:36] <Tom_itx> you CAN use the isp but they have a built in bootloader
[11:33:39] <ben1066> I know, but I still like not to be forced to use a bootloaer
[11:33:43] <Tom_itx> ok
[11:33:58] <Tom_itx> it's easy to wire one from the pins
[11:34:11] <ben1066> where are you to be 5c outside?
[11:34:19] <Tom_itx> ks
[11:36:35] <rue_house> hmm should I blow $100 on 25 avrs?
[11:36:48] <Tom_itx> naw
[11:36:52] <rue_house> 40 dip
[11:36:53] <Tom_itx> which ones?
[11:37:00] <rue_house> I'm not using them up as fast as I used to
[11:37:03] <Tom_itx> you should move up to some newer ones
[11:37:06] <rue_house> http://search.digikey.com/ca/en/products/ATMEGA324A-PU/ATMEGA324A-PU-ND/2271034
[11:37:16] <Tom_itx> look at the 328 etc
[11:37:21] <rue_house> yea, I need to get into the usb ones dont I
[11:37:22] <Tom_itx> 48... 328
[11:37:28] <Tom_itx> those aren't usb
[11:37:47] <Tom_itx> 28dip with plenty of features
[11:37:56] <rue_house> I dont think the 48...328 are availa in 40 dip are they?
[11:38:01] <Tom_itx> no
[11:38:03] <Tom_itx> 28
[11:38:12] <Tom_itx> in my tut
[11:38:18] <rue_house> ooo less oi
[11:38:23] <rue_house> I need io
[11:38:27] <Tom_itx> ok
[11:38:47] <Tom_itx> what about a i2c or spi io exapnder?
[11:39:08] <rue_house> latency isn't good for servos
[11:39:12] <Tom_itx> ok
[11:39:30] <Tom_itx> how about a fpga io expander?
[11:39:33] <Tom_itx> :)
[11:39:41] <rue_house> although, since you mentioned it, whats that spi latch with drivers someone was using in robotics from microchip?
[11:39:43] <Tom_itx> you could even parallel in to it
[11:39:53] <Tom_itx> probably
[11:40:02] <Tom_itx> i don't have the part number of it
[11:40:46] <ben1066> rue_house: there are some like the 644 with a large amount of io afaik
[11:41:16] <Tom_itx> well he could get one of the 100+ pin tqfp too if he wanted
[11:41:49] <Tom_itx> i think he wants to stick with dip as long as humanly possible
[11:41:56] <ben1066> 644 is dip
[11:42:16] <ben1066> http://www.atmel.com/dyn/products/product_card.asp?part_id=3694
[11:42:17] <ben1066> 32 ios
[11:42:28] <ben1066> 4kb of ram also
[11:43:38] <rue_house> http://search.digikey.com/ca/en/products/MCP23S17-E%2FSP/MCP23S17-E%2FSP-ND/894276 not that...
[11:43:42] <ben1066> i think thats the biggest through hole backage
[11:48:57] <ben1066> Hmm, for an external 16mhz crystal, what setting do I require in avrstudio
[11:49:09] <ben1066> It makes little sense with the naming of the options :p
[11:49:46] <ben1066> external crystal/res startup 64ms+16ck?
[11:49:59] <ben1066> high frequency
[11:50:19] <Tom_itx> yeah sounds right
[11:50:51] <Tom_itx> http://www.engbedded.com/fusecalc/
[11:50:57] <Tom_itx> that might help you decide
[11:52:19] <rue_house> http://www.firmwarefactory.com/Docs/USB-SPI%20HW144.pdf heh its an usb avr programmer in a chip....
[11:52:43] <ben1066> YAY, I had the wrong caps :P
[11:53:05] <Tom_itx> for the crystal?
[11:53:22] <ben1066> Yea, I had some 22pf and something else that LOOK very similar
[11:53:31] <ben1066> And they were in the same packet,
[11:53:36] <ben1066> Which I had written 22pf on :P
[11:53:38] <Tom_itx> i've got some that only use 8pf
[11:53:51] <ben1066> ive got 16mhz and 20mhz crystals
[11:54:11] <ben1066> Which does me fine, 20mhz for the fancy avrs that support 20mhz
[12:05:41] <rue_house> Tom_itx, you back?
[12:05:46] <Tom_itx> no
[12:05:50] <Tom_itx> haven't gone yet
[12:06:32] <Tom_itx> what's up?
[12:06:41] <rue_house> the board you have
[12:06:53] <rue_house> would I need to get anything?
[12:06:55] <Tom_itx> which one are we taling about?
[12:06:57] <rue_house> dk
[12:07:16] <rue_house> lets say the m32 baord that didn't work out for ya
[12:07:20] <Tom_itx> the U2 or U4
[12:07:21] <rue_house> cause it dosn't matter to me
[12:07:40] <rue_house> well, honestly I'm starting with usb, so it dosn't matter
[12:07:48] <rue_house> I dont HAVE to have ADC
[12:07:54] <Tom_itx> i've got plenty of u2's made up
[12:08:01] <Tom_itx> you don't need to get anything
[12:08:15] <Tom_itx> unless you want pin headers
[12:08:27] <rue_house> I dont need to take from your directly saleable stock
[12:08:40] <rue_house> heh, like I need pin headers
[12:08:42] <Tom_itx> i may have one or two that aren't
[12:08:58] <rue_house> whats most convienient for you to get rid of?
[12:09:18] <rue_house> what avr did you put on that SD board?
[12:09:22] <Tom_itx> probably the U2
[12:09:29] <Tom_itx> mega32
[12:09:44] <Tom_itx> tqfp mega32
[12:09:56] <Tom_itx> but that's not usb
[12:10:59] <rue_house> oh
[12:11:13] <rue_house> did you use dip, its freezing out and I dont want to dash out to the shop
[12:11:21] <Tom_itx> no
[12:11:31] <rue_house> esp cause I might stop at the boiler and freeeze to death
[12:11:36] <Tom_itx> i said i used a tqfp mega32 on the sd card
[12:11:42] <Tom_itx> the other one is 40 dip yes
[12:11:45] <Tom_itx> the one i sent you
[12:12:07] <rue_house> ok I'm gonna think in a shower of warm water for a few
[12:12:31] <Tom_itx> i'll prolly run to the store while you do
[12:59:15] <rue_house> are you back yet?
[13:00:34] <Steffanx> No is is not back yet
[13:01:05] <rue_house> hmm
[13:01:10] <rue_house> what do I need from dk
[13:03:24] <rue_house> nothing
[13:04:03] <Steffanx> I've no idea what you need from 'dk'.. as i've no idea what 'dk' is :)
[13:04:05] <Steffanx> or wo
[13:04:07] <Steffanx> who
[13:05:23] <rue_house> digikey
[13:06:45] <Steffanx> Ah ofcourse
[13:10:15] <CapnKernel> could have been butter cookies...
[13:10:26] <Casper> how long does it take for an avr to flash one page in flash?
[13:11:05] <CapnKernel> Casper: Does Google know?
[13:11:32] * Casper hits CapnKernel with a baseball bat for saying that
[13:12:48] <Steffanx> The datasheets knows i guess?
[13:12:52] <Steffanx> -s
[13:15:39] <Casper> trying to find in the datasheet, sadly, I still can'T find
[13:18:27] <rue_house> datasheet for what?
[13:19:34] <Casper> avr of course
[13:19:44] <Casper> to see how long it take to flash one page of data
[13:20:47] <rue_house> hahaha programming data! they keep that tucked away deeep in archives of unlabaled pdf's that aren't accessable from links on webpages
[13:25:25] <Steffanx> The programming info is pretty open rue_house .. except the timing parts probablt
[13:25:28] <Steffanx> probably
[13:26:24] <Steffanx> When using SPM is seems to take 3.7-4.5ms
[13:26:53] <CapnKernel> Might it vary between different part numbers?
[13:27:00] <CapnKernel> For example, when there's a process change?
[13:29:05] <Steffanx> Uhm it's sort of described in the "serial programming algorithm' chapter Casper ..
[13:29:41] <Steffanx> At least, it mentions some timings like "TWD_FLASH" which is 4.5ms
[13:34:32] <Casper> 4.5ms hmmm
[13:34:37] * Casper do some math
[13:35:43] <Casper> too fast for on the fly at 115200 :D
[13:44:28] <Casper> ARRG my toolchain is broken AGAIN.... damn idiot of maintainers...
[13:48:51] <Casper> stupid bug...
[13:49:06] <Casper> why didn'T the maintainer fixed that stupid symlink yet?
[13:49:36] <rue_house> well re-release a fork with it fixed
[13:49:39] <rue_house> piss him off
[13:50:17] <Casper> they throw the problem on the gcc developper
[13:50:41] <Casper> which say it's the distro (all of them) that mess up stuff
[13:50:52] <specing> Casper: compile it yourself
[13:51:14] <Casper> specing: it's just a matter of doing a simple symlink
[13:51:23] <Casper> # ln -s /usr/lib/binutils/avr/2.21.53.0.2/ldscripts/ /usr/avr/lib/ldscripts
[13:51:26] <Casper> that's it
[13:51:47] <specing> Distro?
[13:51:51] <Casper> gentoo
[13:52:00] <specing> No crt*.o problems?
[13:52:16] <Casper> every time I upgrade the toolchain the problem come back
[13:52:25] <Casper> what crt*.o problem?
[13:52:29] <Casper> (so no?)
[13:52:57] <specing> My install didn't find those files, so I had to manually copy them into the project directory
[15:11:38] <ben1066> I wish composite signals were easier to tint :(
[15:16:54] <Tom_itx> rue_house
[15:17:36] <rue_house> yes
[15:17:41] <Tom_itx> bak
[15:17:54] <rue_house> I'm about > < that close to buying a finished board from you
[15:18:05] <rue_house> considering where I started, thats pretty good
[15:18:15] <Tom_itx> wen you get >< that close lemme know
[15:18:40] <rue_house> I'm really thinking about the unpopulated boards you were saying you had kicking around
[15:18:48] <Tom_itx> you'd spend more getting parts
[15:18:51] <rue_house> I know how stuff like that finds corners to die in
[15:18:57] <rue_house> and assembling it
[15:19:03] <rue_house> you know my time is worth nothing
[15:19:22] <Tom_itx> i do have one that is a at90usb162, the others are atmega32U2
[15:19:41] <Tom_itx> someone requested the 162 so i populated a couple that way
[15:19:45] <Tom_itx> same thing really
[15:19:47] <rue_house> the demo I want to play with said U4, I dont want t deviate too far from that
[15:19:54] <Tom_itx> oh
[15:20:08] <Tom_itx> ok
[15:20:11] <rue_house> I dont mind not having adc, cause I'm not doing audio in
[15:20:17] <Tom_itx> i have 2 of those put together
[15:20:23] <Tom_itx> one with xtal one with osc
[15:20:26] <rue_house> 2 of the 162?
[15:20:28] <Tom_itx> both 16Mhz
[15:20:37] <Tom_itx> no 2 of the atmega32U4
[15:20:44] <rue_house> gee, you made a bunch of oddball stuff didn't ya?
[15:20:46] <Tom_itx> one 162 populated left
[15:20:47] <rue_house> mmm
[15:20:51] <Tom_itx> no nothing oddball
[15:21:04] <Tom_itx> but the U2 is the same as the 162
[15:21:09] <rue_house> what do you expect to be throwing out in 4 yeras
[15:21:11] <Tom_itx> at90162 that is
[15:21:24] <Tom_itx> at90usb162 that is
[15:21:39] <Tom_itx> i'm like you
[15:21:44] <Tom_itx> if i got it, i keep it
[15:22:41] <ben1066> whats the difference between at90 and atmega?
[15:22:49] <Tom_itx> age
[15:23:00] <ben1066> No functional difference?
[15:23:07] <Tom_itx> the at90usb162 was superseeded by the atmega32U2
[15:23:17] <ben1066> So they are legacy parts?
[15:23:22] <Tom_itx> nothing i'm aware of but there are probably some differences
[15:23:47] <rue_house> Tom_itx, have you come to the point in your life where you look at things and know your gonna throw them out before they have a chance to get used?
[15:24:22] <rue_house> I wonder if the lufa demos I want to play with would fit on a 16
[15:24:25] <Tom_itx> yeah but i hug em and put em back on the shelf
[15:24:44] <Tom_itx> probably so but not much smaller
[15:24:50] <Tom_itx> and may be a tight fit at that
[15:25:00] <Tom_itx> won't fit on an 8
[15:25:16] <rue_house> Tom_itx, so, your saying that just like my dip40 4Mhz Z80 chips, your not gonna give up finding a use for all your carrier boards
[15:25:22] <Tom_itx> that uno thing uses an 8
[15:25:30] <Tom_itx> and has a custom ver for serial for it
[15:27:12] <Tom_itx> rue_house which one are you leaning toward? the atmega32U2 or the atmega32U4?
[15:27:46] <rue_house> I'll accept U2
[15:28:01] <Tom_itx> do you think you can solder QFN?
[15:28:09] <rue_house> whats your U4 board worth?
[15:28:11] <Tom_itx> leadless
[15:28:14] <Tom_itx> i dunno
[15:28:23] <Tom_itx> i was gonna look
[15:28:39] <rue_house> I think I cn do anything, I have a clothes iron and an incredible sense of determination
[15:28:54] <Tom_itx> you only get one shot at those
[15:29:09] <rue_house> after I got the chip on, the rest would be a walk thru the coals
[15:29:23] <soul-d> u2 has tqfp to
[15:30:02] <soul-d> orderd one of those from farnell
[15:33:05] <Tom_itx> yes all my U2's are tqfp
[15:33:11] <ben1066> I like farnell, they deliver quickly :P
[15:33:11] <Tom_itx> the U4 i have is qfn
[15:33:18] <Tom_itx> they weren't available when i got them
[15:33:27] <Tom_itx> so i was fortunate to get the qfn
[15:33:34] <ben1066> how did you get it?
[15:33:43] <Tom_itx> i have connections
[15:33:45] <Tom_itx> :)
[15:33:47] <ben1066> engineering sample?
[15:33:49] <Tom_itx> no
[15:46:56] <rue_house> mmmm fresh fried engineer
[16:37:55] <_abc_> Hello. What's the deal with the *update* functions in avr/eeprom.h ? Do they read-modify-write? Is this a compat mode wrt some older library or what?
[16:57:19] <abcminiuser> Thesis: Submitted.
[16:58:38] <mrfrenzy> congratulations abcminiuser
[16:59:12] <abcminiuser> Whee
[17:00:44] <Casper> is there any case where there would be a part of the .hex that do NOT start at the begening of a flash page? or will the page be "zero" filled first?
[17:01:27] * Valen sends abcminiuser a 6-pack
[17:02:06] <abcminiuser> Cheers Valen
[17:47:27] <Casper> guys
[17:47:55] <Casper> does anyone of you made a bootloader with interrupt? looking at how to deal with the interrupt vectors...
[17:48:00] <Casper> the table...
[17:48:17] <Casper> to tell the cpu to execute the interrupt in the bootloader and main apps
[17:48:28] <Casper> is there a macro already defined?
[17:48:58] <Casper> I can see a big problem with the "normal" bit clearing way, as it would go past the 4 cycles limit
[17:50:35] <Craio> Got a question about an avr as a usb slave. Would it be doable (for someone with limited knowledge in the field) to make an AVR act as a usb printer? (just make a host believe a printer is connected)
[17:53:33] <Casper> Craio: depend up to what point. if you want it to be listed only then yes, if you want it to react to an existing driver, it might be just not possible. so it depend on how close you want it to be
[17:54:54] <Craio> I just want the device to think the avr is a printer is connected and then have the avr send the data received to a PC for decoding.
[17:55:54] <Craio> The device aint a PC
[17:57:06] <Casper> so interract with an existant driver then
[17:57:09] <Casper> good luck
[17:57:27] <Casper> this is more than make a pc think that a printer is connected
[17:57:37] <Casper> it's to actually emulate a printer
[17:57:51] <Casper> ỳou will have to find a way to reverse engineer the protocol they used
[17:57:56] <Craio> to a certain level, yes
[17:58:04] <Casper> almost fully
[17:58:22] <Craio> the device requires a usb printer that support PCL4 or 5 not sure
[17:59:14] <Craio> so i thought just acting as a generic usb printer should do it, but i gues i'm wrong
[18:00:01] <Casper> depend on the driver
[18:00:22] <Casper> you have to emulate enought of the printer so the driver can actually accept the device
[18:04:09] <Craio> hm, gues it might more difficult then i thought
[18:07:10] <Craio> thanks for the help, it means i've got more research to do
[18:08:50] <Craio> bye
[21:20:10] <Casper> has anyone found a way to proprelly reset an avr from software?
[21:20:29] <Tom_itx> it's been done
[21:20:30] <Casper> so when it jump from the bootloader to the main application that no left over is there?
[21:20:42] <Tom_itx> i believe you generally use the WDT iirc
[21:20:43] <Casper> without wiring a pin to the reset that's it
[21:21:03] <Tom_itx> one way resets it completely and the other leaves some regs as is
[21:21:21] <Tom_itx> but i think the wdt is the way to go
[21:21:27] <Casper> WDT seems to be the only way...
[21:21:32] <Tom_itx> i'm sure someone will correct me...
[21:21:43] <Tom_itx> no you can jmp to the start
[21:21:50] <Tom_itx> iirc that was the other way
[21:22:15] <Casper> yeah jmp 0x0000
[21:22:26] <Casper> but that actually do not reset the pending interrupts afaik
[21:22:42] <Tom_itx> wdt i think is the way to go
[21:23:59] <Casper> same
[21:24:20] <Casper> and actually would be smaller codewise
[21:25:06] <Tom_itx> i think it clears some regs though that normally wouldn't be
[22:34:06] <inflex> yay, OLED samples are on the way
[22:34:20] * inflex will soon have to work out how to deal with these display units... going to be fun and games
[22:51:06] <Valen> billet Al housings ftw
[22:51:12] <Casper> has anyone made an uart lib with flow control?
[22:51:24] <Valen> i wonder is there a market for a black box for RC stuff?
[22:51:30] <Valen> physically rugged style
[22:52:10] <Casper> I beleive so
[22:52:19] <Casper> as there is already some datalogger in speed controllers
[22:52:37] <Casper> and I know there is some datalogger for RC heli
[22:53:17] <Valen> yeah but datalogger inside something that'll survive the 200km/h Vs Tree/concrete impact
[22:53:52] <Valen> wow houses in america are like houses here, but missing a 0 from the price
[22:54:17] <Casper> house price are just ridiculously high and artificially inflated :/
[22:54:33] <Valen> its the land prices here
[23:06:42] <ziph> Has anyone made a library to set a pin to 1 or 0? I really like code reuse and all. ;)
[23:08:17] <Casper> why a lib for such plain thing?
[23:08:31] <ziph> Code reuse!
[23:08:47] <ziph> Why write it myself when I can use a library?
[23:09:08] <Casper> there is already a deprecated macro (_BV() ) and the foo |= (1<<x) and foo &= ~(1<<x)
[23:09:31] <ziph> Why have one for UARTs then? :)
[23:09:35] <Casper> if you use a library for such basic thing, then you should give up
[23:09:42] <Casper> because the uart lib actually do way more
[23:10:32] <ziph> Barely. :)
[23:10:33] <Casper> like peter fleury's lib have a calculator, interrupt handling, circular buffer, printf handler and more
[23:10:52] <Casper> many lines of code
[23:10:53] <ziph> And on a uC you generally want the application code fairly closely coupled to the UART.
[23:11:05] <Casper> it's closely coupled too
[23:11:15] <ziph> Not once you stick your code on top.
[23:11:31] <Casper> I guess you know even less how to code than me
[23:11:32] <ziph> You rarely need a circular buffer, too.
[23:11:36] <Casper> LOL
[23:11:53] <Casper> that is the words of someone that do not code for sure
[23:12:29] <ziph> You're funny. :)
[23:12:38] <Casper> so you prefer a blocking code?
[23:13:38] <Casper> every application I made that used the uart required the buffer, else the code would halt and a malfunction would have happened
[23:13:54] <ziph> What's the last one you did?
[23:14:40] <Casper> the last one was a failed controller for a psu... failed because the current sensing was too noisy and was throwing out the ADC
[23:14:53] <ziph> What was going over the serial?
[23:15:23] <Casper> update status of what's going on
[23:15:45] <ziph> Polled, or sent on a timer?
[23:16:19] <Casper> if I wouln't have used the buffer it would have blocked the code, caused the avr to not update it's pwm in a timelly manner and the psu would have smoked
[23:16:34] <Casper> not pooled and not timer
[23:16:45] <Casper> the lib is interrupt based
[23:17:00] <ziph> What made the controller decide to send off the status information?
[23:17:04] <Casper> the printf() fill the buffer, the interrupt send it slowly
[23:17:36] <Casper> that was a timer that was causing the update
[23:17:51] <Casper> once a second
[23:18:18] <Casper> I would have went faster, but the data was then hard to analyse due to the fast changing
[23:18:43] <Casper> sometime I was going 10 updates/sec
[23:20:34] <ziph> There's no particular need in that application for a circular buffer. You could've just done it with a pointer into a buffer passed to the UART routines.
[23:21:03] <Casper> do you know the real advantage of the circular buffer vs your linear buffer?
[23:21:14] <Casper> extremelly light on cpu
[23:21:42] <Casper> and on microcontroller, that is what you want
[23:21:58] <ziph> No, on a microcontroller you want something that is light on SRAM use.
[23:22:07] <Casper> and on cpu too
[23:22:31] <Casper> your linear buffer would save only 2 bytes of ram, but would cause 100 times more cpu usage
[23:22:56] <ziph> How so?
[23:23:07] <Casper> unless you plan to use malloc?
[23:23:49] <ziph> Huh?
[23:24:23] <Casper> so how will you deal with your buffer?
[23:24:31] <Casper> and how will you add data to it?
[23:24:50] <Casper> send a byte, move all data "left" ?
[23:25:19] <Casper> keep track of the quantity of data left to send? and add the new one at the end?
[23:26:08] <Casper> or use \0 as the end of data?
[23:26:49] <ziph> If you're sending the same status at a fixed rate then you won't be appending anything to anything.
[23:27:29] <Casper> then you want to wait for each character to be sent before you can continue your code?
[23:28:03] <ziph> Why would you do that?
[23:28:32] <Casper> so how do you want to deal with slowly send the data over uart but quickly execute the code?
[23:29:32] <ziph> The same way you dish things out of a circular buffer.
[23:29:42] <Casper> explain
[23:30:04] <ziph> Why, you don't know? :)
[23:30:30] <Casper> I don't see how you will do it without a good buffer so your code can continue
[23:30:49] <Casper> while keeping the interrupt routine as light as possible too
[23:34:26] <ziph> The interrupt routine just sends the next character and advances the pointer if the pointer is non null. If after it advances it finds a nul it sets the pointer to null.
[23:34:50] <Casper> and how do you add the new data to it?
[23:35:28] <ziph> Why are you adding new data to it? The status rate is fixed.
[23:37:17] <Casper> yes, but it happend sometime that it don't even have time to fully send the buffer somehow
[23:37:26] <Casper> specially on some other code
[23:37:33] <Casper> and the status update wasn't the only thing sent
[23:38:11] <ziph> So when your flow control goes off and you can't empty nor add any more to the buffer, what do you do with the status updates?
[23:38:29] <Casper> for the flow control, that is another project
[23:39:11] <ziph> And aren't you using two buffers? One to snprintf into and then the circular buffer?
[23:39:19] <Casper> basically I want to make a bootloader that can receive .hex directly, pasted or something. sadly, the pc send it way too fast for it to have time to process in real time
[23:39:58] <Casper> I calculated that at the speed I wanted to use, it take 3.4ms to receive one page of data, and the datasheet say 4.2ms to flash
[23:40:24] <ziph> You can't depend on flash write timings, they're variable.
[23:40:41] <Casper> and that is if it work first time, and I don't know if the 4.2 is just the write or if it include the erase cycle
[23:41:20] <Casper> so I receive the data in 3.4ms, but need to work with it for over 4ms, possibly even longer than 10ms
[23:41:33] <Casper> so I need a way to halt the data flow
[23:43:33] <Casper> sadly can't seems to find any premade libs
[23:44:12] <ziph> Does the flash chip have an SRAM buffer on it, or do you have to write byte-by-byte?
[23:44:48] <Casper> it have a 1 page buffer
[23:45:03] <Casper> and it's the avr itself, not separate chip
[23:45:25] <ziph> Oh, that's right, for a bootloader.
[23:45:33] <Casper> ya
[23:45:36] <ziph> Isn't X-Modem traditional if you don't want to write anything on the PC side?
[23:45:51] <Casper> x/y/z modem yes
[23:45:53] <Casper> but...
[23:46:12] <Casper> those protocol ain't much suited on an avr without flow control too
[23:46:56] <Casper> they are packet based, I forgot which one is the most apropriate, but one of them is 128 bytes/packet, and iirc it's the smallest packet you can have on the 3 protocols
[23:47:06] <ziph> I'd just write a firmware loader that queried the AVR for its preferred buffer size and then send binary frames for the update.
[23:47:11] <Casper> this avr is 32 per page
[23:47:31] <Casper> that is what I do not want to do... to write specialised program on the pc
[23:48:52] <Casper> maybe I should hack peter fleury's lib... to add flow control AND to be able to know how much data there is in the rx buffer...
[23:48:58] <Casper> 2 missing things...
[23:49:15] <ziph> It sounds like it would be the easier option (software on the PC ;)
[23:49:24] <Casper> actually not really
[23:49:46] <Casper> I was actually planning on a like 2-3 character rx buffer
[23:50:15] <Casper> as soon as there is data in the buffer, send an xoff
[23:50:18] <ziph> So are you using a buffer for the snprintf and a second one for the circular buffer?
[23:50:20] <Casper> when empty send xon
[23:50:56] <Casper> dunnot yet, but the buffer for the printf stuff is disposable, and small
[23:51:06] <Casper> dumped to the circular, then freed
[23:51:27] <ziph> You're mallocing it?
[23:57:32] <Casper> no
