Back
[01:02:31] <TechIsCool> does anyone know where the people that develop for embedded arm hang out. What channel? well maybe someone can help I am trying to get an interrupt to happen every 1sec and so I have system clock/100 which the notes say should = 10ms but I am confused
[01:02:43] <geckosenator> maybe #arm
[01:02:59] <TechIsCool> 1 person
[01:03:14] <geckosenator> ok welll is your system clock 1mhz?
[01:03:25] <TechIsCool> no its 168mhz
[01:03:56] <geckosenator> sometimes it divides down for io and stufff
[01:04:10] <TechIsCool> general IO is set to 100mhz
[01:04:15] <geckosenator> I dont know I gave up arms in favor of avrs
[01:04:37] <TechIsCool> alright yah I have both but I need a faster clock and this is what I have
[01:05:20] <geckosenator> 32mhz isnt fast enough?
[01:05:40] <TechIsCool> I don't have any of them and since this I have I am using it hehe
[01:05:50] <TechIsCool> fastest avr I have is the 32u4
[01:06:26] <geckosenator> thats only like 8 or 20
[01:06:30] <TechIsCool> 8
[01:06:34] <TechIsCool> on the one I have
[01:07:33] <geckosenator> avr32 can do 66mhz
[01:08:05] <TechIsCool> yup just don't have one hehe
[01:09:09] <inflex> mmm... make it into a 486 :D
[01:09:30] <inflex> loved those old 486DX75 and DX100 chips
[01:09:53] <geckosenator> yeah me too
[01:10:06] <geckosenator> used to play games that you had a whole stack of floppy disks
[01:11:38] <inflex> heh
[04:28:13] <serp___> after changing the fuse of my avr to use an external crystal, it seems to have stopped working... it won't be programmed
[04:28:50] <serp___> I even tried to generate a clock signal by toggling a pin of another avr and connecting that to XTAL1, but no luck
[04:29:06] <serp___> what should I do? (
[04:29:06] <serp___> :(
[04:29:55] <Steffanx> Uhm, you remember what value/fuse you used and which avr?
[04:30:38] <serp___> yup, lfuse = 0xf7, hfuse = 0xd9 on an atmega328p
[04:41:18] <Steffanx> Then a external crystal should work serp___ ..
[04:41:45] <Steffanx> Sure you connected everything right?
[06:58:13] <RikusW> Steffanx: found one of my bugs....
[06:58:22] <Steffanx> :)
[06:58:33] <RikusW> RCom caused loss of sync
[06:58:41] <RikusW> switched back to qext....
[06:58:53] <RikusW> //#define RCOM_SERIAL
[06:58:54] <RikusW> #define QEXT_SERIAL
[06:59:02] <RikusW> in RavrProg.cpp
[06:59:07] <RikusW> at the top
[06:59:09] <RikusW> ugh
[06:59:31] <RikusW> flash writing for the bootloader appears to work, don't know why
[06:59:40] <RikusW> ISP to avr doesn't
[06:59:45] <RikusW> maybe its the parameters
[06:59:53] <RikusW> the bootloader ignores those
[07:01:02] <RikusW> at least reading flash doesn't cause the interface to fail entering programming mode anymore :)
[07:01:18] <RikusW> darn serial ports in linux :S
[07:04:08] <RikusW> And then there is QString.toAscii().constData() thats dangerous unless copied immediately...
[07:38:44] <serp___> Steffanx: yeah
[07:38:54] <serp___> I'm really puzzled by this
[08:21:43] <Tom_itx> try the xtal with no caps
[09:39:42] <inflex> aaah, don't you just love animosity between competing designers on forums
[09:48:41] <Steffanx> Do you?
[09:50:23] <inflex> not really - not when they get on my threads and start pushing their own stuff
[09:50:28] <inflex> it's like "Oh do go away"
[20:52:05] <tlvb> using avrgcc, can I do a PORTsomething |= (or &=) and the values on the pins that would be unaffected by the bolean logic will be unaffected in 'real life'...I recall one would have to jump through some hoops if one wants to get the value currently output on a port...
[20:53:15] <Casper> tlvb: yes you can
[21:04:43] <tlvb> Casper: ok, thanks ...does that mean that the generated code buffers the value somewhere, or is there some way to read the values?
[21:07:07] <Casper> you can read actually
[21:07:18] <Casper> but the reading isn't always what you think it will be
[21:07:49] <Casper> for example, PORT is an output only register, reading will read the last written data, and not the actual port status
[21:08:19] <Casper> while reading PIN will be the actual port status, but writting to it will, on most avr, toggle the bits that are at 1
[21:08:54] <tlvb> ah, that seems straightforward then, I thought there was something additional to this, but I must have remembered wrong
[21:09:27] <tlvb> ...hah, that line matched the length neatly...
[21:09:39] <Casper> ?
[21:10:04] <Casper> btw, the unused bits in some ports (incomplete ports) could always read wrong too
[21:10:19] <tlvb> your last two lines are equal in length, and my response, combined with that I use a shorter nick made the lines end at the same point
[21:10:45] <tlvb> ymmv depending on irc client and setup of course
[21:35:02] * inflex ponders coming up with some sort of SCR/latching indicator without using a uC (again!)
[21:35:32] <inflex> I know, I acn do it with 2 transistors... but there's other conditions to trigger it that make the part count start getting out of hand
[21:35:34] <mark4> sounds like a hardware problem lol
[21:36:00] <inflex> where's with a uC, it's just 1 little SOT23-6 chip... and it's all done
[21:36:22] <mark4> i think you just sold yourself the best solution. just took some convincing?
[21:36:32] <mark4> whers rikus?
[21:37:21] <inflex> the trouble is, a uC version means I have to flash/program the chip first, it's slightly more expensive.
[21:38:37] <Casper> and slower than hardware
[21:41:36] <inflex> Casper: well, I'm not trying to crowbar this one; it's more just an indicator... BUT, yes, it means it could miss a transient
[21:42:19] <inflex> though uC + reference + comparator would work