Back
[00:16:02] <rue_more> hihell
[00:16:43] * Casper throws rue_more in hell since he seems to like it so much :D
[00:39:05] <rue_more> wow, ebay phone system prices are amazingly inflated
[00:39:36] <Casper> ebay is quite inflated now
[00:39:42] <Casper> almost unbuyable
[00:39:54] <rue_more> T1 cards for WAY more than they cost new
[00:39:58] <Casper> one of the few things that is cheaper there is some chinese white leds
[00:41:07] <rue_more> shipping from anywhere in north america kills
[00:41:17] <Casper> ya
[00:41:28] <beaky> what is the best shop to buy atmels?
[00:41:31] <Casper> weirdly, it's cheaper to get stuff from china than to get it in the same country
[00:41:48] <rue_more> things are set up to make it like that
[00:42:11] <rue_more> beaky, best, price? I get mine from digikey, I try to buy 25+ at a time
[00:42:16] <beaky> my local electronics shop is making me pay 20 bucks for an ATmega328 :( I think I should look into ordering from internet companies
[00:42:35] <beaky> digikey has good prices for the stuff
[00:42:45] <beaky> but shipping costs 75 bucks :(
[00:43:05] <rue_more> http://www.ebay.ca/itm/New-Version-Pro-Mini-5V-16MHz-MEGA328P-Arduino-compatible-Nano-Size-/200916486357
[00:43:10] <rue_more> $6 on pcb
[00:43:24] <beaky> ah
[00:44:11] <rue_more> we cant even assemble them for that
[00:45:24] <rue_more> http://www.digikey.ca/product-search/en/integrated-circuits-ics/embedded-microcontrollers/2556109?k=mega328&stock=1&fid=0&pageSize=25
[00:45:30] <rue_more> oh they aren't that expensive anyhow
[00:45:43] <rue_more> $3.22 ea
[00:45:55] <rue_more> $2.70 @ 25+
[00:50:48] <beaky> ah
[00:51:08] <beaky> xlent
[02:12:05] <braincracker> Gumboot <= i tent to make a difference between a microcontroller and a 'PC', microcontrollers are for real-time things with own 'OS', PC's are for using paint, drawing things, net ...
[03:01:07] <braincracker> hah you like this ?
http://pastebin.com/9chiWz6A
[03:01:17] <braincracker> ( avr macro magic ? )
[03:03:22] <specing> someone should fix C to have reasonable bit operations
[03:05:54] <megal0maniac> Now, I know that you shouldn't run a m32u2 at 16mhz at 3v3, but will running it with a prescalar have the same effect as changing the clock source? I.e. would it be as stable, given that the core clock is still running at 16mhz
[03:07:26] <specing> megal0maniac: try
[03:07:39] <nevdull> i think the operation would be undefined since 16MHz is usually a >=4.5V sorta operation
[03:07:59] <nevdull> although there are lots of charts in the back of that datasheet that would probably give you more info about that, too
[03:08:38] <braincracker> it is out-of-specs
[03:08:52] <braincracker> but it will probably work
[03:09:39] <braincracker> well with prescaler, limitation does not apply the same way, only the divided clock must be within limits
[03:11:21] <megal0maniac> Well it works just fine at 16mhz on 3v3, I'm just wondering whether a prescaler and a different clock source are equally reliable
[03:11:41] <megal0maniac> So it's difficult to test, since it works either way
[03:11:49] <braincracker> div 2 will be reliable
[03:12:30] <megal0maniac> I hoped for that answer :P
[03:13:17] <braincracker> hey abcminiuser_
[03:13:24] <abcminiuser_> Morning
[03:15:39] * megal0maniac waves
[03:16:06] <braincracker> why do i have 4 pcs
[03:16:12] <braincracker> ;/
[03:16:58] <megal0maniac> Spares?
[03:17:37] <braincracker> i should get some small ARM thingies
[03:17:52] <braincracker> 2.5W in operation is neat
[03:17:56] <megal0maniac> Seagate Dockstar!
[03:18:02] <megal0maniac> Or Beaglebone Black
[03:18:12] <braincracker> never heard of 'em
[03:18:45] <megal0maniac> Beaglebone Black is actually a dev board, but the Dockstar is a consumer product which runs Debian pretty nicely :)
[03:19:26] <braincracker> most popular is this right?
http://en.wikipedia.org/wiki/Raspberry_Pi
[03:20:06] <megal0maniac> Pretty much
[03:21:06] <braincracker> ah, no free samples?
http://www.ti.com/tool/beaglebk?DCMP=PPC_Google_TI&247SEM
[03:21:08] <braincracker> ;>>
[03:22:06] <braincracker> Example Applications Robotics, motor drivers, Twitter printer, data backup, SDR base station, USB data acquisition and more
[03:22:14] <megal0maniac> Heh :) Yeah
[03:22:16] <braincracker> so they don't know what it is useful for
[03:22:26] <braincracker> just get one and do whatever with it
[03:22:33] <megal0maniac> That's the idea
[03:23:22] <megal0maniac> It's a glorified break-out board for a chip, albeit one with very nice features
[03:25:31] <braincracker> oh cool ti's scripts hung konqueror
[03:25:43] <braincracker> don't you just love that?
[03:34:10] * Valen is looking at making a GSM GPS dog tracking recovery thingie
[03:34:38] <Valen> http://www.telit.com/en/products.php?p_ac=show&p=7 would be nice but last I heard they were around $140
[03:34:43] <braincracker> buying sounds simpler
[03:34:49] <braincracker> just shove it up the dog's ass
[03:35:01] <Valen> $300 and max battery life seems to be 80 hours
[03:35:06] <Valen> which is pretty crappy tbh
[03:35:10] <braincracker> yes
[03:35:27] <braincracker> no idea about power requirements, they usually use it in vehicles with 12V power
[03:35:47] <Valen> umm every mobile phone has a GPS and GSM module in it these days
[03:36:02] <braincracker> you can even get away with a pulse per few minutes for tracking.
[03:36:16] <Valen> I figure most of the issue would be they leave the GSM connection live
[03:36:26] <braincracker> i don't think you want to strap a mobile phone on your dog
[03:36:33] <braincracker> there are smaller solutions
[03:36:50] <Valen> if you shut down totally and only poll GSM and GPS every 10 minutes or so then the power requirements would be greatly reduced
[03:37:14] <braincracker> a cd40106, resistor, capacitor and mosfet will do ?
[03:37:19] <Valen> really? like perhaps that bare module i posted a minute ago
[03:37:48] <Valen> I was planning on making something, you know, buying IC's programming firmware, milling out a case
[03:38:03] <braincracker> make it small
[03:38:18] <Valen> brilliant, why didn't I think of that!
[03:38:19] <braincracker> now only the battery will be large
[03:38:29] <braincracker> i think that is the biggest problem.
[03:39:25] <Valen> yes, you need to spend time in total shut down, looks like the current for the radio modules is in the 50ua range and the GPS is around the same
[03:39:44] <Valen> probably dont want them turned all the way off or the turn on time will nerf the power saving
[03:40:05] <Valen> standby current for GSM is ~3ma, and operational is 460ma
[03:40:34] <Valen> so yeah, spending 3ma 24/7 will lead you to a 90hr battery life with a sensible sized battery
[03:40:48] <braincracker> just gate with a mosfet, now you get a leakage current while st-by
[03:41:03] <braincracker> 1uA sounds better than 3mA
[03:41:06] <Valen> 50ua is low leakage
[03:41:07] <megal0maniac> Valen: Ask RikusW when he's online. He's designed exactly that for cattle
[03:41:38] <Valen> megal0maniac: heh, he probably has a SLA hanging off it to power it though cow won't mind ;->
[03:41:57] <braincracker> noo
[03:42:02] <braincracker> solar cells
[03:44:16] <megal0maniac> I'm not sure how it works, but he can definitely give you some pointers on hardware and such
[03:44:44] <Valen> yeah, just trying to find modules that arent the size of bricks and dont cost eleventy million dollars
[03:44:51] <braincracker> stupid gcc complains about this (uint8_t)'í'
[03:44:52] <megal0maniac> SIM900
[03:45:38] <Valen> one idea I had to make it more hands off was wireless charging, put a nice big coil under the dogs bed, and a matched coil in the module
[03:46:07] <Valen> needing to take it on and off the collar all the time to charge it means its going to be basically useless
[03:46:21] <megal0maniac> I like that coil idea
[03:46:31] <Valen> be plenty inefficient though given that air gap i feel
[03:46:41] <Valen> most of the "wireless charging" has a range of like 4mm
[03:47:04] <Roklobsta> more amps
[03:47:12] <megal0maniac> Glowing dog?
[03:47:14] <Roklobsta> make that primary field the biggest sucker you can
[03:47:51] <braincracker> how about a microwave oven aimed at the cows?
[03:48:00] <Valen> I figured you could put a weight sensor on the bed so it knows when it should charge, then bluetooth or a nordic module or something to signal end of charge
[03:48:04] <braincracker> you mount a microwave antenna on them
[03:48:07] <braincracker> ;>>
[03:48:12] <Valen> bluetooth could be handy for setup as well
[03:49:14] <Roklobsta> modulate the charging signal.
[03:49:19] <Roklobsta> like rfid does
[03:49:34] <Valen> interesting
[03:49:44] <Valen> there are off the shelf wireless charger IC's out there
[03:49:45] <Roklobsta> i mean the inductive rfid
[03:49:58] <Valen> this *should* be a solved problem, I'm just not sure about the scale
[03:50:27] <Valen> http://www.wivia.com/p/productid-73/telit-ge865-quad-module
[03:50:32] <Roklobsta> stupid laws of physics say magnetice fields have a short range.
[03:50:35] <Valen> € 40.90
[03:50:59] <Roklobsta> I am messing with a telit HE910 module. Penta band 3G
[03:51:07] <braincracker> Roklobsta <= bend spacetime then
[03:52:50] <Valen> http://en.wikipedia.org/wiki/Resonant_inductive_coupling is the one I think, uses resonances to get more range out of stuff
[03:53:55] <megal0maniac> http://www.otto.co.za/index.php?page=product&p=1075&name=Dual%20SIM%20miniature%20Quad-Band%20GSM/GPRS%20surface%20mount%20module
[03:54:11] <megal0maniac> That's like half the price...
[03:54:40] <megal0maniac> (about ZAR12 to the Euro)
[03:54:43] <Roklobsta> http://www.glynstore.com/gsm-3g-gps-modules/
[03:55:09] <Valen> 24x24x3 feels pretty big though
[03:55:21] <Roklobsta> pentaband, gps, NOT BGA
[03:55:38] <Roklobsta> ZA gets ripped every which way
[03:55:53] <megal0maniac> We do
[03:56:10] <Valen> 1.5ma sleep too on that sim900 one
[03:56:28] <Valen> i wonder ig it has a lower power mode
[03:57:03] <megal0maniac> RikusW knows all about it. It takes custom firmware too
[03:57:17] <Valen> Telit GE865 runs python
[03:57:25] <Valen> that gives it lots of ticks in my book lol
[03:57:31] <Roklobsta> yeah don't forget the ACMA testing.
http://www.approvalsblog.com/?p=223
[03:57:39] <Valen> I wasn't going to sell it
[03:57:45] <Roklobsta> i used to use GE864quad commercially.
[03:57:49] <Roklobsta> not a bad unit.
[03:59:18] <Roklobsta> stupid gprs gets 2nd class fare in the afternoons when the levels of voice traffic picks up though.
[03:59:38] <Valen> I was mainly planning on using SMS for interaction
[03:59:50] <Valen> theres a plan here now with 0 monthly fee
[04:00:18] <Valen> but data is a like 5c/mb and you just know its done in 1mb blocks lol
[04:00:30] <Roklobsta> i got a telstra prepaid sim. $5/mo 30MB which is fine for the puny traffic i am making
[04:01:03] <Roklobsta> nono get one of the prepaid voice plans and use the bonus browse data pack
[04:01:08] <Valen> check amaysim they have a no fee plan provided you do something at least once a month
[04:01:15] <Roklobsta> much better value than the data only plans
[04:01:19] <Valen> IE send one SMS each month, job done
[04:01:25] <Roklobsta> $10 SMS
[04:01:32] <Valen> nup, 10c
[04:01:36] <Roklobsta> i need nextg
[04:01:50] <Roklobsta> coz optus blows chunks in the boonies
[04:01:55] <Valen> http://www.amaysim.com.au/mobile-plans/amaysim-as-you-go.html
[04:02:39] <Roklobsta> the issue with sms is it's unreliable delivery
[04:02:41] <Valen> telstra just charge way too much
[04:03:24] <Valen> thats true, I figured it'd do nothing most of the time though, then look at firing up a data connection or much more rapid SMS's in the event of the dog leaving the "safe" zone
[04:04:48] <Roklobsta> and with data you need a server
[04:05:06] <Roklobsta> AHA telit modules also let you send emails
[04:05:20] <Roklobsta> they do all the SMTP work. just send some AT command and email sent.
[04:05:38] <Roklobsta> better than SMS
[04:05:42] <Valen> server isn't an issue, email isn't guaranteed delivery either
[04:05:44] <Roklobsta> reliable delibvery
[04:05:55] <Valen> reliable perhaps +-12hours though
[04:06:17] <Roklobsta> well, even data is unreliable
[04:06:50] <Roklobsta> having dealt with 100+ telemtry units on grps in the field i can tell you the networks can SUCK
[04:07:18] <Valen> heh, worst case have it make a voice call and text to speech the stuff ;->
[04:07:22] <Valen> double HA
[04:07:32] <Valen> modem over the voice call
[04:07:39] <Valen> DTMF that stuff man
[04:07:47] <Valen> rx it in an "app" on yer phone
[04:07:51] <Valen> here doggy doggy ;->
[04:08:02] <Roklobsta> if you send an SMS to a telstra voice or fax line it will be read out to the party at the other end or turned into a fax.
[04:08:19] <Valen> that'll bring back the memories 9600bps modem noises
[04:08:43] <Roklobsta> the exchange works out what is answering and does text to voice or fax.
[04:09:12] <Roklobsta> i don't know if fixed line SMS is still working.
[04:09:22] <Roklobsta> i think telstra gave up on that one
[04:10:54] <Roklobsta> marketing driven idea, like the old iMode in the pre-smartphone days.
[04:11:26] <Valen> i just hate telstra lol, it never should have been sold, at least not the wholesale arm
[04:12:16] <Valen> I was having a poke around on their website, their cheapest plan was $60
[04:13:11] <Roklobsta> nonnono
[04:13:19] <Roklobsta> prepaid 2$ sim.
[04:13:25] <Roklobsta> $5 bonus data.
[04:13:47] <Valen> i just meant for general use
[04:18:23] <megal0maniac> http://www.otto.co.za/index.php?page=product&p=961&name=SIM900%20+%20SIM08%20Combination
[04:18:43] <megal0maniac> Just a little big. But cheap
[04:19:00] <megal0maniac> ~EUR35 for quad band gsm and gps
[04:21:03] <megal0maniac> Maybe not for a dog, but still :)
[04:21:03] <Roklobsta> ok
[04:21:24] <Roklobsta> valen: what is the concept anyway
[04:21:48] <Valen> basically alert if dog leaves the yard, then updates to find it again
[04:22:09] <Valen> also ability to tell it to stfu the dog is with you or poll it and ask where it is
[04:22:10] <Roklobsta> electronic fence
[04:22:23] <Valen> that won't stop somebody from stealing it
[04:22:35] <Valen> and yes that does happen
[04:23:34] <Roklobsta> so you need gps and data of some kind
[04:24:02] <Valen> yup, and from a user POV it needs to be as hands off as possible I think
[04:24:23] <Valen> if you need to charge it every 3 days it'll last for about 2 weeks before it gets put in the too hard basket
[04:26:22] <Roklobsta> valen: sounds liek this:
http://www.techworld.com.au/article/456536/australian_startup_snapshot_ollo_mobile/
[04:27:52] <Valen> The issue I'm having with most of them is short battery life and wired charging
[04:28:42] <Valen> 10 day standby is not bad
[04:28:53] <Roklobsta> needs to be asleep most of the time and maybe once a monite get a hot fox from teh gps and sleep again.
[04:29:30] <Valen> thats what I was figuring
[04:29:51] <Roklobsta> occasionally you will need a cold and warm fix.
[04:29:57] <Valen> even 10 minutes would be sufficient I think, if you can go a month of standby 10 minute polling would be a worth while price
[04:30:13] <Valen> if the almanac is right it shouldn't need cold fixes
[04:30:24] <Roklobsta> dog could be well on it's way to Liverpool after 10mins
[04:30:50] <Valen> the point (at least for me) wasn't to prevent it from escaping when you were home
[04:31:08] <Valen> it was to alert you when you weren't then help you track the sucker down ;-.
[04:31:36] <Valen> I can see upsides to faster polling of the GSM for the "dog has effed off at the dog park" use case
[04:32:05] <Valen> I wonder how shitty the phone companies would get at you for popping on and off net that often
[04:34:41] <Roklobsta> just put the dog in a moniskirt, it can't jump or run much then.
[04:34:58] <Valen> ?
[04:59:58] <theBear> 'n they do look so purty in a miniskirt :)
[05:27:33] <theBear> Roklobsta, hmm, it's about time... those of us with vested interests have been looking into these kinda things, and that seems to be the first not-hopelessly-technically-misguised effort so far
[05:28:48] <theBear> the popular/recommended things with same purposes for example are often analog-fm based, and struggle to work 50meters from the basestation in your average home (with walls etc), doesn't really make them very useful, and cheap they are not ! and current technology they are not !
[05:30:23] <Roklobsta> there have been a few gsm/gps units around but larger than that one
[05:30:41] <Roklobsta> i mean tracking units for olides
[05:31:01] <Roklobsta> how do ankle bracelets the krims use work?
[05:31:50] <theBear> dunno, don't think we got them here, but they'd have to be currentish tech with a basestation surely, tho i suppose these days gps is fairly accurate, not like they're gonna advantage from a 100meter error that lasts 30 seconds
[05:32:11] <Roklobsta> sleep time...
[05:33:29] <theBear> ooh, god, my pills ! i feel like a heart patient... if only my pills fixed me almost instantly like theirs :(
[08:08:11] <megal0maniac> Quiet Sunday on #avr
[08:13:48] <RikusW> hi megal0maniac
[08:13:54] <megal0maniac> Yo
[08:14:14] <RikusW> I assembled your boards yesterday evening
[08:14:26] <megal0maniac> Got your PM, thanks :)
[08:36:12] <braincracker> (sizeof((ind)) < sizeof(int))?printf("input :%x = ", (ind)):printf("input :%lx = ", (ind)); \
[08:37:08] <braincracker> this gives warning for all cases
[08:37:15] <Horologium> that's nice.
[08:37:26] <megal0maniac> Oh no
[08:37:47] <Horologium> too bad we don't know what warnings.
[08:38:02] <braincracker> warning: format ‘%lx’ expects type ‘long unsigned int’, but argument 2 has type ‘int’
[08:38:11] <braincracker> warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘long int’
[08:38:12] <braincracker> :)
[08:38:14] <megal0maniac> Cast all the things!
[08:38:20] <Horologium> sounds like someone needs to learn how to CAST!
[08:38:30] <megal0maniac> Horologium: Beat you to it ;)
[08:38:33] <braincracker> wanted an universal macro without warnings
[08:38:41] <twnqx> sounds like someone need to learn to apply the correct modifiers in printf
[08:38:48] <Horologium> then cast everything to what it should be.
[08:39:00] <braincracker> it was meant to accept any size
[08:39:01] <megal0maniac> Sounds like I should learn how to program
[08:39:11] <braincracker> i'm being lazy
[08:39:15] <Horologium> then disable warnings.
[08:39:18] <megal0maniac> braincracker: Well your compiler disagrees with you
[08:40:58] <braincracker> (sizeof((ind)) > sizeof(int))?printf("input :%lx = ", (ind)):printf("input :%x = ", (ind)); < well this would guarantee "l" prefix for everything greater than int
[08:47:34] <braincracker> twnqx <= i was feeling like binprint((uint8_t)0xf0); binprint((uint64_t)0xf0f0);
[08:49:49] <braincracker> oh these hacks are sometimes ugly
[09:26:59] <timemage> braincracker, what are you trying to do?
[09:27:20] <edman007> tzanger, I'm not sure, though I suspect it had something to do with the ADC being off when I set ADMUX (or maybe I turned it off after setting it..)
[09:28:02] <timemage> edman007, i asked about that much later after our conversation.
[09:28:58] <timemage> edman007, btw, was that meant for me?
[09:34:05] <edman007> oh...yea
[09:34:09] <edman007> i think...
[09:34:19] <edman007> it was
[09:36:32] <timemage> edman007, heh. ok. i didn't see where it was happening in your code though. but the problem /went away/ in any case?
[09:37:17] <sabesto> megal0maniac: yeah, what is the point of 32/64 bit archs, cast it to 8 bits :P
[09:37:36] <timemage> braincracker, not that you care, but there is z for size_t types in c99 onward. e.g. "%zu" and "%zx"
[09:38:12] <sabesto> watched a docu on you tube a few days ago about the 10 worst computer errors
[09:39:16] <sabesto> they used a bit of casting in the Patriot missile, didnt work as well when they upgraded it and suddently it accelerated faster...
[09:40:27] <Netlynx> Where can i find additional information on how to use/program/configure the Quadrature decoder on an xmega avr controller? There is something missing on the software, but i can't find out what.
[09:41:07] <theBear> what software ? avr's don't have quadrature decoders
[09:41:18] <sabesto> yes they do
[09:41:47] <sabesto> Netlynx: what part? never used it but i would like to read about it
[09:42:37] <sabesto> Netlynx: read this:
http://www.atmel.com/Images/doc8109.pdf ?
[09:42:43] <theBear> they do ? seriously ? hardware quadrature decoding ?
[09:43:11] <specing> theBear: hail XMEGA
[09:43:38] <sabesto> also SAM got them too, not shure about UC3
[09:43:46] <Netlynx> xmega256A3BU
[09:43:48] <theBear> holy crap ! that's cool
[09:43:55] <timemage> heh, weird.
[09:43:58] <sabesto> also they got a few configurable logic cells
[09:44:05] <sabesto> like an fpga
[09:44:41] <theBear> holy crap ! that's cool
[09:45:02] <OndraSter_> that is the new E series
[09:45:38] <sabesto> Netlynx: here is the demo:
http://www.atmel.com/Images/AVR1600.zip
[09:45:39] <OndraSter_> all A series has got at least one decoder
[09:45:42] <OndraSter_> not sure about D series or C
[09:46:16] <Netlynx> sabesto, I have read the AVR1600 AP (doc8109.pdf) and used the code they provide. But there is something not right.
[09:46:31] <sabesto> ok
[09:52:40] <tzanger> edman007: did you say REG = 1 << ADMUX instead of REG |= 1 << ADMUX or someshit?
[09:52:44] <tzanger> that's a common mistake
[10:23:55] <Netlynx> sabesto, i have found the mistake. The AVR1600 demo code requires that changes on port and pins used as quadrature input are applied on multiple places. The demo code works (After applying the changes on every place.)
[10:25:35] <Tom_shop> you often have to move pins around
[10:33:50] <sabesto> hm
[10:34:32] <Netlynx> Tom_itx, i made the wrong assumption that the code was completely abstracted.
[10:38:24] <Tom_itx> you often have to change register names as well
[10:38:42] <Tom_itx> however once you do the code usually works
[10:52:09] <tyrosine> Greetings! I am using USART to send data to a PC. I desire to send about integer values at maximum speed continuously. I desire to send them as a data stream (not ASCII formatted characters representing the number). How do people usually send "break" codes to indicate the start/end of data? It's confusing me, because that sequence of bits could be in the data. Any suggestions?
[10:52:18] <tyrosine> *about 5 integer values
[10:52:49] <Tom_itx> checksum
[10:53:04] <Tom_itx> comes to mind
[10:53:22] <tyrosine> but how does one format the frames of data? The PC wouldn't know where the data ends and the checksum starts
[10:53:35] <Tom_itx> it's up to you to write it
[10:53:39] <specing> tyrosine: send in 64-byte packets followed by a one byte sum
[10:54:11] <tyrosine> how does the PC know where the one byte sum is? How is it separated frmo the preceeding packets, and the following packets
[10:54:29] <Tom_itx> start/stop bits etc
[10:54:34] <Tom_itx> numerous ways
[10:55:26] <specing> tyrosine: that is what the packet header does
[10:55:30] <tyrosine> start/stop bits -- I'm limited to 256 bits per character. Let's say I'm sending a bunch of "char" values. If it's random data, that's 1 in 256 chance my data will actually be a stop byte
[10:55:41] <tyrosine> but how does one separate the packet header from the end of the previous data?
[10:55:46] <specing> That is one big character
[10:56:00] <Tom_itx> I desire to send them as a data stream (not ASCII formatted characters representing the number)
[10:56:03] <Tom_itx> what character?
[10:56:04] <tyrosine> let's call data D, header H, and checksum C. DDDDDCHDDDDDCHDDDDDCHDDDDD
[10:56:25] <tyrosine> how can the computer know where the Ds are and where the Hs are, because a D could be the same value as an H
[10:56:29] <specing> tyrosine: the checksum will probably not match
[10:56:38] <tyrosine> 1/256 chance it will
[10:57:20] <Tom_itx> use a parallel data stream then and tie into the pci buss
[10:57:26] <tyrosine> ONE SOLUTION: I could set the USART timeout to a very small value and let it time out after every frame. That would be exactly what I want. It would clearly give the PC HDDDDDC - but it would be slow.
[10:57:39] <specing> tyrosine: you continously send out zeros until you get a packet from the PC telling you to start transmitting
[10:57:46] <tyrosine> lol, I like it Tom_itx, but surely there's a way to send frames of data over the serial port :)
[10:57:55] <specing> tyrosine: then you send the packet (H+D+C)
[10:57:57] <Tom_itx> ack nak
[10:58:11] <Tom_itx> xon xoff
[10:58:15] <tyrosine> That would be another solution. But for my purposes, unidirectional is preferred.
[10:58:48] <tyrosine> I understand a "long pause" separates bits from one byte from those in the next bite with USART. I wish there were a "long long pause" to separate data frames.
[10:59:18] <specing> It is not that long
[10:59:26] <specing> the pause is only 1/2 of a bit
[10:59:39] <tyrosine> exactly. I wish there were a 2-bit pause to indicate the start/end of a frame.
[11:00:19] <specing> tyrosine: look into 9-bit transmission maybe?
[11:00:32] <tyrosine> specing, yeah I was thinking that. I'll probably go with it
[11:00:44] <tyrosine> I was just wondering if there was anything more standard
[11:01:20] <tyrosine> the headerwill have the 9th bit be 1, and the data bits' 9'th bit will be 0...
[11:01:33] <tyrosine> actually I guess no header is required
[11:01:54] <tyrosine> the 9th bit will be 1 for the stop bit, and the other 8 bits will be the checksum
[11:02:57] <tyrosine> although I still like Tom_itx's PCI idea XD
[11:03:33] <Tom_itx> rue made an isa buss programmer
[11:03:44] <Tom_itx> maybe it was pci, i forget
[11:03:53] <Tom_itx> it made hackaday
[11:05:10] <tyrosine> heh, I love that phrase
[11:05:16] <tyrosine> I'm gleaming when my stuff makes hackaday
[11:05:49] <Tom_itx> it _is_ kinda geeky
[11:06:19] <tyrosine> hackaday got me interested in electronics, and when my stuff goes full circle and gets shown there, it makes my happy
[11:07:53] <tyrosine> back to the flow control... isn't that what RTS/CTS is for?
[11:08:06] <Tom_itx> kinda what i said above
[11:10:03] <tyrosine> I hadn't used xon/xoff before. I'm reading about it now, it looks like it's exactly what I'm looking for
[11:11:29] <tyrosine> er, I mean RTS/CTS
[11:12:30] <Tom_itx> one is hardware one is software iirc
[11:12:39] <tyrosine> yeah, the hardware one interests me
[11:12:48] <tyrosine> I'm between that an using 9-bit bytes
[11:13:58] <homeflix> whats the difference between relais? i can find a 5v/220V,8A for 4€ and a 12v/220V,10A for 1€?
[11:13:58] <homeflix> id like to control them via a transistor + atmega8
[11:14:33] <Tom_itx> the coil voltage
[11:14:52] <Tom_itx> and 2A on the contacts
[11:17:00] <homeflix> thank you Tom_itx :) okay, right now iam using a 16v dc input and a 7805 dc regulator for the avr 5v. the above values were just examples. so iam going to search for some cheap 16V relais :(
[11:17:02] <homeflix> *:)
[11:17:29] <Tom_itx> you may not want to run the coil off the regulator
[11:18:00] <Tom_itx> hamlin HE101, not sure about the contact current/voltage rating
[11:18:25] <Tom_itx> but you _can_ drive them from logic directly
[11:20:12] <homeflix> i live in germany. i have to stick to my local suppliers stock :/
[11:20:55] <homeflix> hm.... or ill just buy the 5v name-brand relais for 4€ and drive it with a standard transistor
[11:21:12] <Tom_itx> add a diode to it
[11:21:16] <homeflix> jup :)
[11:21:35] <homeflix> <Tom_itx> you may not want to run the coil off the regulator << na, i was trinking to run the coil off the 16V input.
[11:21:38] <Tom_itx> the hamlins come with it builtin
[11:21:42] <homeflix> wouldnt that be possible too?
[11:21:58] <Tom_itx> if it's rated for 16v
[11:22:32] <homeflix> ah, okay :) then ill just buy a cheap 16v rated relais + a diode and a capable transistor
[11:22:37] <Tom_itx> i run my 2v steppers off 50v
[11:22:57] <Tom_itx> but they're current limited
[11:24:46] <homeflix> thank you Tom_itx :)
[11:25:03] <Tom_itx> np
[15:19:53] <Fleck> http://www.ebay.com/itm/5-x-32-768Khz-High-Precision-Crystal-Clock-Oscillator-/300696808770?pt=LH_DefaultDomain_0&hash=item4602ed2d42 << how do you know - how precise is it? bought crystal @ local store - runs faster then should - 10 seconds in 5 days :/
[15:21:01] <braincracker> use 22pf capacitors maybe
[15:21:09] <braincracker> hmm
http://en.wikipedia.org/wiki/File:P1-P5.gif
[15:27:58] <Fleck> braincracker: internal caps, can't change them
[15:28:05] <Fleck> 12.5pF
[15:29:28] <braincracker> i don't see how this contain the 2x12.5pf capacitors.
[15:30:05] <braincracker> anyway, you can trim a little by adjusting load capcitors
[16:20:36] <other019> hi
[16:26:07] <Fleck> hello
[16:28:15] <edman007> hi, any idea why after burning the flash my AVR seems to work, but then if USI get's enough corruption it breaks (I understand that), but when I reset it it seems to keep the same state and I can't get USI working again
[16:30:43] <ambro718> what's USI?
[16:30:48] <robotustra> as soon as I understand the channel @robotics is just a copy of this channel?
[16:31:42] <edman007> ambro718, serial/SPI
[16:33:53] <ambro718> edman007: what do you mean "if it gets enough corruption it breaks"?
[16:34:09] <ambro718> what's corruption? how does it break? what breaks?
[16:34:25] <ambro718> does the AVR itself crash?
[16:39:31] <ambro718> what's the most efficient way to "loop N times" in asm?
[16:39:55] <ambro718> i.e. with minimal overhead per iteration
[16:40:22] <Tom_itx> loop: DEC r16 BRNE loop ;inner loop DEC r17 BRNE loop ;outer loop SBI PINB, PB2 ;toggle PB2 RJMP loop
[16:40:29] <Tom_itx> 2 loops ther
[16:40:30] <Tom_itx> e
[16:41:13] <nevdull> for (i=0;i<n;i++) { volatile inline asm("<your asm here>"); }
[16:41:15] <nevdull> ;)
[16:44:10] <ambro718> but dec+brne takes 3 cycles per iteration
[16:45:12] <ambro718> I would think they'd make something like a combined dec+brne to reduce the overhead
[16:46:07] <nevdull> ambro718: conditional opcodes are an interesting topic. you can increase code density like 33% or more with instruction sets that support it
[16:55:23] <Xark> nevdull: Indeed. However, might not worth "wasting" too many bits per opcode (ala ARM wasting 4 bits). For ARM Thumb2 they came up with a very interesting hybrid that seems to be a good compromise (the If-then-else conditional opcode).
[16:57:23] <nevdull> yeah, i was looking at that the other day (i like to collect instruction set architecture datasheets ;). also 75-95% of all instructions only use 4 addressing modes so there's a chance to reduce the instruction size there, too
[16:59:18] <Xark> nevdull: Cool. I am also "into" various architectures and how they do things (playing around designing my own for FPGA). The ARM thumb2 if-then-else worked quite nicely on a recent ARM project I did (but I think it is patented...)
[17:01:52] <nevdull> Xark: yeah, switching back to 16-bit mode is an interesting tactic but i think it looses the neon or that multimedia instruction set that arm9v has i think. that's cool you're designing your own fpga. sounds like fun.
[17:03:25] <Xark> nevdull: Sounds like you are confusing thumb1. With Thumb2 there is (basically) no reason to use 32-bit mode (and in fact, some ARM parts are only thumb2 mode now).
[17:03:53] <Xark> nevdull: Thumb2 supports 16-bit or 32-bit opcodes (intermixed) as well as full VFP/NEON access.
[17:05:02] <Xark> nevdull: So you get like 30% more code density at almost no reduction in speed (for most code).
[17:06:33] <nevdull> Xark: aha!
[17:08:23] <Xark> nevdull: So for example ADD R1, R2, R3 might be 32-bit, whereas ADD R1,R1,R2 would be 16-bit (and dest being one of source operands is quite common).
[17:09:39] <nevdull> yeah i read something about how they designed that ISA using extending opcodes and grouping instructions that are similar into an easily bitmaskable code
[17:10:27] <nevdull> and are there 32 gpio registers? or 15? eithe rway that's only 4 or 5 bits to reach all register space
[17:11:45] <nevdull> i saw a couple weeks ago that 12-16 bits of displacement can accommodate 75-99% if addresses and in immediate address mode 8-16bits can reach 50-80%
[17:13:46] <Xark> nevdull: Both ARM and Thumb2 has 16 GPRs (although that includes stack, PC which aren't too GP).
[17:14:11] <Xark> nevdull: However, some opcodes have restrictions (e.g., if you access Rx with x > 7 then it often forces 32-bit opcode).
[17:14:51] <nevdull> yah so 4 bits and some according to the call spec ABI are used for parameter values, function returns, and like you said, the special ones like LR, SP, IR, PC, etc
[17:15:17] <nevdull> Xark: oh is that so? i didn't know that but makes design sense
[17:16:30] <nevdull> the avr instruction set is likethat. there are some instructions that you can only use r0-r15 with and some r16-r31 with.
[17:16:43] <Xark> nevdull: Yeah, with a few exceptions you only get 16-bit opcodes with "op rD, rA" form when rD and rA are < r7 (otherwise 32-bit opcode). Note that 16-bit and 32-bit are both "single cycle" (it actually fetches 64-bits at a time from memory).
[17:17:01] <Xark> <= r7 *
[17:17:35] <nevdull> and puts the instructions in the pipeline or ?
[17:17:39] <Xark> nevdull: Yep, you only had so many bits (and full orthogonality often isn't needed).
[17:18:09] <Xark> nevdull: Well, I just mean that 16 or 32 bit opcode affects code density (not cycle count).
[17:18:36] <nevdull> yah, that's a holy grail design spec pounded into us in undergrad school to have a fully orthogonal isa but it rarely is in practice (and like you said, probably not essential anyway)
[17:18:46] <nevdull> Xark:right, gotcha
[17:18:51] <Xark> As I understand it the ALU is exactly the same for ARM, Thumb1, Thumb2, just the encoding changes.
[17:19:44] <nevdull> yah one instruction set i was looking at recently also had an instruction to change endianess on the fly. i remember the arm isa supports a branch and change instruction sets opcode
[17:19:53] <Xark> nevdull: It can complicate compiler design (not having full orthogonality), but for "real code" it often results in better performance to have "special cases".
[17:20:22] <Xark> nevdull: Yeah, typically uses low bit of PC for "mode".
[17:20:26] <Xark> (on ARM)
[17:21:16] <nevdull> for sure...cpu designers have a transistor budget they have to stick to and throwing in "the kitchen sink" to the instruction set is problematic since once an instruction is in it's really hard to deprecate it cuz somebody's something will break
[17:22:15] <Xark> nevdull: Right. Look at all the "legacy baggage" in x86 (the instructions all need to "still work", but they are typically "slow and stupid" to use nowadays). :)
[17:22:38] <nevdull> oh god for sure, prime example
[17:23:02] <Horologium> x86 is awesome!
[17:23:19] <Xark> Horologium: Well, it is fast. But the design is horrid (IMHO). :)
[17:23:20] <Horologium> 64bit processor that supports 8bit from 20 years ago!
[17:23:29] <Horologium> </sarcasm>
[17:24:27] <Xark> At least AMD64 fixed many of the egregious issues (but still "messy").
[17:24:45] <Horologium> yeah
[17:24:49] <Horologium> ia64 was horrid
[17:25:34] <edman007> ambro718, what I mean is I wrote a packetized protocal over SPI, so the AVR sends an ACK when it gets data... anyways, i got stuff where if the host stops seeing it then it sends a reset... only that reset doesn't seem to actually reset the AVR (it doesn't fix the problem, and I know the code can at least work because it works after a fresh burn)
[17:25:42] <Xark> Horologium: I agree. I feel sorry for people having to write compilers for it (or anything, really - EPIC asm sounds daunting too). :)
[17:26:21] <nevdull> heh, here are a few of my favorite instructions: BPO (Branch and Power Off), COS (Copy Object code to Source file), DWIM (Do What I Mean), GLC (Generate Lewd Comment) lol i love that last one heh
[17:26:23] <ambro718> edman007: you use the RESET pin to reset the AVR?
[17:26:49] <Horologium> edman007, I don't see how the software needs to be reflashed...it can't be writing to flash,,not normally anyhow.
[17:26:55] <Xark> nevdull: Hehe, you missed HCF (halt and catch fire). :)
[17:27:00] <nevdull> LOL
[17:27:16] <ambro718> edman007: maybe it's your other chip (the one doing the resetting) that's at fault
[17:27:28] <Xark> nevdull: I gather it was a "real" opcode on some old mainframes (where it was a "bad idea" to jump to yourself or somesuch). :)
[17:27:44] <Horologium> Xark, how about the pentium 60 with the division issue...
[17:28:03] <Horologium> I am pentium of borg...division is futile, you will be approximated.
[17:28:04] <nevdull> Xark: haha better than branching to a random address i suppose ;)
[17:28:29] <Xark> Horologium: It was entertaining to watch it happen to Intel. :)
[17:28:41] <Horologium> it was profitable for me.
[17:28:46] <nevdull> it's all approximation when you get down to it, i think
[17:28:55] <Horologium> replacing processors in several dozens of machines at walmart.
[17:29:50] <Xark> nevdull: Sure, but FP needs to use a specifically designed "approximation" (or it is broken).
[17:30:27] <nevdull> yeah, it all comes down to the sig figs you have to work with
[17:34:19] <edman007> ambro718, hrm... maybe... I doubt it... such a PITA to hook up a scope to the chip though...
[18:48:01] * Vutral bla
[19:12:36] <ambro718> If anyone needs fast division or sqrt, I wrote this,
https://github.com/ambrop72/avr-asm-ops
[19:14:13] <ambro718> division in particular is significantly faster than what gcc 4.8 produces (the fully unrolled div_32_32_large takes 384 cycles in worst case, compared to 653 instructions with gcc).
[19:14:30] <ambro718> * cycles
[19:17:13] <Xark> ambro718: Very nice, thanks. Bookmarked. :)
[19:26:30] <ambro718> The _small versions are much slower due to 3-cycle overhead per iteration for the loops. Looks like there's no way to make loops with less overhead.
[19:29:06] <Xark> ambro718: Right. That is why I had to make my AVR tiled video generation code all inline (which got large).
[19:30:14] <Xark> ambro718: Still, AVR isn't too bad for an 8-bitter, overall.
[19:30:24] <ambro718> yeah, it's all right :)
[19:30:43] <Xark> ambro718: Seems very "deluxe" when you did a lot of 8-bit 6502 coding. :)
[19:32:20] <ambro718> heh, I'm too young to have messed with those
[19:34:16] <Xark> ambro718: I see. Well, if you would like some modern 8-bit "trials", you could try a smaller PIC. :)
[19:34:45] * Xark would probably prefer a 6502 over that. :)
[19:46:10] <braincracker> hey guys, let's say you have the opportunity to decide if you want to send MSB or LSB first as a data stream, what would you choose?
[19:48:50] <R0b0t1> It's pretty immaterial, I usually send MSB first.
[19:49:00] <R0b0t1> So each receive is added to the value shifted left.
[19:49:17] <R0b0t1> val = (val << 1) & new;
[19:49:58] <braincracker> i was thinking the same, but without shifting, so for example a dac could prepare the MSB as soon as it receives it
[20:00:41] <OndraSter_> braincracker, if it is approximating then sure
[20:01:38] <braincracker> but, byte ordering is mixed up this way, so there is the other method too, sending lsb first, and file from 0 offset
[20:02:21] <braincracker> ps2 keyboard sends data from LSB to MSB too
[20:03:52] * Xark notes most serial protocols seem to be least significant bit first...
[20:04:20] <braincracker> less byte ordering problems i think
[20:04:23] <Xark> braincracker: If you use AVR UART to read the PS/2 keyboard (using XCK), then it will do all the dirty work (and even check parity). :)
[20:05:02] <Xark> (since it supports an external clock like PS/2 uses)
[20:07:01] <braincracker> i don't know now if it would work
[20:08:05] <Xark> braincracker: I had no problem getting it to work that way. I needed to use UART because I was pumping out video and could not have interrupts enabled (and just polled UART byte data reg in hsync).
[20:08:14] <braincracker> but ps2 clock is 70-100us anyway
[20:08:43] <braincracker> hehe
[20:08:53] <braincracker> well if it has hw support then ...
[20:09:05] <braincracker> so it works without interrupting cpu
[20:09:32] <Roklobsta> any of youse made an rtos kernel from scratch?
[20:09:35] <Xark> Yeah, just enabled "external clock" on UART (XCK pin) and it pretty much presented a keycode as if it was normal UART data/
[20:10:01] <braincracker> Roklobsta <= i did patch and compile mine, did you mean that?
[20:11:01] <braincracker> Xark <= so you just plugged it in and use, not even sent a single command?
[20:11:09] <Xark> Roklobsta: Rarely makes sense having a general purpose kernel on a flash based MCU like AVR. Usually just a custom "micro kernel".
[20:12:01] <braincracker> it makes sense on pc
[20:12:07] <Xark> braincracker: Well, you have to use the UART registers as normal. I didn't try sending to keyboard (but I suspect that would work also, but AVR may need to generate clock).
[20:12:07] <braincracker> and arm
[20:12:34] <braincracker> Xark <= no, the keyboard generates clock while you are sending :)
[20:12:55] <Xark> braincracker: OK. I have only done bi-directional with FPGA (but I don't recall the details). :)
[20:13:09] <braincracker> insane hah?
[20:13:25] <Xark> braincracker: IIRC you had to yank the clock line to get the keyboards attention. :)
[20:13:35] <braincracker> yea
[20:13:44] <braincracker> and the data line too
[20:22:02] <Gumboot> ambro718: I figured out a way to make the linear interpolation more efficient for that 16.16 divider:
https://gist.github.com/sh1boot/5732738
[20:22:33] <Gumboot> Now several of the shifts have either gone away completely or been replaced with byte offsets instead.
[20:23:27] <Gumboot> Also, I added comments.
[20:23:51] <tzanger> comments++
[20:24:06] <tzanger> in 3 months when you come back to this you won't go "dafuq?"
[20:24:49] <Gumboot> If it doesn't make me go "dafuq?", it's not clever enough to bother writing!
[20:25:02] <ambro718> Gumboot: Cool. Have you done any speed tests with AVR?
[20:25:08] <Gumboot> I don't have one.
[20:25:44] <Gumboot> I'm just a wannabe. I joined the channel looking for the means to test code I wrote speculatively for 8-bit micros.
[20:26:01] <Gumboot> Then I saw your question and wrote more code, speculatively, for more 8-bit micros.
[20:26:31] <Gumboot> It's still in C and the compiler is going to do a horrible job of it, so I don't expect it to be fast.
[20:27:06] <Xark> Gumboot: You probably have a few AVRs in your house, you just don't know it. :)
[20:27:31] <Gumboot> Then perhaps I can upgrade them with improved PRNGs and dividers.
[20:27:54] <Xark> Gumboot: Hmm, might improve your dishwasher? :)
[20:28:30] <tzanger> Gumboot: you might be pleasantly surprised what gcc for the AVRs will do to it
[20:28:41] <Gumboot> Yes, washing my dishes using random numbers which reveal patterns in the lower bits is exactly why I get that weird crap in the bottom.
[20:29:00] <tzanger> no, the weird crap is because you don't rinse
[20:30:15] <Gumboot> I prefer to think that I've solved the problem permanently by writing this:
https://github.com/sh1boot/8bitrand
[20:30:34] <Gumboot> Rinsing is just more hard work that would never end.
[20:31:14] <Xark> IME the main place where avr-gcc gets really "stupid" is where C rules/standards force it to use 16-bits (when an asm coder would only use 8 bits).
[20:31:30] <Gumboot> It's bad with address generation, too.
[20:32:10] <Gumboot> Compile
https://github.com/sh1boot/8bitrand/blob/master/examples.c and see what happens to tinyrand().
[20:33:18] <ambro718> Gumboot: MUL_8x8(x, y) ((uint16_t)((uint8_t)(x) * (uint8_t)(y)))
[20:33:20] <ambro718> wrong
[20:33:43] <Gumboot> Oh?
[20:33:43] <ambro718> you need to cast either of the operands to (uint16_t) or they will be auto-promoted to int (which is *signed* !!!)
[20:34:11] <Gumboot> That's OK. They'll be zero-extended to int, and the result is cast back to unsigned anyway.
[20:34:27] <ambro718> Gumboot: unless the multiplication overflows
[20:34:47] <ambro718> int(255) * int(255) is not representable in an int
[20:34:58] <Gumboot> But it fits within the int bit-pattern.
[20:35:03] <ambro718> so there you have undefined behavior
[20:35:13] <ambro718> huh?
[20:35:38] <Gumboot> Well, I don't expect any compiler to implement signed-multiply with clamping.
[20:35:49] <Gumboot> If it did that the whole exercise would be pointless.
[20:36:21] <Gumboot> I tried a few idioms like casting to uint16 before the multiply, but some compilers were generating rubbish in that case.
[20:37:01] <Gumboot> So it may be undefined behaviour in principle, but no reasonable implementation is going to give the wrong result.
[20:37:19] <Gumboot> And it's in a macro like that ready to be replaced with inline assembly, anyawy.
[20:40:12] <ambro718> it's still wrong, prepare to find it doesn't work now or in some newer compiler
[20:40:53] <Gumboot> A compiler with 16-bit ints which clamps to legal signed ranges?
[20:42:02] <Gumboot> Anyway; it's in a macro so you can fix it for your platform.
[20:42:16] <ambro718> I don't know what you're talking about. The correct C code to multiply two uint8_t's into an uint16_t is "(uint16_t)((uint16_t)x * y)"
[20:42:46] <Gumboot> Yeah, but SDCC generated a function call in that case, rather than using the hardware multiplier.
[20:43:34] <ambro718> without first cast the code has undefined behavior according to C standard (if you read it, check the arithmetic conversions section, because what happens here is the conversion of the product value to int result)
[20:43:47] <ambro718> complain to SDCC ;)
[20:44:23] <ambro718> C would be so much nicer without default promotions.
[20:44:55] <Xark> ambro718: Probably. They totally messed up C++ too (when extended). :)
[20:45:16] <Gumboot> Anyway, I sprang out of bed when inspiration struck on how to improve the divider (in principle, at least). I should go back to bed and get some sleep before I have to get up again.
[20:45:38] <ambro718> you have code that uses uintN_t, and it works for some N, simply because that N happens to be less than the size of int. Even though your code never uses ints.
[20:46:06] <ambro718> Gumboot: try coding it in asm :D
[20:46:10] <Gumboot> I know the promotion rules, and I know that I broke them. But I also know I don't care because it's meant to be taken as an example and reimplemented in assembly.
[20:46:39] <ambro718> well then there certainly isn't any reason to break them
[20:46:53] <ambro718> since being slow due to stupid compilers doesn't matter
[20:47:13] <Gumboot> Well, it cleared up the assembly output so I could see how far off it really was.
[20:47:26] <ambro718> btw avr has "mul" instruction
[20:47:33] <Gumboot> If I were, for example, to replace the macro with inline assembly.
[20:49:09] <ambro718> why do you use SDCC? Are you programming PICs?
[20:49:32] <Gumboot> Just trying the various tools that were available.
[20:49:53] <ambro718> if you're planning for coding in C, AVR is definitely better than PIC
[20:50:12] <Gumboot> I tried avr-gcc first, and it didn't use a mul at all, so I tried sdcc's 8051 output and that eventually did. Then I went back to looking at commandline switches for gcc to get that mul out.
[20:50:16] <ambro718> also if you'll be doing assembly ;)
[20:50:37] <ambro718> Gumboot: not all AVRs have mul
[20:50:41] <Gumboot> Indeed.
[20:50:57] <Gumboot> I don't care about those other ones. Although I did do a shift-based implementation just in case.
[20:51:11] <timemage> ambro718, not all of them have mul.
[20:51:18] <Gumboot> I notice GCC inlined shifts for the multiply. I didn't compare GCC's code to mine.
[20:51:18] <timemage> ambro718, heh, beat me to it.
[20:51:47] <Gumboot> timemage: Some AVRs don't have mul.
[20:52:08] <timemage> Gumboot, thanks. we could go around in circles for hours this way.
[20:52:17] <Gumboot> I'd better not. I should sleep.
[20:52:50] <Gumboot> 'night.
[20:53:29] <ambro718> bye
[21:02:58] <Roklobsta> xark: yeah i am in the throes of writing a mini kernel
[21:03:22] <Roklobsta> haven't done something like it since 68000 assignment at uni in 1993
[21:05:28] <Xark> Roklobsta: So are you trying for interrupt based round robin, cooperative or what?
[21:05:58] <Roklobsta> round robin with an I/O signal fucntion
[21:06:11] <Roklobsta> so reading and writing serial isn't blocking for other processe3s
[21:06:35] <Roklobsta> i have a primitive fifo structure that obstracts things like serial
[21:07:27] <Roklobsta> but the timer/kernel interrupt will check the serial fifos, update use of RTS and CTS signals, restart any serial interrupts etc.
[21:08:18] <Roklobsta> so for now i plan to have something like while(!signal(UART0_RX))
[21:09:03] <Roklobsta> but signal() will just yield the task until the UART0_RX fifo has something new.
[21:10:02] <Roklobsta> same idea will be for timer_wait() will keep yielding until the timer expories.
[21:10:37] <Roklobsta> ANYWAY, i need to write the interrupt routine now. first foray into avr asm
[21:10:44] <Roklobsta> i have been able to avoid it so far
[21:11:31] <Roklobsta> xark: have you made an avr task scheduler?
[21:12:08] <Xark> Roklobsta: No. It has always worked for me to just have a polling main loop, or a main loop with some interrupt driven I/O.
[21:15:26] <ambro718> Roklobsta: you don't need asm to write ISRs
[21:16:45] <ambro718> ISR(USART0_RX_vect) { your code }
[21:18:38] <Roklobsta> ambo: you do for a task switcher: push reg and pop reg lots of times
[21:19:14] <Roklobsta> yeah, main loops are ok except you then need to write nonblocking code and things can get ugly
[21:19:54] <ambro718> I find well designed event-driven code is much nicer than tasks/threads
[21:38:52] <Xark> ambro718: Usually more efficient too (but it depends).
[23:59:48] <dgriffi> is there some debian package that provides avr32-linux-gcc?
