Back
[00:03:41] <mark4> im having a minor issue with atmel studio and im wondering if anyone can tell me if there is anything i can do about it
[00:04:19] <mark4> i have a directory structure for my project. i have the project dir, under that i have src and under that i have kernel. there are many files in kernel but only ONE of them is to be assembled
[00:04:24] <mark4> it includes all the others
[00:04:50] <mark4> when i add this file to the project the IDE copies it out of that directory into the root of the project. is there any way i can have it NOT do this?
[00:05:56] <mark4> the simple answer is to create a load file in the project root and i can do that if the ide INSISTS that the project sources be in the prokect root (stupid)
[00:06:10] <mark4> project even
[03:24:44] <Flipp_> noob question: Is it possible/conventional to write a main program via AVRDUDE+ICSP without erasing the chip first?
[03:34:34] <dufa> Flipp_: I think the -D flag in avrdude disables erasing the flash
[03:37:01] <Flipp_> dufa: thanks. just as I find it, you mention it :)
[03:37:26] <dufa> It is possible, but I don't believe it's conventional, since it's not the default option :)
[03:38:26] <Flipp_> dufa: yeah. I'm just futzin' around with bootloaders + "main programs" now, learning how the chip handles
[03:38:28] <Flipp_> :)
[03:39:53] <Flipp_> ordinarily I assume you'd use the bootloader to actually program the no-read-while-write memory location, aka the main program... right?
[03:42:52] <dufa> To my underastanding, yes. To be honest, though, I've so far only used external programmers without using bootloaders.
[03:44:09] <Flipp_> dufa: yeah, I'm blundering my way through this just to learn. I can program just fine via a buspirate, but I'm trying to learn the quirks between bootloaders, main programs, and their respective status registers :)
[03:44:31] <Flipp_> dufa: if I understand it, if you're planning to program directly, there's usually no reason to have a bootloader
[03:45:05] <Flipp_> dufa: but if you wanted to, say, program via Bluetooth, you'd have to have a bootloader in the read-while-write section of the chip that would program the main program
[03:50:36] <dufa> yeah, I was doing a custom USB chording keyboard once, and considered making it programmable using the usb connection. I lost hope in the project before I ever got around to implementing it, thogh
[04:09:07] <dufa> Does anyone know if there is a channel somewhere for embedded linux and/or ARM topics?
[05:34:35] <aczid> dufa: if you find it I'd like to know too :)
[06:49:59] <Lambda_Aurigae> Flipp_, just so you know, you can NOT write to a section of flash without first erasing it.
[06:50:24] <Lambda_Aurigae> dufa, same comment as above but directed to you.
[06:50:45] <Lambda_Aurigae> wait,,which,,,ok, I guess it was Flipp_ who asked the question.
[06:50:53] * Lambda_Aurigae will go back to eating breakfast and reading comics now.
[10:44:03] <mark4> anyone awake?
[10:44:34] <dufa> mark4: aawefwfahs
[10:44:40] <dufa> yes...
[10:44:42] <mark4> im having a problem with the AVR version of gcc thats not a problem in any other version.
[10:44:49] <mark4> i compile a string with a leading length byte
[10:45:00] <mark4> so i have a line that looks like this in the macro
[10:45:18] <mark4> .byte 9f - (. + 1)
[10:45:27] <mark4> .ascii "\the string"
[10:45:30] <mark4> 9:
[10:45:42] <mark4> the 9f is a forward reference to the 9: local label
[10:45:52] <mark4> well "9f" is an address and is thus too big to fit in a byte
[10:46:33] <mark4> its not compiling the address. its compiling the distance from .+1 TO that address
[10:47:09] <mark4> where do i report bugs for avr-gcc?
[10:48:07] <martinus> Don't you mean features? :)
[10:50:49] <dufa> there is an atmel bugzilla:
http://asf.atmel.com/bugzilla/
[10:51:02] <dufa> That might be the right place...
[10:52:44] <mark4> aha. yea just foud that lol
[10:52:54] <mark4> any ideas how to get around this "feature"?
[11:28:13] <mark4> erm is a .int a 16 bit value for an AVR?
[11:28:38] <LeoNerd> C requires int to be at least 16 bit. I don't imagine why a C compiler would ever make it any *larger* than that
[11:28:49] <LeoNerd> If you wanted a definitely-16 bit value though, you could consider int16_t
[11:31:36] <mark4> so i need .long for 32 bits?
[11:31:45] <mark4> no im not using C types
[11:31:47] <mark4> this is assembler
[11:34:00] <mark4> value of 121074 too larget for field of 2 bytes at 139 (line 139 of a TEMPORARY file created during the buld) lol
[11:34:29] <mark4> i guess you cant store a .INT in the .text section
[11:37:05] <mark4> this is screwed up. i cant store a 32 bit address in a 16 bit flash address and i cant convert that 32 bit address into a 16 bit offset becase "target - source" addresses are ADDRESSES and wont fit in 16 bits
[11:37:24] <mark4> fucking stupid avr gcc lol. this works on every othre version of gcc in existance
[11:37:34] <mark4> address-address can be 8 or 16 bits
[11:37:44] <mark4> except with avr
[11:40:42] <mark4> .long 1f code code code 1: <-- oopts .long is 32 bits and you cant put a 32 bit value in the .text section wtf?
[11:41:15] <mark4> this one i have no idea how to work around
[11:42:09] <LeoNerd> I suspect few people here are really able to follow along; we don't really get much assembly-level chat around the channel
[11:42:21] <LeoNerd> So don't expect *too* much reply :)
[11:45:09] <mark4> theres plenty of people in here that do asm
[11:45:16] <mark4> those are the sane ones :P~
[11:45:33] <mark4> writing embedded applications in C is like opening a ca
[11:45:34] <mark4> can
[11:45:37] <mark4> with a rock
[11:45:43] <mark4> :)
[11:53:28] <aandrew> lol
[11:53:30] <aandrew> why do you say that
[12:04:00] <twnqx> mark4: i disagree
[12:04:21] <twnqx> i have embedded applications with thousands of lines of C
[12:04:30] <twnqx> doinf that in asm would be insane
[12:06:19] <mark4> that quote is from a good friend of mine who has (like me) over 30 years of doing low level realtime embedded control applications development in C and Forth.
[12:06:38] <mark4> development in forth is significantly faster than development in C and the result is about 100 times smaller
[12:06:48] <twnqx> surprising
[12:06:51] <mark4> well. 100 times smaller for any non trivial example
[12:07:10] * twnqx wonders how that is possible
[12:07:12] <mark4> doing it in forth would be trivial
[12:07:15] <mark4> how its possible?
[12:07:27] <twnqx> yes
[12:07:33] <mark4> well i can show you a real world example (or could if my domain had not expired)
[12:07:39] <twnqx> having the same code functionality in just 1% of the binary
[12:07:44] <mark4> have you ever done any lib ncurses development?
[12:07:48] <twnqx> no
[12:07:57] <mark4> well libncurses is about 500+k in size
[12:08:04] <twnqx> ncurses to be is beyond embedded for me
[12:08:10] <twnqx> s/to be//
[12:08:25] <mark4> i rewrote it in forth and my code fits in 6k and i can do a bunch of shit with it that is almost impossible with ncurses
[12:08:42] <aandrew> yeah I call bullshit on forth compiled code being 1% of C compiled code for any nontrivial example
[12:08:50] <twnqx> i also call shit
[12:08:52] <mark4> like having any number of overlapping windows and having the windows move around in the "screen" while text is scrolling left/right/up/down in each window
[12:09:01] <aandrew> if there's even >10% difference the C compiler is crap or intentionally hobbled
[12:09:04] <twnqx> on comparing "i wrote a condensed version on my own" vs "i uses an external library"
[12:09:10] <mark4> aandrew, your speacking from years of ignornace of forth :)(
[12:09:14] <twnqx> no
[12:09:20] <twnqx> you compare apples to peaches
[12:09:36] <twnqx> or does forth come with a curses style library?
[12:09:42] <mark4> i have the same functionality (other than sub windowing which i have not needed so didnt implement)
[12:09:50] <mark4> other than that i can do EVERYTRHING ncurses can do
[12:09:59] <mark4> same functionality in 6k instead of 50+k
[12:10:01] <twnqx> does your library, like curses, handle hundreds of different terminal types and their respective color and other escape codes, or are you down to bare ansi
[12:10:03] <mark4> 500+
[12:10:19] <aandrew> I do not doubt that forth makes certain types of programming easier but I very much doubt that the compiled binary is appreciably smaller
[12:10:20] <mark4> it can handle every terminal type that has a terminfo file
[12:10:26] <LeoNerd> twnqx: Terminals differ *far* less these days than you'd imagine
[12:10:36] <LeoNerd> Also terminfo doesn't know most of the modern features, and most of the modern differences
[12:10:55] <mark4> LeoNerd, correct.
[12:10:55] <LeoNerd> In 1980, terminfo could tell you whether the giant lump of plastic and glass knows bold or not
[12:11:14] <LeoNerd> In 2015, terminfo can't know whether I typed ./configure --enable-256color when I built my terminal from source
[12:11:15] <mark4> actually it tells you a little bit more than that
[12:11:30] <twnqx> and that's why ┌ vs + depends on TERM variable, hm?
[12:11:31] <mark4> like the escape sequences for most of the cursor stuff
[12:11:32] <LeoNerd> The way to know what the terminal can do is *gasp*: to ask it
[12:11:39] <LeoNerd> Hah! No it doesn't
[12:11:44] <twnqx> interesting
[12:11:49] <LeoNerd> terminfo doesn't e.g. tell you how to change the cursor shape. There's no strings for it
[12:12:06] <twnqx> no system that does not have my urxvt terminfo file displays midnight commander in "good looking"
[12:12:22] <twnqx> e.g. any crap stock debian
[12:12:26] <mark4> LeoNerd, ask a terminal to put the cursor at "1:1" is an escape sequence. the sequence can be different for every terminal type. tho thers usually overlap
[12:12:41] <mark4> thers also things like turn on bold, underline etc etc. and turn off (turn off is a PITA)
[12:12:42] <LeoNerd> mark4: On any terminal that matters in 2015, that is CUP; cursor position
[12:12:44] <LeoNerd> CSI G
[12:12:46] <mark4> sgr and sgr0
[12:12:47] <LeoNerd> Er.. CSI H, sorry
[12:12:57] <twnqx> (all of which doesn't matter if you connect via serial, since plain ANsI works sufficiently good)
[12:12:58] <LeoNerd> Yesyes; I'm well-aware
[12:12:59] <mark4> ues CUP is the terminfo name for it
[12:13:25] * LeoNerd wrotes libvterm, libtickit, libtermkey, advised Thomas Dickey on how to maintain xterm, advised tarruda on how to reimplement neovim's UI,...
[12:13:27] <twnqx> anyway
[12:13:34] <LeoNerd> ;)
[12:13:35] <twnqx> you *still* compare an external library
[12:13:48] <twnqx> that evolved over decades to support EVERYTHING
[12:13:50] <twnqx> to your own code
[12:13:53] <mark4> to turn off BOLD and nothing else you output an SGR with the right parametes. problem is, almost NO terminfo database lists the SGR and only lists the SGR0 (turn off ALL)
[12:14:05] <twnqx> and i bet you could have done the same that you did in your 5k of forth
[12:14:07] <LeoNerd> Yah.. terminfo doesn't play nice with the SGR stuff.. :/ It's awkward
[12:14:08] <twnqx> in 5k or less of C
[12:14:09] <mark4> i compare its functionality against mine
[12:14:12] <twnqx> no you don't
[12:14:21] <twnqx> did you even try to write the same in C
[12:14:25] <mark4> LeoNerd, yes and terminal INPUT is also a pita lol.
[12:14:28] <twnqx> to see if you could get it as small?
[12:14:40] <mark4> your the first persion ive met in about 10 years that knows anyhthing about terminfo :)
[12:14:42] <twnqx> you compare a generic library vs a full custom one
[12:14:48] <LeoNerd> My xterm libtickit driver is much nicer. It calculates the smallest set of SGR arguments to make the required change; either turn things on/off, or reset and set the desired state.
[12:15:24] <LeoNerd> And it knows about much more of the SGR - bold, under, italic, altfont, blink, strikethrough, fg/bg colour (256)
[12:15:30] <mark4> LeoNerd, right now my "library" does the SGR0 then reinstates the things it didnt want to turn off
[12:15:32] <LeoNerd> (doesn't yet support RGB8 though; should add that)
[12:15:47] <aandrew> SGR is ?
[12:15:55] <twnqx> makr4: how aboput i give you one of my larger projects
[12:15:57] <LeoNerd> Yah; that's reasonable, but not always byte-efficient. Turning off one option and leaving on the other 4, say,..
[12:16:01] <LeoNerd> aandrew: Select Graphic Rendition
[12:16:01] <twnqx> 0 external libraries, bare metal avr
[12:16:12] <twnqx> or next to, i think it uses reduced sprintf
[12:16:13] <LeoNerd> I call it "set pen"; it selects the rendering attributes to be used for more text
[12:16:22] <twnqx> and then you show me how to shrink it to 1%
[12:16:45] <mark4> oooh maybe you can help with alt charset things lol. my code is broken for that but ONLY on the linux terminal. the linux terminal does not require the ENACS because theoretically its permanantly enabled. but in that terminal and that terminal alone i cannot get the alt charset to work
[12:16:54] <mark4> works fine in any X terminal
[12:16:58] <LeoNerd> Oh, I wouldn't bother with those
[12:17:04] <LeoNerd> Nobody uses 2022 any more. Just use Unicode
[12:17:17] <LeoNerd> Seriously, if in 2015 people can't cope with Unicode, then lend them $0.02 to buy a real terminal
[12:17:22] <twnqx> :D
[12:17:25] <twnqx> good choice
[12:17:49] <mark4> LeoNerd, im sure i can figure out how to support unicode :)
[12:17:59] <mark4> but its till bugs me that my existing code does not work in that one area :P
[12:18:22] * LeoNerd waves the libtickit advertising banner again then; full unicode support there
[12:19:07] <twnqx> mark4: on what platform do you even get to use curses? in my oppinion it either doesn't matter as it runs something big enough for network stack etc anyway, or you don't need the functionality
[12:19:46] <twnqx> (my linux 64 bit ncrses is also just 330kB, including all the ELF overhead which probably is a third of that)
[12:20:32] <aandrew> I'm a little confused as to how you're doing all this on AVR :-)
[12:20:41] <mark4> doing all what?
[12:20:55] <mark4> i would send you my sources but they are not even close to complete
[12:21:13] <mark4> twnx gentoo linux on my desktop AND gentoo linux on my beagleboard XM (arm)
[12:22:14] <twnqx> gentoo linux on all PCs here, too
[12:22:32] <twnqx> admittedly i don't consider that embedded
[12:22:37] <twnqx> beaglebone & co
[12:22:50] <twnqx> if it runs more than an RTOS, it's not embedded any more
[12:23:17] <megal0maniac> twnqx: I just got one of these
http://wrtnode.com/
[12:23:17] <LeoNerd> Linux "that feels like a PC", that just happens to be running on a small CPU on a bare PCB doesn't automatically make it "embedded"
[12:23:21] <megal0maniac> It's pretty cool
[12:23:23] <mark4> i dont have a BBB i have the BB-Xm
[12:23:26] <LeoNerd> That's just a small PC
[12:23:31] <megal0maniac> It is
[12:23:49] <mark4> twnqx, if it runs an rtos its a pita unless that rtos is linux or forth :)
[12:23:57] <megal0maniac> But it's very small, and quite capable.
[12:24:10] <mark4> yes. the PI2 is a very powerful small desktop computer, not even CLOSE to embedded
[12:24:16] <twnqx> if it runs a full OS it's not embedded
[12:24:27] <twnqx> imho.
[12:24:51] <twnqx> your oppinion may differ, but then we're not talking about the same things
[12:24:54] <megal0maniac> twnqx: Would OpenWRT be considered a 'full OS' by your standards?
[12:24:57] <twnqx> yes
[12:25:17] <twnqx> it's just another linux distribution
[12:25:28] <twnqx> minimalistic, but sufficiently complete
[12:25:52] <aandrew> megal0maniac: interesting
[12:26:04] <mark4> ill be getting some raspberry pi 2's here soon, about 7 of them. ill be putting gentoo linux on all of them :P
[12:26:08] <mark4> brb
[12:26:22] <megal0maniac> aandrew: One of the coolest things is that it has an ethernet switch built-in
[12:26:23] <twnqx> turn them all into a large distcc farm!
[12:27:06] <megal0maniac> So I'll probably gut an old 100mbit switch and use the magnetics and ports to make a router
[12:27:47] <twnqx> woo-hoo.
[12:27:59] <twnqx> i just got myself an ubiquity edgerouter for that
[12:28:23] <twnqx> (what would i even do with a 100mbit router, accept being annoyed by far too slow wlan...)
[12:28:24] <megal0maniac> Yeah but I'll use it for other stuff too
[12:28:43] <megal0maniac> Haha yes yes. Practically I wouldn't use it for much
[12:29:18] <twnqx> Linux router 3.10.20-UBNT #1 SMP Thu Oct 16 16:29:39 PDT 2014 mips64
[12:29:21] <twnqx> edgerouter.
[12:29:52] <twnqx> dual core 64bit mips cavium
[12:30:08] <twnqx> 512MB ram, 2G flash
[12:30:14] <megal0maniac> Good grief
[12:31:25] <twnqx> 3x gbit ethernet, one of them connected to a 3port switch :3
[12:32:05] <megal0maniac> Is that the edgerouter lite?
[12:32:40] <twnqx> erpoe-5
[12:33:06] <twnqx> basically same as the lite, but the switch is only in that, and the poe functionality
[12:33:14] <twnqx> i have my access points hanging from it
[12:33:24] <megal0maniac> Yeah that's way out of my budget
[12:33:44] <megal0maniac> I have an old TP-Link WR1043ND at home for actual infrastructure
[12:34:00] <twnqx> so 25$ plus some parts and building is in, but 100$ is out? sad :X
[12:34:37] <megal0maniac> It's about $200 here
[12:34:52] <megal0maniac> That's dealer price. And the exchange rate is horrendous
[12:35:32] <twnqx> 100$ is msrp :S
[12:35:32] <megal0maniac> I live in South Africa
[12:35:48] <megal0maniac> I paid under $50 for the TP-Link
[12:36:10] <twnqx> it's 100€ in the online shops here
[12:37:51] <learath> tp-link has always struck me as a poorly thought out name.
[12:39:56] <megal0maniac> learath: It's fantastic bang-for-buck though. And the best quality of the Chinese stuff
[12:42:05] <megal0maniac> RikusW :)
[12:42:18] <RikusW> hi megal0maniac
[12:43:16] <learath> megal0maniac: I have no real opinion on their quality
[12:43:46] <megal0maniac> learath: My entire home network is run on it
[12:44:08] <megal0maniac> And it's far more complex than necessary, of course :P
[12:45:20] <learath> heh. yeah, I run a Mikrotik router :)
[12:45:37] <megal0maniac> I've wanted to get one for years
[12:45:40] <megal0maniac> But I never do
[12:46:02] <learath> I'm tempted by one of the new Tile based routers, for no reason I can explain
[13:01:00] <specing> maybe because 36 cores?
[13:01:09] <specing> and they are hardly new
[13:02:29] <learath> specing: heh, fair enough :)
[13:02:42] <learath> I'd probably *only* get the 9 core v ersion
[13:02:48] <learath> and there's a new 72 core version of teh tile
[13:03:54] <specing> learath: no point in 9 core
[13:04:05] <specing> can get an octa cortex-a53
[13:04:27] <mark4> specing, what do you mean no point?
[13:04:42] <mark4> chuck moore creates 144 core processors using a VLSI editor he wrote himself
[13:04:50] <mark4> and yes, they are in production
[13:05:16] <mark4> the most intel can manage is 9?
[13:13:37] <specing> chuck moore?
[13:14:14] <specing> mark4: less faster cores is better than more slower ones @intel
[13:20:58] <mark4> specing, which is why machines need 1000+ watt power supplise now :)
[13:21:22] <mark4> ch's 144 core processors use MINUTE amouts of current
[13:21:27] <mark4> ultra minute
[13:21:50] <mark4> of course, they are not "Desktop" cores
[13:33:14] <specing> oh cool, that 144 core is an async processor
[13:34:36] <LeoNerd> Like a Niagra?
[13:34:57] <aandrew> async processing is kind of weird to get your head around
[13:52:12] <RikusW> and difficult to program for..
[13:55:03] <mark4> specing hang on ill link
[13:55:20] <mark4> www.greenarraychips.com
[13:56:09] <mark4> RikusW, chuck moore has a quote i reference alot "The ANS forth standard does not describe the forth language but a language of the same name"
[13:56:16] <mark4> i apply that quote to HIS forths too now lol
[13:56:22] <mark4> specially his hardware forths
[13:56:42] <mark4> RikusW, any kind of programming is difficult
[13:56:55] <mark4> specially when your doing it withy braindead tools
[13:56:57] <mark4> like gcc
[13:56:59] <mark4> gnu as
[13:57:03] <mark4> atmel studio
[13:57:05] <mark4> etc etc
[13:57:09] <RikusW> mark4: I've seen the greenarray chips, are they made by chuck ?
[13:57:15] <mark4> yes
[13:57:24] <RikusW> nice, I didn't realize
[13:57:27] <mark4> he designed them using a VLSI editor he wrote in colorforth
[13:58:20] <RikusW> those are low power chips indeed
[13:58:27] <mark4> yup
[13:58:33] <RikusW> so have you used them ?
[13:58:36] <mark4> no
[13:58:39] <mark4> not yet, maybe never
[13:58:48] <mark4> i cant get my head around that shit lol
[13:59:14] <mark4> fuck i cant get my head around this AVR shit lol
[13:59:24] <mark4> RikusW, do you still do any avr asm?
[13:59:40] <RikusW> I haven't done much programming lately
[13:59:42] <mark4> if i sent you my sources could you tell me where the FUCK the error is? because line 5000+ does not exist in my sources
[13:59:49] <RikusW> but I still dislike avr-gcc
[14:00:03] <mark4> this is what i will use to replace it
[14:00:26] <RikusW> what kind of code is it ?
[14:00:31] <mark4> avr asm
[14:00:37] <RikusW> project ?
[14:00:39] <mark4> but the macros are scary :)
[14:00:57] <RikusW> what are the code for ?
[14:01:02] <mark4> a forth compiler in avr asm that ill put on my atxmega256a3bu xplained board
[14:01:16] <RikusW> ah
[14:01:19] <mark4> the board itself will be THE compiler (at least at first)(
[14:01:50] <mark4> i was compiling and assembling this entire project with my linux forth tools but the HEX file i outoput needs to be debugged
[14:02:02] <mark4> i ported it to an atmel stupido project for assembly with avr-gcc
[14:02:32] <mark4> just so i could single step with and unit test all 843792846928 of the primitives lol
[14:02:49] <RikusW> sounds bigish
[14:02:54] <mark4> not really
[14:03:02] <mark4> want me to zip up the project? :)
[14:03:11] <mark4> actually the code is not complete, im not trying to run it yet
[14:03:14] <mark4> just build what i hafve
[14:03:16] <mark4> have
[14:03:26] <mark4> some of the asm is left over from a different avr processor
[14:03:36] <mark4> so is not relevant to this one but i can change it later.
[14:03:45] <mark4> i just need it to BUILD not run
[14:04:03] <mark4> i still didnt finish the CPU initialization/reset code
[14:04:08] <RikusW> not sure I have that much spare time, but I could take a peek
[14:04:13] <mark4> doesnt matter. if the rest of it builds
[14:04:19] <mark4> remind me of your email addy lol
[14:04:35] <RikusW> how big would it be when zipped ? I've only got a GPRS connection...
[14:04:47] <mark4> hang on, ill zip and see
[14:06:00] <mark4> 98.7k wtf
[14:06:11] <RikusW> thats ok
[14:06:20] <mark4> ok my sources are not that big lol
[14:06:32] <mark4> no idea what is in the project tree that causes the zip to bge that HUGE
[14:07:19] <RikusW> possibly .o files ?
[14:07:33] <RikusW> or other compile output
[14:09:31] <mark4> no the error is
[14:09:41] <mark4> erm i was going to type it here but its in the email lol
[14:10:16] <mark4> error at line 5714 of a file thats not even 50 lines in length
[14:13:24] <mark4> RikusW, are you charged per byte?
[14:13:40] <RikusW> per mb
[14:13:58] <RikusW> about $0.02 per MB
[14:15:23] <mark4> ouch lol
[14:15:32] <RikusW> the other ISP charges $0.20/MB out of bundle
[14:15:34] <mark4> 0.0000000000002 would be fair :P
[14:15:39] <RikusW> indeed
[14:16:03] <RikusW> South African internet can't compare to USA ot EU
[14:16:21] <mark4> mote to north africa?? lol
[14:16:22] <mark4> } : )
[14:16:26] <mark4> they probably have it worse
[14:16:54] <RikusW> no way :-P
[14:18:26] <RikusW> ASF is like 300KB
[14:18:43] <mark4> is asf in there?
[14:19:17] <mark4> wtupid freeking tools ... tell me it didnt put the entire freeking asf in my project tree. is that why its so freeking huge?
[14:20:13] <RikusW> indeed :-D
[14:20:36] <RikusW> you seem a bit annoyed ;)
[14:20:49] <mark4> no lol im actually laughing at the entire thing
[14:20:58] <mark4> if i were annoyed i would be frothing at the mouth
[14:21:44] <mark4> the ONLY reason im even using these tools is because i have no other way to debug my code. i already wrote my own avr assembler and built this entire project using that
[14:21:49] <mark4> i output a .bin or .hex
[14:22:09] <mark4> debug that when every 4th of 5th opcode is a jmp to some obscure address
[14:22:22] <mark4> call foo... foo: do something... call bar... no returns
[14:22:34] <RikusW> I haven't hacked PDI debug yet, so can't help you there....
[14:22:50] <specing> RX packets 56600500 bytes 30322887475 (28.2 GiB)
[14:22:51] <mark4> you get tied into a mental gordian knot in no time flat
[14:22:57] <specing> you jelly RikusW ?
[14:23:09] <RikusW> ?
[14:23:43] <mark4> anyone not familiar with what my macros.s is doing would also be tied into a mental gordian knot lol
[14:23:57] <RikusW> seems so
[14:25:56] <RikusW> mark4: why not just use the assembler with AS4 ? it does support macros like .macro etc
[14:26:37] <RikusW> you might need to read a few docs to get the syntax right though
[14:27:18] <mark4> because its macros are braind ead
[14:27:30] <mark4> you cannot do what im doing in those gnu as macros
[14:27:32] <RikusW> worse than gcc's ?
[14:27:55] <mark4> about the best you can do is .macro mov r0, @0 mov r1 @1 .endm
[14:28:09] <mark4> orders of magnitude worse than the GNU as macros
[14:28:14] <mark4> look in macros.s
[14:29:01] <mark4> and im using as6 atm, im not sure if as4 would have been a better choice
[14:29:04] <mark4> i have both
[14:29:07] <RikusW> what doesn't work in the atmel asm ?
[14:29:24] <mark4> erm lunch time lol. its usually only 10 minutes
[14:29:37] <mark4> look at the _FORTH_ macro
[14:29:41] <mark4> and the header macro
[14:29:50] <mark4> show me how to do that with as4s assembler
[14:30:01] <RikusW> will have a closer look and try to compile your code a bit later
[14:30:08] <mark4> ill. brbm ill explain the macros to you
[14:44:30] <mark4> back
[14:45:27] <mark4> ok code/colon macros plus a bunch of others reference the header macro. this creates a new forth word header in a "headers" section. a header is a pointer to previous header, a name string (with leading count byte) and a pointer to the code in the .text (list section).
[14:46:32] <mark4> the _FORTH_ _COMPILER_ and _ROOT_ macros are used to create arrays of linked lists of word headers. tho i simplify the issue by linking all of them on the fist list in the array at assembly time. the gnu macros are not up to hasing those symbol names :P
[14:46:54] <mark4> the avr assembler cannot do macros of this sofistication at all
[14:47:29] <mark4> .macro push3 push @1 push @2 puch @3 .endm <-- thats about the most complex macro the atmel assembler is capable of
[14:47:43] <mark4> not sure if i got the syntax on that right but you get the idea
[14:54:50] <RikusW> seems like you're abusing macros ;)
[14:55:04] <mark4> no
[14:55:16] <mark4> the macros are not really that complex and imho this is exactly what macros are for
[14:55:28] <mark4> not .macrp push3 .... .endm bullshit
[14:55:53] <RikusW> seems my studio is 6.1, and won't open 6.2 projects :/
[14:56:04] <mark4> in my dos A386 assembler my macros not only do everything these do in a MUCH simpler way but it actually does do hashing on the symbols
[14:56:13] <RikusW> Atmel and their crazy strict versioning...
[14:56:17] <mark4> yea. doesnt supprise me
[14:56:26] <mark4> delete the project files
[14:56:57] <RikusW> they are as strict on the dragon fw version even though it doesn't seem to matter at all
[14:57:05] <mark4> create a new prj and add the xmforth.s to it. the one in the project root
[14:57:11] <mark4> dont add any of the src/kernel files to the project
[14:57:17] <RikusW> I've hacked AS4 to ignore the version and it works fine with AS6 fw
[14:57:41] <mark4> yea i was considering getting two so i wouldt have to keep potentially bricjking it
[14:58:02] <RikusW> Have you seen the new Atmel ICE ?
[14:58:03] <mark4> i would love to add dragon supoprt to my linux forth :)
[14:58:11] <mark4> not looked. cant afford
[14:58:24] <RikusW> its about the same price as the dragon
[14:58:35] <mark4> wouldnt mind reverse engineering the avr dragon fw
[14:58:41] <mark4> cant even afford that right now lol
[14:58:53] <RikusW> or cheaper if you take the bare board its only $30 iirc
[14:59:49] <mark4> maybe i can afford that. is it better than the dragon?
[15:00:45] <RikusW> it can do atmel arm too
[15:00:51] <mark4> a few years ago the eevblog guy had a youtube vid on how atmel and microchip were supporting each others devices so the avr dragon could be used to program a pic device... ive not seen any other info on that other than his video
[15:01:05] <mark4> so im guessing he was pulling the legs of every atmel pic hater :)
[15:01:18] <mark4> not interested in atmels arm yet
[15:01:21] <RikusW> definitly
[15:09:42] <RikusW> I get like almost 1000 errors all -> value of 13x,xxx too large for 2 byte value
[15:10:09] <RikusW> I edited the cproj file to be version 6.1 instead of 6.2 and it loaded :)
[15:11:17] <RikusW> mark4: I think you broke the compiler
[15:11:20] <RikusW> :-D
[15:11:29] <mark4> no the compiler is stupid
[15:11:42] <mark4> i think my .int blah being compiled to .text is failing
[15:11:47] <RikusW> I have no clue what it is complaining about
[15:11:54] <mark4> because .text is opcode space and opcodes are 16 bits wide
[15:12:01] <mark4> so EVERYTING in .text has to be 16 bits wide
[15:12:11] <mark4> me either. because it doesnt tell me where the fuck the error is
[15:12:19] <mark4> like 5178 doesnt freeking exist lol
[15:12:21] <mark4> line
[15:12:50] <RikusW> It might, after the macros are expanded :-P
[15:13:32] <mark4> its "lets preprocess all those files into just this one" error is on line 5178 of this temp file which doesnt exist anywhere except in memory
[15:13:54] <RikusW> gcc allow outputting preprocessed files
[15:14:06] <RikusW> there are some commandline switch for that
[15:14:20] <RikusW> no clue how to tell that to AS6 though
[15:14:30] <mark4> -keep-temps or something i added it
[15:14:44] <mark4> -dont-delete-the-temporary-files-dumbass
[15:15:38] <RikusW> will look again later, if I do figure out what is going on I'll mail you or tell you here
[15:15:59] <mark4> i think i need to count source lines by hand lol
[15:16:02] <mark4> in order of include
[15:17:05] <RikusW> or preprocess using avrgcc and look in that file
[15:17:11] <RikusW> use commandline
[15:18:25] <RikusW> btw have you seen the new x265 compression ?
[15:19:01] <mark4> erm no?
[15:19:21] <RikusW> it can put 45min of 720p video into 160MB
[15:19:42] <RikusW> and it looks good
[15:20:28] <RikusW> much much better than divx/mpeg4
[15:20:31] <mark4> i once compressedd a 30k image down to 90 bytes with my own compression method
[15:20:48] <mark4> but... if you gave it a JPG it would make it more like 3000 times larger :P
[15:21:06] <mark4> it was for a very specific format of image (format being content)
[15:21:06] <RikusW> seems like you had a special image...
[15:21:11] <mark4> yes it was
[15:21:14] <mark4> but it was dynamic
[15:22:03] <mark4> i had a inner compression method that converted pixle colors into either a 0 or a 1 followed by a new color. it was optimized to be more likely to output a 0
[15:22:05] <RikusW> I'm not sure either of us can comprehend the math behind the new video codecs ? ...
[15:22:08] <mark4> rle the result and....
[15:22:26] <mark4> i know i cant lol. i skipped that boring "education" shit! lol
[15:23:21] <RikusW> My brother tried doing some OpenCV stuff, it proved more difficult than expected, he did manage to track moving objects though
[15:24:22] <RikusW> detecting the background and changes in lighting mess everything up
[15:24:51] <RikusW> it NOT as simple as detecting RGB values
[15:25:36] <mark4> sensing movement is as simple as heavilly pixlating the image and watching for changes in color
[15:26:13] <mark4> i.e. average all the pixles ina 20x20 grid throughout the imnage. any movement affects a huge color change in one or more squares
[15:26:30] <RikusW> His project was to track a queue of people, it didn't get quite that far...
[15:26:35] <mark4> im simplifying this of course lol
[15:27:14] <mark4> i want to create autonomous dog fighting drones
[15:27:27] <RikusW> count the persons, and calculate how long they've been standing there, though that part didn't work
[15:27:53] <mark4> toy ones so my drone can dog fight your drone...
[15:28:02] <RikusW> and it had to run on a beaglebone black...
[15:28:28] <mark4> for anyone with any REAL image sensor knowledge thats not that difficult
[15:28:31] <mark4> erm not me lol
[15:28:38] <mark4> but i worked for a guy that could do it in a snap
[15:29:04] <mark4> he used to run motorolas image sensor division before they got out of that multi billion dollar a year profit thing
[15:29:07] <RikusW> have you seen the beaglebone boards ?
[15:29:23] <mark4> i have a beagleboard black
[15:29:37] <mark4> i developed my arm and thumb2 forths on it
[15:29:39] <RikusW> ah, nice little things
[15:29:59] <mark4> im about to get a BUNCH of RPI2's
[15:30:10] <mark4> quad core, 900mhz oc' to 1ghz
[15:30:18] <mark4> 1g of ram...
[15:30:57] <mark4> .data on an avr is ram yes?
[15:31:04] <mark4> and .rodata would be rom data ?
[15:31:17] <RikusW> guess so
[15:31:32] <RikusW> s/rom/flash
[15:31:50] <mark4> lol i just did see one innocuous error (as far as build goes) in my macros
[15:32:01] <mark4> the first 3 .sets should be 1 2 3 not 1 1 1
[15:32:05] <mark4> but thats not whats causing this
[15:32:41] * RikusW thinks its preprocessor stack overflow :-D
[15:33:21] <mark4> i think its a bug in the assembler
[15:33:24] <mark4> not the preprocessor
[15:33:32] <RikusW> quite possible
[15:33:40] <mark4> CPP already did its shit
[15:46:20] <mark4> i haz coding skillz... i can find a way to make ANY compiler fuck up :P
[15:55:01] <mark4> if i knew what was causing the error i could probably find a work around :(
[16:45:49] <mark4> anyone here know off the top of their head how to specify tool paths in as6.2?
[16:46:12] <mark4> nvm i think i found it
[16:47:15] <mark4> ugh you cant switch tool chains
[16:47:23] <mark4> bugger these fucking tools
[16:47:33] <mark4> now i have to figure out where the freek the read only file is
[16:55:09] <mark4> anyone just happen to know?
[17:18:54] <mark4> how do you change what toolchain is used to build in as6
[17:19:14] <mark4> i go to the config item. select the new path and hit ok and... nope it refuses to overwite the -w config file
[17:20:14] <mark4> can anyone tell me how the hell one switches the toolchain from the fucked up broken doesnt fucking work avr-gcc from atmel to the "it works flawlessly" one from winavr?
[17:59:27] <Lambda_Aurigae> mark4, not I...never was able to get AS6 to actually run on my computer.
[18:06:56] <martinus> I think I'll invest myself in setting up the toolchain for linux tomorrow. :D
[18:09:02] <Lambda_Aurigae> that's been my way since I started with AVR back around 2002 or so.
[18:10:12] <Lambda_Aurigae> but, I've been windows free on my home computer since long before that,,,
[18:12:11] <mark4> boss calling
[18:12:13] <Lambda_Aurigae> I suffer from a rather strong dislike for microsoft due to certain personal experience I had with the company some years ago so I tend to be rather anti-microsoft.
[18:12:18] <Lambda_Aurigae> boss...bah.
[18:12:25] <Lambda_Aurigae> my boss is on vacation...I'm in charge!!!
[18:12:33] <Lambda_Aurigae> at least until my wife comes home tomorrow...
[18:17:34] <martinus> :D
[19:28:25] <mark4> even totally uinstalling AS6 and reintalling it i cannot select a different build tool
[19:29:01] <mark4> what ever config file it created doesnt get deleted and its fucking LOCKED to all further changes till the sun expires
[19:46:33] <ryan-c> Any ops here? BlackMustard is sending unsolicited DCC sends of svchost.exe
[19:47:09] <mark4> try in #opers or something
[19:47:32] <mark4> telll them in there and they will kline his ass
[19:47:36] <mark4> "its" ass
[19:47:39] <mark4> its a bot
[19:47:40] <slidercrank> here too?
[19:47:48] <slidercrank> he's doing it on other channels as well
[19:48:22] <mark4> im fucked, i cannot switch development tools in as6
[19:51:37] <twnqx> i stopped caring at AS6 :P
[19:52:19] <twnqx> emacs, git, gcc, as, ld, make, objdump, avrdude... in cases of extreme problem avarice and gdb... why would you need more
[19:54:49] <mark4> gdb is the worst pile of shit debugger ive ever used
[19:55:13] <mark4> i hate c with a passion, i cannot express how deely i LOATHE and DISPISE gdb
[19:55:50] <mark4> i get this forth working and i can uninstall every single other avr development tool
[19:55:55] <mark4> permanantly
[19:56:01] <mark4> but i ahve to bootstrap it here
[19:56:10] <mark4> and these tools are fucking with me big time
[19:58:24] <mark4> uninstalled the atmel toolchains for avr. ALL of them
[19:58:42] <mark4> does not fix anything, just makes the build not have any tools. and i cant give it any.
[19:58:56] <mark4> once you select c:\program files\atmel\this\toolschain
[19:59:00] <mark4> your fucked. thats it
[19:59:05] <mark4> you cant change it EVER
[19:59:18] <N1njaneer> What's the problem?
[19:59:43] <mark4> atmels assembler has bugs in it so it cannto assemble my project. winavr has no fucking problems at all
[19:59:44] <mark4> so
[20:00:04] <N1njaneer> Which assembler? What version of the toolchain are you using?
[20:00:15] <mark4> go to as6 tools->options and browse to the toolchain and...
[20:00:18] <mark4> its GRAYED THE FUCK OUT
[20:00:27] <mark4> its a write once config
[20:00:38] <N1njaneer> Atmel Studio 6.x is all ported winavr gcc, so it shouldn't have any issues.
[20:00:39] <mark4> even uninstalling TOTALY the entire ide and reinstalling it you STILL do not get to change it
[20:01:06] <mark4> it does. it has a regressuion bug it it that winavr does not have
[20:01:41] <mark4> problem is that with AS6, once you select a toolchain thats THE toolchain for EVERY SINGLE PROJECT
[20:01:44] <mark4> forever
[20:01:48] <mark4> no changing it not matter what
[20:01:57] <aandrew> that's why you ditch AS6 and just use GCC
[20:01:57] <mark4> cant even find which file that config is in
[20:02:14] <mark4> because i need the graphical debugger with symbolic disassembly
[20:02:23] <mark4> and no im never going to be using anything based off of gdb
[20:02:24] <mark4> FUCK that
[20:02:34] <mark4> ill gouge my eyes out with a red hot poker first
[20:02:42] <N1njaneer> I see 7 toolchains under Options->Toolchain on mine.
[20:02:52] <mark4> no. they are all ATMEL tools
[20:02:56] <mark4> that wont work
[20:03:14] <N1njaneer> Have you opened a ticket with Atmel describing the specific problem yet?
[20:03:23] <mark4> once you set c:\program files\atmel\foo\bar\bam\avr-gcc\bin\ as the toolchain pat thats it. your FUCKED for chan ging it ever
[20:03:31] <mark4> i need it to be c:\winavr\avr\bin
[20:03:32] <N1njaneer> I always get a very fast response from them.
[20:03:57] <mark4> atmel does not get my email address
[20:03:58] <mark4> not ever
[20:03:59] <N1njaneer> Do you have a project open when you set this?
[20:04:11] <N1njaneer> Where are you geographically located?
[20:04:26] <mark4> ive closed as6, uninstalled. reinstalled. tried to change with no prj open. opend a prj and tried
[20:04:41] <mark4> it will NOT overwrite a file thats been marked read only and it does not tell you what file that is
[20:04:45] <mark4> and i cannot find it
[20:04:49] <mark4> dallas tx
[20:05:00] <N1njaneer> Which version of AS6 do you have installed?
[20:05:07] <mark4> 6.2sp2
[20:05:29] <N1njaneer> .1548?
[20:05:44] <mark4> yes
[20:06:32] <mark4> its satan fucking with me
[20:06:33] <N1njaneer> If you're in Dallas, just call Atmel and find out who the Dallas FAE is and contact them directly if you have having problems on their normal email addresses.
[20:06:36] <mark4> and atmel
[20:06:53] <mark4> i dont have a service agreement with atmel
[20:06:58] <N1njaneer> If you suspect there may be a problem in the assembler and can document the issue well enough I guarantee you they'll look in to it.
[20:07:04] <N1njaneer> You don't need one.
[20:07:05] <mark4> they arent going to send out their sae for joe shmoe
[20:07:35] <mark4> the assembler has a regression bug in it. its known. it took me most of the day to try to get around the bug.
[20:07:35] <twnqx> so why don't you bootstrap your ever so mighty forth compiler in forth...
[20:07:47] <mark4> my project built just fine with winavr'
[20:07:47] <N1njaneer> You would be surprised. We started off quite small, and are still rather small, but they even did failure analysis on silicon for me when I was a single person operation :)
[20:08:11] <mark4> twnnqx because have you ever tried single stepping through forth with NO symbolic disassembly?
[20:08:32] <twnqx> nope. only with C, with is nearly the same as written assembly to begin with
[20:08:34] <mark4> the only reason i need this is so i can unit text every single primitive and the virtual machine. '
[20:08:45] <twnqx> virtual machine?
[20:08:55] <twnqx> are you trying to tell me you run an interpreter on a fuckslow 8bit avr?
[20:09:03] <N1njaneer> In any case, it's worth getting in touch with the Dallas area FAE to get a better direct like for dealing with issues like these.
[20:09:09] <mark4> in forth it would be code code code call foo code call foo code code call foo call bar code code call bam jmp blah and... no returns ever
[20:09:38] <mark4> you would be tied into a stupendous mental gordian knot in 10 seconds flat even if you were single step one. look at source to see where that should take you
[20:09:42] <twnqx> with no returns it's not call but jump
[20:09:44] <mark4> single step one.. .. .
[20:09:49] <mark4> its calls
[20:10:09] <mark4> call foo call bar call bam... but no returning because the return address is popped off the stack and used
[20:10:44] <twnqx> sounds expensive and slow
[20:10:48] <mark4> its all calls and jumps callls and jumps and never a return.
[20:11:01] <mark4> you would be very supprised at how both space and speed efficient forth is
[20:11:15] <twnqx> multiple instructions
[20:11:45] <twnqx> pop <higher> pop <lower> jmp <indirect>
[20:11:50] <twnqx> can't be faster than ret
[20:11:52] <mark4> pop is 2 cycles
[20:12:07] <twnqx> or can you pop 16bits into two regs at once in avr?
[20:12:11] <aandrew> heh we're back at this
[20:12:13] <mark4> no thats 2 opcodes
[20:12:22] <mark4> 4 instruction cycles max
[20:12:30] <twnqx> just for the pops
[20:12:45] <mark4> sec
[20:12:59] <aandrew> a good forth compiler will compile down to the same/similar instructions as any other good compiler. the language it's written in doesn't make the algorithms or ISA any more efficient
[20:13:13] <mark4> EIJMP is 2 cycles
[20:13:17] <mark4> the pops are 2 each
[20:13:44] <twnqx> also, i don't see your other problem
[20:13:46] <mark4> a ret is 5 cycles on this chip
[20:13:50] <twnqx> if you know pop, pop, jmp equals ret
[20:14:03] <mark4> because im not doing pop pop jmp
[20:14:09] <twnqx> but?
[20:14:28] <mark4> well i do in places. i do pop pop use the popped item as a data pointer... then do an indirect jump or discard
[20:14:41] <mark4> what problem dont you see
[20:14:42] <twnqx> use the return address as data pointer?
[20:14:45] <mark4> twnqx you code asm?
[20:14:57] <twnqx> rarely
[20:15:03] <mark4> yes. use the return address as a data pointer or not. it depends on what is being done
[20:15:16] <twnqx> i prefer to decompile gcc and see if it's "doing it right2
[20:15:17] <twnqx> "
[20:15:30] <twnqx> and file improvement requests if it doesn't
[20:15:49] <twnqx> on a non-pipelining CPU interleaving is pointless
[20:16:17] <twnqx> and on a harvard architecture there is not really a sane way you could "use the return value as data pointer"
[20:16:52] <mark4> go to project tools options and select the build tolls... it lest you change them?
[20:17:00] <N1njaneer> Yep
[20:17:01] <mark4> your mistaken
[20:17:08] <mark4> but i cant prove it to you yet lol
[20:17:17] <twnqx> all you have proven so far
[20:17:17] <mark4> wait till i get it working and then i can show you how efficient it is
[20:17:30] <twnqx> is that your return code is 17% slower in clock cylces
[20:17:34] <twnqx> and multiple times the size
[20:17:40] <twnqx> :)
[20:17:45] <mark4> LPM is only 3 cycles
[20:17:51] <mark4> no
[20:17:52] <twnqx> "only"
[20:18:05] <N1njaneer> Oh well. As I suggested, contact Atmel directly, find out who the local FAE is who covers Dallas, and get in touch with them. As long as you can explain the problem satisfactorally they'll be quite responsive to helping you fix it.
[20:18:07] <twnqx> and that "only" restricts you firmly to data structures in ROM
[20:18:11] <twnqx> as you can't read ram with it
[20:18:17] <mark4> you obviously have no clue about software execution time or where speed is absolutely required
[20:18:19] <twnqx> (rom/flash)
[20:18:29] <mark4> not every single line of code needs to run at screaming speeds
[20:18:32] <mark4> and those that do. i code in asm
[20:18:57] <mark4> its 8pm i doubt they are accepting calls
[20:19:01] <twnqx> no, but i don't see a point in slowing down every single function point
[20:19:04] <twnqx> call*
[20:19:16] <twnqx> knowingly and willingly
[20:19:29] <mark4> you have no knowledge of how forth worls. i create forth compilers for any processor you can mention
[20:20:10] <mark4> i have one for x86 linux (32 bit only) and for arm (both arm and thum2 versions) and one for android (ndk lib) and for various uCs like 8051 etc
[20:20:15] <twnqx> are, so you have a hammer (forth) and use it for everything, even replacing screwdrivers, i see :)
[20:20:26] <mark4> and you knock them because all you know is C
[20:21:04] <twnqx> no, i know C/C++, pascal, modula 2, prolog, various ASMs and verilog
[20:21:05] <mark4> forth is THE software engineering solution. so much so that its inventor doesnt code any more, he just produces 144 core processors he designed on a VLSI edit he wrote
[20:21:12] <mark4> yea. exactly. i rest my case
[20:21:18] <N1njaneer> Mark4: Try calling Ion Associates, Inc tomorrow at 817-695-8000 and ask them to put you in touch with the FAE who covers the region and go from there. Making friends with the local Atmel FAE is an exceedingly useful thing. :)
[20:21:20] <mark4> you know nothing of forth
[20:21:24] <twnqx> true.
[20:21:41] <twnqx> but if you tell me that a particular solution that slows things down and blows up code
[20:21:59] <mark4> doing so tomorow would probably be a good idea. i would probably pick a fight with him right now :P
[20:22:09] <twnqx> while complaining before about codebloat from dynamic libraries
[20:22:11] <mark4> who said it slows things down?
[20:22:16] <twnqx> you
[20:22:29] <twnqx> 6 cycles vs 5 cycles, 3 instructions vs one instruction
[20:22:33] <mark4> how long would it take your beloved c++ comiler to compiler 4 megabytes of source code?
[20:22:51] <mark4> my slow, inefficient forth compiler that just DRAGS along in your mind would do so in less than a second
[20:22:53] <twnqx> compile time is utterly irrelevant, and it solely depends on macro use
[20:23:03] <mark4> bbullshit its irrelevant
[20:23:27] <mark4> the amount of you you spend spinning with your thumb up your ass waiting for a build is significant over time
[20:23:51] <mark4> and macros lol. yea... thatll slow you down... cuz its complex shit amirite?
[20:24:35] <mark4> its the language. c++ is inefficient. your in an AVR channel. you do c++ on an avr (like arduino does) and your going to be eathing up hundreds of times more code space than my crappy inefficient forth compiler
[20:25:09] <mark4> and my crappy inefficient linux forth compiler can do ncurses windowing more efficiently than ncurses can.
[20:25:30] <N1njaneer> Depends on what you're doing with it, really. If the solution works at the end of the day and can be created quickly, that's really what matters :)
[20:25:32] <mark4> show me any ncurses application that can have multiple text windows open, scrolling text in any direction in each of them and have them moving and overlapping
[20:25:58] <mark4> N1njaneer, exacytly, not every single line of code needs to be SCREAMING greaced lightening fast
[20:26:05] <mark4> where you need that. code it in asm
[20:26:16] <mark4> even optimized c++ is utter SHIT
[20:26:27] <mark4> look at any ISR produced by gcc on any micro controller
[20:26:44] <mark4> thers going to be 40 lines of asm code setting up the isr, then you preform the function and then 40 lines of clean up and exit
[20:26:58] <mark4> horrendously fucked in the head stupid code at any optimization levelk
[20:27:01] <N1njaneer> I code in C/C++ because I can work extremely fast, and I know where I can finetune if necessary. If I am concerned that I need more processing power, I just bump up to a faster processor like an Atmel SAM
[20:27:01] <mark4> but c is better rite?
[20:27:20] <mark4> N1njaneer, code 300 lines of c, wait for compile, then start debugging
[20:27:28] <mark4> in forth its code one function and immediately test it.
[20:27:38] <twnqx`> f my isp.
[20:27:48] <twnqx`> <mark4> my slow, inefficient forth compiler that just DRAGS along in your mind would do so in less than a second
[20:27:48] <mark4> code a primative, test it, code a primitive, test it, code a primitive, test it
[20:27:51] <twnqx`> <twnqx> compile time is utterly irrelevant, and it solely depends on macro use
[20:27:53] <twnqx`> <twnqx> well, it is utterly irrelevant to me.
[20:27:55] <twnqx`> <twnqx> well, it is 17% in one particular case
[20:27:58] <mark4> use the primitives to create higher level definitions.... TEST THEM
[20:27:59] <aandrew> prolog, I haven't seen that in ages
[20:27:59] <twnqx`> <twnqx> that we talked about
[20:28:01] <twnqx`> <twnqx> i have no idea about others
[20:28:03] <twnqx`> sorry.
[20:28:10] <N1njaneer> I also have projects in C++ that span many hundreds of files. The OOP nature of the code makes writing and managing it actually doable. If it was C, it would be a lot more challenging.
[20:28:14] <mark4> at all stages of development everything you have developed so far has been testd
[20:28:25] <twnqx`> mark4: how do you test the things that i consider µC all about
[20:28:32] <twnqx`> e.g. interfacing with a CAN controller
[20:28:33] <N1njaneer> I use C++ on AVR's and ARMs regularly simply for the OOP nature of things - it doesn't inherently make the code execution any slower.
[20:28:36] <mark4> test what things?
[20:28:36] <twnqx`> reacting to incoming data
[20:28:48] <twnqx`> because i was wondering about that for a long time
[20:28:52] <mark4> like an ISR?
[20:29:00] <twnqx`> for example
[20:29:07] <twnqx`> and then, the code that receives packets
[20:29:09] <twnqx`> filters them
[20:29:14] <mark4> your ISR shlould not be 3000 lines of object obfuscated visual c++
[20:29:25] <mark4> it should be just enough assembler to collect and save away the data
[20:29:25] <twnqx`> of course not
[20:29:38] <mark4> get i, get the fuck out ASAP
[20:29:56] <N1njaneer> Or you use an ARM, which uses a set of shadow registers for processing ISRs, and there's no preseveration overhead at all, and is thus faster in that regard. :)
[20:29:56] <twnqx`> i kind of agree with that
[20:30:06] * Xark notes as long as you disable exceptions, C++ is not slower than C in my experience (and has some features that can potentially make it faster).
[20:30:07] <aandrew> mark4: what you're suggesting (test functions immediately) is no different in any language. You're confusing development methodology with language benefit
[20:30:19] <twnqx`> that too.
[20:30:24] <mark4> aandrew, code 4 lines of c, compile it, test it
[20:30:26] <twnqx`> i just don't KNOW how to test code
[20:30:33] <twnqx`> that depends on hardware
[20:30:34] <mark4> code 5 more lines of c, compile it, test it
[20:30:38] <mark4> thats not how forth works
[20:30:40] <aandrew> you say C must be compiled (and cite half hour build times on embedded, lol) and then say you build forth compilers... how is this ANY different?
[20:30:43] <mark4> : foo lots of forth here ;
[20:30:44] <mark4> 1 2 3 foo
[20:30:47] <mark4> hmmm it worked!
[20:30:53] <mark4> : bar more forth code here ;
[20:30:58] <mark4> 5 6 7 bar
[20:31:02] <twnqx`> you know
[20:31:03] <mark4> oopts it didnt work
[20:31:04] <mark4> forget bar
[20:31:08] <mark4> : bar fixed version ;
[20:31:08] <twnqx`> you exactly cite me coding C
[20:31:09] <mark4> test...
[20:31:31] <twnqx`> the slowest part is reflashing the avr
[20:31:40] <aandrew> mark4: you can't do that *on the hardware* unless you're running an interpreter at which point you're talking an entirely different set of rules
[20:31:40] <mark4> very inefficient to do that in c for any non trivial project but if thats honestly how you code C i commend you for it
[20:31:41] <twnqx`> and guess which part you can't skip in your forth compiler
[20:31:52] <mark4> write 284765897243 lines of c. then try debug .. FUCKING nightmare lol
[20:31:59] <mark4> aandrew, you cant?
[20:32:01] <aandrew> mark4: you really are a troll
[20:32:07] <mark4> sure you fucking can when your development system IS the hardware
[20:32:10] <aandrew> mark4: who writes 284765897243 lines of code in ANY language without testing?
[20:32:10] <twnqx`> i kind of start to agree
[20:32:21] <twnqx`> you CANNOT execute in ram on avr
[20:32:26] <twnqx`> period
[20:32:35] <twnqx`> you have to reflash.
[20:32:46] <mark4> twnqx`, you sort of can but only if what your executing is being executed by a virtual machine :)
[20:32:50] <twnqx`> yes
[20:32:53] <twnqx`> but that overhead
[20:32:58] <mark4> but thats not how my forth works...
[20:33:00] <aandrew> mark4: if your AVR is interpreting ": foo lots of forth here ;" then you are running on an interpreter. ANyone who spends their time "writing forth compilers" knows this and is being intentionally obtuse to state otherwise.
[20:33:13] <aandrew> virtual machine? so it is an interpreter.
[20:33:18] <twnqx`> also, fun fact
[20:33:20] <N1njaneer> And the fact that RAM isn't exactly abundant on AVRs - that's going to limit your interpreted application storage quite a bit :)
[20:33:22] <mark4> twnqx`, you think java is inefficient? a java virtual machine is EXTREMELY small. an embedded java is super fast and super efficient
[20:33:27] <mark4> java IS a virtual machine
[20:33:28] <mark4> so is forth
[20:33:29] <twnqx`> java
[20:33:38] <mark4> not exactly.
[20:33:38] <twnqx`> can be pretty damn fast
[20:33:46] <twnqx`> thanks to dynamic inlining
[20:33:48] <aandrew> mark4: again, if you're executing forth bytecode you're interpreting it. You may very well be JIT compiling it but it's still fucking interpreted.
[20:33:50] <mark4> they call forth "semi" compiled
[20:34:00] <twnqx`> and other dynamic optimzations that binary languages will never hae
[20:34:00] <N1njaneer> java fast and efficient? Heh.
[20:34:15] <mark4> and it depends on the forht threading you use. indirect, direct, token, subroutine... ..
[20:34:18] <N1njaneer> Maybe if you're executing Jazelle code, but they're kind of giving that up :)
[20:34:23] <twnqx`> bytecode is always semicompiled
[20:34:36] <Xark> twnqx`: That is not totally true, now there is profile-guided optimization for C++, e.g.
[20:34:37] <mark4> N1njaneer, yes. not PC based but an embedded java is VERY efficient
[20:34:47] <mark4> this is not exactly byte code
[20:34:53] <twnqx`> Xark: still can't inline between modules
[20:34:56] <N1njaneer> mark4: Embedded java running on what architecture?
[20:34:57] <twnqx`> unlike java
[20:35:02] <aandrew> by your definition I can execute python on an AVR
[20:35:18] <Xark> twnqx`: If course it can. That is called link-time-optimization (and works in frigging Arduino compiler). :)
[20:35:23] <mark4> N1njaneer, pick one. 8051? avr? pic? mips? arm?
[20:35:32] <twnqx`> it can modify existing bytecode in linktime?
[20:35:33] <mark4> tho i dont really consider arm an embeedded device
[20:35:49] <mark4> forth does it at run time. in forth there is no "link" time
[20:35:52] <twnqx`> take a whole function from one block and move it into the place of a "call" instruction?
[20:35:59] <mark4> i have to go home. its 8:14 and im the last one at work
[20:36:02] <mark4> brb
[20:36:03] <N1njaneer> mark4: If you don't consider ARM to be in the embedded realm, then I'm afraid we're on two different planets here :)
[20:36:06] <twnqx`> and knows about the optimizations for register saving, etc?
[20:36:33] <mark4> N1njaneer, i would say the raspberry pi 2 with a 900mhz quad core to be very mucyh NOT embedded
[20:36:36] <aandrew> this is a fun diversion but ultimately a troll as far as I can determine
[20:36:46] <mark4> i have full blown PCs that are orders of magnitude slower :P
[20:36:47] <mark4> brb
[20:36:50] <aandrew> mark4: you are aware that there are vastly different ARM variants, right?
[20:36:56] <N1njaneer> I assume not.
[20:36:59] <Xark> twnqx`: With profile guidance, it can indeed do that (not dynamically, but from information gleaned at run-time [on a previous run]). Kind of a pain (as you have to exercise code etc.), but it can make a significant performance improvement (moves things to play nice with cache etc.).
[20:37:01] <twnqx`> and i would say there are arms that fully qualify as embedded
[20:37:11] <mark4> aandrew, want to see my not complete code when i get home?
[20:37:16] <twnqx`> Xark: enjoy that on AVR :D
[20:37:17] <mark4> then you can decide if im a troll or not
[20:37:26] <aandrew> ARM7TDMI, ARM926? ARM Cortex-Mwhatever?
[20:37:28] <N1njaneer> I do development work on Cortex-M0/M3 ARMs here regularly.
[20:37:30] <mark4> or i can send you my not yet relased ARM (arm or thumb2) forth compiler
[20:37:31] <twnqx`> mark4: there's one thing i wanted to comment, too
[20:37:36] <aandrew> mark4: oh I believe you can code in forth and I even believe you write forth compilers
[20:37:39] <twnqx`> i have git commits with just two lines of C
[20:37:52] <twnqx`> so yes, that is my level of testing and committing
[20:37:53] <Xark> twnqx`: Yeah, haven't see PGO on AVR, but link time optimization works nicely (and makes a nice improvement in speed and size).
[20:38:00] <aandrew> I don't believe that you're having a qualified discussion about forth vs C because every time you trot out an example it's full of exceptions
[20:38:14] <mark4> twnqx`, your a heretic :)
[20:38:20] <aandrew> "I can execute my forth code directly on the forth virtual machine that's running on the avr" for example
[20:38:21] <N1njaneer> I use what I use to get the client their stuff delivered on time, that works reliably. :)
[20:38:35] <N1njaneer> Because it pays the bills, and lets me by more toolss :)
[20:38:40] <N1njaneer> +buy
[20:38:46] <twnqx`> s/tools/toys/ :P
[20:38:46] <aandrew> twnqx`: me as well; isn't this how most people write C after a few years of experience?
[20:38:50] <mark4> aandrew, ive done embedded C coding for almost 30 years. ive done embedded forth for that same length of time
[20:38:59] <mark4> which of us is more qualified to make the comparison?
[20:39:04] <aandrew> mark4: then why are you having such a ludicrous discussion?
[20:39:22] <twnqx`> mark4: i am tempted to say you are biased
[20:39:26] <aandrew> mark4: I've been writing C in various capacities for the same amount of time. That's why I call bullshit.
[20:39:34] * Xark dittos
[20:39:51] <twnqx`> yes, C is easier to shoot your feet with
[20:40:04] <twnqx`> and a single typo can introsuce the most subtile bugs
[20:40:11] <aandrew> everything from deeply embedded (hc8/12/16, etc.) through to linux kernel drivers on various platforms
[20:40:15] <twnqx`> but the speed gain is worth it
[20:40:18] <N1njaneer> But it's a lot more powerful when you know how to use it correctly, since it can be very close to the bare metal.
[20:40:39] <twnqx`> i still like that oneline description of C i've read
[20:40:45] <twnqx`> "platform independent assembler"
[20:40:48] <aandrew> :-)
[20:41:10] <aandrew> yeah it's definitely a hybrid between HLL and assembly
[20:41:17] <aandrew> it's kind of what I like best about it
[20:41:25] <N1njaneer> I've written a lot of real-time processing applications in Windows that need to meet real-time deadlines. C++ allowed handling the complexity of what needed to be done, but afforded the ability to create some extremely complex handling operations to pick up the speed where it was absolutely critical.
[20:41:36] <twnqx`> same here, and that's what makes us biased against stuff like forth
[20:41:50] <twnqx`> don't forget that part
[20:42:00] <twnqx`> N1njaneer: can windows even do hard realtime?
[20:42:18] <aandrew> I have no problem with forth or any other language. I have a huge problem with someone claiming forth code can do what *any other language* can do in 1% of the space and at some undetermined multiple of speed
[20:42:19] <twnqx`> (honest question, i don't know)
[20:42:22] <Xark> twnqx`: For soft levels of hard. :)
[20:42:30] <aandrew> lol
[20:42:34] <aandrew> linux can't do hard realtime either
[20:42:39] <twnqx`> rtlinux can
[20:42:44] <twnqx`> normal linux can#t indeed
[20:42:57] <aandrew> the one hard realtime implementation that worked had a hypervisor that handled the hard realtime tasks and the kernel proper ran as a subordinate "thread"
[20:42:59] <Xark> It wasn't too many years ago when it couldn't manage to burn a disc (with massive hardware buffering). :)
[20:43:01] <twnqx`> though i've heard there's progress getting the rt patchset into main
[20:43:05] <Xark> without*
[20:43:19] <aandrew> heh
[20:43:21] <aandrew> I remember those days
[20:43:24] <N1njaneer> twnqx`: In my this case it's processing real-time blocks of audio data with fixed latency through graphical node-chains of processing. It works tremedously well, even with super-complex nodal networks. So you can cheat it to some degree. :)
[20:43:25] * twnqx` too
[20:43:26] <aandrew> DON"T FUCKING MOVE THE MOUSE, I"M BURNING A CD
[20:43:34] <Xark> aandrew: Haha, totally. :)
[20:44:05] <N1njaneer> aandrew: LOL yes
[20:44:21] <twnqx`> ok, so it's not the "you have 1µs to answer to this packet or the robot is hit by emergency shutdown" kind of realtime :P
[20:45:01] <N1njaneer> Not *quite* that, but if we miss a packet delivery AT ALL the output becomes totally corrupted.
[20:45:18] <twnqx`> "at all" is boring
[20:45:25] <Xark> twnqx`: Not really, no. The x86 can decide to burn many many thousands of clock cycles in one op also...
[20:45:32] <N1njaneer> Handling 16 channels of 32-bit samples at 48Khz both input and output under Windows can be a bit challenging :)
[20:45:45] <twnqx`> lock rep stosd, anyone? :>
[20:46:07] <Xark> twnqx`: Yeah, or hidden ~1500 cycle cache line syncs between cores...
[20:46:12] <N1njaneer> https://www.dropbox.com/s/2s14plidxb6czcz/DSPatchBig.png?dl=0 is a picture of an example of the software, to back up what I'm saying. :)
[20:46:54] <twnqx`> Xark: ok, i admit that last i did stuff that matters for this on x86 was the realmof 80486 cpus...
[20:47:02] <N1njaneer> Said nodal systems then produce imagery like
https://www.dropbox.com/s/x11rmf4txe1kah0/DS3LiveExample.png?dl=0
[20:47:21] <twnqx`> N1njaneer: meh, i had to switch to umts as my isp dropped off :(
[20:47:36] <N1njaneer> twnqx`: Happens!
[21:40:58] <N1njaneer> New pick and place needs to get here sooner!
[21:41:17] <N1njaneer> Anyone want some gently-loved pick and place stuff? :D
[22:16:34] <Lambda_Aurigae> N1njaneer, gently loved? sounds kinda kinky.
[22:16:43] <Lambda_Aurigae> did you throw it across the room or something?
[22:17:19] <N1njaneer> lol, too heavy for that!
[22:19:15] <Lambda_Aurigae> fucking xerox idiots..
[22:19:51] <Lambda_Aurigae> they have had a series of black and white machines for the last 12 years that have been based on the same frame and same internal process and paper path and hardware..
[22:20:19] <Lambda_Aurigae> and every one from the first to the latest have had known issues that they can't seem to fix...odd jams, strange glitches, etc.
[22:20:41] <Lambda_Aurigae> all this with paper feed, scanner, and imaging.
[22:20:52] <Lambda_Aurigae> so, they recreated the line....all new....riiight.
[22:21:05] <Lambda_Aurigae> they change the paper path and updated the imaging section.
[22:21:21] <N1njaneer> Lambda_Aurigae: Yes, but tell us how you REALLY feel? :)
[22:21:23] <Lambda_Aurigae> and put that in the middle of the old paper feed that has had problems for 12 FLIPPIN YEARS..
[22:21:45] <Lambda_Aurigae> and they used the same scanner that has had problems for 12 FLIPPIN YEARS.
[22:21:46] <Lambda_Aurigae> hehe
[22:21:52] <Lambda_Aurigae> and are trying to call it all new.
[22:22:34] <Lambda_Aurigae> why they couldn't have taken the existing color platform that works and has far fewer issues and just converted the core to black only is beyond me.
[22:23:03] <Lambda_Aurigae> and they still don't support distinctive ring/selective ring on their fax hardware!
[22:23:14] <Lambda_Aurigae> which is losing us customers right and left now.
[22:23:30] <N1njaneer> Sell your customers fax-to-email!
[22:23:45] <Lambda_Aurigae> wish I could.
[22:23:52] <N1njaneer> That's how all of our stuff comes in - dedicated number, only costs a couple bucks a month. :)
[22:24:07] <Lambda_Aurigae> unfortunately I'm just a tech, not a salesman.
[22:24:17] <Lambda_Aurigae> not allowed to do such things.
[22:24:26] <Lambda_Aurigae> would mean not selling the hardware.
[22:24:35] <Lambda_Aurigae> cuts into revenues..
[22:24:43] <Lambda_Aurigae> I so need to find another job..
[22:24:52] <N1njaneer> Not always a bad idea!
[22:25:01] <Lambda_Aurigae> this is my number two most hated job ever.
[22:25:11] <N1njaneer> Which was the worst?
[22:25:28] <Lambda_Aurigae> number one being when I worked for a month walking around the mall with a clipboard and asking random strangers questions.
[22:25:54] <N1njaneer> MMm yeah I could see that!
[22:25:59] <Lambda_Aurigae> granted, this job pays about 3 times what that one did.
[22:26:15] <N1njaneer> And you'll say the same about your next!
[22:26:20] <Lambda_Aurigae> nope.
[22:26:34] <Lambda_Aurigae> my last job was ok..one before that was flippin awesome.
[22:26:55] <Lambda_Aurigae> I need to find another sysadmin job.
[22:26:55] <N1njaneer> Then find one that's flippin awesome AND pays 3x as much! :D
[22:27:28] <Lambda_Aurigae> problem with that is I don't have the wallpaper to prove that I know more than any 5 college graduates out there.
[22:27:54] <N1njaneer> Then start creating it!
[22:28:43] <Lambda_Aurigae> I am working on it...just got my A+ and Net+ certs last month and taking college classes online but that's being nasty slow.
[22:29:25] <Lambda_Aurigae> and I cringe at the thought of taking the Must Consult Someone Else class or test.
[22:30:29] <N1njaneer> I liked RalphWiggum better!
[22:30:41] <Lambda_Aurigae> apparently so does someone else.
[22:32:01] <N1njaneer> touche
[22:34:10] <Lambda_Aurigae> and, I've decided it is better if I don't look up anybody else I knew in highschool.
[22:34:29] <Lambda_Aurigae> or from my military days.
[22:34:36] <Lambda_Aurigae> have now looked up 4 of them...two from each.
[22:34:39] <Lambda_Aurigae> they are all dead.
[22:35:47] <Lambda_Aurigae> so, it's a happy happy joy joy day around here!
[22:35:59] <Lambda_Aurigae> and me with no alcohol in the house!
[22:36:23] <Lambda_Aurigae> aahh well, enough about the Aurigae cursed day...it's off to bed time.
