Back
[00:38:05] <MarkX> hi
[00:41:26] <MarkX> i'm looking at the datasheet for the atmega32u4 >>
http://www.atmel.com/images/doc7766.pdf <<. it mentions 4 8bit pwm, 4 programmable resolution pwm, and 6 highspeed pwm.
[00:42:09] <MarkX> does that mean there are 14 pwm channels total?
[00:42:22] <MarkX> also does that mean there are 14 pins that i can output pwm from?
[00:42:52] <Casper> MarkX: most likelly 6
[00:43:45] <MarkX> ah gotcha. i'll look at the pinout now and count. hopefully someone can confirm my counting. don't really know how to count the pwm capable pins
[00:44:00] <Casper> look at the timer section
[00:48:16] <MarkX> four flexible Timer/Counters with compare modes and PWM
[00:48:19] <MarkX> do you mean that?
[01:00:24] <MarkX> 12 (oc0a), 18 (oc0b), 27 (oc4d), 29 (oc1a), 30 (oc1b), 31 (oc3a)
[01:00:47] <MarkX> those are the ones i counted just based on pinout, am i safe to assume that means those 6 pins can all output pwm?
[04:47:41] <oal> Volatile is only needed for global variables / variables that both an ISR and the main program can access, right?
[04:49:16] <oal> And is there any benefit to defining all functions as static? Including main? I only work in the realm of single file projects, and it doesn't seem to change anything
[04:51:40] <oal> To answer my second question: It apparently reduces code size, and makes the function only available from within its own file.
http://www.avrfreaks.net/forum/static-function
[07:28:19] <EI24> I'm reading the datasheet of atmega48-328 series. I getting confused when reading about the different clocks. Is the calibrated internal oscillator the oscillator for the system clock?
[07:32:58] <Tom_itx> i believe so
[07:33:14] <Tom_itx> unless you use an external crystal
[07:34:04] <EI24> tom_itx: thanks, it seems so, but it's not entirely clear to me
[07:51:09] <LeoNerd> It can be, if you set it
[08:13:36] <blundar> Ninjaneer: my question is more along the lines of: I'm trying to write a FUNCTION to call from both an ISR and from userspace where interrupts are active. During this function, I need to disable interrupts to do some time sensitive bitbanging to a device. If I save and restore SREG, will this be sufficient to restore interrupts to the same state they were in at the beginning of the function call (even though I clear them at some poin
[08:15:07] <blundar> Or do I need to pay more particular care to the IE flag specifically? I know that by the time you push SREG in an interrupt handler, IE has already been cleared. I'm THINKING that it will different with a function because there isn't the implicit clearing of IE that happens with an interrupt handler.
[08:15:47] <blundar> I don't have JTAG pins available on this device or I'd single-step through it and experimentally determine. :(
[08:20:11] <LeoNerd> Anyone ever (successfully) written a DMX receiver on AVR? Mine *mostly* works, but occasionally gets falsely triggered
[08:20:55] <LeoNerd> It sometimes thinks it sees a break to indicate start of frame when really there wasn't one... if the next channel after that happens to be at zero (which is fairly likely), then it goes on to believe it's reading real DMX values, and reports a bunch of junk to my application
[08:21:13] <LeoNerd> I say "occsaionally"; it happens maybe once or twice a minute, making debugging via logic probe a little tricky
[08:46:12] <LeoNerd> Ooh.. huhh.... So the UART *does* have a bit of a FIFO in the receiver
[08:46:27] <LeoNerd> So simply reading (void)UDR0; isn't sufficient to flush it
[08:51:09] <Casper> 1 byte fifo yeah
[08:52:12] * LeoNerd also reads http://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/
[08:52:16] <LeoNerd> Rather enlightening
[08:52:39] <LeoNerd> Basically it suggests that actually, I can insert a bit more of a delay between bits (or in my case at least, between the bytes) and that's OK
[09:04:05] <LeoNerd> So maybe this is somewhat easier
[09:04:22] <LeoNerd> I can just output a single byte by inline ASM code, and then switch back to C to manage the UART at the end
[09:43:25] <twnqx> that's what i do :P
[09:45:18] <twnqx> https://bpaste.net/show/0c7c311ba40a works pretty flawless
[09:45:33] <twnqx> (for 16mhz cpu)
[09:46:15] <twnqx> though it's stolen from
https://github.com/cpldcpu/light_ws2812.git
[09:47:44] <LeoNerd> Yah.. sortof similar to mine, except mine expands out all 8 bits currently because then I could reuse the NOP slots
[09:47:46] <LeoNerd> But I may not have to
[09:48:14] <twnqx> https://bpaste.net/show/2ef04415cf42 also for the more annoying ones
[09:48:21] <twnqx> (the 5mm/8mm round ones)
[10:21:23] <LeoNerd> Does anyone know of /any/ pinout diagram for an Ardunio Pro Micro, that actually shows the real AVR pin names..?
[10:21:33] <LeoNerd> I bought one of those boards because seriously, £6 for a 32U4... :)
[10:21:48] <LeoNerd> But now it seems the price I pay for that cheapness is nowhere can I find out what the actual IO pins actually map to
[10:23:34] * LeoNerd might have to ask in #arduino
[10:24:49] <twnqx> google image search for "arduino pro micro" seems to tell you all you need to know
[10:25:02] <twnqx> google image search for "arduino pro micro schematic" seems to tell you all you need to know
[10:25:27] <LeoNerd> Yah.. I was hoping for a ready made diagram I could print and stick on my wall with all the others :P
[10:25:38] <LeoNerd> It seems not to be. I'll have to write on the pin assignments manually then
[10:26:15] <twnqx> damn
[10:26:20] <twnqx> that pro micro is almost good
[10:26:25] <twnqx> if only it had ethernet, too
[10:26:56] <LeoNerd> Yeah - 32U4 for £6 ;)
[10:27:00] <LeoNerd> There's a few downsides to it
[10:27:12] <twnqx> like "it's crap like all arduinos"?
[10:27:15] <LeoNerd> E.g. the totally-bizarre way that the board designer puts the TX/RX LEDs on.. they eat two of the GPIOs
[10:27:20] <LeoNerd> Not two /sensibly-chosen/ GPIOs
[10:27:32] <LeoNerd> Two totally-random ones, each from the middle of what would otherwise be a nice clean 8bit IO port
[10:27:43] <twnqx> yes, like ALL arduinos
[10:27:49] <LeoNerd> Also, the 32U4 chip itself has quite a few more IO pins than the board gives you
[10:28:03] <LeoNerd> I much prefer my real Adafruit 32U4 board which breaks them all out, but that is £18
[10:28:17] <twnqx> speaking of xUy...
[10:28:31] <twnqx> how does flash self-programming work - erasable in 256B pages?
[10:28:44] <LeoNerd> All of the FTDI+UART -based Arduinos get TX/RX LEDs for free out of the FTDI chip, so they don't need to waste two GPIOs off the AVR
[10:30:41] <twnqx> og, 128byte pages
[10:31:03] <twnqx> i need some storage for rarely-changing-but-large config :P
[10:32:18] <LeoNerd> Hah.. you're going to store that in program flash?
[10:32:24] <twnqx> why not
[10:32:30] <LeoNerd> Not a totally insane idea
[10:32:35] <twnqx> eeprom is an order of magnitude too small
[10:33:18] <twnqx> still designing that 128i+128o monster
[10:33:36] <twnqx> i resorted to huge shift register approach ;_;
[10:34:11] <LeoNerd> Mm?
[10:34:17] <LeoNerd> Oh.. SRs for input?
[10:34:22] <twnqx> and output.
[10:34:27] <LeoNerd> What are you using for input?
[10:34:34] <LeoNerd> I've still yet to find anything that's even vaguely sensible for SPI input
[10:37:21] <twnqx> http://i.imgur.com/0l5q5ey.png that....
[10:37:36] <twnqx> and it should kind of work with SPI
[10:38:01] <LeoNerd> Eh...
[10:38:04] <LeoNerd> 74'165
[10:38:12] <LeoNerd> It has no tristate output, so you have to buffer the DO pin
[10:38:22] <twnqx> oh, for muxing?
[10:38:31] <LeoNerd> Also the parallel load thing is a bit weird
[10:38:33] <twnqx> i am just chaining them
[10:39:04] <LeoNerd> You *can* use a 74'165 as a parallel-read SR on SPI, so long as you don't actually want to *share* the SPI bus with ANYTHING ELSE
[10:39:24] <LeoNerd> And additionally that you dedicate a second GPIO line to be the LOAD control line of the 165s
[10:39:25] <twnqx> so one strobe to SH/!LD, then 128 clocks, then stobe to the micrel driver to set outputs
[10:39:34] <LeoNerd> Which isn't really SPI
[10:39:47] <twnqx> using spi hardware to read and write at once
[10:39:48] <LeoNerd> As compared to the *perfect* way that a 74'595 can be attached to SPI absolutely fine
[10:40:14] <twnqx> but that one's not chainable
[10:40:29] <twnqx> so instead of dedicatign one pin to the whole chain for loading
[10:40:30] <LeoNerd> You cna justabout get away with using a [chain of] 74'165 as a true SPI device if you buffer its output with something like a 74'125
[10:40:33] <LeoNerd> Hrm?
[10:40:38] <twnqx> you need to use one pin for each driver for CS
[10:40:42] <LeoNerd> I've chained 6 595s in a row out of SPI just fine
[10:40:45] <twnqx> oh
[10:40:48] <LeoNerd> For output
[10:40:53] <LeoNerd> I drove LEDs with them. Worked great
[10:41:18] <twnqx> just don't quite work with my voltage :P
[10:41:19] <LeoNerd> Pull the SS line low; write out 6 bytes, push SS high.. it latches those 6 bytes out to the LEDs. Exactly as SPI should be
[10:41:41] <twnqx> so just like mi micrel
[10:41:45] <LeoNerd> I want similar for input. I want to pull an SS line low, clock in a number of bytes of serial data that reads their parallel-load pins, then put SS high again.
[10:41:58] <LeoNerd> I cannot find *any* 74- or 4000-series SR that will behave like this
[10:42:19] <twnqx> just add a monoflop and a low-activated three state buffer :P
[10:42:36] <LeoNerd> 16:18 <LeoNerd> You cna justabout get away with using a [chain of] 74'165 as a true SPI device if you buffer its output with something like a 74'125
[10:42:41] <LeoNerd> I believe I said that :)
[10:42:50] <LeoNerd> It just annoys me that you can't find it in one chpi
[10:42:56] <twnqx> except for he shift/!load
[10:43:02] <LeoNerd> Ah.. well, again you can cheat
[10:43:10] <twnqx> with a monoflop.
[10:43:13] <LeoNerd> Nah, not even
[10:43:18] <LeoNerd> Just an inverter on the SS lien ;)
[10:43:42] <twnqx> true, but then you can't share the ss line with something like the micrel or '165
[10:43:45] <LeoNerd> SS => inverter => 165's LOAD# line; SS => gate of 75'125 to buffer the DO
[10:44:04] <LeoNerd> Where "inverter" could be something as simple as a transistor on the pin
[10:44:06] <twnqx> because laod is level triggered, not edge triggered
[10:44:10] <LeoNerd> Yes.. and?
[10:44:16] <LeoNerd> The 165 does *async* load
[10:44:33] <twnqx> oh wait
[10:44:35] <twnqx> i see
[10:44:38] <LeoNerd> While the LOAD line is held low, the SRs are being latched with the input data
[10:44:40] <twnqx> you justperma-load
[10:44:42] <LeoNerd> Yes
[10:44:47] <twnqx> mh
[10:44:52] <LeoNerd> The moment you raise the LOAD line, that stops.. it snapshots the input on that rising edge
[10:45:10] <LeoNerd> The inverter is simply to switch that to latching on a falling edge, as "standard" SPI would be
[10:45:41] <LeoNerd> Alternaitvely, you just invert the output and call the pin SS#, active-high, and buffer the DO/MISO line using a 74'126 instead
[10:45:54] <LeoNerd> Saves an inverter, but now means you need a 126 which tends not to be as standard inventory
[10:46:13] <twnqx> since i order at digikey, almost everything is inventory :P
[10:46:14] <LeoNerd> But either way, you need that buffer, because the SR doesn't tristate output
[10:46:30] <twnqx> i tend to use the single-gate chips from TI in sot-23
[10:46:32] <LeoNerd> "inventory" is what I call the things I keep in my plastic boxes available for tinkering at a moment's notice at 2 in the morning :P
[10:46:35] <twnqx> sot-23-5
[10:46:38] <LeoNerd> Yah those things are great
[10:46:40] <twnqx> ah
[10:46:54] <LeoNerd> I keep a few 74AHC1G125s/126s on SOT-23-5 breakout boards
[10:47:19] <LeoNerd> http://www.hobbytronics.co.uk/electronic-components/breakout-boards/sot23-adapter <== great for these :P)
[10:47:39] <twnqx> i generally don't breadboard
[10:48:16] <twnqx> did you scroll the image to the right, beyond x=1920? :>
[10:48:19] <LeoNerd> Actually, usually what I want isn't even just a straight SR, it would be one with a pinchance interrupt line sa well
[10:48:40] <twnqx> yeah
[10:48:43] <twnqx> same here
[10:48:46] <LeoNerd> I'd looooove a chip that had 8 parallel-load inputs, SS/SCK/MISO + IRQ
[10:49:03] <twnqx> i am considring "making" one
[10:49:05] <LeoNerd> You can sortof get that in the I2C-based GPIO expanders, but.. meh.. I2C :(
[10:49:12] <LeoNerd> make one on an ATtiny84
[10:49:41] <twnqx> http://www.latticestore.com/products/tabid/417/categoryid/9/productid/261/searchid/1/default.aspx?searchvalue=ice40lp384*
[10:49:46] <twnqx> from those.
[10:50:28] <twnqx> would be 16pin, though
[10:50:35] <LeoNerd> I'd consider looking at PLA/PLD/CPLD/FPGA end of things if there was *AAANYTHING* by way of standard dev. tools on it
[10:50:50] <twnqx> mh?
[10:50:58] <LeoNerd> avr-gcc, avrdude + a £5 USB adapter will let me program any AVR chip I damn well like
[10:51:07] <LeoNerd> What's the equivalent for, say, a 10L8?
[10:51:22] <LeoNerd> What do I type into apt-get install that gives me a full PLA dev environmenmt?
[10:51:35] <twnqx> no idea, but xilinx ISE (free) is ./install
[10:51:49] <twnqx> not much different from lattice's soft
[10:51:51] <LeoNerd> And the programming burner hardware...?
[10:52:00] <twnqx> for xilinx, it's a ft2232
[10:52:12] <twnqx> well, you don't hard-program their fpgas anyway
[10:52:19] <twnqx> wither you add an i2c flash
[10:52:26] <twnqx> err spi flash
[10:52:29] <LeoNerd> Yeah.. I mean more down at the smaller end
[10:52:43] <LeoNerd> I'm 99% sure that my shift-register is -trivially- easy to implement on a 10R8
[10:52:45] <twnqx> or you just software-upload through SPI like i intend
[10:52:56] <LeoNerd> So I just want a 10R8 burner
[10:53:16] <twnqx> ok, i have no clue what a 10r8 is
[10:53:23] <twnqx> and can't find it with quick goolging
[10:53:28] <LeoNerd> PLA
[10:53:40] <LeoNerd> 10 input pins, 8 output pins, each with a D latch on
[10:53:56] <LeoNerd> ("10 input, Registered 8 output"
[10:54:12] <LeoNerd> It's like a tiny trivial dirtcheap chip
[10:55:26] <LeoNerd> That said I could also implement my SR quite trivially on a tiny84, I'd just have to knock out the RST pin to do so
[10:55:48] <LeoNerd> And then it would be somewhat slow because it would be a bitbanged SPI slave :(
[10:56:00] <twnqx> no feedback, no shift registers
[10:56:20] <twnqx> doubt your PLAs will do
[10:56:30] <twnqx> guess you'll need CPLDs as minimum
[10:56:44] <LeoNerd> Hrm?
[10:57:04] <LeoNerd> A 10R8 can trivially implement an SR.. that's what the feedback lines are for. among other things
[10:57:29] <LeoNerd> Gah.. I meant 16R8. Getting my numbers confused
[10:58:26] <twnqx> ttl...
[10:58:32] <twnqx> can an atmel drive ttl inputs?
[10:59:14] <twnqx> ah, other vendors went cmos, too
[10:59:33] <LeoNerd> Actually looking at it, not quite enough inputs to do this
[10:59:33] <twnqx> but it's also not threestate, or is it?
[11:00:01] <LeoNerd> Some PLAs let you do buried registers and reuse the IO pin for other purposes. But seems not these
[11:00:06] <LeoNerd> Soyeah, it'd need something a bit bigger
[11:00:50] <LeoNerd> Butyah the main problem with the general field of 16R8 and friends, is that there's about 20 different manufacturers that make them that'll all sell you fancy programming hardware that's totally unspecified how it works...
[11:01:05] <LeoNerd> Kindof useless except for huge production runs
[11:02:14] <learath> "16R8"?
[11:03:04] <LeoNerd> https://www.google.co.uk/search?q=16R8+PLA
[11:03:19] * LeoNerd not in a mood to teach everything to everyone today
[11:21:11] <twnqx> well, i have a xilinx programmer anyway, and they even state how you program their device via jtag from a µc
[11:24:22] <learath> microsemi provides "DirectC" to program their FPGAs from a uc, which I'd love to play with
[11:52:32] <idiot2> hello
[12:03:41] <LeoNerd> Ooooooh
[12:04:18] <LeoNerd> For all my annoyed ranting at the GODDAMNED STUPID pinout of the Arduino Micro Pro board, there is one saving grace. They (perhaps-thoughtfully?) put A0 to A3 on PF4 to PF7.. which conveniently is the JTAG port
[12:04:33] <LeoNerd> So there's a nice handy strip of four neighbouring pins that conveniently holds JTAG off the board.
[12:05:23] <EI24> Hi, i'm trying to learn about timer/counters and interrupts. Simply toggling a LED whenever the timer overflows. I don't get why i wont work. here is my code,
http://paste.debian.net/177034/ . Im using an arduino, built in LED i on PORTB 5
[12:05:27] <LeoNerd> Now, if only they shipped the boards with the JTAGEN fuse... :/
[12:05:58] <EI24> why it wont work*
[12:06:16] <LeoNerd> You did SEI to turn on interrupts generally, but I don't see a line to turn on the specific timer-overflow interrupt
[12:06:30] <LeoNerd> Ohwait there it is; TIMSK0
[12:08:01] <LeoNerd> Stylistically, it's best not to SEI until all the individual pieces are in place.. just in case an interrupt happens too soon
[12:08:44] <LeoNerd> Offhand I can't see anything much wrong there, but a bit hard to see in the opaqueness of hardcoded port numbers, etc...
[12:08:52] <LeoNerd> Aren't there macros you can use for this sortof thing? :)
[12:09:07] <LeoNerd> Or, yaknow, try it out in C first and move on to asm once it works
[12:09:18] <EI24> ok, i will call SEI lastly
[12:09:48] <EI24> ahh but then i have to learn the AVR-GCC lib haha ;)
[12:10:52] <LeoNerd> Not at all
[12:11:20] <LeoNerd> E.g. your line 11, the SBI, would look like DDRB |= _BV(5);
[12:11:30] <LeoNerd> Or (1 << 5) if you object to the _BV() notation
[12:11:30] <idiot2> macro it lol
[12:11:56] <idiot2> or c++
[12:12:36] <EI24> hmmm.. i will try some more, but when my patience is lost i will try it out in C instead.
[12:13:29] <EI24> idiot2: yes but i have not learned m4 yet, but for larger projects i will prob have to
[12:13:42] <idiot2> gcc has macro too btw
[12:13:47] <idiot2> it is just simpler
[12:14:26] <EI24> but does it work for .asm files as with m4?
[12:14:37] <EI24> as m4 does*
[12:14:50] <idiot2> EI24, i'd suggest to forget the adruweenie, and write real C code
[12:15:00] <idiot2> then i could help some too.
[12:15:12] <EI24> ;) keep geeting those
[12:15:12] <LeoNerd> idiot2: he is writing real code.. real assembly code, at that
[12:15:33] <EI24> getting*
[12:16:07] <LeoNerd> I suspect by saying "using arduino" he means "using an arduino board"
[12:16:07] <idiot2> this is your code now?
http://paste.debian.net/177034/
[12:16:16] <idiot2> simplest way to toggle a pin is to xor a bit...
[12:16:39] <EI24> yes thats mine
[12:17:11] <idiot2> EI24, what is your goal? ;>
[12:17:12] <EI24> i wrote wrong TIMSK, it supposed to be the first bit, but i've tried that to. i get the same result
[12:17:35] <idiot2> i'm just lazy to asm all the time, but if you like that go on
[12:17:50] <EI24> idiot2: well right know im just trying to learn about interrupts and counters
[12:18:18] <idiot2> also gcc usually does a good job in potimizing asm output
[12:18:25] <LeoNerd> idiot2: some AVR chips (of which I believe the mega328p is one) have a handy feature whereby writing a 1 bit to the PINx register will toggle the PORTx register
[12:18:25] <idiot2> optimizing
[12:18:31] <LeoNerd> It avoids needing a read/modify/write cycle, so it's faster
[12:18:49] <idiot2> LeoNerd, yeah i read about that too, or you can just double buffer
[12:18:49] <LeoNerd> But again that would become a lot clearer in C, becaue you'd write PINB |= _BV(5)
[12:18:57] <EI24> but i need that for my other project where im trying to animate multiple sprites on a TFT screen, at the same time
[12:19:17] <LeoNerd> EI24: generally my advice is that asm is a last-resort. If you /can/ write your program in C, do so
[12:19:29] <LeoNerd> If there are parts that can't be done in C, move _those parts_ to assembly
[12:19:31] <idiot2> LeoNerd, asm is not harder to toggle a bit.
[12:19:41] <LeoNerd> No harder no. Just less obvious when you read the code
[12:19:49] <LeoNerd> SBI 0x05 , 5
[12:19:58] <LeoNerd> Off the top of my head I can't remember what IO address 0x05 is
[12:19:59] <idiot2> setb eax,8 is self explanatory to me
[12:20:09] <LeoNerd> But PINB is fairly self-explaniatory
[12:20:58] <EI24> SBI toggles the bit right? so if its set, it will be cleared
[12:21:06] <idiot2> it sets bit
[12:21:16] <LeoNerd> Set Bit in IO Register
[12:21:27] <idiot2> xor toggles bits
[12:21:29] <LeoNerd> <LeoNerd> idiot2: some AVR chips (of which I believe the mega328p is one) have a handy feature whereby writing a 1 bit to the PINx register will toggle the PORTx register <== TO REPEAT MYSELF
[12:21:30] <EI24> one example i looked at, used SBI to toggle a bit, on and off
[12:21:36] <idiot2> or clc - complement bit
[12:21:38] <LeoNerd> idiot2: This is a special feature of the PINx registers
[12:21:47] <idiot2> LeoNerd, oh yea
[12:22:04] <idiot2> EI24, that is feature of PINB
[12:22:09] <LeoNerd> So the /effect/ of SBI 0x05, 5 or PINB |= _BV(5) is to toggle the 5th bit of PORTB
[12:22:26] <EI24> ahh ok
[12:23:14] <LeoNerd> Ofcourse this is all presuming that IO regiser 0x05 reallyis PINB
[12:23:19] <LeoNerd> and offhand I don't know if it is
[12:23:22] <LeoNerd> I know the C code is right
[12:23:34] * LeoNerd again reiterating "do it in C first because that's easier to read/understand"
[12:24:24] <idiot2> i learned ASM first too :P
[12:24:38] <idiot2> made delays even without interrupts
[12:24:56] <EI24> you know i had a problem where i tried to initiate a tft screen in asm, looking at C examples. It took me weeks but in the end it worked.
[12:25:12] <idiot2> hehe
[12:25:30] <idiot2> the problem with that is you need high bandwidth for a decent resolution and bit depth
[12:25:36] <EI24> it feels strange to move back to flashing leds, but thats what you get if you skip learning basic stuff
[12:26:48] <LeoNerd> Yah.. again: start in C, and if small parts are too slow, rewrite those bits in asm
[12:26:53] <idiot2> DVI is doable too with an mcu
[12:26:59] <LeoNerd> Most of the program isn't where most of the time is spent
[12:27:05] <idiot2> it would be more suited because it is digital
[12:27:35] <idiot2> unfortunate that a single very high bandwidth data sending is required
[12:28:01] <idiot2> doable for high resolution only with an expensive fpga
[12:28:51] <EI24> thanks, i will actually do that if i cant figure it out
[12:29:40] <idiot2> dvi? ;>
[12:30:19] <idiot2> that will require 100MHz+ clocked data
[12:31:41] <idiot2> EI24, btw you only enable interrupts after you set your timer :P
[12:31:53] <idiot2> because timer will start to run at the instant you enable them
[12:32:41] <EI24> ohh yeah ill change that
[12:32:45] <EI24> thanks
[12:32:48] <idiot2> so move line 13 to 29
[12:33:27] <idiot2> and use names instead of addresses for registers, pins.
[12:33:44] <idiot2> that will be more readable, and it might even work more often
[12:34:14] <EI24> yeah thats true, but for this proj im just using one reg
[12:34:43] <idiot2> you will not know what 0x05 was later :)
[12:34:52] <idiot2> and it will differ in devices
[12:35:23] <EI24> i know of extensive use haha
[12:35:27] <EI24> portb
[12:35:40] <idiot2> you use gcc with -masm=intel ?
[12:35:41] <EI24> i know after extensive use*
[12:35:52] <EI24> no avra assembler
[12:36:19] <EI24> it's like a avr assembler duplicate but for linux and with added features
[12:36:41] <idiot2> thanks i fetched it, will check out
[12:37:31] <idiot2> wiwhat extra features of it you like?
[12:37:53] <EI24> well i havent used them but i read about them in the documentation
[12:38:27] <EI24> i dont remember though
[12:43:02] <idiot2> www.usb.org FINISHED Total wall clock time: 2h 7m 37s Downloaded: 712 files, 985M in 2h 4m 14s (135 KB/s)
[12:43:10] <idiot2> fetched some junk
[12:47:19] <EI24> idiot2: ont om svenskar på data irc kanaler, du är nog den första jag mött på XD
[13:33:31] <deerhawk> EI24: men bubbis, jag hittar ju inte mina cigaretter :(, kan inte du köpa cigaretter åt mamsi?
[15:03:13] <idiot2> hmm tested this logitech crapstick 3d pro :/ it has 10 bit axes (that can do about 7 bit precision)
[15:03:49] <idiot2> an atmega adc is 12 bit
[16:34:38] <timemage> Tom_itx, was wondering if the isp recover clock feature you have is a square wave and whether or not you've seen any problems with feeding a PWMed signal to a chip that was configured for an external crystal.
[16:40:09] <RikusW> timemage: you can use a 50% duty cycle pwm signal for the clock
[16:40:55] <timemage> RikusW, that's what i thought, but ran into someone claiming to have had issues with using that method. was wondering what if any reason.
[16:40:58] <RikusW> his is most probably square wave
[16:41:44] <RikusW> Some people even used while(1) PORTA++; and then used A0
[16:41:44] <N1njaneer> I have never had an issue doing that for clock recovery purposes.
[16:41:49] <timemage> RikusW, this was likely pwm to reprogram something originally configured for 16mhz xtal to internal osc instead.
[16:42:21] <RikusW> iirc just connect the pwm to XT1 on the dead chip
[16:42:27] <N1njaneer> Since AVR is an entirely static-based architecture, you could sit there with a toggle-switch and generate the clock manually if you had a LOT of time to spare :)
[16:42:58] <RikusW> toggling in the bootloader is ancient tech :-P
[16:43:25] <timemage> yeah, it may be nothing. but, figured i'd ask. my only part it is was going to suggest tom's programmer. he was feeding the signal using pwm himself. thought maybe if here was such a problem that a different technique was adopted for the programmer's recovery feature.
[16:43:32] <Jartza> maybe we can try with my modem, something more advanced
[16:43:49] <Jartza> singing the firmware in
[16:44:02] <N1njaneer> New pick and place is now on a truck somewhere in California! Exciting.
[16:44:10] <Jartza> ooh
[16:44:30] <N1njaneer> I always thought it would be fun to drive an AVR using a microphone hooked to the clock inputs!
[16:44:40] <Jartza> :)
[16:44:47] <timemage> N1njaneer, heh
[16:46:07] <Jartza> "clap your hands few dozen times to turn on the lights"
[16:47:10] <N1njaneer> Exactly!
[16:48:16] <Jartza> https://docs.google.com/file/d/0B2dTzW9TMeBxNV81WXJaVXVTU2M/edit?usp=docslist_api
[16:48:29] <Jartza> did you see that already? :)
[16:48:43] <Jartza> tagsu firmware update via audio
[16:51:37] <N1njaneer> Nice! I like the LCD animations
[16:52:26] <Jartza> :)
[16:52:55] <Jartza> nice two-step-process
[16:53:14] <Jartza> I load the bootloader same way ad user data
[16:53:43] <Jartza> it just has magic to tell it apart from user data
[16:54:31] <Jartza> bootloader is then in the upper 2kB part of flash and waits 20 secs for new firmware
[16:54:51] <Jartza> if none uploaded, it just reverts back
[16:55:58] <Jartza> if fw update starts but doesn't finish, the device stays in bootloader-mode until it receives good fw
[16:56:31] <Jartza> only when crc matches for the whole fw, it flashes the page 0
[16:59:47] <Jartza> the bootloader also "looks like" user data to firnware, so no binary crap drawn to screen after update
[17:00:42] <Jartza> required quite heavy linker script-fu though as I needed certain sequence of data almost in the middle of code
[17:01:01] <Jartza> but got everything in <2kB, which is nice
[17:01:34] <Jartza> (audio bootloader with i2c & lcd-lib, that is)
[17:04:05] <bedah> nice hd44780 animation :)
[17:34:07] <LeoNerd> If I want to briefly let any pending interrupts fire, is sei(); cli(); enough to do that..?
[17:34:13] <LeoNerd> Will they *all* fire, or just the first one?
[17:35:20] <N1njaneer> That's actually a good question - I'd be interested to know. I would assume that if there is another pending it would go back to back within a few clock cycles.
[17:35:46] <LeoNerd> But that turns into a literal SEI; CLI; instruction pair
[17:36:02] <LeoNerd> Basically, at the end of every byte of LED output I want to flush pending interrupts, because that's a moment when it's safe
[17:40:02] <Valen> It'll get you one interrupt, I dunno about any further ones, depends if you get to execute any main instructions between finishing up ISRs
[17:41:48] <LeoNerd> Ohwait I remember now... SEI; CLI; does nothing
[17:42:00] <LeoNerd> SEI only enables interrupts on the instruction *after* next, so that you can so SEI; SLEEP;
[17:42:32] <N1njaneer> Might need to make a NOP sandwich :D
[17:43:30] <LeoNerd> Ah.. turns out my ISR is too slow for the LEDs anyway :(
[17:47:42] <LeoNerd> Huh....
[17:47:53] <LeoNerd> error: can’t find a register in class ‘POINTER_Y_REGS’ while reloading ‘asm’ what does *that* mean?
[17:48:19] <LeoNerd> It doesn't seem to like my 'Y' constraint
[17:48:27] <LeoNerd> Mmm but x works
[17:53:34] <LeoNerd> Seems like I'm back to NOP-threading then... :/
[17:53:47] <LeoNerd> A bit late in the evening now to write that... might do it tomorrow
[17:57:28] <idiot2> hi
[17:58:30] <LeoNerd> Ooooooh
[17:58:55] <LeoNerd> No... ofcourse I didn't want to run *all* my interrupts, just the UART one. But I can do that by manually testing the interrupt flag and calling the hagndler func
[17:58:57] <LeoNerd> *handler.
[17:59:00] <LeoNerd> Which now works. o\/
[17:59:09] <LeoNerd> ... oops, my head fell off
[18:00:52] <N1njaneer> Or just call the interrupt handler and put a rejection test in the ISR
[18:01:27] <LeoNerd> Mm?
[18:02:47] <LeoNerd> Actually this doesn't *quite* work
[18:03:34] <N1njaneer> i.e. you can always put the test for work to be done in the actual ISR code, so if it's called unnecessarily it doesn't harm anything other than a few wasted cycles. Though I suppose if you are conserving cycles testing in the main code would prevent the brand and return overhead.
[18:03:57] <LeoNerd> The ISR is already quite minimal
[18:04:08] <LeoNerd> It just stuffs UART bytes into a a buffer and maintains the DMX state engine
[18:05:13] <N1njaneer> FYI, if you ever get in to doing RDM target stuff, the ESTA MFG ID's are free. Just email Karl and ask for one. :)
[18:05:57] <LeoNerd> Mmm..
[18:06:03] <LeoNerd> RDM might be fun for version 2 of this system
[18:06:13] <LeoNerd> so I can return back the state of the fog machine, if it's hot enough yet
[18:19:13] <LeoNerd> Damnit Atmel.. CP, CPC, CPI,... Where's CPCI?
[18:19:26] <LeoNerd> What if I want to compare a multibyte register pair with immediate?
[21:49:23] <overrider_> Imagine i have a circular buffer[32] that i can keep writing data to. How can i search it? Documentation about circular buffers online don't seem to explain searching the buffer for a string, such as AT\r\n where the AT could be in the last two positions of buffer[32] and \r\n could be in the first two positions (wrapped data). As you can see i am trying to communicate to a GSM Modem and store its responses
[21:49:26] <overrider_> somehow for later string searching. Any hints?
[21:49:35] <idiot2> what do you think about using an rj-35 connector for isp ?
[21:49:50] <idiot2> RJ45
[21:50:35] <idiot2> overrider_, a circular buffer is a simple buffer, you just need a head and a tail pointer.
[21:51:48] <idiot2> you have a function to put data in it, and read data from it it writes and reads the head and tail pointers.
[21:52:37] <overrider_> idiot2: correct, so how could i search for a piece of data that might have been wrapped in the buffer? This shows my problem /question nicely i think
http://www.pastebin.ca/3002967
[21:56:18] <idiot2> read sequentially from start and if tmpvar >= sizeof buffer then tmpvar=address of buffer :P
[21:57:10] <idiot2> actually a ringbuffer has 4 pointers
[21:57:33] <idiot2> or 2 pointers and 2 sizes.
[21:57:52] <N1njaneer> I've switched over to using TagConnects for all of our ISP and JTAG connection needs. Zero cost on the PCB, minimal cost on the cable.
[22:01:32] <N1njaneer> http://www.tag-connect.com/
[22:04:04] <idiot2> N1njaneer, sounds ... good
[22:06:09] <idiot2> though i could reduce that board to less than half size in the presentation
[22:06:39] <N1njaneer> The point is demonstrating the TagConnect connector size :)
[22:07:01] <idiot2> yes i see how clever they are :)
[22:07:24] <idiot2> they made a problem and demonstrated a solution to it
[22:07:49] <N1njaneer> Just used one on a stack of US quarter-sized boards with an ATTINY24A - was good for saving on real-estate and a nicer version of the 0.1" pogos I've been using for years. Theirs is a lot easier to push on, and can stay stuck through the board for development. :)
[22:15:05] <idiot2> N1njaneer, would you use a twisted pair for data transmission asynchronously?
[22:15:35] <idiot2> there are only 3 states without gnd :/
[22:16:26] <N1njaneer> Yes, typically RS485. I use it all the time. Twisted pair helps common mode noise rejection as well as matching impedence.
[22:16:54] <idiot2> i mean asynchronously
[22:17:00] <N1njaneer> Yes.
[22:17:05] <idiot2> with self clocked data
[22:17:07] <N1njaneer> Yes.
[22:17:28] <N1njaneer> Fine for synchronous or asynchronous
[22:17:52] <N1njaneer> It's more the network topology and what you are transmitting over what distance and medium.
[22:18:26] <N1njaneer> But regardless twisted pair helps immensely with common mode noise and impedance matching.
[22:18:53] <N1njaneer> Both of which become important once you start reaching any kind of speeds over distance, or noise-hostile environments.
[22:21:49] <idiot2> i have thought about a third operational mode
[22:22:20] <idiot2> mark short space short ...
[22:23:12] <idiot2> with about half speed
[22:23:14] <idiot2> what you think?
[22:23:42] <N1njaneer> I don't follow.
[22:23:55] <idiot2> there are 3 states of bus
[22:24:15] <idiot2> + > -, - > +, x = -
[22:24:21] <idiot2> *+
[22:24:37] <idiot2> so if both are same potential, then they are shorted together
[22:25:41] <N1njaneer> Problem is the window in which they are considered equal then puts additional limitation on your signal amplitude requirements and potentially your edge rates, plus you will potentially deal with more metastability problems.
[22:26:07] <N1njaneer> And the receiver then needs more than a 1 or 0 to convey status, which means difficulty with interfacing to other parts, etc.
[22:26:22] <idiot2> :/ yes
[22:26:28] <N1njaneer> More problems than solutions.
[22:26:41] <idiot2> but ground is not part of twisted pair
[22:26:55] <N1njaneer> If you are doing asynchronous data, you can always just send breaks down the line to provide out of band data framing.
[22:27:03] <idiot2> why isn't there twisted triplet cables?
[22:27:09] <N1njaneer> Much easier and universal.
[22:27:52] <N1njaneer> Because it generally wouldn't be useful, unless maybe you're running three-phase power :)
[22:28:06] <idiot2> or at least a shield + twist pair?
[22:28:38] <idiot2> though that is not optimal
[22:29:05] <N1njaneer> Sometimes you'll have a shield or drain wire depending on topologies, yes, but that's generally used to help keep the ground potentials from floating too far apart at either end depending on what you are doing. Many times the shield or drain is only connected at one end.
[22:29:40] <idiot2> N1njaneer, i dislike the twist pair thing because of the need for a stable data transmission speed
[22:30:04] <idiot2> or at least a pll...
[22:30:08] <N1njaneer> Twisted pair has nothing to do with stable data transmission speeds.
[22:30:29] <N1njaneer> If you want an excellent in-depth reference for a lot of what you are asking about, I would reccomend Henry Ott's book on EMC Engineering as it goes over all of this at length.
[22:30:29] <idiot2> it does, if you use the std transmit method
[22:30:36] <idiot2> http://en.wikipedia.org/wiki/RS-485
[22:30:40] <idiot2> start stop bits...
[22:31:08] <idiot2> im not dumb thanks
[22:31:19] <N1njaneer> Don't confuse the protocol with the transmission medium.
[22:31:51] <N1njaneer> Or moreso Layer 0 with Layer 1.
[22:32:13] <idiot2> well the layer is rather limited with 2 digital wires
[22:32:18] <idiot2> and no gnd
[22:32:43] <N1njaneer> The point of twisted pair is that you do not require a ground.
[22:33:05] <N1njaneer> Differential signaling is used - the only thing that matter is if A>B or B>A
[22:33:11] <N1njaneer> Common mode noise is rejected.
[22:33:24] <N1njaneer> There is nothing inherent in that transport that prevents you from sending DC signal levels.
[22:33:37] <idiot2> and i can not use 2 pairs either because they may by skewed
[22:34:17] <N1njaneer> If you were passing through an AC-coupled medium or transport (for instance if you use LVDS in to an SFP port) then you HAVE to maintain a minimum data speed and observe NRZ things BECAUSE of the AC-coupling that forces you to do so.
[22:34:32] <idiot2> well yes
[22:35:12] <idiot2> and no
[22:35:41] <idiot2> at least if you use capacitive coupling, you will have a spike at whatever speed
[22:36:27] <idiot2> transformer coupling will cause short circuit at dc but that probably does not matter for the driver
[22:36:29] <N1njaneer> Not if you are using it as designed.
[22:36:48] <N1njaneer> Or rather intended
[22:37:40] <idiot2> what do you think if i'd use 2 pairs for clock data and send that way ?
[22:37:56] <idiot2> 1-1 wire from the pairs would be gnd
[22:38:06] <N1njaneer> I don't see why you would need to.
[22:38:28] <N1njaneer> When you can do all of it with a single pair.
[22:38:58] <N1njaneer> It could certainly be possible to that with two pairs, but you'll have an upper limit to speed based on skewing, etc.
[22:39:01] <idiot2> because i could send clock data style
[22:39:18] <N1njaneer> Just Manchester encode, or use any other self-clocking data scheme.
[22:39:55] <idiot2> i like SpaceWire more
[22:40:06] <N1njaneer> Do as you will, then :)
[22:40:20] <idiot2> N1njaneer,
http://en.wikipedia.org/wiki/Data_strobe_encoding
[22:40:32] <idiot2> you see this is not well suited for a single twisted pair
[22:41:22] <N1njaneer> Then don't use it.
[22:41:27] <idiot2> ;<
