Back
[00:42:40] <rue_shop5> well, diagnosing it requires knowing everything about what your doing and what your doing it with, but I'm gonna take a nap
[02:57:25] <_ami_> Is COM00 bit used for enabling CTC mode for TIMER0?
[02:57:42] <_ami_> TCCR0 |= (1 << COM00) | .. ?
[02:59:47] <_ami_> nevermind, it works. got 100 ms toggle using this.
[08:13:28] <LeoNerd> Does anyone know how I might arrange that a disassembly of my object code actually knows the register names of my chip and prints them?
[08:14:05] <LeoNerd> I'd find it so much easier to read if peripheral registers had names and not just numbers
[08:19:04] <Emil> LeoNerd: cp the file and do a quick c/python/bash/sed program to replace from list?
[08:19:34] <LeoNerd> Hah
[08:19:38] <LeoNerd> How... manual
[08:19:54] <Emil> Eh, write once, use always
[08:19:57] <LeoNerd> I was hoping I could avr-objdump -mmcu=atmega328p and it would Magically Work
[08:20:00] <LeoNerd> But alas, no :(
[09:04:31] <Jartza> the problem is, they are just compiler defines and not really stored into .elf as text
[09:07:04] <LeoNerd> Sure, I'm aware of that
[09:07:15] <LeoNerd> I was hoping there'd be a lookup table of memory addresses that objdump could refer to
[09:09:47] <Jartza> LeoNerd:
https://spaces.atmel.com/gf/project/avr-source/
[09:10:29] <Jartza> not _exactly_ what you want, but maybe still useful
[09:13:17] <liwakura> LeoNerd: i just noticed that my assembly doesn't even has the names for the regular SRAM vars
[09:13:37] <liwakura> Also, let me whote for attention again:
https://github.com/liwakura/avr-rgbstrip
[09:13:40] <liwakura> *whore
[09:14:14] <liwakura> LeoNerd: it would be really cool if there was some program that would parse the IO defs and sed's the decompiled assembler files
[09:14:37] <liwakura> if you do not intend to do it, i would try
[09:28:32] <Jartza> it's much easier the other way around
[09:28:41] <Jartza> just write assembly, then you don't need to worry :D
[09:29:05] <liwakura> ...
[09:29:12] <liwakura> but i looove C that much
[09:29:14] <LeoNerd> That'd be *way* too slow for me
[09:29:43] <liwakura> i guess this^
[09:45:33] <Jartza> well yea. I like C too.
[09:45:46] <Jartza> but sometimes it's just must to write asm
[09:46:56] <LeoNerd> Oh *sometimes* sure,.. but the majority of code doesn't really need it
[09:53:23] <LeoNerd> Does anyone know if the "AVR-GCC" mailing list is also suitable for avr-binutils ?
[10:03:20] <LeoNerd> Eh.. I'll email there anyway
[10:03:32] <LeoNerd> Turns out my disassembler isn't giving *any* memory location names
[10:43:29] <liwakura> LeoNerd: yeah
[10:52:43] <LeoNerd> AH! Does anyone know where/how the various avr-libc avr/io*.h files are generated? I presume they must be automatically built from some source of data, as there's so many of them
[10:52:53] <LeoNerd> Those appear to know fuse bits and their default values
[11:06:05] <skz81> LeoNerd, it comes with avr-libc package... Unsure it is generated...
[11:06:52] <skz81> Could be but given Atmel provides some description file in a well-defined format, THAT'S what I doubt...
[11:07:20] <LeoNerd> Yah... even those .h files in avr-libc source seem to be already built
[11:07:22] <LeoNerd> This sucks :(
[11:07:31] <LeoNerd> I'd hate to have to parse C header files just to write a fuse-writing tool
[11:07:41] <LeoNerd> C header files are NOT a suitable machine-readable configuration language
[11:08:06] <skz81> Nope, but probably the most reliable info source, here...
[11:08:32] <skz81> re-use the GCC lexer :) :) :)
[11:09:01] <cehteh> mhm?
[11:10:25] <cehteh> LeoNerd: you are sure these are generated and not manually maintained?
[11:10:50] <LeoNerd> I have no idea
[11:11:11] <cehteh> i bet they are hand maintained, but would need to check the gcc sources
[11:11:11] <LeoNerd> I just feel there's far too many of them and they're huge, that surely someone had automated the process by now
[11:11:17] <LeoNerd> I have the avr-libc source here
[11:11:46] <cehteh> there are a lot worker bees working on the sources and once its set up for a new chip (which doesnt happen that often) its finished
[11:11:56] <LeoNerd> Hrm
[11:12:21] <LeoNerd> So is it really genuinely the case that on the whole of the internet and all 7 billion people on this planet, not a single human *ever* has built a machine-readable database of AVR fuse default values?
[11:12:32] <LeoNerd> I find that shockingly hard to believe
[11:12:58] <cehteh> well if you want to make a parser, then plz parse the datasheets not avr gcc source :D
[11:13:08] <LeoNerd> Hahah
[11:13:17] <cehteh> :D
[11:13:26] <LeoNerd> The Atmel data sheets, that sometimes contain bizarre typoes, mistranslations, Engrishisms, and whatever else?
[11:13:30] <LeoNerd> Nothanks ;)
[11:13:34] <cehteh> fuse defaults are defined in io*.h?
[11:13:55] <LeoNerd> Yes. E.g. this from my iom328p.h => #define LFUSE_DEFAULT (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0 & FUSE_CKDIV8)
[11:14:08] <cehteh> ok
[11:14:14] <LeoNerd> Except of course to parse that you need to understand eg. #define FUSE_CKSEL0 (unsigned char)~_BV(0) /* Select Clock Source */
[11:14:25] <LeoNerd> Which means you nee dto understand the _BV() macro which comes from a different .h file
[11:14:36] <LeoNerd> and... by that time you've written yourself half of a C parser
[11:14:37] <cehteh> it should be easy to get that out with some cpp trickery and scripting
[11:14:43] <LeoNerd> And I'd really really really HATE to do that
[11:14:44] <cehteh> no need to parse C
[11:15:22] <LeoNerd> ... ohwait. I can cheat
[11:15:30] <LeoNerd> ExtUtils::H2PM to the rescue. Again ;)
[11:15:41] <cehteh> huh
[11:16:00] <cehteh> in what format do you need the fuse data
[11:16:01] <LeoNerd> A handy little perl module I wrote myself to get out of exactly this kind of "C programmers are selfish bastards" problem
[11:16:27] <LeoNerd> The observation is that a *trivially* tiny C program obviously knows the value; printf("The default value of lfuse is %d", LFUSE_DEFAULT);
[11:16:39] <LeoNerd> So if you just compile and run that program, then you know the value, without ever needing to parse C yourself
[11:17:19] <LeoNerd> One step further, says that if you printf("use constant LFUSE_DEFAULT => %d\n", LFUSE_DEFAULT); and compile and run that program, then the output *from* that program is itself now a perl program, which now knows the constant too
[11:18:15] <LeoNerd> So ExtUtils::H2PM is a module building helper tool, which you just list some header files and constant names and it'll go off and capture the values of them at build time and generate you a perl file containing the required contants.
[11:18:42] <cehteh> $echo '#include "/usr/lib/avr/include/avr/iom328p.h"
[11:18:42] <cehteh> > HFUSE_DEFAULT
[11:18:42] <cehteh> > ' | cpp
[11:19:03] <cehteh> .. just cpp works almost, (needs some refinements)
[11:19:21] <cehteh> doesnt even need a C program
[11:20:47] <LeoNerd> Doesn't look too reliable for me there
[11:22:57] <cehteh> how that? exactly does what the C preprocessor would do
[11:23:07] <LeoNerd> For me it complains
[11:23:21] <LeoNerd> http://pastie.org/10849276
[11:23:47] <cehteh> cpp -I /usr/lib/avr/include/ -D__AVR_ATmega328P__ -include /usr/lib/avr/include/avr/io.h <<<"HFUSE_DEFAULT" | tail -1
[11:23:58] <cehteh> yes needs work, that was only an example
[11:24:04] <cehteh> look .. getting closer
[11:24:17] <LeoNerd> Meh
[11:24:22] <LeoNerd> So I'd still have to understand enough C syntax to parse that
[11:24:28] <LeoNerd> I think I'll just run the H2PM
[11:24:31] <cehteh> haha
[11:24:58] <cehteh> still not finished
[11:25:45] <cehteh> anyway thats why i asked what format you need the values
[11:25:52] <LeoNerd> Actual numbers
[11:28:19] <cehteh> hex?
[11:28:49] <LeoNerd> hex, decimal, anything
[11:28:51] <LeoNerd> anything MACHINE READALBE
[11:29:08] <LeoNerd> Anything I can use in my avrfuse program
[11:29:21] <LeoNerd> I want avrfuse -c m328p to output the default fuse values for that chip
[11:29:28] <LeoNerd> I don't care how it does it
[11:29:33] <LeoNerd> I'd prefer not to write my own C compiler to do so
[11:33:17] <cehteh> yeah its more reliable to use the existing compiler
[11:35:30] <LeoNerd> \o/ and I have a solution
[11:36:20] <LeoNerd> http://pastie.org/10849287 <== and I didn't actually have to write any C code
[11:37:20] <cehteh> ok
[11:37:37] <LeoNerd> Now just to iterate it a bunch of times over all the device types.. meh. :/
[11:38:07] <cehteh> dont forget the 328pb :D
[11:42:04] <LeoNerd> Ah.. my .h file collection doesn't know the pb yet :(
[11:42:51] <cehteh> thought so
[11:56:36] <skz81> <LeoNerd> I just feel there's far too many of them and they're huge, that surely someone had automated the process by now >> then, what is the data-source ? datasheet are enough "well-defined format" for automatiaztion (it's human langage), IMHO.
[11:57:20] <LeoNerd> skz81: Maybe the data source should be what atmel makes their device-info XML files from
[11:57:22] <skz81> Plus, what is the frequency of a "brand new" AVR architecture that description can't be derived from a nearly-look-alike older chip ?
[11:57:30] <LeoNerd> Those files contain Loooooooads of information. Just not the default fuse values
[11:57:43] <LeoNerd> I'm sure anyone who works on those files at Atmel could arrange for it to be added
[11:57:47] <LeoNerd> I just don't know how to ask. Or who
[11:57:48] <skz81> okay, if such XML exists, they may fit !
[11:59:23] <LeoNerd> Does anyone know of such a person? Some technical contact at Atmel ^WMicrochip ?
[12:10:19] <liwakura> LeoNerd: maybe code it yourself and make a Pull Request?
[12:10:39] <LeoNerd> ??
[12:29:12] <liwakura> LeoNerd: create a patch by yourself that fixes it
[12:29:22] <liwakura> and mail it
[12:29:29] <liwakura> maybe it will get included into the codebase
[12:29:48] <LeoNerd> A patch for the XML files?
[12:29:50] <LeoNerd> No
[12:30:24] <liwakura> oh
[12:30:38] <liwakura> sorry i thought you were talking about that binutils stuff
[12:30:54] <LeoNerd> OK that's a totally separate issue
[12:31:07] <LeoNerd> For *that* one, I could indeed fix binutils, and I may have to if no other solution turns up
[12:48:12] <WormFood> Are there any AVR devices, that don't have a FlashROM size, that is a power of 2?
[12:48:36] <LeoNerd> I don't expect so. But then I didn't expect any devices with non power-of-2 RAM, but yet the 32U4 has 2.5Ki of RAM
[12:49:22] <WormFood> that is a bit unexpected
[12:50:00] <LeoNerd> It's one of the USB chips, so possibly they added a bit more RAM to cope with that
[12:50:16] <LeoNerd> Odd that it's 5 halfKi blocks though
[13:08:57] <LeoNerd> Hrm.. Seems some of the newer chips have a fourth interrupt source on the UART; one for "receiver start". I wonder what situations that's useful
[13:09:08] <LeoNerd> You can't really do anything with the data yet because you haven't finished receiving
[13:12:19] <WormFood> what does the datasheet say about it LeoNerd?
[13:13:04] <LeoNerd> It doesn't say why you'd want to use it, it only explains how the feature works and what to do if you want to use it
[13:13:15] <LeoNerd> Datasheets rarely give rationale as to why the features they describe actually exist
[13:20:01] <WormFood> what chip is this LeoNerd?
[17:04:18] <PoppaVic> Well, What's shakin'?
[17:06:10] <PoppaVic> well, alrighty-then.
[17:07:55] <LeoNerd> Heh..
[19:10:10] <ne0phyte> arghh. any hints why the TWI ISR on an attiny20 could not get executed? the same twi slave routine worked fine before, it gets linked and is in the vector table and TWEN is set.
[19:11:28] <ne0phyte> I checked whether I fried the twi pins on the slave and master (all working fine), tried a software i2c lib on the master and tried using a different attiny for the slave
[19:11:44] <ne0phyte> just doesn't make any sense
[19:12:27] <Lambda_Aurigae> what changed?
[19:12:51] <Lambda_Aurigae> go back to an earlier version of the software.
[19:13:39] <ne0phyte> that's the tricky part: I just can't put my finger on it. I went back to some older commits but couldn't get it to work again
[19:14:13] <Lambda_Aurigae> so start with some base software and test from scratch.
[19:14:32] <Lambda_Aurigae> fleury's i2c software works well...not sure about on a tiny though.
[19:15:25] <Lambda_Aurigae> think it's only master.
[19:15:40] <Lambda_Aurigae> been a while since I scewed with twi/i2c
[19:15:47] <ne0phyte> I wrote my own i2c slave routine. it's definitely not 100% correct, but it worked before heh
[19:16:31] <ne0phyte> missing support for 10bit addressing for example. but I don't need that
[19:17:37] <ne0phyte> trying to cram a lot in those 128b/2k so the i2c libs I found are too big and most target USI which the attiny20 doesn't have
[19:29:21] <LeoNerd> If software that had been working now doesn't, and you're quite sure it's the same, then maybe consider hardware issues?
[19:32:16] <ne0phyte> soo. I just removed everything but the i2c isr and echo'd back the bytes the master sent.. and it worked
[19:32:36] <ne0phyte> mh. could -Os break my code?
[19:32:45] <Lambda_Aurigae> yes
[19:34:11] <ne0phyte> not sure how to find the cause for that though. the twi isr routine gets definitely linked but not called. everything is is working fine with -Os
[19:35:31] <ne0phyte> *everything else is
[20:19:26] <LeoNerd> Weird. I have a mega328P chip here, with HFUSE=D1 - that means EESAVE should be programmed / 0, meaning it should preserve the eeprom on erase. but yet it seems not to :(
[20:25:43] <Casper> LeoNerd: avrdude may be doing it
[20:34:08] <LeoNerd> Only that one chip though. my other chips are fine
[20:34:16] <LeoNerd> Perhaps I should just reset the fuses on it
[23:49:01] <kre10s__> I shouldn't need pullups on SPI lines right? because they are always driven by the master (save for MISO which is driven by the slave).