Back
[04:22:18] <rue_house> fixed or variable freq?
[04:22:44] <rue_house> what do you know about a LUT?
[04:22:59] <twnqx> LUTs are the basic elements of FPGAs!
[04:24:41] <rue_house> you would be surprised how many people cant use a table
[04:25:31] <twnqx> i wrote PC demos in the 386 era
[04:25:40] <twnqx> i guess i know how to use LUTs :P
[04:26:07] <rue_house> good show
[04:26:26] <twnqx> was totally impossible without
[04:26:28] <rue_house> do you think someone can show dgriffi how to use a sin lookup table to realtime generate his freqs?
[04:26:55] <twnqx> i joined after the first question, but...
[04:27:10] <rue_house> dgriffi> rue_house: I'm looking for a way to play two sine waves at audio frequencies
[04:27:41] <twnqx> i see
[04:28:21] <rue_house> well I C
[04:28:29] <rue_house> I used to asm, but I dont really anymore
[04:28:58] <rue_house> I like the portability tho
[04:30:57] <twnqx> get some standard chiptune player sourcecode and use that as a base? :P
[04:42:04] <rue_house> 0?
[05:57:30] <dgriffi> regarding playing tones, I found this:
https://github.com/blakelivingston/avr_tinytune
[05:57:59] <dgriffi> seems to satisfy my requirements
[06:04:01] <specing> < _ami_>
https://git.enlightenment.org/core/efl.git/commit/?h=devs/ami/eina --> working on implementing license mechanism for EFL modules so that non-GPL and GPL co-exist together.
[06:04:10] <specing> license violations made easy(tm)!
[06:04:33] <_ami_> :)
[06:07:31] <specing> it sounds like you are Chinese, but then again the chinese would not share their work and your english it too good
[06:07:38] <specing> so... Indian?
[06:09:31] <_ami_> specing: yeah :)
[06:12:27] <dgriffi> oh, the joys of calculating a lookup table and finding Meaningful Numbers within
[06:13:03] <dgriffi> ever churn numbers and go "oh, this one reminds me of that thing!"
[06:21:24] <specing> Ah the joys of having an FPGA and Vivado doing that for me
[06:22:54] <dgriffi> specing: do you ever do math just for fun?
[06:23:22] <specing> yes
[09:22:34] <__raven__> hi
[09:23:37] <__raven__> what would be the c equivalent to assemble a string as easy as possible - something like += possible?
[09:24:07] <LeoNerd> Almost always you want some variant on snprintf
[09:24:20] <LeoNerd> Doubly so on an AVR microcontroller... try to avoid anything allocationy
[09:24:47] <specing> or use Ada instead
[09:25:07] <specing> string concatenation is part of the basic language capabilities
[09:25:08] <LeoNerd> Also depends what you're generating the string for. E.g if you're just sending it out of a UART/SPI/I²C port or to some other peripheral, you might instead prefer to create a FILE* stream to represent it and then printf, thus avoiding the need to buffer the entire thing
[09:26:20] <__raven__> thats difficult because i do not know what the exact length would be in the end and fixed allocation would destroy the main goal: i want to assemble a string, count its lenth and append that number to do a selfmade checksum for transmission over uart
[09:27:21] <carabia> __raven__: out of what are you assembling it?
[09:27:56] <LeoNerd> So, use the FILE* approach
[09:28:58] <__raven__> i need to change it out of here: l782
https://github.com/raven576/SolarPower/blob/master/Code/CPU/main.c
[09:36:45] <__raven__> any idea?
[09:38:54] <twnqx> strcat
[09:40:31] <twnqx> or just memcpy if you're brave enough
[09:41:43] <twnqx> but for your particular change, snprintf sounds like the sanest solution indeed.
[09:57:23] <specing> __raven__:
https://gist.github.com/specing/0896e84e17b8dca1e35f0781f580967a :)
[10:00:15] <__raven__> specing: cool thanks :) but what is this doing in detail?
[10:02:16] <specing> it should create a String on the stack
[10:02:39] <specing> "should" as I haven't looked at disasm and haven't done Ada on AVRs yet
[10:03:53] <__raven__> specing: which language is it?
[10:04:04] <specing> Ada/MIL-STD-1815
[10:07:20] <carabia> note the military spec for additional amazement
[10:07:33] <carabia> don't see the point in learning that but hey, to each their own
[10:07:35] <specing> standard
[10:07:51] <carabia> same difference
[10:08:14] <learath> specing: I prefer
http://liw.iki.fi/liw/misc/MIL-C-44072C.pdf
[10:08:30] <specing> and afaik MIL-STD-1815 is its official name, Ada is just a short-hand one
[10:09:04] <specing> codename or how do you call it
[10:09:41] <specing> carabia: its ok, you can keep your segfaults ;)
[10:10:04] <carabia> it only segfaults when you let it... ;;)
[10:10:53] <specing> C makes that choice for you
[10:10:59] <Emil> Anyone played with avr ethernet?
[10:11:49] <carabia> specing: no it doesn't
[10:12:16] <carabia> learath: Amen to that.
[10:12:43] <specing> carabia: yes it does
[10:14:07] <carabia> specing: do elaborate
[10:16:52] <specing> people make mistakes.
[10:17:16] <specing> Ada prevents a whole lot of them at compile time and provides exceptions for most of the rest at run time
[10:17:37] <specing> I can't understand how some people can (still) praise C
[10:18:03] <carabia> so this is like saying it's the hammer's fault when you smash your fingers with it
[10:18:04] <specing> Ada is such a powerful language that you barely need to do any manual allocations at all
[10:18:26] <__raven__> btw specing i had to ifelse the ocr2 regs due to they are giving me 2^x instead of 0 and 1. any way to make it more easy?
[10:19:08] <specing> __raven__: ?
[10:19:16] <carabia> which i do understand -- it's just that for all intents and purposes, in my humble opinion, avrs are designed for simple enough tasks to be handled by c quite easily
[10:20:17] <__raven__> specing: sry i dont understand my own code any more - i meant bat and out ;)
[10:20:36] <specing> I don't know why I even bothered "elaborating". C is resting over there in the thrash can
[10:20:40] <specing> where its place is
[10:20:43] <carabia> and even then, in c you are meant to do e.g. manual allocation, which is not a flaw of the language per-se.
[10:20:50] <specing> __raven__: :D
[10:21:43] <carabia> __raven__: if i were you i'd apply some sort of separation of files
[10:21:47] <specing> __raven__: in Ada you would have declared the flag as a bit and access it as such
[10:22:17] <carabia> specing seems to have unusually high levels of interest towards ada
[10:22:22] * carabia wonders
[10:22:34] <specing> __raven__: and then function Bit.Image -> "0"/"1"
[10:23:25] <specing> carabia: instant black sheep
[10:24:10] <carabia> specing: you need to revise your segfault-preventing skillset.
[10:26:51] <specing> I don't as I haven't had a single segfault since going Ada
[10:32:48] <carabia> that's all fine and dandy, but it's still not quite correct to say "C makes it for you", as it's merely you do make the decision when you're doing overly complicated things with it.
[10:33:00] <carabia> you + who
[10:39:04] <specing> people make overly complicated things in C all the time
[10:40:02] <specing> so what you are saying that C is a toy language?
[10:47:29] <carabia> I'm saying people overestimate their abilities
[10:48:17] <carabia> But avr programs are simple enough to write in c, for most primates...
[10:48:50] <specing> all programs begin simple
[10:49:10] <carabia> that's an irrelevant point, really.
[10:49:10] <specing> but at what point do you decide to port them over to a serious language?
[10:49:30] <specing> and do you actually go and port them? Because this quickly becomes too much work
[10:49:39] <specing> all your points are irrelevant
[10:49:53] <carabia> that's why you don't just hurrdurr, write code. You design it accordingly
[10:50:16] <carabia> an overly-iterative approach is a recipe for disaster for any language
[10:50:56] <carabia> and my point is closely related to the platform at hand, actually, which you fail to recognise
[10:51:27] <carabia> well actually not just overly-iterative, but an overly-iterative "winging it" approach
[11:13:12] <specing> yes you design it, but you don't immidiately start writing 100000 LoC to satisfy the design document
[11:13:19] <specing> you establish milestones
[11:13:31] <specing> so that < specing> all programs begin simple
[11:13:58] <specing> And you rarely forsee all the design goals at design stage
[11:14:21] <specing> result: massive slugs written in Python
[11:17:53] <specing> and you seem to be very inexperienced with the platform at hand as not all AVRs ship with 1KB code space
[11:18:42] <specing> < carabia> ... avrs are designed for simple enough tasks to be handled by c quite easily
[11:19:02] <specing> what do you do when a bug in your pacemaker kills the patient?
[11:19:30] <twnqx> i am pretty sure tha microchip has a line that states avrs are not to be used in such equipment.
[11:22:41] <^Richard> not sure if the MCU does, but i bet the compiler will
[11:59:00] <carabia> specing: with the software field being a wild west as it is in any case (no matter the language), I am sure pacemakers (firmware even perhaps?) go through many a hoop when they get certified.
[11:59:36] <twnqx> of course
[11:59:43] <twnqx> why else would they be hackable
[15:23:58] <owl-v-> how do you program attiny10 ?
[15:24:51] <Tom_itx> TPI
[15:25:03] <Tom_itx> not a regular ISP will do
[15:26:09] <bss36504> owl-v-: Atmel ICE is likely your best bet unless there's a TPI programmer out there that I dont know of (which is entirely possible)
[15:26:40] <Tom_itx> mine does it but i'm not selling em now
[15:27:34] <owl-v-> oh, i mean how do you develop for attiny10? because I can't compile with avr-gcc avr-libc
[15:27:34] <bss36504> I wonder why they didnt just use PDI for the little Tinys
[15:28:59] <Tom_itx> http://www.digikey.com/product-detail/en/atmel/ATATMEL-ICE-PCBA/ATATMEL-ICE-PCBA-ND/4753383
[15:29:01] <Tom_itx> that one will
[15:29:09] <Tom_itx> no cables bare bones version
[15:29:28] <Tom_itx> http://www.digikey.com/product-detail/en/atmel/ATATMEL-ICE/ATATMEL-ICE-ND/4753379
[15:29:37] <Tom_itx> fancy ass version of the same thing
[15:29:50] <bss36504> Yeah the ICE is pretty nice. I got lucky I guess and got mine right when they came out with all the cables and stuff for $75. Now that version is well over $100
[15:30:15] <Tom_itx> looks like they went up
[15:30:16] <bss36504> but, if you have access to a 3D printer or laser cutter, you could make a nice enclosure for the PCB version on the cheap.
[15:30:33] <Tom_itx> i never put the dragon in a case
[15:30:53] <bss36504> I used my dragon once and said fuck it and bought a JTAGICE3 instead
[15:31:05] <bss36504> such a useless pile of shit, besides the HVPP
[15:31:23] <Tom_itx> i used mine a little but not as much as my programmer
[15:31:33] <bss36504> but to me, the cost of a single micro is less than the cost of my sanity trying to wire that godawful thing up
[15:31:46] <Tom_itx> takes a bit yes
[15:31:57] <bss36504> just not worth it, even to set up simple ISP.
[15:32:09] <bss36504> so many jumpers, it's so fragile unless you special make a cable assembly or something
[15:32:13] <Tom_itx> unless you had a desparate situation
[15:33:27] <bss36504> Yeah the only time i've truly bricked a mega was during the transition from/to DebugWire and ISP (again, total nonsense, it shoudnt be so hard)
[15:33:35] <Tom_itx> umm owl-v-, the newer compiler will support the attiny10 etc
[15:33:51] <bss36504> so I just avoid DebugWire now, I stick to PDI, JTAG, ISP.
[15:33:52] <Tom_itx> not just asm anymore
[15:34:23] <Tom_itx> i dunno what ver i have but i've done it
[15:34:31] <carabia> SWD > *
[15:35:51] <owl-v-> Tom_itx, there is no official avr-gcc/libc for osx
[15:36:22] <Tom_itx> well you didn't happen to mention osx. therein lies your problem
[15:36:40] <bss36504> owl-v-: Cant you just build it? Idk, I never tried that with my mac when I had it but I would think you could just build from linux sources...
[15:36:50] <bss36504> or install a linux VM and do your development there
[15:37:02] <Tom_itx> or get a real pc?
[15:37:05] * Tom_itx runs
[15:37:23] <bss36504> Tom_itx: lol
[15:37:58] <bss36504> I had a mac for a while and you gotta be prepared to work around it. I had a windows partition and a VM that could read from it, or I could native boot for better performance
[15:38:05] <bss36504> Then I wised up and bought a PC
[15:38:50] <Tom_itx> i'm not saying they don't have a place... i just don't know where the hell it is
[15:39:14] <Tom_itx> and it's certainly not on my desk
[15:39:42] <bss36504> It's an arguably nice user experience, but you have to go in with an open mind and not expect to do things you can do in linux and windows.
[15:39:54] <bss36504> So for non-power users, they're fine
[15:59:31] <carabia> I haven't owned a laptop in hmm, 5 years. IIRC macbooks were (for a long time) the only ones using li-pos, and they had a pretty good battery life. I'm thinking of getting a laptop again, and really interested in this particular fact
[16:02:06] <carabia> Also I vaguely remember reading about a hack back in the day, where they reconfigured the charging IC from the computer itself causing a potential risk of a fire...
[16:09:07] <specing> carabia: thinkpads had lipos more than a decade ago
[16:09:39] <specing> not sure why you are so enthusiastic about li-po
[16:09:59] <specing> it is just polymer added to cells so they can be shaped more arbitrarily
[16:10:12] <specing> i.e. so called pouch packs
[16:12:40] <carabia> generally they are also lighter
[16:13:09] <carabia> in addition, that is
[16:19:37] <specing> no, it is the other way around
[16:19:43] <specing> round cells are lighter
[16:30:17] <carabia> might be something to that actually
[16:31:51] <specing> however it is true that the whole system is usually lighter as puch packs are *usually* integrated into the case and do not have plastic casing of their own as is normal for 18650 cell rear battery packs
[16:40:58] <specing> carabia: upgrade your phone battery today ...
https://bmsbattery.com/ebike-battery/815-5c-rate-lifepo4-battery-8460260-polymer-cell.html
[16:41:47] <carabia> I have a ton of lipos and lifepos hanging around
[16:42:17] <carabia> well, lifepo4
[16:43:10] <specing> LiFePOO4*
[16:43:54] <specing> NCA/NMC is where the fun is .. twice the energy density per weight and a while lot more dangerous
[16:44:03] <specing> 150'C only for thermal runaway
[16:47:06] <carabia> gets quite exotic to find sellers. and that's just a bit too low of a tipping point for me
[16:51:42] <specing> nkon.nl, reputable EU seller with low prices
[16:52:12] <specing> it is THE eu cell shop
[16:52:35] <carabia> well, still not interested in playing with fire hazards
[16:53:18] <specing> lifepo4 is a fire hazard too
[16:53:23] <specing> it just takes more beating
[16:53:46] <specing> but also provides more energy
[16:53:54] <specing> but also provides less* energy
[16:54:08] <carabia> lifepo4 takes a shit ton of beating.
[16:54:12] <carabia> lipos, not so much.
[16:54:27] <carabia> literally, a shit ton of beating before you get them to smoke.
[16:54:32] <carabia> trust me i've tried
[16:57:36] <specing> :D
[16:57:51] <carabia> with a clawhammer.
[16:59:14] <specing> < carabia> well, still not interested in playing with fire hazards
[16:59:16] <specing> right.
[17:02:06] <Lambda_Aurigae> what's the fun in that?
[17:02:14] <carabia> specing: hey, it was a scientific experiment.
[17:02:32] <Lambda_Aurigae> hell, I spend entire weekends trying to make things emit the magic blue smoke, catch fire, or just plain explode!
[17:02:34] <carabia> there's nothing scientific about burning your garage down to the ground by accident.
[17:02:48] <carabia> about = in
[17:02:51] <specing> carabia: is it published in an impact factor journal as well?
[17:03:33] <specing> Lambda_Aurigae: I have eyes laid on one old 6-cell laptop 18650 battery ... *sooooon*
[17:04:53] <carabia> specing: well, i got my hands on some packs back when they were really scarcely distributed, so for a short moment I thought of publishing my results in a very esteemed scientific (and academic) journal, you might have heard of it...
[17:05:07] <Lambda_Aurigae> specing, MUAHAHAHAHAHA!
[17:55:24] <Tom_itx> someone online i know recently 'scientifically' burned his house down... with a laser cnc
[17:56:01] <carabia> nono, that's really not scientific at all.
[17:56:08] <Tom_itx> walked in the other room to check on something and came back to the laser on fire
[17:57:24] <Tom_itx> so be careful playing with those avrs... you never know what may be lurking inside
[17:57:41] <carabia> Tom_itx: but I do know, it's the little green men.
[17:57:47] <carabia> ...in the inside
[17:58:05] <Tom_itx> especially for you cheapasses that buy them from china
[17:59:53] <carabia> I haven't bought even a single avr from china, then again I haven't bought any avrs in years... :)
[18:00:09] <Tom_itx> i haven't gotten any in a while
[18:02:02] <specing> Tom_itx: everything is from china these days
[18:02:09] <specing> we just refuse to pay middlemen
[18:02:42] <carabia> Tom_itx: that is so very ambiguous someone might even interpret it as promiscuous
[18:10:18] <carabia> i can feel a question coming...
[18:10:31] * carabia waits in anticipation
[18:14:12] <specing> What is that single wire (through RESET) debug that AVR uses called again?
[18:14:33] <learath> spi?
[18:14:38] <learath> no.. debugwire!
[18:14:46] <specing> and what are the usual OpenOCD(?) supported debuggers used?
[18:17:48] <specing> "AVR debug wire" on ebay -> 0 hits
[18:17:50] <specing> srsly?!
[18:18:18] <aczid> avr dragon / iceII works
[18:18:29] <aczid> actually, I'm not sure about the iceII
[18:18:34] <aczid> dragon works with DW
[18:18:45] <aczid> with avrdude / avarice
[18:18:50] <aczid> and also atmel studio
[18:19:35] <carabia> debugwire is proprietary to atmel
[18:19:59] <aczid> that's why you need a programmer with atmel's firmware
[18:20:22] <aczid> but some work has been done to reverse DW
[18:20:29] <specing> this
http://www.ebay.com/itm/USB-Download-Programmer-Emulator-Debugger-For-AVR-JTAG-ICE-Atmega-AVR-STUDIO-/281524885470?hash=item418c30d7de:g:W6AAAOSwg3FUhqy7
[18:20:32] <specing> ?
[18:20:49] <aczid> a good clone would have atmel's firmware in it :-)
[18:20:58] <aczid> specing: no this won't do
[18:21:04] <carabia> specing: probably won't do DW, no
[18:21:27] <aczid> these can only do ISP, unless you are prepared to put in a lot of effort to make it work (by reversing a working DW programmer like the AVR dragon)
[18:21:29] <specing> yah I know... but JTAG with OpenOCD?
[18:21:43] <aczid> they are just spamming keywords
[18:21:47] <specing> (note: I haven't worked with AVRs in like 3 years)
[18:21:56] <specing> aczid: as usual
[18:21:56] <aczid> this looks like a usbasp
[18:21:59] <aczid> which is reprogrammable
[18:22:01] <aczid> and open source
[18:22:04] <specing> usbasp is $1
[18:22:05] <carabia> JTAG is a better option. And rather avarice than openocd, I think
[18:22:23] <aczid> still looks like a usbasp... but more expensive
[18:22:32] <specing> k :D
[18:23:02] <aczid> save your money, buy a dragon
[18:23:11] <aczid> it will work with DW on linux and windows
[18:23:27] <Tom_itx> NO!!! get their new programmer for the same price
[18:23:34] <aczid> oh?
[18:23:37] <carabia> I think the barebones ICE is a better option to go for than the dragon, no?
[18:23:40] <aczid> which one is that Tom_itx ?
[18:23:42] <Tom_itx> i posted a link earlier
[18:23:45] <Tom_itx> zlog
[18:24:04] <Tom_itx> does arm too
[18:24:10] <aczid> ok by 'buy a dragon' I meant buy something official from atmel
[18:24:10] <carabia> Yeah.
[18:24:19] <carabia> it's ICE3 or something I think
[18:24:36] <Tom_itx> http://www.digikey.com/product-detail/en/atmel/ATATMEL-ICE-PCBA/ATATMEL-ICE-PCBA-ND/4753383
[18:24:47] <carabia> http://www.digikey.com/product-detail/en/atmel/ATATMEL-ICE-PCBA/ATATMEL-ICE-PCBA-ND/4753383
[18:24:50] <carabia> oh you beat me to it
[18:24:50] <carabia> hahah
[18:24:58] <Tom_itx> http://www.digikey.com/product-detail/en/atmel/ATATMEL-ICE/ATATMEL-ICE-ND/4753379
[18:25:06] <Tom_itx> if you need frills
[18:26:08] <carabia> I sneer at the sight of a $133 debugger
[18:26:11] <aczid> I have not had much luck with newer ICE thingies using avarice
[18:26:40] <carabia> Well, I guess you can use openocd then...
[18:27:21] <carabia> I've been using it for quite some time for but not for avrs (swd-arm), works quite good.
[18:27:24] <aczid> you're right the bare bones does cost the same as the dragon... wtf
[18:27:26] <carabia> -for
[18:28:16] <aczid> carabia: does openocd do debugwire?
[18:28:25] <carabia> aczid: I don't think so
[18:28:27] <aczid> i meant for DW obviously...
[18:28:32] <aczid> sorry :)
[18:28:32] <carabia> Oh. Well then...
[18:28:51] <carabia> I guess atmel studio's the way to go, then...
[18:29:00] <carabia> I've never used DW...
[18:29:20] <carabia> JTAG/SWD/led debugging is all you need!!
[18:29:24] <aczid> it's a pain to get working even with various programmers and devices at hand...
[18:29:41] <aczid> well, not with atmel studio
[18:29:43] <aczid> but with linux
[18:29:58] <aczid> but once it works it's pretty damn dope... avarice as gdb bridge
[18:30:14] <carabia> Does it play nice on wine or in wmvare/whatever?
[18:30:22] <aczid> atmel studio?
[18:30:27] <carabia> yea
[18:30:31] <aczid> I wouldn't dare trying
[18:30:36] <carabia> /dare/?
[18:30:44] <aczid> it insulted my winxp install for being outdated
[18:30:55] <specing> It is funny how the ARM world is full of $5-$10 devkits with JTAG debuggers on board
[18:30:56] <aczid> atmel studio is horrendously bloated
[18:31:13] <learath> *everything* is bloated these days
[18:31:22] <aczid> requiring a boatload of .net runtimes
[18:31:34] <aczid> while underneath it's just gcc
[18:31:41] <aczid> I'm baffled really
[18:31:41] <carabia> specing: yeah ST's nucleos are nice. Also has tabs to break the programmer pcb off, and breakout pins \:D/
[18:31:58] <learath> aczid: IIRC it's running MS's visual studio
[18:32:01] <carabia> then again, an st-link costs $4 off ebay
[18:32:03] <learath> with some helpers
[18:32:10] <aczid> learath: yeah since v6 I suppose?
[18:32:14] <aczid> v5 was usable
[18:32:24] <aczid> v7 is even worse
[18:32:31] <aczid> or what is the latest...
[18:32:37] <aczid> :D
[18:32:48] <aczid> ah yeah, 7
[18:32:51] <Lambda_Aurigae> when it became atmel studio it went downhill.
[18:32:52] <learath> eh, everyone wins - ms increases their lockin, atmel does not have to spend money
[18:33:31] <aczid> I get sad when I think about how MS will never go away
[18:33:37] <aczid> it's just going to be there, doing stupid shit
[18:33:49] <aczid> making everyone suffer their antics
[18:34:05] <specing> carabia: I have a st 072RB board
[18:34:07] <carabia> Well, having programmed with eclipse gnu-arm + openocd + gdb (cause they integrate nicely), whenever i touch atmel studio it really feels like heaven.
[18:34:31] <specing> carabia: all their PCBss have breakout pins for JTAG and a whole lot of them have split design that can be broken into two boards
[18:34:34] <carabia> programmed with eclipse-shit for close to two years or so...
[18:34:43] <Lambda_Aurigae> atmel studio feels like nothing to me....it won't run stable on wine.
[18:34:48] <aczid> at least eclipse is open source...
[18:34:55] <carabia> aczid: at least eclipse's horrible.
[18:35:00] <aczid> fair enough :)
[18:35:01] <aczid> it is
[18:35:06] <specing> But the problem with ARMs are those damn clocks
[18:35:12] <aczid> I just want a Makefile...
[18:35:32] <carabia> specing: doesn't take that long to learn them.
[18:35:37] <Tom_itx> make for what?
[18:35:47] <specing> aczid: try GPRBuild
[18:35:49] <carabia> specing: and yea, they do. It's nice.
[18:35:56] <specing> aczid: you wont use Makefiles any more
[18:36:36] <carabia> The real problem with arms is you either go gnu-arm (with macgyver gizmos) or spend a shit ton of $$ to get IAR or KEIL
[18:36:55] <specing> IAR and KEIL don't do Ada so that is an easy choice
[18:36:58] <aczid> specing: I actually lean conservative when it comes to compiling software
[18:37:03] <specing> at least not Ada 2012
[18:37:12] <specing> only GNAT GCC does that
[18:37:45] <carabia> specing: that's true but then again, the proprietary compilers dish out nice and tightly optimized code for arms
[18:38:15] <specing> ARMs usually arent nearly that space/speed constrained as AVRs
[18:38:19] <carabia> Don't know about IAR, but KEIL is bound to. KEIL == ARM.
[18:38:36] <aczid> since I've found out atmel releases 'packs' with all the xml file data for their devices I used to pick out of atmel studio. so I no longer need to install their crap anymore
[18:38:40] <carabia> specing: that's true also but /sometimes/ it can matter
[18:39:41] <specing> Well I'll just stick with usbasp (and the usbtiny once I revive it again) then
[18:40:13] <specing> I'll make Ada print exceptions to UART
[18:40:17] <specing> best debug :)
[18:41:08] <aczid> if you are lucky enough to have a uart you don't really need dw :P
[19:38:06] <rue_house> wtf, anyone have tiny13 code for 2 adc -> pwm channels?
[19:38:13] <rue_house> just ready?
[19:39:43] <Lambda_Aurigae> not I
[19:41:11] <rue_house> wtf, I dont even see a project on the t13 that uses pwm
[19:41:12] <rue_house> arg
[19:41:22] <rue_house> I'm gonna have to, like, type
[19:41:33] <Lambda_Aurigae> NOOOO!!!!
[19:41:36] <rue_house> no interrupt based adc
[19:41:39] <rue_house> arg
[19:41:50] <rue_house> I'm gonna have to think while I type
[19:41:53] <rue_house> damnit
[19:42:00] <rue_house> I had to think once already today
[19:42:39] <rue_house> ugh, I'm going to need to look at a datasheet
[19:42:49] <rue_house> I dont get paid enough to do this
[19:42:54] <rue_house> wait, I dont get paid
[19:42:59] <rue_house> this is a hobby
[19:43:12] <rue_house> do you think I an just copy t26 code?
[19:43:23] <Lambda_Aurigae> probably
[19:43:25] <rue_house> 13, 26 how different could they be?
[19:43:27] <Lambda_Aurigae> might not work
[19:43:28] <Lambda_Aurigae> but,
[19:43:30] <Lambda_Aurigae> you can,
[19:45:19] <rue_house> ok I have all the bits I need for the t26
[19:45:56] <rue_house> this is all so I can avoid resistors and caps, otherwise I'd use a dual op-amp
[19:50:49] <carabia> oh those pesky resistors and caps...
[19:57:44] <Lambda_Aurigae> they are such passive components.
[19:57:58] <rue_house> so much copying and pasting, my fingers are wearing out
[19:58:17] <Lambda_Aurigae> you need voice activated controls there dude!
[19:58:50] <rue_house> "copy" "paste" "copy" "paste" "copy" "paste, NONONO NOT THERE!"
[19:59:07] <Lambda_Aurigae> ok.ok....a psylink system then.
[19:59:08] <Lambda_Aurigae> sheesh.
[19:59:13] <rue_house> MATH TIME,
[19:59:23] <Lambda_Aurigae> NOOO!
[19:59:28] <rue_house> billy needs between 50khz and 200Khz, his clock is 4.8Mhz
[20:00:12] <rue_house> he can divide by 2, 4, 8, 16, 32, 64, or 128,
[20:00:14] <Lambda_Aurigae> depends on which direction his train is running on the tracks.
[20:00:18] <rue_house> what number should billy divide by?
[20:00:48] <Lambda_Aurigae> 32
[20:01:38] <rue_house> *&%^&%$ channels 2 and 3, thats just, ARG
[20:01:47] <rue_house> I cant just ... atg
[20:04:16] <rue_house> ADMUX = (1 - ADMUX) + 2; // select channel
[20:04:24] <rue_house> ok, not too horrid
[20:05:56] <rue_house> anyone ever written a software uart rx?
[20:06:07] <LeoNerd> Yup
[20:06:09] <rue_house> here
[20:06:12] <Lambda_Aurigae> Jartza has!
[20:06:17] <Lambda_Aurigae> on an attiny85
[20:06:20] <rue_house> what sample rate you use?
[20:06:24] <LeoNerd> 9600
[20:06:34] <rue_house> 4x sample rate tho?
[20:06:45] <rue_house> did you sync on a level change?
[20:06:54] <LeoNerd> No... considered it though
[20:07:09] <rue_house> how did you get framing?, long low?
[20:07:10] <Lambda_Aurigae> https://github.com/rakettitiede/octapentaveega
[20:07:34] <LeoNerd> Ohwait.. 57600 baud actually
[20:07:43] <LeoNerd> Soyeah, I've got plenty of clock time spare to consider oversampling
[20:08:35] <rue_house> which file has the uart?
[20:09:35] <Lambda_Aurigae> vga.asm
[20:20:01] <rue_house> ok thats twice I'v fallen asleep writing this code
[20:20:22] <rue_house> http://paste.debian.net/799426/
[20:20:27] <rue_house> see anything stupid?
[20:25:00] <rue_house> got it to compoele
[20:36:17] <Lambda_Aurigae> now to try to get it to compile.
[20:59:24] <dgriffi> how does the ADC prescaler work with regard to the ADC input frequency? The datasheet says that I need to set ADCSRA such that I get a frequency between 50 and 200 kHz. Is that all I need to worry about? Just find a divisor that divides the crystal frequency down to that window?
[21:00:56] <Casper> basically yes
[21:01:18] <Casper> if the ADC run too fast, then the voltages won't have time to settle
[21:01:28] <Casper> and if too slow then it may have time to decay
[21:06:40] <dgriffi> so it looks like a prescaler of 128 will cover all the crystals I'm likely to have on hand.
[21:33:32] <owl-v-> poor me.. i'm using arduino ide as avr ide :P
[21:53:25] <carabia> Poor me, I'm using eclipse, I imagine this is worse than arduino ide
[21:53:40] <carabia> I can't fathom how slow it actually is.
[22:32:59] <carabia> Anyway, damn the dma2d controller is fun to play with on the stm32s
[23:17:09] <dgriffi> when determining DDR settings, what do I do for the bits that represent where the crystal connects? how about don't cares?
[23:18:25] <Casper> ideally, keep them as input
[23:18:45] <Casper> as for the "don't care" they are normally not connected internally anyway
[23:20:21] <dgriffi> I'm talking about an ATtiny85. for the pins only used for ISP, does it matter what direction I say they are?
[23:22:52] <rue_house> dgriffi, the adc freq just needs to be in that range
[23:23:00] <rue_house> the faster, the faster your get your samples
[23:23:07] <rue_house> too fast and your lose accuracy
[23:23:35] <rue_house> I'm going to move the ocr updates to the adc interrupt
[23:23:59] <dgriffi> rue_house: I'm using the adc to read a resistor ladder keypad. slow should be fine
[23:25:24] <dgriffi> I think I got most of what I'm trying figured out... except for generating a pair of sine waves mixed together
[23:25:38] <rue_house> oh, your doing dtmf
[23:25:41] <rue_house> why didn't you say so?
[23:26:13] <dgriffi> rue_house: dtmf and a bunch of other sine pairs
[23:26:25] <rue_house> did you want us to show you how to do a sin lookup table?
[23:26:30] <rue_house> yea, A-F eh?
[23:26:46] <rue_house> er A-D
[23:27:02] <rue_house> 0123456789*#ABCD
[23:27:03] <dgriffi> more. MF, etc
[23:28:30] <rue_house> so you want 697Hz - 1633Hz range?
[23:29:06] <rue_house> 697, 770, 852, 941, 1209, 1336, 1477, 1633
[23:29:41] <dgriffi> that range should work. I'm trying to cram as many telephone tones as I can into the AVR
[23:29:52] <rue_house> well thats all of them
[23:30:23] <rue_house> I dont know the thd limit for dtmf
[23:30:43] <rue_house> you might get away with a 6 or 7 bit sin lookup table
[23:30:50] <rue_house> at 6 bits
[23:31:12] <dgriffi> what I have so far is using 8-bit resolution
[23:31:32] <rue_house> yea, 8 bits may slow down the samples too much
[23:31:55] <rue_house> at 6 bits, your samples can be min 104.512Khz
[23:32:15] <rue_house> 7 bits 209024Hz
[23:32:36] <rue_house> 418048hz at 8 bit
[23:32:57] <dgriffi> what I'm after is to be able to do this: play_tone(freq1, freq2, duration);
[23:32:57] <rue_house> iirc, I coulnd't get an avr to do 60Hz at 8 bit
[23:33:05] <rue_house> yea
[23:33:13] <rue_house> do you know how to use a lookup table?
[23:33:17] <dgriffi> yes
[23:33:25] <rue_house> k, do you know about sin lookup tables?
[23:33:34] <dgriffi> yes
[23:34:02] <rue_house> ok, so its just a matter of updating the two pointers at the right rates
[23:34:09] <rue_house> OR
[23:34:18] <dgriffi> basically something like unint8_t sine[256] = {0x80, 0x83, 0x86, ...};
[23:34:24] <rue_house> you store a cycle of samples for every combo
[23:35:00] <rue_house> I must have done something wrong in that math
[23:35:04] <dgriffi> I gotta run and do some stuff.
[23:35:08] <rue_house> I'm not awake so, its possable
[23:35:15] <rue_house> yea I gotta sleep
[23:35:24] <dgriffi> can you point me to some demo code?
[23:36:38] <rue_house> what dac are you using?