Back
[00:19:28] <rue_shop2> JanC, there are also errors, for example, this datasheet says, quite clearly 0.1nf and they quite obviously mean 0.1uf
[02:14:55] <rue_shop2> WOW THATS STABLE!
[02:15:06] <rue_shop2> I slapped togethor a UC3842 buck supply
[02:15:15] <rue_shop2> didn't even use a driver transistor
[02:15:35] <rue_shop2> 5.01V, rock stable (not tested to much current tho)
[02:16:11] <rue_shop2> , wrong channel
[09:45:52] <mux_> I am getting so pissed off at avr-libc now
[09:51:01] <clever> mux_: why?
[09:51:25] <mux_> I'm rewriting an old library (boot.h) to include xmega support right now
[09:51:43] <mux_> and it's a mess of unintelligible asm written in an age where apparently C was not invented yet
[09:52:11] <mux_> (also, there are 5+ versions of boot.h depending on who you are asking, and they all appear to be 'current')
[09:52:37] <clever> heh
[09:52:40] <mux_> I just felt like bitching to the void to relieve my anger :P
[09:54:10] <mux_> it just feels like in an age of pretty good toolchains and deterministic compilers, this mess of startup files, makefiles and assembly seems antiquated
[09:54:18] <mux_> really thinking of rewriting it into C entirely
[09:54:50] <clever> and i'm trying to jam assembly into an interupt routine, because i only have ~7 clocks between each interupt
[09:54:59] <clever> we are going in entirely different directions, lol
[09:58:12] <mux_> if you only have 7 clocks, why use interrupts? That's 4 clock cycles wasted on service jumps
[09:58:26] <mux_> (depending on what AVR you're using)
[09:59:42] <mux_> by the way, in boot.h the reason they're using assembly is (probably) to make timing deterministic, but the required timing really doesn't seem to justify messing with asm
[10:00:43] <mux_> there has to be at most 3 clock cycles between two operations (loading CCP with a magic number and executing the SPM instruction), which any compiler will always hit anyway...
[10:03:04] <clever> i'm trying to read a 3.072mhz bit-stream (it has its own clock, like SPI)
[10:03:43] <clever> so i need to shift the bits together into a 32bit value, buffer it, then write it out the SPI port
[10:05:26] <clever> the avr clock isnt an even multiple of the data clock, so i cant hard-code the loops
[10:05:55] <clever> and an while loop waiting on the clock edge feels like it would waste more cycles that i could spend buffering and sending
[10:08:47] <clever> i see the 4 clock delay you mentioned, i think that means the main loops is still running for those 4 clocks?
[10:09:00] <clever> causing the ISR to just sample in the middle of a bit, rather then the start, which helps
[10:10:24] <clever> ah, page 15 says it also uses those 4 clocks for pushing the PC
[10:10:41] <mux_> (sorry was making a sandwich)
[10:10:42] <mux_> yeah
[10:11:09] <clever> ouch, and another 4 clocks for reti
[10:11:29] <mux_> the while(1) loop is touched, and to do the context switch the AVR needs to shift over its stack which is a couple of bytes and thus takes a couple of clocks to do
[10:11:35] <clever> and i only have 6.5 clocks per bit of data
[10:11:38] <mux_> because the internal bus is only 8 bits wide
[10:11:48] <clever> yeah
[10:11:57] <mux_> what you're doing is much better suited to an XMEGA
[10:12:16] <clever> just trying to prototype it before moving to an fpga
[10:12:23] <clever> because i plan to do 8 of these in parallel
[10:12:27] <mux_> then you can just use the event bus and DMA, which puts data into an auto-incremented address
[10:12:44] <mux_> this is still microcontroller territory if you want to
[10:12:58] <mux_> fpga is going to be more expensive for such a 'slow' signal
[10:12:59] <clever> not when i start dealing with 77 million bits per second
[10:13:18] <mux_> wait, you were saying 3.072MHz x 8?
[10:13:23] <clever> yeah
[10:13:35] <mux_> 24ish MHz is doable, 77 isn't
[10:13:44] <mux_> is this a display controller or something?
[10:13:55] <clever> also, the 3.072mhz is just for testing, the end goal is 6.144mhz * 8
[10:14:00] <mux_> aaah
[10:14:01] <clever> audio processing
[10:14:14] <mux_> well then, fpga's the shit!
[10:14:19] <clever> exactly
[10:14:35] <mux_> have you looked at PSoC?
[10:14:41] <clever> nope
[10:14:49] <mux_> they're a bit cheaper and easier to prototype this kind of stuff
[10:15:13] <clever> i think i can also cheat the prototype with just an 8 bit shift register
[10:15:20] <mux_> they have a very small pld-like segment that you can program
[10:15:24] <clever> convert the serial stream to an 8 bit wide parallel stream
[10:15:59] <clever> that will /8 the clock and skip the bit shifting mess
[10:20:37] <clever> a shift register would give me ~52 clocks per byte
[10:20:58] <clever> just a minor issue, the data is in 32bit samples, so id need to carefully control the latch line
[16:22:52] <Jartza> any opinions here?
[16:23:19] <Jartza> attiny85 and spi. my prev design has pull-up resistors on spi (output only), but the pins are push-pull in output-mode, aren't they?
[16:23:28] <Jartza> so those pull-ups arent necessary?
[20:20:21] <Jartza> hmmh
[20:20:28] <Jartza> sigh
[20:20:42] <Jartza> 4 hours and I need to wake up to go to work :)
[20:20:47] <Jartza> and I'm not even sleeping yet
[20:21:03] <Casper> baseball bat
[20:21:37] <Jartza> drew my first.. or second schematics again once more
[20:21:42] <Jartza> now it's 3rd then
[20:22:27] <Jartza> basically first device I ever do schematics for, still the same device
[20:22:43] <Jartza> a bit of a learning, but now it's at least readable to my eyes :D
[20:22:55] <Jartza> and not something that the spider did on LSD
[20:23:18] <Casper> it'S amazing to see how hard it is to make a good looking schematics
[20:23:39] <Jartza> and educating
[20:24:09] <Jartza> one starts to appreciate good schematics much more
[20:24:29] <Jartza> I'm not saying this is still good, but it's better than it used to be :)
[20:24:53] <Jartza> https://www.dropbox.com/s/yhjn4in1o1ru6ec/tagsu_v3.pdf
[20:25:01] <Jartza> ...if someone wants to take a look
[20:27:39] <Jartza> yeah, it's simple, but one has to start from something
[20:39:07] <Jartza> but, now time for sleep
[23:30:22] <UnKnOwN|> Anyone can point me in the right direction for getting these two things to work together??
[23:30:23] <UnKnOwN|> Arduino Yun - Linux (BusyBox v1.19.4) w/ TP-Link TL-WN722N USB Adapter [Linux Driver: 'ath9k_htc']
[23:34:57] <rue_mohr2> hmm
[23:35:17] <rue_mohr2> wifi adapter?
[23:35:44] <umquant> anyone here use cmake with their avr/embedded projects
[23:36:38] <rue_mohr2> cmake?
[23:37:03] <umquant> yup,
http://en.wikipedia.org/wiki/CMake
[23:37:22] <evil_dan2wik> CakeMake
[23:50:15] <UnKnOwN|> rue, yes wifi usb