Back
[00:20:47] <dsal> OK. I consistently get 1 - 1.7µs now. I'll go with that. Still might be good to get rid of the interrupt.
[00:28:10] <dsal> Not totally sure how to get rid of this timer. I could count loop iterations that didn't detect a pin change, but I'm going to need more than 8 bits for that.
[00:28:54] <dsal> I need help. heh
https://usercontent.irccloud-cdn.com/file/Lw4A36JN/latency
[00:42:35] <dsal> I'm anding data coming in from pinb with ddrb = 1 -- do I actually need to do that?
[00:45:50] <Xark> dsal: Only once at boot.
[00:47:03] <Xark> dsal: Hmm...ANDing. Seems immediate may be a cycle faster. :)
[00:47:59] <dsal> I mean do I need to and if ddrb == 1? Like, will it also give me outputs?
[00:48:27] <Xark> I believe it is harmless to set other bits (if that is what you mean).
[00:48:37] <Xark> I do that in my video bit-banging crap. :)
[00:49:09] <Xark> (and require you to use bit 0 or bit 7 of a port shifting left or right)
[00:50:07] <Xark> (this is assuming other bits are all inputs)
[00:50:48] <dsal> No, I'm just detecting change of one pin. Want to make sure I'm not seeing my outputs.
[00:54:12] <cehteh> morning
[00:55:27] <cehteh> dsal: dont you think you are overoptimizing?
[01:05:27] <Xark> cehteh: Is there such a thing? :)
[01:21:25] <dsal> cehteh: I'm learning. I found that I can follow consistently faster polling, but the timing is less consistent.
[01:22:25] <cehteh> no isr's now?
[01:22:49] <dsal> I have the sync timer still.
[01:23:06] <dsal> Wasn't sure how to do that without the timer.
[01:23:07] <cehteh> you could remove even that
[01:23:32] <cehteh> and make each branch the the same time (possibly stuff with nops)
[01:23:52] <cehteh> when you have a constant time loop, then you can just increment a variable on each iteration
[01:25:22] <cehteh> timer would work too, but w/o interrupt, so you need to zero it at frame start in the loop
[01:25:39] <cehteh> 16bit timer then
[01:25:46] <dsal> This is where I ended up:
https://github.com/dustin/snippets/blob/master/avr/deppm/deppm.S
[01:25:47] <cehteh> do you have one?
[01:26:06] <dsal> Fast loop just checking for change
[01:26:17] <dsal> No 16 bit timer
[01:26:23] <dsal> This is tiny 85
[01:27:27] <cehteh> how about stuffing everything into one big loop, nothing else? .. do it in C as proof of concept
[01:28:28] <dsal> I can burn cycles on change since it won't change again soon.
[01:29:37] <dsal> Not sure what that loop is. The hardest part for me is knowing when to switch outputs.
[01:30:20] <cehteh> not really
[01:31:31] <cehteh> you just have a array of timestamps and what outputs to toggle
[01:31:37] <cehteh> keep that array sorted
[01:31:53] <dsal> Oh, that's a different problem.
[01:32:03] <dsal> That's the one I *should* be solving.
[01:32:15] <cehteh> hint: mergesort is constant time
[01:33:08] <dsal> This code doesn't deal with time, it just follows a ppm stream and outputs the channels over different outputs.
[01:33:12] <cehteh> then you just if (time >= timestamp_in_array) PORTB |= toggle_bits
[01:33:24] <cehteh> then even easier
[01:33:30] <dsal> I do actually want to emit pwm. Where do you get time?
[01:33:47] <cehteh> you dont need to store state at all
[01:34:00] <cehteh> just have a bit shifting for the output
[01:34:12] <dsal> This one doesn't. I should've declared it done last night. Heh
[01:34:53] <dsal> The other one, though. Turn up all the bits and then turn them down as time passes.
[01:35:13] <dsal> Oh, that's the 16 bit timer you were talking about.
[01:35:49] <cehteh> yes forget about that
[01:36:09] <cehteh> you just toogle as signals come in
[01:36:18] <dsal> I can get 1us/tick in a 16 bit timer, right?
[01:36:31] <dsal> Yeah, two different programs.
[01:36:56] <cehteh> 0.125µs/tick
[01:37:03] <cehteh> timer /1
[01:37:10] <dsal> The one I worked on the last couple nights reads ppm and emits pwm. That was done last night.
[01:37:13] <cehteh> thats what i am using for parsing cppm
[01:37:31] <dsal> It fits 2ms in 16 bits?
[01:37:41] * dsal can't math
[01:37:45] <cehteh> 8 something
[01:37:51] <dsal> Oh, cool.
[01:37:58] <cehteh> but frame length is 27ms
[01:38:02] <cehteh> my timer can cope with that
[01:38:18] <dsal> Sure. I'm not touching ppm in the other thing.
[01:38:19] <cehteh> its bit more elaborate
[01:38:35] <dsal> I've got numbers and just want to spit out pwm
[01:38:51] <cehteh> using the input capture, filtering inputs, storing them into a channels[8] array where the user can pick them up
[01:38:57] <cehteh> much more than you need to do
[01:39:19] <dsal> But I get them every 9ms, so I can't do it sequentially, even if that were desirable.
[01:39:21] <cehteh> because of input capture timing isnt that critical
[01:39:43] <cehteh> why not?
[01:39:58] <dsal> I almost understood input capture a couple days ago. Haven't needed it yet.
[01:40:12] <cehteh> it makes such things much simper
[01:40:24] <dsal> I can't do 8 channels of 2ms in 9ms
[01:40:39] <dsal> Unless I do them at the same time.
[01:40:53] <cehteh> i thought you want only 4
[01:41:00] <dsal> Harder, but what I need in the end.
[01:41:17] <dsal> Well, yeah, I could just do 4
[01:41:35] <cehteh> where do you get the 9ms from?
[01:41:48] <cehteh> didnt know that any rx uses that short frames
[01:41:51] <dsal> That's how frequently radio packets come in
[01:41:59] <cehteh> what system is that?
[01:41:59] <dsal> D8 does
[01:42:02] <dsal> Frsky
[01:42:05] <cehteh> no
[01:42:23] <dsal> Yeah, I just wrote all that.
[01:42:33] <cehteh> ah your own thing
[01:42:44] <dsal> https://usercontent.irccloud-cdn.com/file/s1Hdcx0L/SUMD
[01:43:06] <dsal> The blue is d8 packets from my taranis
[01:43:25] <cehteh> i have d4r's here standard is iirc 18ms with the optional 27ms firmware
[01:43:46] <dsal> That's ppm
[01:43:49] <cehteh> yes
[01:43:55] <dsal> It gets updates every 9ms
[01:44:15] <dsal> Except it skips every fourth one for telemetry
[01:44:32] <cehteh> thats the raw protocol
[01:44:46] <dsal> Yeah. That's what I speak
[01:44:47] <cehteh> i am speaking what falls out of the d4r
[01:44:51] <cehteh> yeah ok
[01:44:59] <dsal> Sure. I'm building a radio.
[01:45:04] <cehteh> then you are a bit tight on timing
[01:45:31] <cehteh> also you possibly want to integrate few frames for smoothing and error correction
[01:46:07] <dsal> Well, it's all digital here and has a checksum and stuff. Should be OK.
[01:46:08] <cehteh> no wonder frsky uses stm32 .. :D
[01:47:07] <dsal> I'm doing OK with avr. Only real issue is sumd wants 115200 baud, which doesn't work out well at 8 or 16 MHz
[01:47:18] <cehteh> sumd?
[01:47:33] <dsal> The radio does a lot of the when.
[01:47:37] <dsal> Work
[01:48:06] <dsal> Sumd is graupner I think. Pretty good protocol.
[01:48:10] <inflex> lo folks
[01:48:19] <dsal> 16 bit checksum, 32 channels max
[01:48:45] <cehteh> btw on tiny85 you can/should switch to 16mhz
[01:49:00] <cehteh> pll ftw
[01:49:09] <Xark> dsal: Hmm, I think I can see a few cycles to shave from main loop...
[01:49:09] <dsal> Yeah, but 115200 doesn't divide well.
[01:49:25] <dsal> I don't understand pll... What do I lose?
[01:49:29] <cehteh> then bit more whats the next best freq 16.8?
[01:49:50] <dsal> Xark: heh. Oh yeah? I'm not sure about that andi...
[01:50:17] <dsal> Something like that. Maybe someone said 18.3?
[01:50:18] <Xark> dsal: AVR has no problem doing 115200 (even if not 100% perfect rate - 8 and 16Mhz are so much faster it is fine)
[01:50:22] <cehteh> not much needed for understandng the tiny85 has a pll which uses the internal 8mhz osc to generate a 64 mhz clock .. this then can be divided to give a 16mhz cpu clock
[01:50:36] <cehteh> just correct fuse bits and win
[01:50:38] <dsal> Xark: baud calculation complains
[01:51:04] <Xark> dsal: i am not sure what you mean, I have used 115,200 all the time (and up to ~1Mbps)
[01:51:11] <cehteh> also i am OSCCAL on the 27ms frames you may do that with your 9ms frames (or multiples of them)
[01:51:50] <Xark> dsal: Do you only have one input pin on port B?
[01:51:53] <cehteh> Xark: but he has no uart on tiny85
[01:52:09] <dsal> Xark: it's not the speed, just how it computes. I can't do 250k with no complaints. Just doesn't divide evenly for 115.2
[01:52:24] <dsal> Xark: yeah
[01:52:27] <Xark> cehteh: Well for output it is fine (semi-bit banged though)
[01:52:47] <cehteh> dsal: just adjust the clock to a better suitable freq
[01:52:50] <Xark> dsal: Well, only need to be within ~2%. :)
[01:53:17] <dsal> Xark: yeah, it says it gets like, 3.5% at 16MHz
[01:53:19] <cehteh> you want to calibrate it anyway, else your pwm stuff would be off
[01:53:59] <dsal> Hmm. I have to learn this stuff next.
[01:54:22] <cehteh> http://wormfood.net/avrbaudcalc.php
[01:55:25] <Xark> dsal: Here is my idea
http://hastebin.com/igigiyemuy.avrasm
[01:55:34] <dsal> Wow. Neat. Yeah, 18.432
[01:56:17] <cehteh> 16.6mhz is fine
[01:56:59] <Xark> dsal: On ATTiny85 might as well run ~20MHz. :)
[01:57:06] <dsal> Xark: that's neat. I'll try that when I'm not in bed. :)
[01:57:11] <cehteh> you only get ±1% with OSCCAL anyway
[01:57:33] <dsal> What does osccal do?
[01:57:41] <cehteh> calibrate the clock
[01:57:49] <dsal> To what?
[01:58:13] <cehteh> kindof throttle control for the clock :)
[01:58:24] <Xark> dsal: Like fine tuning the RC timing (but it can be abused to overclock). Also the PLL....
[01:58:40] * dsal finds data sheet
[01:58:56] <cehteh> i am telling that to you since days
[01:59:00] <Xark> dsal: For example, if you get UUUUUU over a UART, it will be a square wave and an ATTiny can use that to calibrate its RC for accurate timing (VUSB uses that trick).
[01:59:11] <cehteh> lets say you want to run at 16.6Mhz ..
[01:59:37] <cehteh> your 9ms pulses are crystal stabilized right? they come from the receiver
[02:00:01] <cehteh> so you can time this 9ms pulses and adjust the OSCCAL value to met what you expect
[02:00:06] <dsal> Yeah, but I'm still polling them.
[02:00:14] <cehteh> (with some deadband, OSCCAL is somewhat coarse!)
[02:00:14] <dsal> Oh, I see.
[02:00:36] <Xark> dsal: Yeah, RC is not to be trusted much (but it is useful to calibrate it every so often in some cases).
[02:00:37] <cehteh> thats what i am doing in my cppm driver
[02:01:09] <dsal> Triggering is hard on this particular radio because it doesn't have a dedicated pin to poke the mcu
[02:01:15] <cehteh> Xark: even if his RC timing isnt exact, its his timebase in any way
[02:01:30] <cehteh> triggering?
[02:01:35] <Xark> cehteh: Yes, in his case. So he will want to keep polling in some way
[02:01:46] <cehteh> no need for polling
[02:01:47] <dsal> The radio can raise a pin when it gets a packet.
[02:02:05] <dsal> The chip that is. But it's not available on this board I got.
[02:02:12] <cehteh> just do that along with your normal work
[02:02:34] <cehteh> well you want to do that all the hard way :D
[02:02:37] <dsal> So it has a secondary way using the miso pin, I think.
[02:02:44] <cehteh> and tiny85 has no input capture .. too bad
[02:03:08] <cehteh> (me plans to rewrite the cppm to use PCINT too .. but that will be much less precise)
[02:03:15] <dsal> I'm probably building on m328p
[02:03:25] <cehteh> look at tiny84
[02:03:43] <dsal> I ported that to t84 just because
[02:03:44] <cehteh> its small, cheap, has 16bit timer and input capture and few more pins
[02:03:52] <dsal> Er, 85
[02:03:56] <cehteh> (but no pll .. 8mhz max on internal osc)
[02:04:21] <cehteh> yes thats why i am saying look at tiny84 .. might be be useful
[02:04:28] <cehteh> thats what i am using for this thing
[02:04:37] <dsal> Man. So many chips. I want to port one of my things to t4
[02:05:04] <Xark> t4?
[02:05:40] <cehteh> the input side of the ppm thing is really the simplest problem .. output that stuff willl become tight, esp when you have 9ms frames
[02:06:28] <dsal> Xark: attiny4 - sot23-6
[02:06:31] <cehteh> you dont have enough hardware pwm (would need 4x 16 bit hw pwm .. noway)
[02:06:52] <cehteh> and in software you cant use interrupts, that would be too much jitter
[02:06:58] <dsal> cehteh: the radio signal is digital. I just read stuff over spi
[02:07:12] <cehteh> thats the graupner thing now?
[02:07:20] <Xark> dsal: I see. Like this
http://electronut.in/attiny10-hello/ :)
[02:07:21] <dsal> No, that's my output
[02:07:29] <cehteh> ok
[02:07:32] <dsal> D8 is digital from the radio
[02:07:54] <cehteh> i am still at rrm to pwm
[02:07:57] <cehteh> ppm
[02:08:00] <dsal> Frsky uses a cc2500 spi that does a lot of the work
[02:08:05] <cehteh> ok
[02:08:42] <dsal> I was thinking about outputting that signal in pwm for one radio build
[02:09:01] <dsal> I do sumd only today.
[02:09:18] <dsal> So I have no timing issues anywhere (except baud rate)
[02:12:50] <daey> im trying to interface with an SD Card. Atm. im trying to get the writing to work, it kinda does already. but im not sure how i have to send the data after CMD24. if i send 1024x0xAA. I get 1byte of 0xAA on the Card. but 512x 0xAA should be sufficient for that.
[02:13:51] <daey> that gave me the idea that i maybe need another dummy frame after each Data byte. so i send 512x 0xAA, 0xFF. and guess what i get on the sd card... a nice 0xAA 0xFF pattern :p
[05:15:56] <theBear> i got a hd like that, problem is some of the aa's don't go away if you write something else to it
[06:05:05] <LeoNerd> Well, this is novel. I ordered 10m of 3core signal cable. It has arrived in a wound-up bundle that appears to have not the traditional two, but in fact four ends to it
[06:05:54] <LeoNerd> Ah I think I see what they've done. I appear to have 2 5m pieces
[06:06:32] <Lambda_Aurigae> so, it's a variable air hop cable.
[06:15:10] <LeoNerd> Actually now I measure it, I've got one 4.5m piece and one just-over-8m piece. So I've got about 13m of cable, when I only ordered 10. So bit of a mixed bag really
[06:19:37] <Lambda_Aurigae> I would throw a fit personally.
[06:20:02] <Lambda_Aurigae> maybe get them to send me the right one and not bother to ask for the others back.
[06:21:50] <cehteh> now you know what the Terms of Service mean with "Order might be split into serveral parts"
[06:48:20] <GeneralStupid> Hi can anyone tell me how ASF has implented the rs-232 flow control?
[08:33:20] <cehteh> isnt the source available?
[08:48:58] <hetii> I just finish my AVR programmer based on esp8266
https://bitbucket.org/hetii/espstk/ anyone who want to contribute it is welcome :)
[10:53:19] <LeoNerd> Ohjoy.. added to all the other fun about what the various AT* chips have on timers; it seems there's some interesting fun around all the various PWM modes and whether they can achieve 0% or 100% output
[10:53:39] <LeoNerd> E.g. phase-correct PWM mode can do full off or full on; but fast PWM cannot
[10:56:51] <liwakura> i'd like to know why
[10:57:05] <liwakura> i guess its somehow written in the datasheet
[11:20:27] <cehteh> yes
[15:42:11] <daey> my spi appears to be very slow. im using an atmega328p @14...Mhz. a _delay_us(100) results in a 100us delay. The SPI clock divider is set to /2. But im getting 950ish khz spi clock
[15:46:08] <daey> that results pretty much in a /16 division
[15:47:50] <antto> how do you measure it?
[15:49:13] <antto> the clock rate may be fast, but if you have silence "gaps" between the bytes, depending on how you measure it, that can result in lower overal frequency
[15:49:50] <antto> if you have a scope - zoom-in on the clock to see
[15:50:09] <liwakura> hm, spi clock may be in bits/cycle, so if you have prescaler 2 and accidentally measure bytes/cycle, you would get that 950kHz
[15:50:23] <liwakura> factor 2 * 8 = 16
[15:58:56] <daey> liwakura: im looking a a logic analyzer data dump. one clock cycle are 1.083uS. which is 923khz
[15:59:11] <daey> liwakura: is your name related to lain iwakura?
[15:59:32] <liwakura> you might want to join #lainchan
[15:59:35] <daey> :O
[15:59:50] <liwakura> its exactly what you think its about.
[16:11:14] <liwakura> one of us. one of us.
[16:20:14] <daowee> Oxford Town, Oxford Town, tis evr'ybody's going-on chan. (sorry. it works OK if you've heard the tune, probably)
[18:36:51] <carabia> Hmm. I haven't been here in months. Maybe even a year. Is that guy still going around here who was gonna sue the state for $M's cause the cops busted him with pot while driving?
[18:37:25] <carabia> He was also doing some sort of assembler stuff and he was bitching about atmel studio not letting him do something
[19:25:31] <Jartza> never heard
[19:25:46] <Jartza> I do assembly stuff too. I make it do what I want :)
[21:59:31] <dsal> Xark: I tried out your eor thing -- problem is that it does see itself, so I still need the andi to isolate the pin change. That's annoying. if I only got what was DDR'd, this would work quite well.
[22:52:47] <Emil> Anyone submitted patches to avrdude and avrgcc?
[22:52:54] <Emil> and so forth
[22:53:18] <Emil> I'd really like to push the support to atmega328pb there since it's rather trivial
[23:13:45] <Xark> dsal: What do you mean "see yourself"? Also, I wouldn't think that would matter unless what you "see" changes (other than input pin).
[23:14:26] <dsal> I'm writing out on that part. AFAICT, I'm getting stuff I'm writing when I read PINB
[23:17:22] <Xark> dsal: I see. One option is to load "prev" right before the loop (so you are okay with whatever other bits written)
[23:17:37] <dsal> Yeah. That's a good point.