Back
[03:12:37] <megal0maniac> abcminiuser: I have two thumbs, if you still need them
[03:12:58] <megal0maniac> Didn't quite understand the other bit, but I think I have it XD
[03:13:48] <abcminiuser> Youwah?
[03:14:13] <megal0maniac> 21:46 < abcminiuser> Who has two thumbs and a working DFU transport/tool/protocol?
[03:18:30] <abcminiuser> Aha, right
[03:18:41] <abcminiuser> Spoiler alert: It's me
[03:20:22] <megal0maniac> Aight :)
[03:20:37] <megal0maniac> I get it now
[03:20:41] <megal0maniac> It was late
[03:36:02] <megal0maniac> abcminiuser: What lib are you using for usb communication?
[03:37:41] <abcminiuser> pyUSB
[07:03:33] <bitd> Anyone here know of a open source hardware engine management system?
[07:04:12] <OndraSter_> hardware engine management system? Like.. for combustion engines? Electrical engines?
[07:07:29] <bitd> Combustion engines.
[07:07:52] <bitd> So an EMS that is open hardware.
[07:33:26] <specing> you mean ECU?
[07:37:37] <bitd> Yes, specing
[07:51:58] <megal0maniac_afk> bitd: Ask w|zzy
[07:55:02] <bitd> Thanks megal0maniac_afk
[08:27:52] <ambro718> can avr-libc printf handle 64-bit integers?
[08:28:26] <ambro718> doesn't look like it can considering PRIu64 is not defined in <inttypes.h>
[08:34:12] <specing> ambro718: you know the drill
[08:34:33] <specing> template <typename someint> myprint(someint i) {...
[08:36:16] <ambro718> not as nice as printf ;)
[08:36:40] <ambro718> what would be wonderful is if C++ templates could accept strings as template parameters
[08:37:02] <ambro718> then I could do something like Print<"Foo %d %f">(4, 5.4);
[08:37:24] <ambro718> and the template would decompile the format string at compile time ;)
[08:38:13] <antto> you h4x0r
[08:39:07] <ambro718> * it can sorta be done already, but it's ugly since you need to define the string as a variable somewhere in file scope. i.e. char const format[] = "Foo %d"; ... Printf<&format>(...)
[08:39:46] <ambro718> (pointers to such things are valid template arguments)
[08:42:25] <timemage> ambro718, #ifdef __avr_libc_does_not_implement_long_long_in_printf_or_scanf they're surrounded by that. maybe it's an option when building avr-libc.
[08:43:53] <ambro718> for example I wrote this some time ago which parses a decimal number at compile time
http://ideone.com/mrRLcb
[08:44:19] <ambro718> timemage: yeah, but I don't really *need* it, it's just for debugging. I'll go with printing high and low parts separately.
[08:46:24] <ambro718> and this one which does the inverse is even more crazy ;)
http://ideone.com/gRFm5d
[08:48:48] <timemage> if you only needed it for a quick debug session you could just as easily use / and % an print the number out, not even bothering to reverse it.
[08:49:03] <sjokkis_> hey abcminiuser
[08:49:39] <sjokkis_> abcminiuser: when atmel studio is unable to program an avr because it can't read it, for whatever reason, it pops up four error windows after one another
[08:49:49] <sjokkis_> abcminiuser: could you shoot whoever figured that was good UI design?
[08:50:20] <abcminiuser> What version of Studio?
[08:50:21] <abcminiuser> 5 did that
[08:50:25] <abcminiuser> 6 shouldn't
[08:50:48] <sjokkis_> we have 6 at the computer lab here at ntnu and it sure does
[08:51:25] <timemage> ambro718, what da you doing that requires 64bit types on an avr? =)
[08:51:34] <ambro718> timemage: capacity of SD card
[08:52:46] <timemage> ambro718, did want to do it in blocks or didn't want to limit yourself to a couple of TB?
[08:53:26] <ambro718> just wanna print it out so you know what kind of card you inserted
[08:54:25] <ambro718> but yeah, 32bit*512B gives you 2TB
[08:55:09] <timemage> don't think were in danger of having sdcards that size soon. i could be wrong. =)
[08:56:58] <Tom_itx> ahoy abcminiuser!
[08:59:55] <abcminiuser> Yo Tom_itx
[09:00:01] <abcminiuser> sjokkis_, what are the messages?
[09:00:10] <abcminiuser> The old cascading crap is supposed to be fixed
[09:00:40] <Tom_itx> 2Mhz seems solid so far
[09:27:39] <specing> timemage: people didn't think we were ever going to have HDDs larger than 2TB...
[09:28:07] <specing> in 10 years time you are going to have 2TB uSD cards
[09:31:59] <timemage> specing, i've been around long enough to see drives grow =). if i were to apply that same logic some years ago i would assume we'd all have really large floppy disks now. if it were me, i think i'd just design the device with a 2TB limit and not screw around with 64bit types on avr.
[09:47:03] <specing> No timemage
[09:47:17] <specing> template <int bytes_of_lenght> ...
[09:48:29] <timemage> specing, i'm not talking about the template mess that was posted.
[09:48:56] <specing> you design stuff so that it is adaptable
[09:49:25] <specing> whether it only has < 256 blocks, of if it has > 18446744073709551616 blocks
[09:51:21] <twnqx> google mosfet level shifter, fkregs
[09:51:27] <twnqx> :S
[09:51:37] <megal0maniac_afk> Just looking at the topic, avrbeginners' news feed was last updated 9 years ago
[09:56:15] <ambro718> how would one go about designing an efficient abstraction of SPI?
[09:57:10] <ambro718> I'm thinking about a command queue, with commands such as: read N bytes to buffer, write N bytes from buffer, read bytes until the received byte is different from C.
[09:58:03] <ambro718> the last one for example would be useful with SD cards where after you send a command, you need to keep reading while the card is busy, until you get something different from 0xff
[09:59:14] <ambro718> plus error handling, such as adding the maximum read count to "read bytes until the received byte is different from C", and and a command "read byte an expect it is equal to C".
[09:59:50] <ambro718> and implementation would be using the SPI interrupt, on AVR at least
[10:02:20] <ambro718> the idea is these commands would be fed from the main loop, and the main loop would receive feedback upon their completion, so the code using the abstraction doesn't run in ISR context
[10:02:44] <specing> a queue of function pointers?
[10:03:01] <specing> when sth happens, pop a function and let it decide what to do
[10:03:41] <specing> which means write one fat function and call it every interrupt
[10:03:45] <ambro718> no need for that, I have compile time mechanisms to get feedback (basically there's a bunch of flag bytes in ram, ISR toggles them and main loop polls them)
[10:04:45] <ambro718> this is pretty easy to do "directly", but I coded some template magic so the variables are automatically populated (an integer index is assigned to each kind of event and an array of bool is made)
[10:05:08] <ambro718> but this is irrelevant, I'm more worried about the abstraction itself, not how the callbacks are done
[10:06:21] <ambro718> (I don't even need multiple callbacks, just one callback that consumes a queue of completed commands would work)
[10:07:45] <ambro718> (heck, just repetedly polling the queue would work, no need for callback)
[10:09:17] <ambro718> specing: no, the idea is that callbacks wouldn't happen in the ISR. IRS would just push completed commands to a queue...
[10:09:27] <ambro718> calling a callback during ISR can be disaster
[10:09:38] <ambro718> who knows how long it can be
[10:10:10] * abcminiuser yaaaaay GDP
[10:12:29] <ambro718> if you decided to call callbacks from within the ISR you wouldn't need a command queue in the first place. Purpose of commands is to define an "instruction set" sufficient to implement common types of SPI I/O eficiently without the "user" code having to deal with ISRs.
[10:12:50] <megal0maniac_afk> Wheeeee
[10:13:33] <ambro718> kind of like DMA controllers which you can give a list of operations
[10:14:15] <ambro718> huh, so nobody tried something like this before?
[14:47:16] <kdehl> Has anyone of you guys interfaced 30-pins SIMMs with a µC?
[14:48:04] <kdehl> If it is that 36-bit version with parity, do I have to use it, or can I just ignore that?
[14:59:31] <kdehl> No wait. 36-bit version is for 72-pin SIMMs.
[15:03:48] <specing> the Linux on AVR project does
[15:08:14] <OndraSter_> I did kdehl
[15:08:50] <OndraSter_> I wrote it fully in ASM
[15:08:55] <OndraSter_> I think I used it with mega32
[15:09:14] <OndraSter_> I also wrote it in C to compare the speed of my code vs fully optimalized gcc
[15:09:20] <OndraSter_> gcc was a few instructions longer
[15:09:30] <OndraSter_> wondering if I still have the source somewhere
[15:09:37] <OndraSter_> and if yes, then where
[15:12:35] <OndraSter_> oh yes I do!
[15:12:37] <OndraSter_> in one of the old backups
[15:13:25] <OndraSter_> last change on it was 17th may 2012
[15:15:38] <OndraSter_> kdehl,
https://github.com/OndraSter/AVRDRAM
[15:16:13] <OndraSter_> the dram.asm file
[15:18:02] <Fornaxian> it's been done several times. I remember a pic version that did it with 30pin simm some time back and I ripped that code out to do it with avr...like, 6 years ago.
[15:18:10] <OndraSter_> :)
[15:18:37] <Fornaxian> if you can get 30 pin sipp modules from an old 286 then you can breadboard it easily..
[15:18:46] <OndraSter_> yep
[15:18:51] <OndraSter_> that's why it was only half meg module I used
[15:18:53] <Fornaxian> sipp and simm are the same thing only sipp has the pins already soldered on.
[15:19:07] <Fornaxian> I have a bunch of 1Mb sipp modules here.
[15:19:16] <OndraSter_> Mb or MB?
[15:19:22] <Fornaxian> yeah...MB
[15:19:28] <Fornaxian> 1Mx8bit
[15:19:39] <OndraSter_> :)
[15:19:42] <ambro718> but... M or Mi ?
[15:19:45] <OndraSter_> they all were *8
[15:22:43] <Fornaxian> I ran it on an avr32 at 16MHz...should redo it for a 20MHz avr just for the fun of it.
[15:23:42] <OndraSter_> I tested it on 8MHz AVR
[15:23:48] <OndraSter_> I can't remember the numbers anymore
[15:23:52] <OndraSter_> of how much cycles it used per second
[15:26:02] <Fornaxian> back then it ran on a pic running at 8 or 10 MHz too.
[15:27:45] <Fornaxian> http://www.piclist.com/techref/microchip/picsimm.htm?key=dram&from=
[15:30:49] <Fornaxian> with that code taking only 7% of a 10MHz pic 16c74a, it should take considerably less than 5% of the processor time on a 20MHz avr.
[15:31:55] <Fornaxian> kdehl, that page also shows what you need to do for 9bit simm...the Q8, CAS8, and D8 lines are the difference.
[16:53:38] <kdehl> Fornaxian, OndraSter_: Sorry, you guys, I got distracted. Real life crap. But thanks! I'm going to have a look at the links.
[16:54:35] <Fornaxian> no worries.
[16:54:50] <Fornaxian> I've made a potroast with taters and onions and carrots in the meantime.
[16:55:10] <Fornaxian> including going out and digging up the taters, onions, and carrots out of our garden.
[18:37:20] <ColdKeyboard> Can I program Tiny85 with Tiny84 selected in eXtreme Burner 1.4 ?
[18:37:26] <ColdKeyboard> Or I need to use AVRDude?
[18:38:51] <Fornaxian> 84 and 85 are different chips.
[18:39:10] <Fornaxian> different minor series...so they will have different signatures..
[18:39:16] <Fornaxian> so, guessing, no, it won't work.
[18:40:05] <ColdKeyboard> So I have to use AVRdude for windows...
[18:40:18] <Fornaxian> what programmer do you have?
[18:40:20] <ColdKeyboard> And does anyone have a documentation on TV-B-Gone, what are the fuses?
[18:40:22] <ColdKeyboard> USBasp
[18:40:35] <Fornaxian> have you looked at the website for it?
[18:40:39] <Fornaxian> should all be in there somewhere.
[18:42:42] <ColdKeyboard> Oh, I have makefile in rar...
[18:42:53] <ColdKeyboard> I just need to run it from WinAvrDude?
[18:43:32] <Fornaxian> if you have the tools installed properly you just run make.
[18:43:52] <Fornaxian> am looking at the makefile now.
[18:44:03] <Fornaxian> should be make and make install...
[18:44:19] <Fornaxian> make burn-fuse
[18:44:33] <Fornaxian> not make install
[18:44:49] <Fornaxian> I use install for mine, but I'm strange.
[18:45:27] <Fornaxian> looks like a pretty generic makefile.
[18:47:22] <ColdKeyboard> avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)
[18:47:36] <ColdKeyboard> avrdude -p attiny85 -P com3 -c usbtiny -B 250 -u -U lfuse:w:0xfd:m -U hf
[18:47:36] <ColdKeyboard> use:w:0xdf:m
[18:47:49] <ColdKeyboard> This is the line it sends when I try to make burn-fuse
[18:50:13] <ColdKeyboard> What should I set AVRDUDE_PORT to if I'm using USBaspISP over USB? :)
[18:53:53] <ColdKeyboard> seems like -P usb :D
[18:56:27] <ColdKeyboard> Stil, it doesn't see usbasp :\
[19:07:26] <sirpatrick> Is it better to use macros for common things like digitalWrites and reads? Or should I use a function?
[19:07:37] <sirpatrick> This is a macro I made for digital write:
http://pastebin.com/8zrkJaVB
[19:27:35] <Casper> a function add some delays due to the push and pop and all
[19:27:55] <v0kehc> sirpatrick: macros can be difficult to troubleshoot
[19:28:06] <v0kehc> sometimes.
[19:28:07] <Casper> a macro I beleive is inlined, so if I'm not wrong the code is inserted each times, using more space
[19:28:16] <v0kehc> yes, the macro is expanded at each instance
[19:28:16] <Casper> but I may be wrong about the inlining
[19:29:03] <v0kehc> there are sublte pros and cons
[19:29:08] <v0kehc> but there is a reason people dont write entirely in macros
[19:29:20] <v0kehc> http://stackoverflow.com/questions/9104568/macro-vs-function-in-c
[19:33:32] <sirpatrick> awesome thank you for the help!
[19:39:44] <sirpatrick> are these equivilent: PORTB |= (0 << PB5) and PORTB |= ~(1 << PB5)
[19:42:36] <sirpatrick> nevermind I am silly
[19:42:50] <kline> sirpatrick:
http://ideone.com/R7hvsd
[19:43:11] <kline> oh hey i missed a char
[19:43:57] <kline> but yeah, you can use ideone to test basic programming truths
http://ideone.com/FLg6sp