Back
[12:52:26] <Duality> are there like any channels on freenode that are in the topic of old style computers :) and cpu's and the kind :)?
[12:55:11] <jeremyabel> it'd be on-topic in ##electronics
[12:56:35] <Duality> i see
[12:56:46] <Tom_itx> rue_house likes old junk
[12:56:48] <Tom_itx> ask him
[12:56:56] <jeremyabel> I like old junk too, but not too up on CPUs :P
[12:59:47] <hmw> Duality: perhaps ask in #c64
[13:02:16] <hmw> Is this good for calling a subroutine at the given address? uint16_t target_address =0x1234; ( ( void(*)() ) target )();
[13:03:02] <hmw> uhm... s/_address//
[13:06:52] <Xark> Duality: Perhaps #classiccmp : "Discussion of vintage Classic Computers" (they aren't fond of emulators and remakes AFAIK).
[13:11:48] <hmw> Hmm... the code above creates an icall, which looks nice, but it ends in a totally different routine and I don't know, how to debug this. Any hints on how to tackle this?
[13:13:24] <Xark> hmw: What is the problem? Not calling 0x1234?
[13:17:14] <hmw> I looked at the code (in the living ROM, my AVR can hexdump to an LCD) and the jump address points at the correct location, that location contains the correct function, but when I type that test command, it does not call the CLRSCR routine but another (it jumps right into another command handler)
[13:18:07] <Xark> hmw: Perhaps confusion between word and byte addresses (AVR code has word sized opcodes and addresses)?
[13:18:46] <hmw> so when I want to call 0x1000 i should do uint16_t target = 0x1000 >> 1 ??
[13:20:26] <hmw> it compiles to: ldi r30, 0x34 ... ldi r31, 0x12 ... icall .... i swapped the two bytes because i was too lazy to look up endianness-problems, but without the wanted result
[13:20:34] <Xark> hmw: I am not sure, I always use "symbols" and let the linker figure that out. :)
[13:21:10] <hmw> i need it dynamically... i am writing a machine language monitor, so i want to implement a "go 0x1234" command
[13:23:21] <hmw> hah thanks
[13:23:55] <hmw> weird though... i need to learn to understand, what my mcu is doing with this LSBit
[13:23:56] * Xark writes a small test...
[13:24:13] <hmw> It just called CLRSCR... or a weird crash simulated it *g*
[13:24:31] <hmw> needs to divide the target byte address by two
[13:25:47] <Xark> Yeah, makes sense (as an odd code address is non-existant).
[13:26:31] <hmw> Not sure, if I like this... perhaps I should organize my software to "think" in words instead of bytes
[13:26:47] <Xark> hmw: Well, SRAM is byte addressable. :)
[13:27:21] * Xark confirms the compiler automatically does a >>2 on address when setting code pointer
[13:27:27] <Xark> Er, >>1
[13:29:06] <hmw> not in my given example, the value gets unmodified into the machine code. Is this a bug??
[13:31:51] <hmw> or some setting?
[13:36:27] <Xark> hmw: Well, the compiler can't tell it is a program address. In your code it is just an int (so you have do >>1 yourself).
[13:37:03] <hmw> ic, that makes sense
[13:37:29] <Xark> Here is my cheesy test ->
http://hastebin.com/umohigaceg.coffee
[13:59:35] <hmw> I slapped in a snippet for finding the amount of used SRAM:
http://hastebin.com/marazugoda.cpp - When I change the line extern... into the commented out version below, malloc() does no longer get assembled into my object. How can I find the amount of RAM used by static stuff without getting that huge malloc/free functions? Can I "skip" them with obj-copy, like putting it into another section?
[14:04:59] <Xark> hmw: I just do this...(one sec)
[14:06:37] <Xark> http://hastebin.com/abikopumij.m
[14:06:42] <hmw> omg someone suggests overwriting the RAM with a known pattern and look, what gets overwritten
[14:07:59] <Xark> hmw: That can be handy for finding stack "high water" (lowest address used), but seems overkill for RAM size check. :)
[14:08:01] <hmw> Xark: looks a bit like voodoo to me (i am not experienced with C, nor do I know the build process in detail)
[14:08:29] <Xark> hmw: Basically those symbols are automatically created by the linker (assuming GNU tools).
[14:08:50] <Jartza> does anybody know if attiny85 pwm can run while mcu is in idle-mode?
[14:09:10] <Jartza> I'm tryind to decipher datasheet, but thought if someone knew that already :)
[14:09:13] <hmw> Jartza: depends on how deep it sleeps... the data sheet should tell you
[14:09:16] <hmw> ah
[14:10:02] <Jartza> well there's few sleep modes. idle, adc noise reduce and "power-down"
[14:10:18] <hmw> i am looking at it right now
[14:10:28] <Jartza> power-down will shut down clocks (except wd), I'm pretty sure that doesn't work
[14:11:00] <Xark> hmw: The main one is "_end" which is the end address of all your static variables and where "malloc" (or other dynamic allocations) should start. The subtract from __data_start just generally subtracts 0x100 (which is space used by registers/IO not RAM).
[14:15:49] <Jartza> d'oh, might be easier just to try it out
[14:15:57] <hmw> heheh
[14:17:23] <Jartza> at least idle mode leaves io and other clocks running
[14:17:39] <hmw> pwm uses the timer counter, afai understand
[14:17:48] <Jartza> yes
[14:18:08] <Jartza> ahh
[14:18:10] <Jartza> now I found it
[14:18:13] <Jartza> "Idle mode stops the CPU while allowing the SRAM, Timer/Counter, ADC, Analog Comparator, and Interrupt system to continue functioning."
[14:18:20] <Jartza> so the answer is, yes :)
[14:18:22] <Jartza> cool
[14:21:04] <hmw> General question: How do I learn, what I need to learn about my compiler suite? I know what linking means, but I never did anything manually. I find most documentation way too detailed, because I know most of the stuff already. Is there a quick crash course for people like me?
[14:22:15] <hmw> * either I know "most of the stuff" or it is way beyond my understanding.
[14:22:39] <hmw> It's somewhat weird. I need an outline of what a real programmer should know or something of the sort.
[14:23:05] <Xark> hmw: Well, I'd suggest reading the doc (or at least skimming it). You may find some useful bits and even the parts you don't understand may start to make sense eventually.
[14:23:38] <Jartza> hmw:
http://tuxgraphics.org/electronics/200904/avr-c-programming.shtml
[14:24:00] <Jartza> hmw:
http://www.nongnu.org/avr-libc/user-manual/index.html
[14:24:03] <Jartza> start with those
[14:24:12] <Jartza> and the library reference is also your friend
[14:25:29] <hmw> the avr-libc manual is not good for me, it does not explain the things, i am actually missing (I have gaps in my knowledge, autodidact freak here)... I usually end up searching the web for hours or days until I get my insight, when there is something I do not know yet
[14:25:43] <hmw> I don't even know, how to phrase my question, so you know what I am looking for
[14:26:00] <Jartza> then look at the tuxgraphics tutorial
[14:26:09] <Jartza> I found that to be quite easy to follow, even if it's a bit old
[14:26:21] <hmw> i will, but it looks like it is not written for me. it starts at a VERY low level
[14:26:54] <hmw> i've been programming for 30 years now, but never really bothered to learn the C tool chain
[14:28:37] <hmw> That tuxgraphics page is nice, though...
[14:29:28] <Jartza> hmm.
[14:29:52] <Jartza> the C toolchain isn't that mystical, although gcc has gazillion options which might make it look hard
[14:30:58] <Jartza> there's of course some generic gcc toolchain tutorials
[14:30:59] <Jartza> https://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html
[14:31:04] <Jartza> most of that stuff applies to avr too
[14:31:27] <hmw> i need a starting point somewhere between "a byte is made of 8 bits" and "use a linker script to do it. (You certainly know already how to)"
[14:31:45] <Lambda_Aurigae> programming for 30 years? and don't understand how a compiler works?
[14:32:22] <Jartza> just remember that the commands start with avr- when using avr-gcc toolchain
[14:33:31] <Jartza> Lambda_Aurigae: not that unusual if just using some ides
[14:33:35] <hmw> i understand what a compiler is, i wrote an assembler for Redcode once. I just started using C really when I started with AVR stuff. I even remembered almost all details about C which I read in a book 16 years ago.
[14:33:58] <hmw> I shouldn't have done so much web stuff and started doing hardware way earlier *g*
[14:34:41] <hmw> the last IDE I was using was Borland Delphi 6.0
[14:34:47] <Jartza> I worked as an instructor for >5 years, taught people C, C++, Python, etc... saw a lot of people who coded even C++ but didn't have any clue what happens after pressing the "run" -button on your IDE, except magical .exe happens
[14:34:52] <Jartza> :)
[14:35:25] <hmw> I miss Delphi. That IDE was /perfect/ for hobby programming
[14:35:38] <Jartza> hmw: I've also programmed for 30 years, and started doing electronics half a year ago
[14:35:56] <Jartza> although, I've done embedded programming for ~6 years
[14:36:15] <Jartza> but for hw "someone else made"
[14:36:34] <Lambda_Aurigae> I started with hardware 37ish years ago and programming in basic 35ish years ago.
[14:36:59] <Jartza> so you have around 36 and half years of more experience of hw than I do :)
[14:37:04] <Jartza> "just a tiny bit"
[14:37:10] <hmw> heheh... for once, I am not the most senior freak in a group
[14:38:10] <Lambda_Aurigae> unfortunately I am almost completely self-taught so my knowledge is kind of freakish and piecemeal.
[14:38:52] <Jartza> Lambda_Aurigae: for most parts, so am I
[14:39:14] <Jartza> but I don't see any self-learning as a bad thing
[14:40:16] <hmw> autodidact people might have unexpected holes in their knowledge.
[14:40:33] <hmw> someone educated should have a more complete overview, I suppose...
[14:40:59] <Jartza> depends
[14:41:06] <Lambda_Aurigae> one of the first thing you need to learn is how to understand.
[14:41:22] <Lambda_Aurigae> comprehension is the key to going forward.
[14:41:22] <Jartza> some people surf through schools with just a bare minimum requirements.
[14:41:43] <Jartza> ...and some educated people have no vision outside their "comfort zone", which they were taught at school
[14:41:56] <Lambda_Aurigae> hmw, what is it you are after knowing as far as the toolchain goes?
[14:42:12] <Lambda_Aurigae> how to compile? how to use the functions in the libc?
[14:45:09] <hmw> How to compile, link basically. Yesterday I learned about sections and how to use objcopy to make a boot loader function. Took me a while to figure all this out. All I knew was that there are segments and that in a PC they may be write protected or something of the sort.
[14:46:03] <Lambda_Aurigae> I would suggest looking at some of the example makefiles out there.
[14:46:33] <hmw> good idea
[14:46:42] <Lambda_Aurigae> looking at one for you right now.
[14:47:45] <Jartza> I would check that through:
https://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html
[14:47:55] <Lambda_Aurigae> http://homepage.hispeed.ch/peterfleury/avr-software.html
[14:48:10] <hmw> thanks
[14:48:10] <Jartza> that's quite simple tutorial, showing how to compile, link, compile multiple files, etc.
[14:48:10] <Lambda_Aurigae> some simple examples in a zip file there.
[14:48:20] <Lambda_Aurigae> including makefiles.
[14:48:40] <Jartza> and yes, also checking some ready makefiles, that's a good idea too
[14:52:25] <hmw> Xark: now I get the proper memory from what I calculated by looking at my C code. My old routine added 20 bytes or so.
[14:53:09] <Xark> hmw: Cool. You mentioned using objcopy a bit ago. Using avr-nm -n can be very handy to see exactly where everything landed.
[14:53:47] <hmw> I use objdump to look at the hex dump and disassembly
[14:53:50] <Lambda_Aurigae> avr-objcopy makes a hex file out of your .elf file
[14:54:11] <hmw> I learned that yesterday *g* Was a great moment, when I finally made my box flash itself
[14:54:34] <Lambda_Aurigae> "made my box flash itself" that just sounds like a personal problem to me.
[14:56:31] <Xark> hmw: Cool. That is handy too. avr-nm will dump the symbols in a program (and -n sorts numerically). One "quirk" of the GNU AVR toolchain is SRAM has a "fake" address of 0x00800000 (I believe this is to simulate the two address spaces). So e.g. and _end symbol with value of 0x0080089b is really 0x89b (or using 0x79b bytes of SRAM statically).
[14:56:57] <hmw> I see that in the hex file
[14:57:24] <hmw> no, not really... that's something else
[14:57:56] <hmw> i came across that 0x00800000 value yesterday... uhm. Forgotten :)
[14:58:22] <Xark> Makes sense.
[14:58:53] <hmw> Lambda_Aurigae: Heheh. My box is intended to be a mobile programmable AVR computer (LCD, self built i2c keyboard, etc).
[14:59:17] <hmw> I shall learn AVR assembly with it.
[14:59:28] <Xark> I think you can see it with e.g. avr-readelf -l *.elf (which dumps program sections and their flags)
[14:59:50] <hmw> I fear, I will have to wade through the whole doc
[15:01:15] <Lambda_Aurigae> that's what I use my tablet for.
[15:01:29] <Xark> hmw: Hehe, you can get pretty far trying the utilities in "bin" directory with "--help" (and then Google if you have more questions). :)
[15:01:39] <Lambda_Aurigae> finally got the avr toolchain compiled for android.
[15:01:58] <hmw> Eek... you have a bloat there on that tablet *g* I love 8 bit computers, one can fully understand what it is doing... which can't be said about a modern computer.
[15:02:09] <Xark> Lambda_Aurigae: Neat! I only found a $$$ compiler (F that). :)
[15:03:11] <hmw> Hmm.... I once used a Raspberry Pi for AVR coding... neat to have a C compiler in your pocket. I guess that won't fit into my ATMega *grins*
[15:03:15] <Lambda_Aurigae> hmw, then take on the project I did when I was 16...build a 4-bit processor from 74xx logic.
[15:03:51] <hmw> I'd love to create my own ICs
[15:04:09] <jeremyabel> FPGAs!
[15:04:12] <learath> I'll pass on that stress. "get it right, or it's an extra million"
[15:04:19] <learath> FPGAs make my brain hurt
[15:04:19] <jeremyabel> lol
[15:04:24] <hmw> heheh
[15:04:24] <jeremyabel> I keep meaning to dive into them
[15:04:34] <learath> I'm trying to. it's *weird*
[15:04:40] <Xark> hmw: Self hosted AVR C compiler would be quite a trick. :)
[15:04:59] <learath> self hosted *windows based* c compiler
[15:05:00] <hmw> Well... there is this AVR Linux project...
[15:05:05] <learath> I mean, if you are trying to do every possible thing wrong....
[15:05:22] <Lambda_Aurigae> hmw, yeah, it would only take a few weeks to compile a program.
[15:05:33] <hmw> a small one
[15:05:57] <Lambda_Aurigae> my linux on avr build took many multiple hours to just boot.
[15:06:18] <Xark> I think AVR Linux is "cheating" too, as it is really an AVR ARM emulator running Linux (if I am thinking of the same project). :)
[15:06:27] <Lambda_Aurigae> a 32bit arm emulator running on an 8bit processor...
[15:06:31] <hmw> If I manage to put in a small assembler/disassembler, that would be luxurious enough. I guess I will be typing a lot of hex numbers into my box soon.
[15:06:57] <Xark> Lambda_Aurigae: Yeah. An impressive hack, for sure. It actually indirectly lead to me getting an AVR. :)
[15:07:09] <hmw> lol
[15:07:10] <Lambda_Aurigae> well, on the vic-20 I wrote a 6502 assembler/disassembler in basic.
[15:07:32] <Lambda_Aurigae> then wrote a basic compiler in basic...
[15:07:36] <Lambda_Aurigae> then used it to compile itself.
[15:07:37] <hmw> lol... you had 3.8Kbyte or so
[15:08:06] <hmw> My system is already at 4K :(
[15:08:11] <Lambda_Aurigae> my atmega1284p chips have 128K program space and 16K data space...blows away my vic-20....is even over 50 times faster overall.
[15:08:12] <Xark> Lambda_Aurigae: Cool. I remember writing an assembler on my OSI-C1P (very much like a black and white VIC-20 - few years earlier), but the crappy Microsoft BASIC in ROM had a bug that would hang during string garbage collection. So I switched to hand-assembling (until I got an Apple). :)
[15:08:16] <learath> maybe a compiler to self modify itself into the code you are compiling? :P
[15:08:37] <Jartza> oh, c64
[15:08:38] <Jartza> those times
[15:08:42] <jeremyabel> <3 c64
[15:08:45] <jeremyabel> still have two of 'em!
[15:08:46] <Lambda_Aurigae> pre-c64.
[15:08:56] <Lambda_Aurigae> I have 2 working vic-20s here.
[15:09:02] <Lambda_Aurigae> and several c-64s and a c-128
[15:09:07] <Xark> Lambda_Aurigae: I believe I have one.
[15:09:12] <Jartza> I made a "graphics demo" in one print and sys :)
[15:09:14] <hmw> I did this 2 years ago:
https://www.youtube.com/watch?v=l3n3i5SuXf4
[15:09:15] <jeremyabel> Lambda_Aurigae: niiice
[15:09:19] <Jartza> one line of "basic"
[15:09:44] <Jartza> although to be honest, it just printed the program to display memory and then jumped to that.
[15:09:45] <jeremyabel> hmw: niiiiice!
[15:09:53] * Xark wrote games for C64 back in the day (and 2600, Vic20 and other 8-bits). :)
[15:10:19] <Lambda_Aurigae> I wrote utilities for them.
[15:10:31] <Lambda_Aurigae> and viruses
[15:10:32] <jeremyabel> Xark: any good ones?
[15:10:49] <Lambda_Aurigae> viruses were mostly for the apple-2 though.
[15:11:07] <Xark> jeremyabel: Sure. I did arcade ports for Sega and stuff for DataSoft like ->
https://en.wikipedia.org/wiki/Alternate_Reality_(series)
[15:11:08] <jeremyabel> Lambda_Aurigae: prank ones or damaging ones?
[15:11:13] <Lambda_Aurigae> prank ones.
[15:11:17] <jeremyabel> Xark: damn, badass
[15:11:19] <Lambda_Aurigae> most famous was diskwasher.
[15:11:36] <jeremyabel> Lambda_Aurigae: word, I love me some prank viruses
[15:12:14] <Xark> Lambda_Aurigae: I don't remember getting any significant apple ][ viruses. They weren't a problem until Amiga days for me.
[15:12:16] <Jartza> but anyways, I'm off to bed, the flu takes its toll
[15:12:23] <Jartza> laters _o/ &
[15:12:24] <jeremyabel> Jartza: I know that feel
[15:12:28] <Lambda_Aurigae> it would randomly clear screen and display, "found water on floppy drive, running spin cycle," spin the disk drive up and move the head back and forth rapidly..then go back to your program.
[15:12:37] <Xark> Jartza: Feel better! :)
[15:12:49] <jeremyabel> Lambda_Aurigae: mhahahaha
[15:12:56] <jeremyabel> that's great
[15:13:07] <Lambda_Aurigae> on the apple 2 when you did that to the drive it sounded like it was eating itself.
[15:13:13] <jeremyabel> hahahah
[15:13:14] <Lambda_Aurigae> or eating your disk.
[15:13:21] <Xark> Lambda_Aurigae: Hehe. I remember a program on the Apple ][ called "Intercourser" that would make the floppy disk drive make obscene noises. :)
[15:13:25] <jeremyabel> lol
[15:14:01] <Lambda_Aurigae> on the commodores I played with writing programs for the floppy drives...they were full fledged programmable computers after all.
[15:14:14] <jeremyabel> indeed
[15:14:17] <Lambda_Aurigae> using the floppy drive as a mathcoprocessor was fun.
[15:14:23] <jeremyabel> things were huuuge
[15:14:29] <jeremyabel> still have one, weighs a ton
[15:14:32] <Xark> Lambda_Aurigae: Indeed. Elaborate DOS fastloader included in that game I linked.
[15:14:35] <Lambda_Aurigae> have several here.
[15:14:50] <jeremyabel> I have a bunch of SID chips I need to do something with too
[15:15:17] <Xark> Lambda_Aurigae: IIRC, the disk drive was actually a bit faster than the main C64 CPU (and especially with DMA overhead). :)
[15:15:18] <Lambda_Aurigae> also have a little toy I built from an atmega32 and an SD card that emulates the floppy drive.
[15:15:28] <Lambda_Aurigae> multiple floppy images on one sd card.
[15:15:32] <learath> hah, what kind of data rates do you g et?
[15:15:46] <hmw> jeremyabel: put them back into their c64's... ripping the SID out is a crime.
[15:15:55] <jeremyabel> lol I bought them separately!
[15:15:57] <Lambda_Aurigae> I can push the bus to full speed...it's faster than the old 1581 3.5 inch drives.
[15:16:07] <jeremyabel> my two c64s have their SIDs in place
[15:16:10] <jeremyabel> I have two extra
[15:16:13] <hmw> heheh
[15:16:21] <hmw> I got two c64 without SID :/
[15:16:27] <Lambda_Aurigae> which, I am looking for still...at a decent price or trade.
[15:16:49] <jeremyabel> aw
[15:16:58] <jeremyabel> a c64 without a SID is a sad c64
[15:17:05] <Lambda_Aurigae> I also have a cable and program that I got online years ago that turns a PC into a commodore harddrive.
[15:17:19] <hmw> C64 with the Final Cartridge III = "Macrocontroller"
[15:17:24] <jeremyabel> lol
[15:17:31] * Xark has an FPGA that does a pretty good job at being a SID (but not perfect). http://retrocade.gadgetfactory.net/
[15:17:34] <learath> Lambda_Aurigae: what happens when you present a 1t hard drive to a commodore?
[15:17:46] <jeremyabel> Xark: ah yeah, been meaning to check that out
[15:18:01] <Lambda_Aurigae> learath, dunno...I had it on a 386dx40 with a 100MB harddrive running dos6.22
[15:18:07] <jeremyabel> oh nice it does YM2149 too
[15:18:21] <jeremyabel> I've got a full keyboard with a YM2149 in it
[15:18:28] <Xark> jeremyabel: It does play some clean sounding MOD files (and several other kinds of chiptunes) :)
[15:18:34] <jeremyabel> nice
[15:18:42] <Lambda_Aurigae> I haven't touched the commodores in a couple years now though.
[15:19:24] <hmw> Xark: btw. your code snippet says extern "C" char _end[]; which does not compile, but without that "C" it does as shows the expected amount of free RAM
[15:19:26] <Xark> Lambda_Aurigae: I had some similar "dongles" for PC parallel port that would allow you to have it pretend to be a C64 or Atari disk drive (two different dongles).
[15:20:00] <Lambda_Aurigae> now I'm working on porting the c64 kernal and basic roms to avr.
[15:20:17] <Xark> hmw: Hmm, it most certainly does compile, but it is C++ code. For C, you just want: extern char _end[];
[15:20:33] <hmw> ah. now that "C" appears to make sense.
[15:21:03] <Xark> hmw: Yeah, that prevents the C++ compiler from "mangling" the symbol (and adding type info like C++ typically does - but C doesn't).
[15:21:09] <hmw> But only appears. It is not a function call, where conventions might be an issue. Why do you need it in C++?
[15:21:20] <Xark> ^
[15:21:48] <hmw> I have a vague idea, what that means. Thanks!
[15:22:17] <Xark> hmw: E.g., in C++ void myfunc(int) creates a different symbol thatn void myfunc(float). In C both would have the same name (and not be "type safe" calling them).
[15:22:41] <Lambda_Aurigae> C++ rounds off the edges so you can't hurt yourself.
[15:22:49] <hmw> heheh
[15:22:58] <jeremyabel> so soft and friendly!
[15:23:07] <hmw> But by hurting one self, one learns quicker :)
[15:23:08] <Xark> Lambda_Aurigae: Heh, one could argue it ups the blast radius of the ordnance too. :)
[15:23:18] <hmw> lol
[15:23:21] <Lambda_Aurigae> Xark, but, of course.
[15:24:19] * Xark quotes famous quote: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"
[15:24:29] <jeremyabel> lol
[15:24:35] <Lambda_Aurigae> I like it.
[15:24:48] <Xark> From the creator of C++ too. :)
[15:24:57] <Xark> http://www.stroustrup.com/bs_faq.html#really-say-that
[15:26:08] <hmw> "Computers count. Especially on humans to think. That's why computers have so many enemies" (translated)
[15:30:05] <dunz0r> I've got an int and I want to display it on an HD44780-display, how should I accomplish this? I'm guessing itoa... but it seemed to hang the AVR...
[15:30:26] <Lambda_Aurigae> dunz0r, sprintf
[15:31:09] <dunz0r> Oh, ofc. Thanks Lambda_Aurigae :)
[15:31:21] <Lambda_Aurigae> itoa has caused others problems in the past.
[15:31:40] * dunz0r sets up the LCD as stdout
[15:31:47] <Lambda_Aurigae> that would be printf
[15:32:04] <Lambda_Aurigae> sprintf outputs a string that you can then display on the display...but your way should work too.
[15:32:15] <dunz0r> Lambda_Aurigae: Yeah... I've never seen such a weird behaviour. It lit up all the ports and more or less hung.
[15:32:25] <dunz0r> The LCD got filled with crap and things like that :D
[15:33:03] <Lambda_Aurigae> not sure what is up with the itoa implementation but I have seen 3 or 4 people have problems with it in the last year alone.
[15:35:19] <Steffanx> whop.
[15:40:25] <hmw> I might be affected by an utoa bug as well. I will try writing my own routine and that weird glitch might go away...
[15:40:40] <Lambda_Aurigae> just use sprintf instead
[15:41:02] <Lambda_Aurigae> although, Xtoa isn't too hard to do really..
[15:41:07] <hmw> that would reintroduce malloc/free into my code, right?
[15:41:40] <Lambda_Aurigae> dunno.
[15:42:04] <Lambda_Aurigae> I always guestimate my code size then double or quadruple the processor specs to fit.
[15:42:56] <hmw> ah. I set myself the goal to create my NOPS (no operating system) for an 8K ROM, leaving at least 2K for the user.
[15:43:26] <Lambda_Aurigae> atmega1284p....
[15:43:31] <hmw> too large *g*
[15:43:35] <Lambda_Aurigae> biggest dip package avr...
[15:43:40] <hmw> heheh
[15:43:56] <Lambda_Aurigae> lots of flash, a shitload of sram.
[15:46:10] <Lambda_Aurigae> I've been playing with a competitor chip lately...it's complex as hell compared to an AVR but it is also powerful in a small package.
[15:46:53] <rue_house> hmw, why not leave 512 bytes for the user, then they have to get creative to do anything with it
[15:47:13] <rue_house> you could make it 16 bytes and have it prettymuch just select one of a few built in applications
[15:47:47] <rue_house> your prettymuch gerunteed that if someone uses a microcontroller on a project its either a reprap or a hexapod
[15:47:55] <rue_house> or a quadcopter
[15:47:59] <hmw> heheh
[15:48:07] <hmw> I am making a mobile computer. ...
[15:48:34] <rue_house> call it he huckleberry muffin
[15:48:45] <Lambda_Aurigae> hmw, you need my vga display system and a small vga monitor.
[15:48:49] <rue_house> those sorts of names seem to be all the rage now
[15:49:07] <rue_house> why not composite and a 4.3" backup screen?
[15:49:18] <Lambda_Aurigae> that could work too.
[15:49:25] <Tectu> Hello
[15:49:31] <Lambda_Aurigae> hello Tectu
[15:49:34] <rue_house> www.ebay.ca/itm/400754371815 <-- look, $15!
[15:49:49] <Lambda_Aurigae> nice.
[15:49:54] <Steffanx> This listing has ended...
[15:50:09] <rue_house> there are lots more out there for $15
[15:50:19] <Tectu> if you guys search for a library to drive those displays, I can recommend µGFX:
http://ugfx.org
[15:50:25] <rue_house> I'm gonna make a realtime goggle set with mine
[15:50:30] <rue_house> no digital in the middle
[15:50:35] <Steffanx> i can't recommend ugfx.
[15:50:42] <rue_house> = no lag
[15:50:50] <rue_house> 0 lag
[15:51:01] <Tectu> Steffanx, is trolling - we know each other and I'm the founder and maintainer of µGFX and he always tries to screw it up :D
[15:51:07] <jeremyabel> lol
[15:51:17] <Steffanx> wut.
[15:51:17] <hmw> Lambda_Aurigae: I am actually looking for a nice display of the right size with 320x200 or so. I recently upgraded my NOPS from 2x16 chars to 128x64 pixels! So much woot!
[15:51:51] <rue_house> characters are out of date, you should use sprites now
[15:52:17] <Lambda_Aurigae> hmw, I'm using serial srams to generate 800x600 vga.
[15:52:27] <hmw> The whole project is really hard to describe. It is a gadget that helps me bootstrapping gadgets that bootstrap themselves... or so.
[15:52:31] <rue_house> !! and you can transfer fast enough?
[15:52:45] <hmw> depends on the µC i guess
[15:52:49] <Lambda_Aurigae> triple buffered.
[15:53:27] <Tectu> hmw,
http://www.ebay.com/itm/3-2-TFT-LCD-Display-Module-Touch-Panel-PCB-adapter-65K-SSD1289-White-LED-/330809062108?pt=LH_DefaultDomain_0&hash=item4d05c1b2dc
[15:53:35] <rue_house> i didnt think you could pull fast enough from a serial memory to do something like video
[15:53:38] <Tectu> hmw, µGFX already has working drivers for that one too
[15:53:43] * Xark links to the AVR NTSC pseudo-sprite stuff he is playing with :) -> https://www.youtube.com/watch?v=Imk5ony8JHI
[15:53:47] <Lambda_Aurigae> the chips I'm using will clock out at 20MHz.
[15:54:01] <Lambda_Aurigae> higher even but that's out of spec.
[15:54:10] <Lambda_Aurigae> spec says 20MHz and that's all I need for 800x600 vga.
[15:54:14] <Tectu> hmw, if you prefer, they also come with SPI:
http://www.ebay.com/itm/2-8-inch-320x240-Touch-TFT-LCD-Display-Module-SPI-16bit-8bit-all-Interface-/171201078046?pt=LH_DefaultDomain_0&hash=item27dc61231e
[15:54:16] <rue_house> wow
[15:54:26] <rue_house> whats that running on?
[15:54:41] <Lambda_Aurigae> solderless breadboard with a 20MHz can oscillator and some glue logic.
[15:54:54] <Lambda_Aurigae> have 3 buffers...2 display and 1 write.
[15:55:09] <rue_house> all the processing done in the blanking?
[15:55:30] <Lambda_Aurigae> cpu writes to the write buffer...then while one display buffer is used to display the write buffer gets written to the second display buffer...then swap display buffers and write to the other one.
[15:55:31] <Xark> rue_house: My link? 328 16Mhz 4-cycles per pixel tile character graphics (with horizontal and vertical fine scroll too). It is interrupt driven (so a little bit of time between scanlines too).
[15:55:39] <rue_house> must be 100% during the trace
[15:56:21] <Lambda_Aurigae> all the processing is done "offline" basically...and switch the two display buffers between being written to and being used to display.
[15:56:31] <hmw> why using a third buffer? I can see, how using a background buffer makes sense, but 3 buffers confuse me
[15:56:47] <rue_house> I wonder if you could use the spi serial line to clock out the pixels for you and help reduce the overhead
[15:56:59] <Lambda_Aurigae> I can write the graphics and text to one buffer from outside...
[15:57:00] <Xark> rue_house: Yes. About ~20% of AVR cycles are still available for user code (while generating video).
[15:57:19] <Lambda_Aurigae> if I don't use the intermediate buffer then the parent processor must write twice...
[15:57:30] <rue_house> what is the time for one pixel then? 8ns?
[15:57:52] <Xark> rue_house: Yes, you can use SPI, however annoying it is 9-bits. You can also use serial (8-bits, so nice except lose serial port). My technique is just straight bit-banging without hardware assistance (so you can still use serial and SPI port).
[15:58:32] <rue_house> I wonder if the buffer empty interrupt could keep the shift register fed
[15:58:45] <rue_house> or if you would get slip between bytes
[15:59:33] <rue_house> cool people!
[16:00:41] <Lambda_Aurigae> I'm not actually getting 800x600...more like 400x600....
[16:00:54] <Lambda_Aurigae> but it's pushing the monitor at 800x600 vga.
[16:00:57] <Lambda_Aurigae> svga
[16:01:28] <Lambda_Aurigae> real 800x600 is 40MHz...which I did achieve once by interleaving 2 chips and using a pll to double my clock frequency...but that on a solderless breadboard was,,,,not good.
[16:01:31] <Lambda_Aurigae> unstable as hell.
[16:04:25] <Xark> Lambda_Aurigae: Yeah, I did some 40Mhz 8051 VGA stuff and it wasn't too pretty on a breadboard. :)
[16:06:09] <Xark> I barely got 640x480 though (and processed every other scanline). However fun hack for ~1K MCU ->
https://imgur.com/nDceh
[16:06:20] <Lambda_Aurigae> anything over 20MHz gets real flakey on solderless breadboard.
[16:08:17] <Xark> Lambda_Aurigae: So in your design are you using quad-SPI?
[16:08:30] <Lambda_Aurigae> only using the dual spi right now.
[16:08:47] <Xark> Lambda_Aurigae: You mean two chips or two data lines per chip?
[16:08:48] <Lambda_Aurigae> I have played with the quad but not enough memory in the chip for that to be useful.
[16:08:54] <Lambda_Aurigae> 2 datalines per chip.
[16:08:58] <Xark> I see.
[16:09:09] <Lambda_Aurigae> the chips I have are capable of single, dual, or quad.
[16:10:25] <Lambda_Aurigae> http://www.microchip.com/wwwproducts/Devices.aspx?product=23LC1024
[16:10:27] <Xark> Lambda_Aurigae: An IRC friend did a project with 4-bit VGA with the QSPI doing direct scanout to DAC for VGA (64KB SRAM). Worked pretty nicely.
http://www.fleasystems.com/fleatiny.html
[16:11:07] <Lambda_Aurigae> same kind of idea..
[16:11:56] <Lambda_Aurigae> I'm just doing mono right now but figure I can do 8color pretty simply by adding more chips and a little glue logic.
[16:11:59] <Xark> Lambda_Aurigae: I tried some VGA stuff with AVR, but even 20Mhz was too slow (without external help).
[16:13:04] <Lambda_Aurigae> Xark, that's why I'm not actually using the AVR to generate the video signal..just the sync pulses and to reset the chips for each frame scan.
[16:14:04] <Lambda_Aurigae> and let the chips run free for the whole display sequence....it is counting during the horizontal blank time too.
[16:14:16] <Lambda_Aurigae> so uses a bit more memory than it should.
[16:14:35] <Lambda_Aurigae> if I had an oscope then I could get my timing down right so I could turn them on and off for each scanline.
[16:14:36] <Xark> Lambda_Aurigae: Yep. You need some external circuit unless you are OK with extreme low-res. Interesting how you are triple buffered.
[16:16:00] <Xark> Lambda_Aurigae: Consider getting a cheap logic analyzer. Awesome for getting timing right (capturing digital signals). Perhaps
http://www.seeedstudio.com/depot/Logic-Pirate-p-1750.html
[16:16:07] <Lambda_Aurigae> my "computer" writes to the write buffer...then the controller AVR handles the copying over at the same time there is a display scan happening...it sets one chip up to clock data out sequentially and the other to clock it in sequentially, then pulses the clock lines really fast.
[16:16:28] <Lambda_Aurigae> hehe..logic pirate is where I got the idea to use the serial srams in the first place.
[16:16:35] <Xark> :)
[16:16:39] <Lambda_Aurigae> I have one I made...with more memory than that one.
[16:17:24] <Lambda_Aurigae> I need to go to the dungeon and work on this whole project some more...haven't touched it in about 3 months.
[16:17:27] <Xark> I have an analog scope (which is great), but I tend to use my LA to capture an entire frame of video and examine the timing etc.
[16:19:17] <Lambda_Aurigae> have had too many other projects of the non-electronics sort to work on lately.
[16:19:29] <Lambda_Aurigae> will get back into it come winter when I can't work outside.
[16:19:39] <Xark> Fair enough. :)
[16:20:52] * Xark relaxes by tinkering with small AVRs and FPGAs at a low-level instead of bloated multi gigabyte C++ apps during the week. :)
[16:20:56] <Lambda_Aurigae> with having the 2 stage buffer system with the output double buffered I do eliminate display flicker and things showing up half way through a screen refresh.
[16:21:32] <Xark> Lambda_Aurigae: Yes, it is a simple sure-fire way to achieve that (without complex timing or racing the beam).
[16:21:40] <Lambda_Aurigae> yup.
[16:21:55] <Lambda_Aurigae> can take as long as I want to draw what I want on screen then trigger the display upload.
[16:22:09] * Xark hates "tearing" (or rendering while things are getting scanned out)
[16:22:29] <jeremyabel> I don't think anyone likes tearing!
[16:22:32] <jeremyabel> I know I don't
[16:22:38] <Lambda_Aurigae> sounds like a personal problem to me.
[16:22:39] <Xark> Lambda_Aurigae: How fast can AVR "render" to SPI SRAM?
[16:23:11] <jeremyabel> Xark:
https://www.youtube.com/watch?v=sNCqrylNY-0 have you seen this?
[16:23:36] <Xark> jeremyabel: Indeed. :) Very cool.
[16:23:44] <jeremyabel> guy's one of my heros for sure
[16:23:52] <jeremyabel> everything he makes is super cool
[16:24:00] <Xark> jeremyabel: Yes, great stuff.
[16:24:04] <Lambda_Aurigae> think I'm writing at 400Kb/s but that's a limit of my spi routine.
[16:24:08] <jeremyabel> somehow still manages to be married with a kid
[16:24:25] <Xark> Lambda_Aurigae: Are you rendering fonts and stuff?
[16:24:45] <Lambda_Aurigae> haven't gotten that far yet.
[16:24:52] <Lambda_Aurigae> but that should be fairly simple really.
[16:26:47] <dunz0r> The itoa()-weirdness could be on just the ATTiny... I distinctively recall using it on an Atmega328 and not having any issues with it.
[16:26:57] <dunz0r> Maybe it's very RAM-heavy?
[16:27:01] <Lambda_Aurigae> dunz0r, possibly...a memory issue.
[16:28:09] <dunz0r> Since the Attiny4313(which I tried this on) just has 256 bytes of SRAM as opposed to the 328s 2kB
[16:28:44] * Xark gets back to work adding 4 voice 8-bit audio to his "AVR video game system"... :)
[16:28:58] <jeremyabel> :D
[16:29:17] <dunz0r> *sigh*. I really, really need to clean my workbench...
[16:29:18] <hmw> anyone ever doing real work with AVRs or only playing? *smirks*
[16:29:27] <Lambda_Aurigae> playing here.
[16:29:27] <jeremyabel> I guess I am? :P
[16:29:30] <dunz0r> I just lost my only rotary encoder. On the desk. Can't find it :D
[16:29:38] <jeremyabel> stuff I'm doing is paid work at least, if that makes it real work!
[16:29:49] <Lambda_Aurigae> dunz0r, go rip the radio out of your mom's car...should have at least one in it,,maybe 2.
[16:29:49] <dunz0r> hmw: I've built a few robots and a timer-box-thingie for a shooting range :)
[16:29:58] <jeremyabel> project is kinda dumb though
[16:30:00] <hmw> jeremyabel: that counts as real
[16:30:01] <Xark> dunz0r: Losing parts that are in arms reach is a sure sign of workbench clutter. :)
[16:30:12] <Lambda_Aurigae> Xark, that or cats.
[16:30:13] <jeremyabel> coffee-mug shaped wireless accelerometer-based game controllers...
[16:30:25] <dunz0r> Lambda_Aurigae: But it's like 50 kilometers... can't I take my neighbours stereo instead?:D
[16:30:28] <Lambda_Aurigae> jeremyabel, is this for a Dilbert Cartoon game?
[16:30:33] <jeremyabel> Lambda_Aurigae: god I wish
[16:30:35] <Lambda_Aurigae> dunz0r, if you can get in.
[16:30:38] <jeremyabel> no, a coffee machine company
[16:30:43] <Xark> Lambda_Aurigae: Hehe, totally. Bad news when a cat gets in my lab unsupervised...
[16:30:46] <jeremyabel> for an event they're doing, and mall kiosks
[16:30:48] <hmw> heh... shooting range that is easy... i have a race clock using a laser pointer to measure times of RC cars. New nifty gadget for the Metalab incoming!
[16:30:53] <dunz0r> I think I may have a shimmy here somewhere, just in case, you know.
[16:31:13] <Lambda_Aurigae> brick works too.
[16:31:23] <Lambda_Aurigae> usually quicker as well.
[16:31:45] <dunz0r> hmw: Yeah, it's a horribly simple circuit, relay controlling a larger relay that turns the targets at the correct time + LCD and buttons.
[16:31:55] <dunz0r> But it was fun and I even got paid :]
[16:32:22] <hmw> I hope, I will get similar tinkering jobs, too
[16:32:33] <dunz0r> Working on version ~1.0 of that same project right now, since the first one is built with an Arduino + perfboard
[16:32:41] <dunz0r> It aint pretty, but it sort of works :D
[16:32:59] <jeremyabel> hmw: if you live in a city, check out places that do interactive installations for art or advertising
[16:34:01] <Lambda_Aurigae> I made a jeopardy game pushybutton thing once....up to 8 buttons...first to press got a little flashy light in front of them...super simple....was for work,,,but I didn't get paid for it specially as I did it during work hours. It was for games at the company christmas party..
[16:34:02] <jeremyabel> I'm working at a place like that right now, hence the weirdo ad ideas
[16:34:25] <dunz0r> Lambda_Aurigae: Oh, I did that too, but with just three buttons :)
[16:34:42] <dunz0r> Did it for a big computer party thingie where I'm part of the crew.
[16:34:56] <Lambda_Aurigae> they used it one year for a jeopardy like game and another year for a family feud kinda thing.
[16:35:38] <Lambda_Aurigae> used a bunch of mosfets out of copiers for driver chips and an atmega32 from free sample.
[16:35:50] <dunz0r> haha :D
[16:35:53] <Lambda_Aurigae> the lights were 12V car tail lights.
[16:36:52] <Lambda_Aurigae> I tried getting the local artsy fartsy guys into microcontrollers....after two lessons they were like, "this is too hard, we are gonna get arduinos."
[16:37:00] <Lambda_Aurigae> I haven't talked to them since.
[16:37:00] <jeremyabel> lol
[16:37:11] <jeremyabel> and they'll never move beyond arduino...
[16:37:15] <jeremyabel> it's a black hole, that thing
[16:37:16] <Lambda_Aurigae> probably not.
[16:37:29] <dunz0r> Arduinos are a good start though. Trying to dive right in to "proper" AVR isn't a small feat.
[16:37:32] <Lambda_Aurigae> second class we made RGB LED throwies deadbug style.
[16:37:34] <jeremyabel> yeah
[16:37:42] * dunz0r started with Arduinos and then moved on to "real" C
[16:37:42] <Lambda_Aurigae> with random colors!
[16:37:55] <jeremyabel> heh, I started like a year before Arduinos came on the scene
[16:37:59] <jeremyabel> I started with ASM even!
[16:38:05] <dunz0r> jeremyabel: Hipster :P
[16:38:13] <jeremyabel> somehow got it into my head that I Couldn't use C for some reason, like it wasn't supported
[16:38:13] <Lambda_Aurigae> literally, an attiny45, 3V lithium battery, and an RGB LED...
[16:38:16] <Lambda_Aurigae> and a little wire.
[16:38:21] <jeremyabel> dunno where I got that idea though
[16:38:51] <Lambda_Aurigae> jeremyabel, when I started with microcontrollers you had to buy the C compiler..there were none free for the pic chips I was using.
[16:38:52] * dunz0r uses arduino-boards but regular C
[16:38:57] <jeremyabel> ha
[16:39:02] <dunz0r> And on my own designs I just use the bootloader.
[16:39:12] <jeremyabel> dunz0r: yeah, I'm making do with that now too,
[16:39:15] <jeremyabel> only I killed the bootloader
[16:39:31] <jeremyabel> I took 75% of arduino's USART class though
[16:39:33] <dunz0r> Not on this Attyiny-board though, so little PROGMEM :)
[16:39:49] <jeremyabel> it's a nice USART class though
[16:40:08] <hmw> Aaah! I might have found the problem that was causing the "i2c" bug, I was asking about yesterday. But it doesn't make too much sense.
[16:41:05] <hmw> ah. now it makes sense. I have that sucker nailed down finally. It was a software bug.
[16:41:18] <jeremyabel> nice
[16:41:23] <jeremyabel> i2c is on my "to learn" list for sure
[16:41:32] <jeremyabel> might have to for this project, not sure yet
[16:43:15] <hmw> My bug didn't have anything to do with i2c, though. But I learned how to use my mail stamp sized osci/bus sniffer while looking for the error.
[16:43:26] <jeremyabel> nice
[16:44:09] <hmw> This is so great. Now all the pieces start falling together and start working. My NOPS is almost done.
[16:44:30] <dunz0r> hmw: NOPS?
[16:48:17] <hmw> Portable AVR computer with several applications, e.g. entering machine code to flash. NOPS = "No Operating System". Trying to up an image...
[16:48:51] <jeremyabel> good name
[16:49:07] <hmw> thanks :)
[16:50:42] <hmw> NOPS proto 1:
http://imgur.com/Mtr5lfa,wDe1jUt
[16:50:55] <jeremyabel> ha neat!
[16:52:42] <hmw> It has a breadboard inside with a test i2c slave.
[16:53:09] <Jartza> agh
[16:53:11] <Jartza> stupid flu
[16:53:19] <Jartza> can't even sleep, it seems
[16:53:27] <Jartza> more medicin then, and some coding :)
[16:53:38] <hmw> Coding is the best medicine *grin*
[16:54:09] <Jartza> talking about i2c, I just implemented bitbang i2c to attiny85
[16:55:14] <Jartza> only master, though, and only writing so far
[16:55:44] <Jartza> I've used several i2c devices and wrote linux drivers to them, but never actually implemented the i2c itself before
[16:56:05] <Jartza> it was a nice excercise
[16:56:26] <hmw> I worked through the app note about i2c. Nice exercise, true.
[16:57:12] <hmw> I found it somewhat hard and didn't finish my bit-banging version. Using Fleury's lib now.
[16:57:34] <Jartza> that's what everyone suggested to me too, but I wanted to nail it myself
[16:57:50] <Jartza> although, I bet Fleury's lib is much more advanced and optimized than mine
[16:58:10] <Jartza> and this works for me
[16:58:13] <hmw> It is neat. You may want to take a look at it to get ideas.
[16:58:28] <Jartza> yeah, some day ;)
[16:58:41] <Jartza> I needed the i2c to talk to cheap lcd screens, which only have input
[17:00:46] <hmw> Reminds me on my first display controller (main mcu --> i2c slave (t45 LCD controller) --> SIPO --> LCD). That sucker is so slow!
[17:10:33] <Jartza> now that I tried it, it does compile though
[17:10:46] <Jartza> so I have no idea what was I doing when it didn't :)
[17:11:14] <Jartza> but I'll use my own still, as it's smaller ;)
[17:11:24] <Jartza> shenanigans:firmware jartza$ avr-size --format=avr --mcu=attiny85 i2c.o
[17:11:28] <Jartza> Program: 162 bytes (2.0% Full)
[17:13:21] <hmw> sounds nice
[17:14:25] <Jartza> good enough and looks ok with saleae
[17:23:19] <Jartza> main point was anyway that I wanted to learn to talk to i2c "myself"
[17:23:49] <Jartza> maybe later I'll switch to fleury's lib if I need reading too, or want "proven" lib :)
[17:24:35] <hmw> It doesn't bitbang, which is of course preferable.
[17:25:32] <Jartza> it does on attiny
[17:25:37] <Jartza> as attiny doesn't have i2c hw
[17:25:54] <Jartza> i2c could be done with USI, but I haven't tried that yet
[17:26:08] <hmw> hm. my copy of that lib can't bitbang. Perhaps we are talking about different programs.
[17:26:22] <hmw> ah, that was it... my other library does it in USI
[17:28:42] <Jartza> yeah, I haven't used USI yet, maybe I'll dig into that too some day
[21:25:40] <woodyj21> clear
[21:25:47] <woodyj21> window