Back
[00:46:26] <inflex> mmm....strtoi ?
[00:46:41] <inflex> ah strtol
[00:47:07] <inflex> so, int = strtol( "0010101011010101010", NULL, 2); ?
[00:57:51] <Casper> sorry found it... but I have issue now<
[00:58:50] <Casper> 000110000011100000000011000001010010 -> 1111111111111111111111111111111110000011100000000011000001010010
[00:59:13] <Casper> and it's strtoll
[01:02:47] <Casper> inflex: can you take a look at my code and see if you see something wrong? PC code, not avr, yet
[01:03:06] <Casper> https://bpaste.net/show/0ac170d4e147 <=== the code
[01:04:10] <Casper> https://bpaste.net/show/76316a4cb0cc <=== the result
[01:09:42] <inflex> yep, tab is a single char and strtok won't understand the string "\t"
[01:09:51] <inflex> should just be char tab = '\t';
[01:10:14] <inflex> instead strtok will be splitting on \ and t characters
[01:10:41] <Casper> the split is fine
[01:11:14] <Casper> it appear to really be the issue with strtoll...
[01:12:29] <inflex> I'm amazed that strtok worked
[01:14:56] <Casper> OH DUH
[01:15:03] * Casper checks something
[01:15:45] <Casper> the token is a char
[01:15:55] <Casper> could that be the issue?
[02:26:15] <cehteh> grr.. ok stupid bug, serial transmission buffer overflows when just echoing back the input, forgot that each "\r" gets translated to "\r\n"
[02:37:30] <Xark> I have been bitten by that before. :)
[03:30:53] <cehteh> Xark: you dont just happen to have a clever idea how to work around that?
[03:31:33] <Xark> cehteh: It is actually a tough problem, since (I assume) you have no handshaking.
[03:32:19] <Xark> Even if you got rid of '\r' -> '\r\n' it still can (eventually) fail if RX data is even minutely faster than TX data.
[03:32:56] <Xark> I finally solved this on a FPGA by detecting the "bit drift" and dynamically adjusting TX clock (to send slightly faster to make sure it was >= RX rate).
[03:32:59] <cehteh> i may implement that later but i just thinking if there is some way to either make the sending side sending \r\n (or other fill chars) as well
[03:33:32] <Xark> cehteh: That seems easy if you control that side.
[03:33:35] <cehteh> i have some queues for rx and tx, actually it will become even double buffered later
[03:33:59] <Xark> A queue only delays death (if RX faster than TX). :)
[03:34:01] <cehteh> and echoing back bulk data is some corner case anyway
[03:34:13] <Xark> Yep
[03:34:40] <cehteh> well i had it on another controller that copy-paste configuration into the cli overflowed
[03:34:43] <cehteh> thats exactly the case
[03:34:59] <Xark> cehteh: Another easy fix is to add a small delay in sending side (like at end of line).
[03:35:40] <cehteh> but my question was rather if there is some really clever solution which fixes that, guess not
[03:35:57] <cehteh> maybe i just add xon/xoff soon
[03:36:30] <Xark> cehteh: It is kind of a fundamental problem. Handshake is "best" fix. You can also slightly "goose" TX rate (usually serial is fine up to 2% off).
[03:36:45] <Xark> Like RX at 9600 and TX at 9601
[03:36:54] <cehteh> huh .. how that?
[03:37:30] <cehteh> i mean i am using duplex transfers, there is only one baudrate setting
[03:37:31] <Xark> Just set baud to 9601 (e.g. or slightly fast).
[03:37:39] <cehteh> ah good idea
[03:37:40] <Xark> You don't directly control RX rate.
[03:37:45] <cehteh> yes
[03:37:47] <cehteh> thats it
[03:37:54] <cehteh> well maybe its not it
[03:38:08] <cehteh> because it doesnt fix it really
[03:38:18] <Xark> That helps with 1:1 echo when TX is slightly fast, but not the \r -> \r\n problem
[03:38:57] <cehteh> for a test for example i just did yes >/dev/ttyUSB1 ... that gives 30% more traffic
[03:39:09] <cehteh> yes it doesnt really fix anything
[03:39:35] <Xark> I suspect +1 isn't enough to cope with 10 extra bits for \r
[03:40:04] <cehteh> maybe i should measure the receiving rate and adjust to that
[03:40:30] <Xark> You really need to remove output \r expand (or you can try adding a bit more...but eventually will give receive issues).
[03:40:45] <cehteh> besides on a modern computer i expect the baudtrates quite close to the norm
[03:41:07] <Xark> cehteh: That is exactly what I did on FPGA, probably more tricky on AVR (but I bet doable - just measure cycles per UART byte).
[03:41:37] <Xark> cehteh: I was surprised how off FTDI was (at least vs FPGA xtal). :)
[03:42:09] <Xark> Also, as I mentioned, with direct echo, even 1 ns faster RX vs TX will accumulate.
[03:42:45] <Xark> Adding a stop bit (or additional stop bit) on RX will also give you a "cushion" on each byte.
[03:44:20] <cehteh> well the buffers here should be enough crushion, even if its only few byte buffers, but i may change the baudrate to 0.5% more
[03:44:47] <Xark> cehteh: Yes, those will help (as long as you eventually pause sending).
[03:45:38] <cehteh> its mostly meant as CLI so it will not satuate the link under 'normal' circumstances
[03:45:48] <cehteh> even if a gui gets connected there are pauses
[03:45:48] <Xark> Sounds good.
[03:46:18] <Xark> In my UART stress test, I was echoing a ~4MB file (and checking returned data exactly matched).
[03:47:15] <cehteh> yes that can not work if you balloon the send back data with \r -> \r\n translation
[03:47:55] <Xark> Yeah. I fixed that issue (with terminal program), but as I mention, I still had eventual issues when RX was minutely faster than TX.
[03:48:24] <cehteh> yeah i add a config setting to increase tx rate by a little bit
[03:48:34] <Xark> (which I fixed by dynamically speeding up TX when it detected it was falling behind - easier on FPGA where I could just check "bit time").
[03:48:34] <cehteh> thats prolly a good idea in either case
[03:49:02] <Xark> Yeah, simple solution that is mostly effective.
[03:49:37] <cehteh> (9600 * 1005) / 1000 = 9648
[03:49:46] <cehteh> wow 0.5% is already a lot :D
[03:49:59] <Xark> But UART is fairly robust.
[03:50:11] <Xark> (before bit sample falls out of bit window)
[03:50:21] <cehteh> +/- 2% should be a safe tolerance adding 0.5% wont fail
[03:51:10] <Xark> Yep.
[03:52:29] <cehteh> anyway like i saied things becomeing double buffered here, small circular buffers for the interrupt handlers and some more clever buffering for real data, that is RX gets a lineedit, maybe even with completion and history, tx gets a tagged queue where one can push things somewhat compressed
[03:53:13] <cehteh> aka integers/floats are put into binary form on the queue, string and progmem strings are put there as pointers and so on
[03:54:22] <cehteh> so tx should have a higher capacitiy then it need memory and work asynchronously, but still that doesnt help when one satuates the link in TX direction
[08:56:31] <LeoNerd> http://www.gearbest.com/development-boards/pp_18643.html <== does anyone have, or recognise this ATmega128 devboard?
[08:56:44] <LeoNerd> I've just received one. It has two jumpers on it but I can't quite work out what the second one is for
[08:57:26] <LeoNerd> The 3pin jumper lower down is for switching between onboard or external crystal, but I can't see what the top 2pin one is for
[09:06:48] <Lambda_Aurigae> never seen it.
[09:06:58] <Lambda_Aurigae> maybe it's for disconnecting one of the LEDs?
[09:07:02] <Lambda_Aurigae> time to get out the meter.
[09:07:08] <aandrew> hah
[09:07:10] <Lambda_Aurigae> see where it goes.
[09:07:37] <aandrew> that looks like a FX2LP dev board (it's clearly not but the same buttons and I/O positions)
[09:07:38] <Lambda_Aurigae> one should probably make sure the website for gear one buys is in a language one can understand.
[09:08:06] <aandrew> http://www.gearbest.com/fx2lp-_gear/
[09:11:40] <LeoNerd> The LEDs are on PA0 and PA1
[09:12:15] <Lambda_Aurigae> I don't see that board anywhere on www.lcsoft.net either.
[09:12:30] <LeoNerd> The jumper is labeled PO or maybe P0
[09:12:35] <Lambda_Aurigae> so, get out the meter and check out where things go.
[09:13:10] <LeoNerd> But that's in the garage and it's cold and wet out there
[09:13:26] <Lambda_Aurigae> shit happens.
[09:13:33] <Lambda_Aurigae> get out a battery, some wire, and an LED.
[09:13:38] <Lambda_Aurigae> and do the same thing.
[09:13:54] <Lambda_Aurigae> or, don't buy chinese knockoff shit
[09:16:04] <LeoNerd> Ahah. so one end is just on the grounding plane, and the other goes to the LEDs.. Yah; it takes out the LEDs
[09:16:28] <Lambda_Aurigae> how was that for a guess?
[09:17:38] <LeoNerd> :)
[11:15:35] <nuxil> on a ATtiny85 .. what the best way to check if pin inputs has been high for n seconds ? lets say i need to check if two pins are high for 500ms, 1/2 sec or soemthing like that then do something,
[11:15:51] <nuxil> i tried doing something like this.
http://pastebin.com/jFP2m7KQ but im a noob when it comes to C.
[11:15:59] <nuxil> it kind of works.
[11:16:08] <nuxil> but its not working well
[11:16:21] <LeoNerd> I'd use a pinchange interrupt to know of state changes, start a counter when it goes high, and then if that counter reaches whatever value would be after 500msec, do the thing
[11:17:01] <nuxil> ok.
[11:17:59] <nuxil> but in my main while loop i have no delay.. so how do i know how long each "count" is taking ?
[11:18:07] <LeoNerd> Use a timer interrupt?
[11:18:21] <nuxil> can you give me and short code example
[11:18:49] <LeoNerd> Not terribly easily
[11:18:58] <LeoNerd> I have no idea what the rest of your system looks like
[11:19:11] <LeoNerd> Arduino? Straight C? Using avr-gcc? Atmel Studio?
[11:19:18] <LeoNerd> What's the rest of the program running?
[11:19:19] <nuxil> avrdude
[11:19:34] <nuxil> im on linux
[11:19:39] <LeoNerd> avrdude is the program that transfers the compiled binary into the actual chip
[11:19:49] <LeoNerd> Where do you get that compiled binary from? Move earlier in the toolchain
[11:20:02] <nuxil> ah. avr-gcc
[11:20:14] <LeoNerd> Righty
[11:20:52] <LeoNerd> So doing that in "raw" code, you'd poke the various timer registers to set it up to do what you want, and have an ISR(...) on the compare or overflow interrupt appropriate to that timer
[11:20:58] <LeoNerd> Pick a timer, pick some numbers
[11:21:14] <nuxil> oh god..
[11:21:15] <LeoNerd> Personally I have little library wrappers around that kind of common task
[11:21:22] <nuxil> lol. i never done any of that ^
[11:21:32] <LeoNerd> Well now you have some starting points to learn it then
[11:23:11] <LeoNerd> There's a number of relatively arbitrary things to pick
[11:23:11] <nuxil> hmm .. im using the internal timer for the pwm on pb1.. i can use this timer right ?
[11:23:28] <LeoNerd> Eg you might decide to pick a timer interrupt period of 10msec, and then count up to 50
[11:23:38] <LeoNerd> or 1msec and count to 500, but then that's a 2-byte value.
[11:23:42] <LeoNerd> 2msec and count to 250?
[11:23:57] <LeoNerd> It's a tradeoff of accuracy vs. power usage / CPU time
[11:24:42] <LeoNerd> Or if you're not using the timer unit for anything else, maybe reset it back to zero on each pin transition and let it count to the full 500ms itself, then your interrupt tells you the end of the time
[11:24:57] <LeoNerd> Personalyl I like to keep faster "ticker" interrupts and maintain my own timers... but either's a valid technique
[11:25:32] <nuxil> a code example would be real handy :p
[11:25:37] <nuxil> i'll try to google a bit
[11:25:57] <LeoNerd> I can't write /part/ of a program that will work with the rest of /yours/
[11:26:05] <LeoNerd> I could show you an entirely new one of /my/ programs
[11:59:48] <LOMAS> hello there friends, does Timer0 of ATmega8 runs independently from interrupt ?
[12:01:05] <cehteh> what do you mean by run independently?
[12:01:12] <nuxil> LeoNerd, pls do. my google failed. hehe.. ended up on youtube watching EEVBlog ranting a bit :p
[12:01:14] <nuxil> https://www.youtube.com/watch?v=DBftApUQ8QI&t=18m37s
[12:01:17] <nuxil> ^^
[12:01:32] <cehteh> timers count in hardware, whatever your mpu does wont affect them unless you poke into their config registers
[12:02:24] <LOMAS> I mean, is there any affect on timer count if interrupt ISR is execuated ?
[12:03:05] <nuxil> i was just looking at that myself :)
[12:03:06] <nuxil> http://www.atmel.com/webdoc/AVRLibcReferenceManual/porting_1iar_porting_isr.html
[12:03:22] <cehteh> LOMAS: no
[12:03:37] <cehteh> (unless, i saied that, you poke in the timer registers)
[12:03:56] <LeoNerd> nuxil:
http://pastie.org/10667865 a bunch of copypasted bits and pieces of mine
[12:04:07] <LeoNerd> mine really live inside #ifdef blocks of course...
[12:04:22] <LOMAS> Thanks cehteh . I was confused before.
[12:04:37] <nuxil> LeoNerd, cool.. thanks
[12:22:20] <Jartza> hmmm
[12:22:23] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxeEpNd085cksyVFU/view
[12:22:26] <Jartza> dunno
[12:22:34] <Jartza> maybe I can't get 8 colors with attiny5 :)
[12:22:48] <Jartza> but 4 colors from 3 pins anyway
[12:22:50] <cehteh> not?
[12:23:44] <Jartza> ?
[12:23:54] <cehteh> i am disappointed in you :D
[12:24:01] <Jartza> :(
[12:24:30] <cehteh> quake in 4 colors would look ugly
[12:24:46] <Jartza> quake with attiny5 would look ugly anyway :D
[12:25:24] <cehteh> you may really consider RSTDISBL
[12:36:52] <Jartza> oh, RSTDISBL is of course in use
[12:36:59] <Jartza> that's how I get 3 pins on attiny5 ;)
[12:37:11] <Jartza> the other 3 are VCC, GND and oscillator
[12:38:51] <Jartza> and VGA needs hsync, vsync and colors
[12:39:08] <cehteh> ah forgot about osc
[12:39:45] <cehteh> ok guess you having fun
[12:40:22] <cehteh> has the tiny5 some ultra fast timer like some other tinys?
[12:42:28] <Jartza> nope
[12:42:43] <Jartza> cpu clock max
[12:43:27] <LeoNerd> Very few AVR chips have a faster-than-CPU timer
[12:43:35] <LeoNerd> The only one I've seen is the PLL-based one on the 32U4
[12:44:12] <Jartza> attiny85 ;)
[12:44:15] <cehteh> the tiny25 45 85 have that
[12:44:19] <Jartza> yea
[12:44:20] <Jartza> 64MHz
[12:45:09] <cehteh> in some ways this tiny25-85 are amazing .. they have some features i miss on mega328
[12:45:25] <Jartza> yeah
[12:45:25] <LeoNerd> Ohyes, hmm... Ididn't notice that
[12:45:28] <cehteh> differential adc w/ gain amplifier ..
[12:45:42] <cehteh> some megas have that but not the 328
[12:46:08] <LeoNerd> Jartza: Yah; I've sometimes wanted a ./configure-avr --with-timer16 --with-interrupts=2 --with-uart ...
[12:46:30] <cehteh> well tinys lack the 16 bit timer
[12:46:35] <LeoNerd> It'd be nice just to get a custom chip with just the periphs. I want in just the right places :)
[12:46:49] <cehteh> and only USI no USART
[12:47:28] <cehteh> but i guess Jartza would course it there would be a usart, usi is more versatile for the veega
[12:47:28] <LeoNerd> tiny84 has a 16bit timer
[12:47:36] <LeoNerd> tiny841 has two(I think). and two real UARTs
[12:47:47] <LeoNerd> tiny1634 is crazy... don't look there
[12:47:57] <cehteh> its not tiny anymore? :)
[12:48:32] <Jartza> attiny5 has 16-bit timer
[12:48:35] <Jartza> but only one
[12:49:09] <LeoNerd> The AT"tiny"1634 isn't really tiny, nop
[12:49:21] <Jartza> tiny doesn't have MUL
[12:49:41] <Jartza> then, attiny1634 is tiny :)
[12:49:43] <LeoNerd> 16Ki flash, 20pin package w/ 17(18) IOs, 8ch ADC, two UARTs, a real I2C slave,...
[12:49:55] <cehteh> LeoNerd: woah 12 channel adc .. using all ping
[12:49:56] <cehteh> wtf
[12:50:01] <cehteh> pins
[12:50:03] <Jartza> but yea, that's quite nice for tiny
[12:50:14] <Jartza> cehteh: well, attiny5 doesn't have usi, nor uart :D
[12:50:22] <Jartza> ...nor spi
[12:50:24] <LeoNerd> It doesn't come in a DIP form though
[12:52:01] <cehteh> LeoNerd: do you know any avr which has more than 1 analog comparator?
[12:53:02] <cehteh> muxing adc and having some patience sampling data is ok, but muxing analog comparator feels like one doesnt really want to do it
[12:53:07] <LeoNerd> I think I saw a recent ATmega with two of them
[12:53:22] <cehteh> i once did for my ne555 emulation
[12:53:27] <LeoNerd> AC0 can mux over its own input pins or the ADCoutput, whereas AC1 aws just its own pins
[12:54:09] <cehteh> when you want the comparator as reliable interupt source then muxing is prolly a nogo
[12:54:49] <cehteh> (unless you know in advance that it wont trip for some time)
[12:54:53] <nuxil> LeoNerd, im having a blast, still no idea what im doing but its fun :p was suring up and down the manual and noticed the watchdog. isnt that a suted timer to use for my thing ?
[12:55:11] <LeoNerd> Not really
[12:55:21] <nuxil> why not?
[12:55:27] <LeoNerd> the WDT is for high-reliability concerns to ensure your program doesn't crash entirely. Or rather, when it does, restart the entire chip
[12:55:36] <nuxil> oh
[12:56:00] <cehteh> oh one can abuse the wdt as slow timer :D
[12:56:32] <cehteh> one timer for free when the others are used
[12:56:35] <nuxil> yea for looking at the manual
[12:56:59] <LeoNerd> You -can-
[12:57:04] <LeoNerd> I've seen it used as an entropy source even :)
[12:57:08] <LeoNerd> It's just not the bset thing to use
[12:57:10] <cehteh> yes
[12:57:34] <cehteh> well in future projects i consider using it as watchdog as it should be
[12:58:23] <cehteh> but if you need a slow blinking led and used up all timers and code space just toggle a pin in the wdt isr hits the spot
[12:58:55] <LeoNerd> I don't ever run out of timers. What I do is I decide on a system "tick" frequency (often 5msec) and use the ISR for that to maintain multiple "tickers" in my code
[12:59:04] <LeoNerd> Each of those has its own count limit + function
[12:59:08] <LeoNerd> so I could have tens of those even
[12:59:24] <cehteh> yeah thats what i am doing now with my scheduler
[12:59:50] <cehteh> gives one world clock where you can hook in a lot things
[12:59:59] <LeoNerd> Mhm
[13:00:08] <LeoNerd> Even on chips with multiple timers I often just use the one for this
[13:00:18] <cehteh> later also a queue for very long times .. aka calendar
[13:00:21] <LeoNerd> I kept the second one spare to possibly make a beeping noise on a spare PWM pin
[14:18:07] <studdentt>
[14:19:20] <Lambda_Aurigae> love my pic32 core timer.
[14:31:46] <Jartza> yea
[14:31:47] <Jartza> wat
[14:31:48] <Jartza> https://www.youtube.com/watch?v=8YRBR0Kb5ig
[14:32:52] <Lambda_Aurigae> supposed to look like that?
[14:33:23] <Jartza> well. I just tested the horizontal offset routine, which seems to work
[14:33:32] <Jartza> the "scroll" was unintentional :D
[15:04:14] <Jartza> https://www.youtube.com/watch?v=azcZexai4JU
[16:35:17] <studdentt> what is the best program to use so that: an analog value is read by the uC, results sent to the computer through UART and write the values in a file?
[16:36:06] <Lambda_Aurigae> a program written to do what you want.
[16:36:08] <studdentt> with linux, can i redirect the output of a serial terminal to a file saved on the computer ?
[16:36:33] <Lambda_Aurigae> cat /dev/ttys1 > /home/me/file.txt
[16:40:59] <studdentt> Lamba_Aurigae: you need to set baudrate no ?
[16:41:08] <studdentt> can't do that with cat
[16:41:08] <Lambda_Aurigae> yes.
[16:41:10] <Lambda_Aurigae> setserial
[16:41:26] <Lambda_Aurigae> you didn't ask about setting serial baudrate.
[16:41:40] <Lambda_Aurigae> you asked about directing serial port to a file.
[16:41:44] <studdentt> right
[16:42:24] <Lambda_Aurigae> ask the right questions and get the right answers.
[16:46:48] <Jartza> heh
[16:46:50] <Jartza> or python
[16:46:53] <Jartza> would be very easy
[16:47:20] <Lambda_Aurigae> that requires python.
[16:49:13] * nuxil likes python
[16:49:39] <Lambda_Aurigae> it's just another high level language.
[16:49:39] <nuxil> 99.9% of linux distros comes with it anyway
[16:49:46] <Lambda_Aurigae> like php or perl or any other.
[16:49:57] <Lambda_Aurigae> an interpreted scripting tool.
[16:50:21] <Lambda_Aurigae> this generation's version of BASIC
[16:50:36] <Lambda_Aurigae> powerful, yes.
[16:50:54] <nuxil> this generation of basic?
[16:50:59] <Lambda_Aurigae> but one of a few dozen out there.
[16:51:11] <Lambda_Aurigae> everybody has their favorite.
[16:51:11] <nuxil> python is rather old vs other scripting languages
[16:51:21] <nuxil> or languages in general
[16:51:45] <nuxil> 94 or something it was released
[16:52:21] <nuxil> so i would not call it tis generations basic :p you missed out on one .p
[16:52:53] <Lambda_Aurigae> BASIC is older still.
[16:52:59] <nuxil> hell its older than java. ;p
[16:53:06] <nuxil> python tho
[16:53:08] <nuxil> .
[16:53:16] <nuxil> yeah ofc it is
[16:53:18] <Lambda_Aurigae> 1991 is when python was first released.
[16:53:27] <nuxil> its a dinosaurus like C
[16:53:41] <nuxil> oh.. missed a couple of years :p
[16:53:50] <Lambda_Aurigae> php is 1994 as I recall.
[16:54:42] <nuxil> then we have perl. ruby aswell.
[16:54:50] <Lambda_Aurigae> lots of new ones.
[16:54:52] <nuxil> idk when they where released
[16:55:56] <Lambda_Aurigae> I like csh myself.
[16:56:22] <Lambda_Aurigae> but,,,to each their own...everybody has their favirote.
[16:56:27] <Lambda_Aurigae> favorite
[16:56:34] <nuxil> yea
[16:56:38] <nuxil> mine is python :p
[16:57:15] <Lambda_Aurigae> mostly I just write stuff in C.
[16:58:09] <nuxil> :)
[16:59:14] <Lambda_Aurigae> which is why I've been rewriting picoC
[17:01:05] <nuxil> nice
[17:01:21] <Lambda_Aurigae> a C interpreter.
[17:01:34] <Lambda_Aurigae> that I've gotten to run on the atmega1284p and pic32mx270f256b
[17:02:38] <nuxil> thats cool
[17:02:52] <Lambda_Aurigae> using it to teach programming to kids.
[17:03:02] <Lambda_Aurigae> or, that's the plan eventually.
[17:03:10] <Lambda_Aurigae> like BASIC, only C
[17:03:55] <Lambda_Aurigae> we are going to make computers this summer.
[17:04:24] <nuxil> as in??
[17:04:27] <Lambda_Aurigae> using Jartza's vga controller for output.
[17:04:36] <nuxil> oh
[17:04:37] <Lambda_Aurigae> recreating the C-64 era computer.
[17:04:38] <Jartza> yay
[17:04:39] <nuxil> cool
[17:05:10] <Jartza> that's a cool idea
[17:05:16] <Lambda_Aurigae> hopefully, a full screen editor like the C-64 world.
[17:05:29] <Lambda_Aurigae> with a C interpreter rather than a BASIC interpreter.
[17:05:46] <Jartza> that'll be very nice
[17:05:50] <Lambda_Aurigae> yeah.
[17:05:56] <Lambda_Aurigae> hopefully.
[17:06:29] <Jartza> talking about vga :D
[17:06:30] <Jartza> https://www.youtube.com/watch?v=LJOzUHDjLik
[17:06:32] <Lambda_Aurigae> the pic32 chips I'm playing with can access usb keyboard.
[17:06:39] <Jartza> that's now my "basic engine" for attiny5
[17:07:00] <Lambda_Aurigae> sweet.
[17:07:11] <nuxil> wow.
[17:07:12] <Jartza> engine 158 bytes, but with that "back'n'forth" sawing horizontal offset, 188 bytes
[17:07:17] <nuxil> to much lsd on you :p
[17:07:21] <nuxil> jk
[17:07:31] <Lambda_Aurigae> too much LDS in the 60s..
[17:07:32] <Jartza> lol :D
[17:07:49] <Jartza> Lambda_Aurigae: yea. LDS is the way!
[17:08:00] <nuxil> :\
[17:08:01] <Lambda_Aurigae> I did some in the 80s.
[17:08:06] <Lambda_Aurigae> it really fucked up my head.
[17:08:47] <Lambda_Aurigae> I vowed not to mess with that or any religion ever again.
[17:08:54] <Lambda_Aurigae> well,,,not to join anyhow.
[17:09:01] <Lambda_Aurigae> I still fuck with em every chance I get.
[17:10:08] <nuxil> i dont care much about religion.. leave me alone and i'll leave you alone with your own belivs :)
[17:10:18] <Lambda_Aurigae> I'm mostly the same way.
[17:10:24] <Lambda_Aurigae> but they keep trying to poke their noses into my life.
[17:10:29] <Lambda_Aurigae> so I poke back.
[17:10:42] <nuxil> hehe
[17:11:32] <Lambda_Aurigae> I got a restraining order against the mormons back in the late 90s....I keep copies of it in the closet by the front door to hand out whenever they come knocking.
[17:11:48] <Lambda_Aurigae> over the years I've given out probably 30 copies.
[17:11:57] <nuxil> lol..
[17:12:19] <Jartza> heh
[17:12:32] <Jartza> my religion is 8-bit
[17:12:34] <Jartza> :D
[17:12:43] <nuxil> :D
[17:13:15] <Lambda_Aurigae> religion is against my religion.
[17:14:41] <nuxil> Jartza, you need to make a pong game. 1969 version on a tiny :D
[17:14:46] <Jartza> lol
[17:14:53] <Jartza> with attiny85 maybe
[17:14:57] <Lambda_Aurigae> sure.
[17:14:58] <Jartza> not with attiny5
[17:15:08] <Lambda_Aurigae> you have the spare flash
[17:15:14] <Jartza> or well
[17:15:19] <Jartza> maybe with tiny5
[17:15:21] <Jartza> :D
[17:15:24] <Jartza> that would be a challenge
[17:15:26] <Lambda_Aurigae> only need monochrome.
[17:15:30] <Jartza> indeed
[17:15:31] <nuxil> yea
[17:15:37] <Jartza> and now I drive 4 color VGA from 3 pins
[17:15:43] <Lambda_Aurigae> it's the inputs that is the problem.
[17:15:45] <Jartza> lose 1 color and you can put paddle in
[17:15:58] <Jartza> I mean, lose one color _bit_
[17:16:09] <Lambda_Aurigae> no adc on that though.
[17:16:12] <Lambda_Aurigae> or is there?
[17:16:14] <Jartza> yes
[17:16:18] <Jartza> attiny5 does have adc :)
[17:16:20] <Lambda_Aurigae> well then, there ya go.
[17:16:32] <Jartza> and whole 32 bytes of SRAM
[17:16:43] <Jartza> and 512 bytes of flash
[17:16:52] <Lambda_Aurigae> you should only need about 3 or 4 bytes.
[17:16:52] <Jartza> sot23-6
[17:17:22] <Lambda_Aurigae> you could put a whole one player pong inside an old paddle.
[17:18:05] <Jartza> heck, I could solder it to some small potentiometer
[17:18:10] <Jartza> :D
[17:18:11] <Lambda_Aurigae> hehe.
[17:18:29] <Jartza> "Pong game. You only need screwdriver and VGA monitor to play"
[17:18:34] <Lambda_Aurigae> hehe.
[17:26:42] <Jartza> wow
[17:26:46] <Jartza> now THIS is challenge
[17:26:53] <Jartza> attiny5 does not have LPM instruction
[17:29:13] <Jartza> wtf
[17:29:28] <Lambda_Aurigae> no self programming capability?
[17:30:59] <Jartza> that too, but that's not critical
[17:31:04] <Jartza> LPM = Load from Program Memory
[17:31:06] <Lambda_Aurigae> http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_instruction_list.html
[17:31:13] <Lambda_Aurigae> just found a nifty site on atmel's site.
[17:32:48] <Jartza> Lambda_Aurigae: oh, I have that bookmarked and as desktop "webkit widget"
[17:32:48] <LeoNerd> LPM is for handy lookup tables, but at a small cost to code size/runtime you can get away without it
[17:32:48] <Jartza> :)
[17:32:58] <Lambda_Aurigae> just bookmarked it myself.
[17:33:12] <Jartza> ohh
[17:33:14] <Jartza> no probs
[17:33:22] <Jartza> on attiny5 the flash is memory-mapped :D
[17:33:29] <Lambda_Aurigae> oh?
[17:33:30] <Lambda_Aurigae> sweet.
[17:33:32] <Jartza> starting from 0x4000
[17:33:46] <Jartza> what the hell... why not on every avr then? :D
[17:34:07] <Lambda_Aurigae> some have the ability to do 64K sram.
[17:34:33] <Jartza> Constant tables can be allocated within the entire address space of program memory by using load/store instructions. Since program memory can not be accessed directly, it has been mapped to the data memory. The mapped program memory begins at byte address 0x4000 in data memory. Although programs are executed starting from address 0x000 in program memory it must be addressed starting from 0x4000 when accessed via the data memory.
[17:34:36] <Lambda_Aurigae> with external memory.
[17:35:09] <Lambda_Aurigae> have done it with both atmega128 and atmega8515
[17:56:00] <Jartza> hmmh
[17:56:11] <Jartza> now this might just be that avra behaves badly with attiny5
[17:56:21] <Jartza> I can't seem to get correct address for my lookup table
[18:09:47] <Jartza> gnnh
[18:09:48] <Jartza> wtf
[19:03:59] <Jartza> mmkay :)
[19:06:41] <Lambda_Aurigae> that bad?
[19:06:48] <Jartza> nah
[19:06:59] <Jartza> just had to get my brains around that mapping and syntax
[19:07:12] <Lambda_Aurigae> all figured out then?
[19:08:05] <Jartza> http://pastie.org/10668652
[19:08:06] <Jartza> yea
[19:08:27] <Jartza> because of course label is "flash address", being word address
[19:08:55] <Jartza> but that 0x4000 shouldn't be added to that, but the "flash address" converted to "byte address" (<<1)
[19:09:13] <Jartza> https://www.youtube.com/watch?v=kxcdLb2LHiM
[19:09:14] <Lambda_Aurigae> multiply by 2 and offset by 0x04000
[19:09:20] <Jartza> yea
[19:09:35] <Jartza> that's now 200 bytes
[19:09:35] <Jartza> :P
[19:13:37] <Jartza> http://pastie.org/10668661
[19:13:38] <Jartza> :D
[19:13:53] <Lambda_Aurigae> daym...you only have 312 bytes left!
[19:14:24] <Jartza> indeed
[19:14:46] <Jartza> but I have already working VGA "main routine" without jitter and with horizontal offset for each pixel line ;)
[19:14:57] <Jartza> so it's not that bad I think
[19:15:09] <Lambda_Aurigae> using internal oscillator?
[19:15:15] <Jartza> of course not
[19:15:19] <Jartza> that looks terrible
[19:15:20] <Lambda_Aurigae> just checking
[19:15:26] <Jartza> external 12MHz osc
[19:15:27] <Xark> That trick never works with video. :)
[19:15:29] <Jartza> no overclocking :)
[19:16:08] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxaWFhTkd4cGg0TDg/view?usp=sharing
[19:16:18] <Xark> 12Mhz? Is this 3.3v? :)
[19:16:39] <Jartza> that's how color bars look with internal oscillator (and that's still picture... in real life those artifacts are moving like crazy)
[19:16:47] <Jartza> Xark: no, but attiny5 is specced to 12Mhz
[19:17:04] <Jartza> http://www.atmel.com/devices/ATTINY5.aspx
[19:17:04] <Xark> Jartza: I see.
[19:17:46] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxejduNm95Q3Q5blU/view
[19:17:49] <Jartza> here's my setup :D
[19:18:28] <Jartza> that piece of perfboard is my home-cooked oscillator
[19:18:36] <Xark> Heh, oscillator dwarfs MCU. :)
[19:18:53] <Jartza> it would even if I used "factory made" :D
[19:18:59] <Jartza> like DIP14 can :D
[19:35:27] <Tom_itx> i thought those had internal osc
[19:35:38] <Tom_itx> is that a t5 etc?
[19:36:06] <Tom_itx> 12Mhz internal
[19:38:24] <Jartza> t5 yes
[19:38:27] <Jartza> 8MHz internal
[19:38:33] <Jartza> but internal oscillators are fail for vga
[19:39:01] <Tom_itx> really? i thought the t 4 5 9 & 10 had 12Mhz internal
[19:39:20] <Lambda_Aurigae> even still it's not stable enough for vga generation.
[19:41:13] <Jartza> no MCU has stable enough oscillator for vga
[19:42:28] <Tom_itx> http://www.digikey.com/product-detail/en/CSTCE12M0G55Z-R0/490-1220-1-ND/584648
[19:42:32] <Tom_itx> what about something like that?
[19:42:37] <Tom_itx> it's pretty small
[19:42:52] <Jartza> that's no oscillator
[19:42:59] <Jartza> I can only have 1 pin for oscillator
[19:43:02] <Tom_itx> i used the 16Mhz ver on my programmer
[19:43:04] <Tom_itx> ahh
[19:43:06] <Tom_itx> that's true
[19:43:19] <Lambda_Aurigae> I've seen smt oscillators though.
[19:43:35] <Tom_itx> those are the smallest ones i could find
[19:44:10] <Lambda_Aurigae> http://www.digikey.com/product-detail/en/NX3225GA-12MHZ-%20STD-CRG-2/644-1173-1-ND/3125562
[19:44:39] <Lambda_Aurigae> nope..still just a crystal.
[19:44:44] <Lambda_Aurigae> 4 pads was misleading.
[19:45:01] <Jartza> http://www.digikey.com/product-detail/en/KC5032A12.0000CMGE00/1253-1285-2-ND/4867113
[19:45:07] <Jartza> that's 5x3.2mm :)
[19:45:15] <Jartza> still huge compared to chip
[19:45:17] <Lambda_Aurigae> that's what I was looking for.
[19:45:47] <Xark> Jartza: I guess they do have SMD ones, but still close to chip size. :)
[19:46:13] <Lambda_Aurigae> http://www.digikey.com/product-detail/en/ASDMB-12.000MHZ-LC-T/535-11724-2-ND/2809926
[19:47:10] <Lambda_Aurigae> 2mmX2.5mm
[19:47:51] <Jartza> Lambda_Aurigae: VGA needs 5V
[19:47:59] <Jartza> sync signals are +5V
[19:48:02] <Lambda_Aurigae> bah.
[19:48:15] <Jartza> that 5x3.2mm is smallest I've found in 5V
[19:48:36] <Xark> Hmm, all my FPGA VGA are 3.3v and seem fine...
[19:48:55] <Jartza> I guess many monitors don't really care
[19:49:01] <Jartza> but standard says +5V ;)
[19:49:03] <Xark> I think 3.3v gets above HIGH level of 5v TTL, so works fine.
[19:49:11] <Jartza> true
[19:55:41] <Jartza> well
[19:55:52] <Jartza> seems to work swell anyhow
[19:56:21] <Jartza> ...I mean, this perfboard-oscillator :D
[19:56:25] <Jartza> at least for protoing
[19:56:38] <Jartza> and how in their right mind would want to make a product out of this?
[19:56:45] <Jartza> https://www.youtube.com/watch?v=ztAN_pSgyxM
[20:00:06] <Xark> Hehe. Just add a Nyan cat leaving that rainbow and people will be wanting one. :)
[20:00:51] * Xark links old video https://www.youtube.com/watch?v=t_lro-z7Wf8 :)
[20:02:41] <Lambda_Aurigae> but that was a major chip compared to the tiny5
[20:05:23] <Jartza> yeah
[20:05:27] <Jartza> but this is still just a test
[20:05:41] <Jartza> biggest challenge will be to get anything useful to that flash space
[20:05:58] <Jartza> that latest sine already takes 222 bytes
[20:07:18] <Jartza> the horizontal offset already takes 42 bytes
[20:13:01] <Jartza> well. some cleanup and 218
[20:24:08] <Jartza> maybe plasma effect could be implemented
[20:24:15] <Jartza> but don't know if that's cool enough
[20:25:22] <Jartza> anyways. 4am. time for good night!
[22:23:22] <LOMAS> hi there, I have programmed Timer0 of ATmega8 for generating square of 50ms. But it is not working.
[22:23:30] <LOMAS> see this code
http://hastebin.com/eficakoxup.coffee
[23:19:56] <rue_shop3> whats it doing ?
[23:20:45] <rue_shop3> you didn't turn on the clock source
[23:20:57] <rue_shop3> er, select..
[23:26:10] <LOMAS> rue_shop3, what ?
[23:26:12] <LOMAS> where ?
[23:26:55] <rue_shop3> I'd have to think about it now, I'll look at it in an hour or so when I can concentrate on it
[23:27:09] <rue_shop3> atmega8 eh?
[23:27:43] <LOMAS> rue_shop3, okay, yes its mega8.
[23:28:08] <LOMAS> rue_shop3, but where do you see that the colck source is not turned ON ?
[23:28:30] <rue_shop3> it looks like you did
[23:28:39] <Casper> packet[0]=000100000011100000000000000011010010; if ((packet[0] & (1<<31))) { <==== should match that 0 bit and fail the test right?
[23:29:06] <Casper> if I still know how to count, that's bit 31... . ... or should it be <<30 ?
[23:29:14] <LOMAS> Casper, are you talkin to me ?
[23:29:35] <Casper> to anybody
[23:30:35] <LOMAS> Casper, WTF!! I mean are those texts are for me or what ?
[23:30:47] <Casper> no
[23:30:51] <Xark> Casper: On AVR you need 1UL or 1ULL << x
[23:30:59] <Casper> pc side
[23:33:01] <Casper> with a cast it worked... great
[23:46:03] <rue_shop3> packet[0]=000100000011100000000000000011010010; <-- that translates as decimal, not binary
[23:54:33] <Casper> bahh pseudo C okay? :D
[23:56:21] <Casper> just need another 6 switches....
[23:56:36] <Casper> and figuring out what to eat tonight
[23:56:52] <Casper> might go with egg and toasts