Back
[00:42:24] <Xark> aczid: Interesting. I notice AVR 328P Pro Mini's are still less expensive at DX.COM. :) Hmm, STM8 is 8K flash, 1K RAM and 16MHz so I'd be interested if it has any advantages.
[00:50:34] * Xark notes the ISA reminds him a bit of 6502...
[01:19:59] <aczid> yeah I also ordered one of those
[01:20:28] <aczid> and a logic analyser and a bunch of other stuff I should really just have on hand if I'm going to be doing this stuff :)
[01:21:43] <aczid> that little stm8 I bought is pretty simple... but 2.82$ for a board with a USB connector and a bunch of GPIO holes is just too nice to pass up
[01:22:01] <aczid> I'm sure it'll find a use
[01:22:48] <Xark> Cool. :)
[01:22:58] <Xark> As long as you don't need some $40 programmer. :)
[01:23:16] <aczid> no I looked it up and it should just work with stmflasher
[01:23:18] <aczid> and sdcc
[01:24:00] <aczid> I also bought a USBasp programmer and separate 10-to-6 pin converter for my AVRs
[01:24:09] <aczid> all crazy cheap :)
[01:24:33] <Xark> aczid: Sounds like you will have a much more stocked workbench.
[01:24:41] <aczid> haha yes :)
[01:24:55] <aczid> now the big wait begins
[01:24:58] <Xark> Did you get the "standard" Salae (sp?) USB logic analyser type deal?
[01:25:17] <aczid> yeah... USBsee. 20% off, 10$!
[01:25:42] <aczid> err, USBee*
[01:25:47] <aczid> http://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-148945
[01:26:13] <aczid> commenters say it works with saleae... been wanting to give that a try
[01:27:40] <Xark> Cool. Can't argue with that price...
[01:28:00] <aczid> exactly. I don't even have a use planned for it... :D
[01:28:06] <aczid> damn you, dx.com
[01:28:15] <Xark> Ouch...the "fancy" software from USBee is $299. :)
[01:29:15] <aczid> where do you see that?
[01:31:11] <Xark> http://www.usbee.com/dx.html
[01:32:06] <aczid> oh lol
[01:32:14] <Xark> Probably why "everybody" pirates the Saleae software. :)
[01:32:43] <aczid> well it's a fake usbee anyway. it doesn't have adc stuff
[01:33:13] <aczid> yeah the commenters give instructions to flash the device to act like a saleae :D
[01:33:22] <Xark> Ahh, A clone of a clone. :)
[01:34:46] <aczid> http://www.jwandrews.co.uk/2011/12/saleae-logic-analyser-clone-teardown-and-reprogramming/
[01:35:33] <aczid> I'm gonna try it :D
[01:56:03] <aczid> oh, this is cool
http://sigrok.org/wiki/MCU123_USBee_AX_Pro_clone
[02:09:14] <Xark> Cool. Sigrok is pretty nice.
[02:10:22] * Xark has used it with his Pipistrello FPGA & buffer board (like a fancy Open Logic Sniffer LA) -> http://sigrok.org/wiki/Saanlima_Pipistrello_OLS
[02:20:14] <aczid> cool
[02:20:35] <aczid> dx doesn't have much in fpga stuff
[02:21:21] <mark4> ok so whats wrong with ... sbi CTRL, IVSEL ;set ivsel bit of ctrl register = put vectors in boot
[02:21:34] <mark4> its telling me "constant required" yet both CTRL and IVSEL are defined
[02:25:09] <Xark> mark4: Hmm, IIRC, those use a funny "address" for port (0-63).
[02:25:33] <mark4> ctrl offset is 0x2
[02:25:35] <Xark> Hmm, actually IO5 is a 5-bit I/O address covering the bit-addressable part of the I/O address space, i.e. the lower half (range: 0–31)
[02:25:37] <mark4> ivsel is bit 3
[02:26:03] <Xark> mark4: If you hardcode the constants does it assemble?
[02:26:09] <mark4> rem ivsel is bit 6 i mean
[02:26:13] <mark4> let me see
[02:26:34] <mark4> i know that ldi r16, CTRL and ldi r16, IVSEL compiles
[02:26:51] <mark4> let me verify that CTRL is actually 2 not "offset 2 from some base"
[02:27:40] <mark4> i wish the hell atmel would simply publish the REGISTER MAP in the same damned document
[02:28:34] <mark4> yea this is "From some offset" which they DO NOT explain and they also do not tell you the base of the offset
[02:28:36] <mark4> fucking idiots
[02:29:40] <mark4> and i cant find the document that gives the actual register map
[02:29:46] <aczid> the register map is the same for all avr cores, only sram offsets and the number of IO ports differs
[02:29:46] <Xark> mark4: Usually there is a full register summary at the back of the datasheet.
[02:29:47] <mark4> i have close to 80 pdfs here for atmel
[02:29:54] <mark4> all nicely names 035434.pdf and 3490564.pdf
[02:30:05] <mark4> its not in this document
[02:30:27] <Xark> mark4: Yes, it is critical to rename them to sane names (or you condemn yourself to downloading same manual N times). :)
[02:30:35] <mark4> its like they make it as difficult as they can possibly make it to find all the relevant pieces
[02:30:53] <aczid> haha yes I have so many docXXXX (5).pdf files in my download dir :(
[02:31:06] <aczid> because re-downloading them is easier than finding them back
[02:31:11] <mark4> xark your condemned to doing that anyway because i have "descriptive name" and oh look theres a new pdf 234234.pdf !
[02:31:24] <mark4> lol
[02:31:31] <mark4> i go thru and puge them every now and then
[02:31:32] <Xark> aczid: Exactly. :) Now I rename them docXXXX - AVR328 datasheet.pdf (or whatever).
[02:32:03] <Xark> mark4: Yes, this is why you need original name preserved. :)
[02:33:10] <aczid> btw dx.com also sells nice-looking 2560-based boards
http://www.dx.com/p/mega2560-r3-development-board-acrylic-case-shell-set-for-arduino-transparent-blue-378746
[02:33:17] * Xark switched to a (zippy) but small SSD drive, so now has to (somewhat) monitor my download directory (which had many dozens of GBs of crap [outdated FPGA IDEs etc.]). :)
[02:33:36] <aczid> uhm, without the case:
http://www.dx.com/p/improved-2014-mega2560-r3-development-board-module-w-usb-cable-for-arduino-blue-368279
[02:33:39] <aczid> $12.22!
[02:34:01] <mark4> and and the datasheet has NOTHING in it for "IVSEL"
[02:34:32] <mark4> no register map
[02:34:49] <Xark> mark4: What part are you targeting?
[02:35:15] <Xark> aczid: I like it better without that case/shell. :)
[02:35:16] <mark4> atxmega256a3u
[02:36:06] <aczid> wow that's a fat datasheet if I ever saw one... 24MB?
[02:36:20] <mark4> the datasheet has no real technical info in it at all
[02:36:30] <mark4> its just marketing bullshit. it tells you what peripherals exist
[02:36:44] <mark4> it tells you a little bit about each ones capabilities
[02:36:52] <mark4> it has Z E R O info in it for an engineer
[02:37:24] <mark4> other than to research the part
[02:38:28] <mark4> half the document is taken up with silly little graphs only a hardware guy would want :P
[02:38:58] <aczid> so it seems IVSEL is a bootloader thingy?
[02:39:03] <aczid> http://www.avrfreaks.net/forum/setting-ivsel-interrupt-vector-bootloader-sector
[02:39:12] <aczid> which you need to do within X number of cycles I think
[02:39:16] <mark4> it moves the interrupt vectors into the boot sector
[02:39:18] <aczid> do you have that pdf on bootloaders?
[02:39:32] <mark4> nope
[02:39:54] <aczid> http://blog.schicks.net/wp-content/uploads/2009/09/bootloader_faq.pdf
[02:40:28] <mark4> thats just talking about it being a protected register
[02:40:53] <mark4> out CPU_CCP, 0xd8
[02:40:58] <mark4> now you have 4 cycles to do
[02:41:05] <mark4> out xxx, yyy as above
[02:41:28] <mark4> its the assembly thats failing. the SBI opcode give an error about a constant being required
[02:41:59] <mark4> in fact it gives TWO errors "constant value required"
[02:42:24] <mark4> yet i can do ldi r16, CTRL and ldi r16, IVSEL immediately before the sbi and they assemble
[02:42:45] <aczid> which assembler are you using and can you share more of the code? like how the registers are defined
[02:43:20] <mark4> i didnt define the registers i includedc avr/io.h :)
[02:43:34] <mark4> and im using as6
[02:44:05] <aczid> ah. and you don't have an i/o poprt mapping to confirm that header...
[02:44:27] <mark4> its atmels header
[02:44:44] <aczid> yeah but still, who knows :)
[02:44:49] <mark4> im sure the port map is buried deep within some ob scure pdf
[02:45:21] <mark4> lol my cat has decided to sit on my chest and purr
[02:45:53] <mark4> the doc im reading (the full i think) also does not state that this register is protectged
[02:45:55] <mark4> are you sure it is?
[02:46:09] <Xark> I need to create a bootloader that loads the main firmware from flash normally, but will go into "update mode" when a GPIO is held low at power on. The update will be via UART. Is this something similar to what you're doing? I'm not sure if changes need to be made for interrupt vector such as:
[02:46:10] <Xark> temp = PMIC.CTRL | PMIC_IVSEL_bm;
[02:46:12] <Xark> CCP = CCP_IOREG_gc;
[02:46:14] <Xark> PMIC.CTRL = temp;
[02:46:25] <Xark> Quote from forum discussing bootloader issues on Xmega.
[02:47:02] <mark4> wtf is that dot notation?
[02:47:22] <Xark> http://www.avrfreaks.net/forum/bootloaders-and-xmega
[02:47:55] <Xark> Structure access, looks like. Could be bitfields.
[02:47:59] <mark4> oooh thats C code
[02:48:11] <mark4> lol
[02:48:28] <mark4> its a very poor way of making the change
[02:48:50] <mark4> c is too inefficitnt
[02:49:23] <aczid> good thing we have compiler optimzation :)
[02:49:37] <aczid> I would rather not do everything in assembly
[02:49:54] <mark4> pmic is offset a0
[02:50:01] <mark4> so pmic.ctrl is a0
[02:50:15] <Xark> mark4: That is easy to find, but bits in PMIC seem more tricky...
[02:50:25] <mark4> compiler optimization == destroy 1:1 corelationbetwen src and obj
[02:50:38] <mark4> this is bit 6
[02:51:22] <mark4> problem is im iffy on indexing the registers or using in/out
[02:51:27] <mark4> when do i have to add 0x20?
[02:51:57] <mark4> mov r16, CTRL follwed by lds r0, r16 <- does that need to be ctrl+0x20 ?
[02:52:35] <aczid> well, .lst files give a nice correlation
[02:52:46] <malinus> Xark: that sounds like arduino bootloader
[02:52:49] <malinus> (almost)
[02:52:54] <Xark> (or .lss in Atmel Studio)
[02:53:12] <mark4> actuallfy LDS r0, CTRL <--- direct
[02:53:40] * Xark notes XMega docs sucks - not all in the datasheet like "mega" E.g., The vectors are moved to the boot section by setting the IVSEL bit in the PMIC CTRL register. More information about bootloaders can be found in the application note AVR109 and AVR1316.
[02:53:51] <mark4> i do notice one MAJOR fuckup with the build output files
[02:53:57] <aczid> Order is being prepared for Shipment \o/
[02:54:00] <mark4> the list file contains ONLY .text
[02:54:09] <mark4> no .data, no .rodata just .text
[02:54:11] <mark4> MORONS
[02:54:18] <Xark> mark4: I think you can control that with -Wa,-lXXXX options.
[02:54:21] <aczid> what about a .map file?
[02:54:43] <mark4> you can?
[02:54:46] <aczid> should show you how things are linked before you go into objcopy-ing stuff into .hex and .eep files
[02:54:50] <mark4> what would the xxxx part be?
[02:55:05] <mark4> the hex file ALSO does not have everything in it
[02:55:08] <mark4> the elf file does
[02:55:19] <aczid> gan you generate a .map file?
[02:55:26] <mark4> i have a .map
[02:55:34] <aczid> does it look ok?
[02:55:41] <mark4> it is not immediately apparant top me exactly what info its trying to give me
[02:55:56] <aczid> you should see all your segments in it
[02:56:00] <aczid> and their sizes
[02:56:23] <aczid> all the symbols too
[02:56:27] <mark4> yes they are there
[02:56:31] <mark4> that part i can read lol
[02:57:12] <aczid> I think .lst files only deal with the .text segment though
[02:57:15] <mark4> its got a bunch of shit about trampilines and init1 init2 init3 that i dont define and ive told it NO standard libs both for the compile and trhe link
[02:57:39] <mark4> aczid thats moronic. i need to see EVERY section in thrr3e
[02:57:59] <aczid> this deals with that C/asm correlation you were talking about
[02:58:11] <aczid> not much sense disassemlbing your unitialized data ;)
[02:58:15] <mark4> i have a .text section and a header section which i defined
[02:58:32] <mark4> i need to see the references from text to header and the references from header to text
[02:58:40] <mark4> i cant. only the text is shown
[02:58:42] <aczid> the trapolines and init stuff are just stubs you can hook into if you need it
[02:59:16] <mark4> aczid .data is STILL needed. i need to see what offset a given variable is assigned to and how much space is assigned
[02:59:26] <aczid> uhm yeah the assembly will use literal values which correspond to the io.h file
[02:59:31] <mark4> and then theres .rodata which is effectivly what my "header" section is
[02:59:44] <mark4> not for variables i define in ram
[03:00:24] <mark4> im moving the interrupt vector to boot. every single vector is a call to the same ISR. the return address of that call tells me what vector was accessed
[03:00:43] <aczid> ah, clever :)
[03:00:45] <mark4> i use that as an address into a RAM vector table allowing user application code to revector any interrupt at run time
[03:01:26] <aczid> maybe you can get more insight into the problem with the live debugger thing
[03:01:35] <mark4> i need to see thre RAM map, the code disassembly and ALL the data thats assembled into rom too
[03:01:45] <mark4> aczid my code is not ready to run yet
[03:01:51] <mark4> i have a nice shiny avr dragon here tho :P
[03:02:26] <Xark> Yeah, looks like no .data in GNU asm list (that I can get). The .map is only good for layout, so you are stuck with objdump I guess. :)
[03:02:52] <mark4> xark the gnu tool developers have their heads firmly planted up their ass
[03:02:55] <mark4> period
[03:03:08] <Xark> Like objdump -D (which will show everything disassembled)
[03:03:08] <mark4> ill ask in #workingset :P
[03:03:22] <mark4> xark another utterly useless tool :P
[03:03:36] <aczid> rather the gnu asshats than the closed source atmel ones :)
[03:03:36] <mark4> you do NOT disassemble data
[03:03:38] <Xark> mark4: I use it all the time. ;)
[03:03:49] <Xark> I do (and then just look at the hex)
[03:04:18] <aczid> -d tells it to not disassemble data :)
[03:04:36] <mark4> xark that makes interpreting the data very VERY difficult when its bytes with 24 bit addresses interleaved with text and other pointers
[03:04:38] <Xark> aczid: Sure, but he already sees that in .lst file. :)
[03:04:53] <mark4> aczid and it has no idea what is data and what is code
[03:05:20] <aczid> no, that's what segments are used for... it's pretty basic I agree
[03:05:27] <mark4> reall what i need to do is a complete reverse engineer of my builds using IDA pro... if only i could afford to update my license :)
[03:05:32] <aczid> IDA can help you there though :)
[03:05:34] <aczid> right
[03:05:39] <Xark> mark4: Hexdump is a hexdump. It would be great if objdump "knew" what the blob of data is, but AFAIK it doesn't (other than symbol offsets).
[03:06:06] <aczid> I would try to get debugwire going
[03:06:10] <mark4> xark there are levels of "debug info" the defalt is 2. i believe thers a level 3, not sure wtf they are tho
[03:06:49] <Xark> mark4: I don't think assembler supports those (other than basic symbols and line number info).
[03:06:54] <mark4> aczid this is all totally temporary. once i have this code in a state where i can debug it ill just write a few hundred unit tests, unit test this ckernel then UNINSTALL EVERY atmel tool
[03:07:14] <Xark> Hmm, if you assemble with -g, then do objdump -S you might get the hexdump along with source assem code for data. :)
[03:07:30] <mark4> its alway very painful to bootstrap a new forth using gnu :P
[03:07:42] * Xark notes that "line level" info is emitted by assembler (for "source level" asm debugging).
[03:07:58] <Xark> Forth is always painful. :)
[03:08:02] <mark4> xark that still means i have to mentally juggle all the 24 bit addresses and try to find where they refer to in the listing
[03:08:10] <mark4> forth is never painful
[03:08:24] <mark4> its only mentally painful to you because you have been brainwashed into using c
[03:08:31] <mark4> which is super super fucked up
[03:08:32] <Flipp_> any idea why my .data section would randomly start at 0x800200? O.o
[03:08:36] <mark4> forth just flows naturally
[03:08:36] <Xark> I will agree to disagree. :)
[03:08:53] <mark4> once you get used to the RPN it is orders of magnitude more natural
[03:09:10] <mark4> no operator presidence at all. no having to mentally juggle where to put the () crap
[03:09:20] <mark4> operator order is the order you present them in
[03:09:30] <Xark> No, the computer needs to learn infix (lazy machine).
[03:09:37] * Xark hates his RPN calculator too...
[03:10:00] <mark4> xark your reaction to rpn is not unique :)
[03:10:13] <mark4> its the reason why forth has not taken over the ENTIRE software engineering industry
[03:10:25] <Xark> mark4: Of course not, see "Forth is always painful". :)
[03:10:31] <mark4> forth is that good it could have
[03:10:45] <mark4> except people like you (not a flame) take one look at it and go screamin for mamma
[03:10:59] <mark4> it just does not fit in with their understanding of the world
[03:11:47] <mark4> that honestly is not a critisim of you or your reaction to forth, it is VERY common
[03:12:38] <Xark> Yes, like 99% of the software industry. I have spent time with forth and stack based machine. Pass. I am pretty happy with C++ (and a bit of asm where needed).
[03:13:22] <Xark> Besides, even if I liked forth, I couldn't use it (too much infrastructure requires C++ these days).
[03:13:37] <mark4> and i think just "C" is the worst thing to have ever happened to the software engineering world
[03:13:47] <mark4> "learn C in 24 hours" <--- this fucking book actualy exists
[03:14:08] <mark4> now every moron and his brother THIKS they can code and i have to compete with them
[03:14:27] <mark4> and the industry LOVES it. lets hire a moron to write our code, it doesnt matter if it works good because we can still sell it
[03:14:42] <mark4> get it written fast and only fix the bugs that people complain about too much
[03:15:01] <aczid> hmm, love me some C99
[03:15:28] <mark4> c lets good programmers do wonderful things. c DEMANDS bad programmers do really bad things
[03:15:51] <Xark> mark4: Lets just agree to disagree about "language wars". Neither of us is going to be changing his mind, so just a re-hashed heat vs light discussion. :)
[03:17:03] <mark4> xark i posted a thread on freaks that covered this a little, i am a gentoo linux user. my computer relies on GNU tools. i recognize and respect the work that went into those tools and the ENORMOUS amouts of work that have been done with them
[03:17:08] <Xark> mark4: Yeah, we have C# for "those guys" now. :)
[03:17:13] <mark4> i dont hate you because you use c/c++ lol
[03:17:21] <mark4> lol
[03:17:44] <Flipp_> mark4: so... what do you think about clang? ;)
[03:17:48] <Flipp_> sorry, couldn't resist :D
[03:17:54] <aczid> way to add fuel to the fire :P
[03:17:59] <mark4> flipp i had really really high hopes for it
[03:18:10] <mark4> it was neither a step backwards from GNU nor a step forwards
[03:18:30] <mark4> they are simply rewriting GNU to look like GNU, smell like GNU and walk like GNU. they just call it LLVM
[03:18:49] <aczid> but they are funded by apple and others :)
[03:19:04] <mark4> it was a sideways step that in a few years will suffer from the same over engineered, badly hacked on and messed up crap that GNU suffers from now
[03:19:12] <Flipp_> and their error messages are so, so, so much nicer. especially for template instantiation
[03:19:22] <aczid> well, this IL thing sounds pretty good
[03:19:35] <mark4> yea so was PIXAR :P
[03:20:00] * Xark looks at "toy" forth-like language using LLVM (http://llvm.org/releases/2.0/docs/Stacker.html)...
[03:20:00] <aczid> ok good point :)
[03:20:42] <Xark> mark4: GNU just copied from Unix (and added a ton of features). :)
[03:21:01] <mark4> feature-itis
[03:21:09] <Xark> If you hate GNU, be glad you aren't stuck on an old Sun box (without GNU tools). :)
[03:21:16] <mark4> and then we hack on it for 30 yeras, patch after patch after patch after patch
[03:21:31] <mark4> turning it intoa clusterfuck of nested if/and/but loops
[03:21:37] * Xark notes mark4 would probably just stay in the Sun bootloader (Forth). :)
[03:21:42] <Flipp_> on-topic question: what's the significance of the .data section starting at 0x800200? that seems way above the upper memory limit... O.o
[03:21:43] <mark4> the same will happen to llvm
[03:22:00] <aczid> then they'll call it 1.0
[03:22:01] <mark4> on what device?
[03:22:08] <Flipp_> mega2560
[03:22:08] <Xark> mark4: What is wrong with that? And then someone will make a new "fresh" thing...
[03:22:29] <mark4> xark they DONT make a new fresh thing, they simply copy the old :P
[03:22:32] <Flipp_> xark: that someone will eventually try to cross-compile back into javascript. because... javascript
[03:22:33] <aczid> Flipp_: in gnu tools all the addresses are offset by 0x000000
[03:22:42] <aczid> er, 0x80000000
[03:22:54] <aczid> because that's how an elf file maps memory
[03:23:00] <Flipp_> ...but the .init sections don't?
[03:23:11] <mark4> aczid more accurately how the linker script maps it?
[03:23:35] <aczid> well, yes.. but that is by convention of how memory is mapped in linux
[03:23:42] <mark4> not on arm :)
[03:23:45] <Flipp_> aczid: fini0 is at 0x03f7d0, but .data is at 0x800200 O.o
[03:23:51] <aczid> yes, x86 :)
[03:23:57] <Xark> Flipp_: Escaping Javascript is like escaping a black hole (too late). :)
[03:23:58] <mark4> you will see your application at 0x2000 on arm :)
[03:24:14] <aczid> x86-64 is different too
[03:24:27] <aczid> Flipp_: yeah that's kinda weird
[03:24:44] <aczid> but .fini is code
[03:24:56] <aczid> big flash?
[03:25:29] * Xark believes the AVR SRAM 0x8000000 offset was a "hack" because GNU C doesn't really support multiple address spaces (although now has some support...).
[03:25:40] <aczid> sounds about right
[03:25:49] <Flipp_> aczid:
http://pastebin.com/enSZKDSV
[03:25:58] <mark4> xark exactly. they cant FIX it because its too complicated
[03:26:07] <mark4> so they patch it with a very MESSY non fix
[03:26:10] <Xark> mark4: AVR is just not a good Unix machine. :)
[03:26:20] <Flipp_> that's not the whole thing
[03:26:22] <aczid> looks normal to me Flipp_, does it work? :)
[03:26:30] <mark4> xark using gnu toolchain for embedded is a REALLY REALLY REALLY bad idea
[03:26:33] <mark4> yet everyone is doing it
[03:26:39] <Flipp_> erm, yeah it does
[03:26:44] <aczid> mark4: why?
[03:26:55] <Flipp_> just trying to understand why :)
[03:27:00] <mark4> because the gnu tools were NEVER developed with harvard architectures in mind
[03:27:03] <aczid> Flipp_: that ram hack
[03:27:11] <mark4> where ram starts at address 0. rom starts at address 0
[03:27:27] <Xark> mark4: Seems fine to me (but I have been doing it for a long time).
[03:27:57] <mark4> xark im 50, ive been coding since i was 18, but did not do it professionally till i was about 25
[03:28:02] <Flipp_> aczid: hm. so that's just for the ELF then, right? not the hex, since mem address 800200 doesn't exist on 256k of flash...?
[03:28:04] <Xark> mark4: Vendor tools are almost always worse than GNU in my experience (thankfully they have mostly quit trying to write their own tools).
[03:28:19] <mark4> xark which is why i roll my own :P~
[03:28:20] <mark4> i win
[03:28:22] <mark4> yay
[03:28:47] <Xark> mark4: I'm 50 and got my first professional job at 17 (on an embedded system [kind of] - Atari 2600).
[03:28:56] <mark4> xark arm bought Keil. keil had the single best embedded tool shite ever devised by man for both 8051 AND arm
[03:29:11] <mark4> arm tells keil. put your stuff in the trash. put your name on our tools
[03:29:27] <aczid> Flipp_: yes you should subtract your 'sram offset' (that 0x800200 is it) for those addresses to get their physical SRAM locations
[03:29:33] <mark4> xark was that 68k? or did it predate the 68k?
[03:29:55] <Xark> mark4: Indeed 6502 (well, 6507 IIRC, less pins).
[03:30:01] <mark4> arms assembler costs $10,000 and it does not know where the end of an assembler source file is unless you TELL IT
[03:30:05] <mark4> awesome tools
[03:30:08] <aczid> Flipp_: EEPROM is done in a similar way. but code has the real mapping for the overlapping address spaces
[03:30:14] <Xark> mark4: 4K ROM, 128 bytes of RAM (fun times). :)
[03:30:16] <mark4> oooh <3 6502 :)
[03:30:24] <Flipp_> yeah, the eeprom is at 0x810000
[03:30:41] <mark4> 640k aughta be enough for everyone
[03:31:03] <mark4> xark you know the indirect jump bug or x2 crash?>
[03:31:24] <aczid> Flipp_: the SRAM stuff is really just for accounting. objcopy will make .hex and .eep files for you from the .text and .eeprom segments in the elf file
[03:32:07] <Xark> mark4: We already discussed JMP (XXFF,X) bug. Not sure about X2...
[03:32:13] <mark4> oooh lol
[03:32:29] <mark4> theres only one opcode that ends in 2. thats the tax i think? or is it txa
[03:32:38] <Xark> Oh, is that the opcode that hangs the chip?
[03:32:40] <mark4> any other x2 opcode, 02, 12, 22 etc will hard crash the core
[03:32:49] <Xark> Yeah....been there done that. :)
[03:33:07] <aczid> hey I have question for you guys... is it bad to do st Y+, YH if you know it won't cross a page boundary?
[03:33:17] <aczid> :)
[03:33:18] <Xark> Tons of fun on systems with only NMI no reset (other than power on).
[03:33:24] * Xark glares at Atari 400/800
[03:33:40] <aczid> the atmel assembler and simulavr don't like it... but it works fine really
[03:34:03] <mark4> yea they complain.. but is it an error or a warning?
[03:34:10] <aczid> warning
[03:34:19] <aczid> undefined opcode or something
[03:34:30] <aczid> it assembles and runs fine
[03:34:31] <mark4> kk i saw it and just rewrote my code to not produce the warning :)
[03:34:33] <Xark> aczid: I think it does 16-bit increment...weird they would warn (maybe some small chips whimped on this)?
[03:34:58] <Xark> I DO think it is a problem going over 64KB boundary....
[03:35:08] <mark4> st y+ does do a 16 bit increment meaning the value stored could be the pre incremented value or the pst incmremented value
[03:35:10] <aczid> well, if YL is 0xff it could hurt
[03:35:16] <aczid> or something
[03:35:19] <mark4> just to not have to suffer the warning messages i dont code those kinds of opcodes
[03:35:50] <aczid> well, this was a very specific case where I was optimizing for size using cleverness :)
[03:35:59] <aczid> indirect register addressing
[03:36:10] <Xark> aczid: What gives the warnings? Some similator?
[03:36:15] <Xark> simulator*
[03:36:20] <mark4> no the assembler
[03:36:29] <aczid> atmel's assembler warns. simulavr balks
[03:36:29] <Xark> Hmm, interesting.
[03:36:34] <aczid> after patching simulavr, it works fine
[03:36:43] <aczid> it is in this piece of code
https://github.com/aczid/ru_crypto_engineering/blob/master/PRESENT_size_optimized.asm
[03:36:47] <mark4> i dont trust the sim :)
[03:36:54] <mark4> avr dragon ftw
[03:37:06] <aczid> 64 bit block cipher with 80 or 128 bit keys in 128 instructions with 16 bytes for s-boxes
[03:37:10] <aczid> ^^
[03:37:45] <Xark> Sounds bogus. The Atmel ST index Y docs say "The data location is pointed to by the Y (16 bits) Pointer Register in the Register File. Memory access is limited to the current data segment of 64K bytes. To access another data segment in devices with more than 64K bytes data space, the RAMPY in register in the I/O area has to be changed."
[03:37:58] <aczid> would be cool if some long time pros like you could help me take anothor instruction or two out
[03:38:16] <mark4> aczid you going for SMALL over fast?
[03:38:41] <aczid> yes, my co-author implemented a speed-optimized version. two actually
[03:38:45] <Xark> OK, I see. It IS a hazard (due to dest register).
[03:38:53] <Xark> The result of these combinations is undefined:
[03:38:54] <Xark> ST Y+, r28
[03:38:56] <Xark> ST Y+, r29
[03:38:57] <Xark> ST -Y, r28
[03:38:59] <Xark> ST -Y, r29
[03:39:08] <aczid> but what about if you don't cross a page boundary?
[03:39:42] <Xark> aczid: Those are documented as undefined. So perhaps format your C: drive? :)
[03:39:43] <mark4> i pick small over fast for the overall project every time. not EVERY INCH of your code needs to be greased lightening.
[03:39:49] <mark4> where it does... asm ftw
[03:40:23] <Xark> aczid: You can test it on chip X and use it if you want, but I would avoid those. :)
[03:40:33] <aczid> I have and it works fine
[03:40:37] <aczid> i'm not changing anything :D
[03:40:42] <mark4> aczid paste the code somewhere :)
[03:40:47] <Xark> aczid: Ok.
[03:40:50] <aczid> it's on that page I linked
[03:40:50] <mark4> not that im ubber expert at avr asm yet :)
[03:40:54] <aczid> the github
[03:41:13] <mark4> lol wish hexchat HIGHLIGHTED links
[03:41:47] <mark4> want it smaller? make the macro a subroutine and pass parameters
[03:42:04] <Xark> aczid: Having designed a few (simple) CPUs in FPGA, I can see why it might be undefined (even if not crossing). However, perhaps it varies per chip etc.
[03:42:54] <aczid> mark4: wouldn't that incur another call instruction?
[03:43:28] <aczid> Xark: I didn't really get that thing about the 16-bit increment...
[03:43:29] <mark4> it would be slower. but smaller because instead of inlining those macros every time you just "call"
[03:43:54] <aczid> the macro's are only inlined once each. I only use it to paste together some code for calling or inlining
[03:43:57] <Xark> aczid: I believe it just means it treats YH:YL as a 16-bit pointer.
[03:44:00] <aczid> to save those extra calls :)
[03:44:10] <mark4> oh
[03:44:15] <mark4> then the macros are fine lol
[03:44:49] <mark4> instead of doing 2 nops yu could do a single 2 cycle opcode :)
[03:44:49] <aczid> Xark: well, that would imply it is safe... right? just that it might give you one value or the other when an overflow happens. as far as I can tell
[03:45:00] <aczid> mark4: oh, that's a good idea!
[03:45:04] <mark4> lol
[03:45:06] <aczid> I owe you a beer for that
[03:45:10] <mark4> i are good :0
[03:45:13] * aczid facepalms
[03:45:20] <Xark> aczid: Not really (but it might be safe, I haven't tested).
[03:45:23] <mark4> erm no, i cant stand beer.. puh puh
[03:45:26] <mark4> make mine a JD :P
[03:45:30] <mark4> mix it with JD only
[03:45:32] <aczid> you got it man
[03:45:39] <aczid> so, neat. :)
[03:45:55] <mark4> i keep my JD in the freezer right next to the shot glasses
[03:45:56] <aczid> any opcode in mind?
[03:45:58] <mark4> so i dont have to add ice
[03:46:02] <mark4> i was about to look
[03:46:04] <Xark> rjmp .+2
[03:46:10] <aczid> oh yeah
[03:46:18] <aczid> that'll work. and confuse the readers :)
[03:46:29] * Xark uses that a few places in his NTSC bit-banging. :)
[03:46:37] <aczid> now that sounds like fun
[03:46:54] <Xark> https://www.youtube.com/watch?v=Imk5ony8JHI
[03:47:05] <mark4> rjmp 0f
[03:47:07] <mark4> 0:
[03:47:13] <mark4> rjmp is 2 cycles
[03:47:19] <Xark> AVR 328P "game console" engine. :)
[03:47:31] <aczid> mark4: Xark beat you to it
[03:47:38] <mark4> oh
[03:47:52] <mark4> i was lookin in the dox didnt see him get to my punch line first :OP
[03:47:56] <Xark> also
https://imgur.com/IgsmEY3 and
https://imgur.com/gNyTb6u (horizontal and vertical smooth scrolling fully supported too)
[03:48:00] <aczid> I'll have to see if it interferes with my flags or anything, but it sounds like a good candidate
[03:48:16] <aczid> wow that's rad. PAL next? :)
[03:48:37] <Xark> PAL is supported (but with more black top/bottom)
[03:49:02] <mark4> rjmp does not touch flags
[03:49:08] <mark4> neither does rcall
[03:49:19] <aczid> ok, that's perfect then
[03:49:22] <Xark> rcall is not good if you go >128KB flash IIRC
[03:49:44] <mark4> rcall is for calling something wtihin 2k of you
[03:49:45] <Xark> (I think timing may change...)
[03:49:55] <aczid> the code is 272 bytes (270 thanks to you!). you can fit it in the low part :)
[03:50:01] <mark4> if its not within 2k it cant get there
[03:50:03] <aczid> .org something
[03:50:18] <mark4> i see, HE gets the credit... bah :P~
[03:50:31] <aczid> no I was using the plural you :)
[03:50:36] <mark4> lol
[03:50:57] <aczid> but rcall is supported from any address right? just not too far away
[03:51:07] <aczid> or is there something funky with the big avr's?
[03:51:08] <mark4> wow you have code that actually uses the T bit lol
[03:51:12] <mark4> im impressed!
[03:51:15] <Xark> aczid: Now I need to make a "demo scene intro" with my lib (just some tech demos currently). :)
[03:51:17] <aczid> thank you :)
[03:51:33] <aczid> Xark: I've seen another atmega demo on yt before ages ago
[03:51:53] <Xark> aczid: Yeah, Linus...
[03:52:07] <Xark> http://www.linusakesson.net/scene/craft/
[03:52:13] <Xark> (and others)
[03:52:22] <mark4> im wondering if the pushes of OUTPUT3/2/1/0 is needed
[03:52:27] <aczid> yeah I'm pretty sure that's it
[03:52:46] <aczid> mark4: it's for doing a bitwise re-arrangement
[03:52:50] <aczid> permutation layer
[03:53:04] <mark4> it pops and st -X, later
[03:53:17] <aczid> looping over those 4 would be bigger than 4 literal instructions
[03:53:21] <aczid> afaict
[03:53:46] <mark4> you cou do st -X st -X st -X st -x followed bhy subi xl, 4 and subi player_index,4
[03:53:53] <aczid> right. in between the pushing and popping it moves the SRAM pointers around so it interleaves the two half-blocks
[03:55:26] <mark4> i still think the pops can be deleted
[03:55:27] <aczid> mark4: uhm, you mean like the playerOut: thing is doing?
[03:55:36] <aczid> 4 pushes you mean?
[03:55:41] <mark4> erm yes
[03:55:49] <mark4> thats what i said..... i distinctly remember syaing it!
[03:56:00] <mark4> honest wouldilietoyou (tm)
[03:56:05] <aczid> those happen twice after eachother. and then the second part interleaves those 2x4 bytes
[03:56:15] <aczid> I'll take your word for it
[03:56:29] <mark4> im not analyzing what the code does, just what the opcodes do :)
[03:57:00] <mark4> it just seems to me like we can NOT do the pops and unroll the loop i
[03:57:08] <mark4> i THINK that might be smaller but im not sure
[03:57:12] * Xark links his crazy NTSC asm code (but "messy" C++ header with inline) -> http://hastebin.com/tiqewirale.tex
[03:57:15] <mark4> do 4 st -x then 2 subs
[03:57:56] <mark4> but i didnt analyze the logic or what operation the code is performing
[03:58:12] <mark4> hang on i have to go put icing on a cake i baked for our church meetin tomorrow :P
[03:58:24] <mark4> hmmmmmm spice cake with spicy icing! drool
[03:59:21] <aczid> mark4: mark4 it's doing this bitwise rewiring of state bits
https://www.cryptolux.org/images/0/0f/PRESENT_round_function.png
[03:59:29] <aczid> very very annoying in sw :)
[04:01:36] <aczid> Xark: have you ever played with the tinyVGA board?
[04:02:24] <aczid> that header looks pro :D
[04:04:20] <Xark> aczid: It supports a lot of "modes" so looks a bit messy, but is quite flexible (and turns into "great" assembly code). I notice the comment block at the top is not really correct anymore (project drift - turned into a game library). :)
[04:05:35] <mark4> tieing a gordian knot withthe bits u mean :)
[04:06:22] <Xark> aczid: A few years ago when I got an Arduino over Thanksgiving vacation I found
https://code.google.com/p/arduino-tvout/ and (over time) re-wrote it to be tiled graphics as bitmap sucks for 2K SRAM. Fun way to learn AVR asm. :)
[04:06:26] <aczid> mark4: pretty much. :) I'm quite happy I got it this small as it is
[04:06:33] <mark4> :)
[04:07:01] <aczid> Xark: it looks pretty usable... but daunting on the inside :)
[04:07:18] <mark4> i hate that the assembler gives you non existant opcode nemonics like "clr"
[04:07:20] <Xark> aczid: Yeah. App code is "Arduino easy". :D
[04:07:26] <mark4> there is no clr opcode
[04:07:40] <Xark> mark4: Just pretend it is a built in macro. :)
[04:07:55] <Xark> Same with ASL, right?
[04:08:05] <mark4> ldi rn, 0 or xor rn, rn or sub rn, rn
[04:08:07] <mark4> res
[04:08:10] <aczid> it helps me keep my sanity
[04:08:14] <mark4> add rn, rn
[04:08:38] <mark4> my svr assembler does not support that crap
[04:08:47] <Xark> aczid: Nicely documenting, IMHO.
[04:09:02] <aczid> yes exactly. expressive. idiomatic
[04:09:14] <aczid> <other superlatives>
[04:09:16] <Xark> mark4: I see no harm as long as it turns into a single instruction.
[04:09:34] <Xark> mark4: I believe it disassembles "your way". :)
[04:09:36] <aczid> syntactic sugar! :)
[04:09:45] <aczid> yes it does
[04:09:55] <mark4> /gist.github.com/5add96b463ed3c6ab1bb
[04:10:03] <aczid> always trips me up for a second too :)
[04:10:05] <mark4> https didnt cut lol
[04:10:13] <mark4> https//gist.github.com/5add96b463ed3c6ab1bb
[04:10:17] <mark4> my assembler
[04:12:23] <aczid> an avr asembler written in forth? bravo
[04:12:29] <mark4> yes
[04:12:37] <aczid> and you were working on a forth compiler for avr too right?
[04:12:42] <mark4> the forth compiler its compiled with was also written by me
[04:12:43] <mark4> yes
[04:12:54] <mark4> and i was building it with this assembler
[04:12:55] <aczid> that's pretty awesome :)
[04:13:05] <aczid> if you like forth ;)
[04:13:21] <aczid> no but that's very very cool
[04:13:26] <aczid> I applaud you
[04:13:44] <mark4> im a heretic. i hate c :P
[04:13:58] <aczid> I wish I could read it! :)
[04:14:00] <Xark> mark4: Do you have a sample source file your avr assembler can assemble?
[04:14:00] <mark4> but agree that asm is painful to write LARGE programs with. tho i do that too
[04:15:11] <mark4> https://gist.github.com/38c303a66223f4d83d39
[04:16:02] <Xark> Ahh, so it is like an inline Forth assembler?
[04:16:15] <mark4> sort of
[04:16:28] <Xark> Or just in a .f file "for yucks". :)
[04:17:10] <mark4> you can call your source files anything
[04:17:15] <mark4> i stole .f who needs fortran
[04:17:25] <mark4> https://gist.github.com/anonymous/52efd42d598c24ea2dae
[04:17:28] <mark4> another example
[04:17:40] <aczid> who needs fortran? gcc thinks everybody does :)
[04:17:41] <mark4> thats from my not yet finished atmega32u4 version of this forth
[04:17:49] <mark4> and gcc sux
[04:17:51] <mark4> nuff sed
[04:18:23] <aczid> don't hold it against me if I don't make the switch to forth just yet :)
[04:18:39] <mark4> notioce how neat and tidy and well commented my sources are?
[04:18:53] <mark4> i should quote my .plan :)
[04:19:13] <mark4> 1: code isforth (linux x86 forth)
[04:19:19] <mark4> 2: convert linus to forth
[04:19:26] <mark4> 3: recode linux in forth (about a week)
[04:19:32] <mark4> 4: stop smoking crack
[04:19:41] <aczid> lol
[04:19:59] <mark4> isforth is done
[04:20:02] <mark4> and ported to arm
[04:20:04] <aczid> maybe that templeOS guy is interested in collaborating :)
[04:20:08] <mark4> and ported to thumb2
[04:20:12] <mark4> and ported to android :P
[04:20:32] <mark4> in the crack smoking operation?
[04:20:39] <aczid> I dare to ask... is isforth written in forth?
[04:20:44] <mark4> yes
[04:20:45] <mark4> and no
[04:20:47] <aczid> XD
[04:20:53] <mark4> its written in x86 assembler using macros
[04:20:53] <vsync_> hahah
[04:21:12] <mark4> the macros make the assembler output exactly the same binary that the forth compiler would produce if it metacompiled the forth kernel
[04:21:20] <mark4> but i dont have an x86 assembler or a metacompiler yet
[04:21:24] <vsync_> aczid: in all honesty, i think he is related to the templeos guy
[04:21:27] <aczid> that's just your bootstrap process then?
[04:21:28] <mark4> so isforth is technically not finshed
[04:21:37] <mark4> but is very usable and compiles super fast
[04:21:54] <mark4> yes
[04:21:59] <Xark> vsync_: Hahaha. :)
[04:21:59] <mark4> isforth is assembled with nasm
[04:22:05] <aczid> well, fuck the haters. I think it's awesome :)
[04:22:24] <aczid> but hope you can take a bit of teasing you for your strongwilledness
[04:22:25] <mark4> this forth is only being assembled with the gnu tools so i can debug it symbolically
[04:22:41] <mark4> once i have proved the primitives i just port the source over for assembly with MY assembler
[04:22:48] <mark4> which will do a much cleaner job of it
[04:22:52] <aczid> yeah I get it
[04:23:10] <aczid> how much time have you invested in this toolchain so far?
[04:23:11] <mark4> this stage of devel is super painful
[04:23:26] * Xark is not a hater (and finds mark4's stuff pretty cool - even if I am not a convert). :)
[04:23:35] <mark4> isforth is written in 100% pure asm and makes zero uses of any external libraries such as libc and what have u
[04:23:39] <mark4> NONE of that shit is used
[04:23:48] <aczid> cool
[04:23:48] <mark4> yet
[04:23:53] <mark4> :P
[04:24:15] <mark4> i have emotional problems. i lose my cool sometimes :P
[04:24:15] <aczid> I can about code hello world in x86 linux asm and that's it :)
[04:25:01] <mark4> ive had people look at my isforth sources who dont code forth OR asm tell me they can read them
[04:25:06] <mark4> thats my #1 primary goal
[04:25:15] <aczid> wish my DX stuff would get here... :(
[04:25:37] <mark4> making code readable is more important than making it cool, small, fast OR work
[04:25:44] <vsync_> mark4: how much acid do you drop on an avg. day?
[04:26:00] <mark4> 5 bor 6 pots of coffee?
[04:26:17] <mark4> 5 or 6
[04:26:32] <vsync_> never knew that induced schizophrenia also
[04:26:33] <aczid> not sleeping can also cause hallucinations :)
[04:26:52] <vsync_> gotta lay off my coffee...
[04:26:59] <aczid> I tend to agree that code should be readable above many other things
[04:27:06] <mark4> im a dedicated coffeeholic
[04:27:11] <aczid> ... but not above working :)
[04:27:15] <vsync_> i agree thats why i use python
[04:27:16] <mark4> and it doesnt keep me awake. WORK keeps me awake but not coffee
[04:27:23] <Xark> aczid: Wait, didn't you just make that order like a few hours ago? Perhaps you shouldn't have used DX if you were in a hurry... :)
[04:27:27] <vsync_> avr python interpreter is the best
[04:27:38] <aczid> Xark: yes I was just being pouty :)
[04:27:48] <mark4> aczid. i code something here and get it 99% complee. i quit and go yeti hunting and you take over
[04:27:49] <Xark> vsync_: Better than AVR javascript? :)
[04:27:51] <aczid> you know what it's like when you anticipate stuff
[04:27:55] <mark4> you want it readable or working? pick one
[04:28:15] <aczid> mark4: don't go hunting man! we need you over here! :)
[04:28:27] <mark4> but thers yeti to catch!
[04:28:28] <mark4> lol
[04:28:28] <aczid> I'd like a fair mix of both
[04:28:37] <mark4> thers an art to it
[04:28:42] <Xark> good / fast / cheap
[04:28:47] <mark4> pick 2
[04:28:48] <aczid> pick two
[04:28:50] <aczid> :)
[04:28:50] <vsync_> Xark: no
[04:29:06] <mark4> now i know you were not bullshitting when you said how old you were :P
[04:29:18] <mark4> i quote that one to my boss all the tim
[04:29:23] <Xark> Or, double up on one. :)
[04:29:23] <vsync_> mark4: how's the lawsuit coming together?
[04:29:42] <Xark> If you want it *really* good, it is not fast or cheap (etc.)
[04:29:43] <mark4> i still have to file it, thats all thats left to do at this stage
[04:29:58] <mark4> but i cant file it yet because i dont have the time. i have to TAKE it to the court to file, not mail it in
[04:30:04] <mark4> if i mail it they will reject it
[04:30:22] <aczid> what lawsuit?
[04:30:25] <vsync_> does your boss have a "golden arches" -pin on his shirt? Cause i'd say it's difficult for a convicted felon to get jobs
[04:30:27] <mark4> if they reject it as i hand it to them i hand them the federal rules of civil procedure with the relevent law highlighted
[04:30:41] <mark4> im not a convicted felon
[04:30:45] <mark4> it was never a felony
[04:31:02] <vsync_> seems to me, it was
[04:31:08] <mark4> nope
[04:31:08] <aczid> were you trying to intimidate people in to using forth?
[04:31:42] <vsync_> he'd been smoking the ole hemp, and he got butthurt for them busting him on it
[04:31:44] <mark4> lol no. a truck driver went postal on me and charged at my 2003 kia rio with his 80,000lb truck (thats the federal weight limit and he was at it)
[04:31:50] <mark4> i aimed a 45 at his grill
[04:32:10] <mark4> he didnt touch his brakes till he saw the pointy end and when he stopped he was less than a foot off my tail end
[04:32:20] <mark4> this happened in milwaukee wisconsin
[04:32:26] <vsync_> oh you mark4, you funny :)
[04:32:35] <mark4> the milwaukee district attorney is a scumbag
[04:32:37] <aczid> wait the grill on his truck? or his grill as in his face?
[04:32:50] <vsync_> it was optimus prime, you see
[04:32:50] <mark4> go look up the tanya wyker story to see just how bad a dick this man is
[04:32:59] <vsync_> the brain is located behind the grill
[04:33:12] <mark4> also look up "secret john doe investigations" something a judge ordered him to stop and he didnt stop
[04:33:23] <mark4> of his truck
[04:33:31] <mark4> i dont aim my gun at a target i cant see
[04:33:39] <mark4> and trust me. i could definately see his grill
[04:34:00] <mark4> i was charged with disorderly conduct while in posession of a firearm. not a felony
[04:34:01] <aczid> I'm still quite confused
[04:34:14] <mark4> the truck driver IS however a felon
[04:34:17] <aczid> it's okay. not everything has to make sense
[04:34:20] <mark4> 7 counts of forgery
[04:34:22] <Xark> mark4: Hmm, so, out of curiosity, does your forth run under TempleOS? :)
[04:34:25] <mark4> one count of child molestation
[04:34:30] <mark4> but the judge ordered the jury not hear that
[04:34:38] <mark4> dont know what that is
[04:34:41] <mark4> but i bet it could
[04:34:51] <vsync_> do you have assembler drivers for RedSea Filesystem(tm)?
[04:34:57] <vsync_> aka. templeos filesystem
[04:35:01] <mark4> nope
[04:35:06] <vsync_> Do you talk to god, motherfucker?
[04:35:09] <mark4> ive never heared of it
[04:35:16] <aczid> I think templeos uses a system of syscalls similar to linux
[04:35:20] <vsync_> mark4: but we all know that's not the reason why you did time
[04:35:27] <mark4> yes it was
[04:35:29] <vsync_> don't try to fool that kiddo over there
[04:35:51] <mark4> i was sentenced to 45 days, did 3o something, appealed, got the conviction tossed on appeal
[04:35:58] <mark4> the DA decided to reprosecute. do over
[04:36:09] <mark4> the conviction was not reversed, just removed
[04:36:23] <vsync_> not file the lawsuit! you can do it!
[04:36:36] <mark4> ?
[04:36:39] <vsync_> so there was no reasonable doubt or whatever the other fuck murican law bs
[04:36:49] <mark4> if my suit was filed i would post it for you guys to read
[04:36:49] <vsync_> to determine you armed and dangerous
[04:37:06] <vsync_> when they searched your vehicle
[04:37:13] <mark4> reasonable suspission and probable cause are the terms you are looking for
[04:37:25] <aczid> more like AVRed and dangerous! :P
[04:37:27] <vsync_> also, loopy story right, how'd you know the truck was at 80k lbs?
[04:37:33] <mark4> for a lesson in how cops can use either look up arizona v gant and terry v ohio
[04:37:45] <mark4> because in court he said so
[04:37:57] <vsync_> relevant, much?
[04:38:10] <vsync_> mark4: neither of which includes threatening with firearms, yeah?
[04:38:13] <mark4> at 60mph with me doing 35?
[04:38:28] <vsync_> mark4: should have nothing to do with your conviction
[04:38:37] <mark4> had he made contact not only would i be dead but so would the people in the vehicle in front of me
[04:38:41] <vsync_> now, can i have your golden arches -pin?
[04:38:43] <mark4> the vehicle in front of them
[04:38:47] <mark4> and the vehicle in front of them
[04:38:52] <mark4> and the 3 vehicles to their right
[04:39:00] <vsync_> and a 100 other vehicles
[04:39:02] <mark4> and god knows how many behind us
[04:39:14] <vsync_> and 3 koalas, 2 kangaroos, mother mary, indira gandhi and buddha himself
[04:39:26] <mark4> i was in a traffic jam with this car in indianapolis, on 65 going north just south of 465
[04:39:44] <mark4> a lady in a mercedes behind me let off her brake and tapped my rear end from a stand still
[04:39:55] <vsync_> you got pegged?
[04:39:58] <mark4> i rocketd forward into the suv in front of me who then dominoed into the car in front of it
[04:40:02] <mark4> that was from a stand still
[04:40:11] <mark4> and caused by a 1970s mercedes benz
[04:40:18] <vsync_> well, americans like you do make poor drivers, is that your point?
[04:40:29] <mark4> a 80klb truck at 60 would be a major catastrophic event
[04:40:43] <mark4> i saved not only my own life but the lives of numerous people close by
[04:40:46] <mark4> i have no regrets
[04:40:55] <vsync_> yes, you're a hero
[04:40:59] <mark4> i would go back to jail agin and again knowing what i did was the right thing
[04:41:00] <vsync_> (read: delusional)
[04:41:11] <mark4> if you sya so
[04:41:15] <vsync_> and now you gotta sue them! Fuck yeah, mmmuricaaaa
[04:41:32] <mark4> but im not a felon, i dont molest children. i dont attack people with 80,000lb trucks
[04:41:34] <vsync_> you should ask all of these people you saved, for some money, for your legal fees
[04:41:37] <mark4> the truckdriver on the other hand...
[04:41:56] <mark4> actuallyt god provided.
[04:41:57] <vsync_> or, legal costs. i guess that's more proper
[04:42:11] <vsync_> eh?
[04:42:26] <mark4> i paied a $2000 retainer and after 2 and a half years of pretrial aftre pretrial after pretrial after pretrial he never charged me another red cent
[04:42:51] <vsync_> i'm thinking
[04:43:02] <mark4> dont over do it
[04:43:22] <vsync_> you will only get yourself in a bigger mess
[04:43:30] <mark4> maybe
[04:43:48] <vsync_> i suspect you're better off writing your silly software stuff :)
[04:43:55] <mark4> that IS quite possible
[04:43:56] <vsync_> if you need to get it out there, write a book.
[04:44:03] <mark4> i have no formal education in anything.
[04:44:10] <mark4> im 100% self taught in programming
[04:44:12] <vsync_> and that's a shocker.
[04:44:21] <mark4> i also play classical guitar. (badly)
[04:44:31] <mark4> i have had 4 years to study the laws of this case
[04:44:31] <vsync_> and are also an expert in legal
[04:44:38] <vsync_> yees
[04:44:47] <mark4> in this case i know what laws were broken
[04:44:51] <mark4> and none of them were broken by me
[04:45:02] <mark4> but you can think otherwise if you wish
[04:46:18] <mark4> tanya wyker. driving home. t-boned by a milwaukee deputy sheriff. charged with driving under the influence AFTER testing negative for alcohol. charges against her maintained for 4 months even thou the DA saw a video recording from a nearby airfield showing the cop running a stop sign
[04:46:34] <mark4> i have more horror stories about this DA too. he is a skumbag
[04:46:40] <vsync_> how does DUI have anything to do with this?
[04:46:51] <vsync_> two different things, really
[04:46:58] <mark4> thats the tanya wyker story. the cop broke her neck in 4 places
[04:47:11] <mark4> and the da maintained the bogus charges against her for 4 months just to protect the cop
[04:47:59] <mark4> then theres that old dood whose name i forget. 3 thugs with baseball bats beating him to death. he shot and killed 2. the DA tried to pin murder on him for 2 weeks but couldnt get it done
[04:48:07] <mark4> da never charged the 3rd thug with murder
[04:48:47] <vsync_> well, you murica fucks can only really blame yourself for being the way you are
[04:48:55] <mark4> i dont care one iota about ANY of the money my lawsuit is claiming
[04:49:07] <mark4> what i want is for this guy to go to prison. but that will never happen
[04:49:24] <vsync_> so, what is the point then?
[04:49:42] <mark4> i dont think you would care or understand
[04:49:57] <vsync_> i think i do
[04:50:21] <mark4> the only thing required for evil to prevail is for good men to do nothing
[04:50:33] <vsync_> will you be the new hans reiser? the software "engineer" who's doing time?
[04:50:44] <mark4> he murdered his wife
[04:50:51] <mark4> im not going to prison lol
[04:50:58] <vsync_> mark4: no, he might have not
[04:51:10] <vsync_> if he would have understood to make a case as strong as you have, for himself, he'd be a free man
[04:51:12] <mark4> no he did. he confessed and took the cops to the body
[04:51:15] <mark4> for a deal
[04:51:30] <vsync_> it was his plan b, everything was faked
[04:51:59] <vsync_> he understood he couldn't make a case, as strong as this, and just resorted to plan b to avoid prolonged trialing
[04:52:18] <vsync_> in reality it was a blow-up doll but, murica
[04:52:26] <mark4> i on the other hand dont care how long it takes for justice to prevail
[04:53:17] <mark4> i work 80+ hours a week. i get $600 and give $500 of that to my landlord for over a year of back rent
[04:53:40] <mark4> i do not consider myself poor
[04:55:36] <vsync_> so it is, after all, golden arches?
[04:55:49] <mark4> i dont get that reference
[04:56:08] <vsync_> starts with an m
[04:56:15] <vsync_> ends in... cdonald's
[04:56:16] <mark4> but i do understand that your trying to belittle me becaus of your own complete and utter ignorance of the entire subject
[04:56:20] <mark4> so... whatever
[04:56:59] <vsync_> i think those $50k a day pops are a great addition to this, $100 / week business
[04:57:14] <vsync_> then you might afford to move from assembler
[04:57:15] <vsync_> \;D/
[05:00:04] <mark4> iave had 4 years of anger on this, im no longer angry, just determined. on this issue you are incapable of making me angry, your not intelligent or knopwledgable enough about the subject
[05:01:18] <mark4> my success or failure is irrelevant. not trying to right a wrong makes every wrong after that YOUR FAULT
[05:01:35] <mark4> allow it to happen to you and you allow it to happen to everone subsequent to you
[05:01:46] <mark4> thats what its about. not money
[05:01:53] <mark4> but 70 million would be nice lol
[05:02:06] <mark4> not that i would get that even if i won entirely
[05:02:32] <mark4> winning and collecting dont always go hand in hand.
[05:03:17] <vsync_> um
[05:03:25] <vsync_> you don't even claim for 50 mills
[05:03:38] <vsync_> you claim for 1.5
[05:03:43] <mark4> ?
[05:03:57] <vsync_> 50, i mean 70
[05:03:59] <mark4> i claim for 50,000 a day for 4 years. do the math
[05:04:07] <vsync_> hahah, oh jesus
[05:04:09] <vsync_> sure
[05:04:22] <mark4> is called constructive imprisonment
[05:04:41] <vsync_> well, i guess the strategy here is to throw out a ludacris claim and still collect, and i think i'm right
[05:04:47] <vsync_> but hey, it's not about the money, right? :D
[05:04:55] <vsync_> really, just get the fuck out of here
[08:08:10] <LeoNerd> Mmm... much cheekiness on my latest board.
[08:08:41] <LeoNerd> On the front, an ATtiny84 in SOIC8. On the back, a 50mil pitch 2x3 pogopad for ISP programming it. Hooked up to the tiny pins using vias under the chip. Zero extra board space :)
[08:09:08] <LeoNerd> Well, almost zero. One of the vias is just outside. but only just
[08:10:55] <Lambda_Aurigae> soic means it has pins....you need one of those no-lead packs.
[08:12:59] <Lambda_Aurigae> MLF package....4x4mm.
[08:13:13] <Lambda_Aurigae> the leads are just pads on the underside that wrap around the edge a little.
[08:13:39] <LeoNerd> SOICs don't have throughhole pins
[08:13:44] <Lambda_Aurigae> I know.
[08:13:54] <Lambda_Aurigae> but there is a smaller package out there for you.
[08:13:58] <Lambda_Aurigae> make it SMALLER!
[08:14:18] <LeoNerd> I don't think I could solder an MLF anyway
[08:14:26] <Lambda_Aurigae> heat it with a hot air gun.
[08:15:12] <Lambda_Aurigae> or toaster oven reflow.
[08:15:49] <LeoNerd> Eh.. I might look into that *one* day but rightnow I need to know this will work in ~23 days time
[08:15:55] <Lambda_Aurigae> oh.
[08:17:05] <Lambda_Aurigae> I've seen people use pogo pins right on top of SOIC chips too and not have a separate programming pad interface..they just have the pins spaced on a programming header board so they match up with the leads on the soic chip itself.
[08:17:45] <Lambda_Aurigae> bit more difficult to make a the programmer hardware and it doesn't work for all chips, but for custom programmer for custom boards it works.
[08:18:04] <Lambda_Aurigae> so, got any pics of your board?
[08:18:16] <LeoNerd> Sure; one mo
[08:18:22] <Lambda_Aurigae> what is this one anyhow?
[08:18:42] <LeoNerd> ATtiny84, nRF24L01+, some connectors, that's about it
[08:19:38] <LeoNerd> http://home.leonerd.org.uk/local/screenie/attiny-nrf-v0.2.png
[08:19:50] <Lambda_Aurigae> I need to get some of those new wifi chip boards to play with.
[08:20:11] <LeoNerd> ESP8266s ?
[08:20:15] <Lambda_Aurigae> yeah.
[08:20:27] <Lambda_Aurigae> full microcontroller with wifi built into one chip.
[08:20:40] <LeoNerd> I might someday. But here I actively don't want wifi - it has to be nicely reliable for stage use
[08:21:45] <Lambda_Aurigae> I suppose the three different SPI interfaces are so you can use this for different things?
[08:22:13] <Lambda_Aurigae> aahh..6pin matches the pogo pads.
[08:22:28] <LeoNerd> 3 SPI interfaces? Oh.. two of those are the AVR ISP6 connectors
[08:22:41] <LeoNerd> In both 100mil TTH pin and 50mil back-copper pogo pad style
[08:23:00] <LeoNerd> The TTH is just in case the pogo does'nt work; I need a backup. Hopefully the pogo will work, and I'll cut a hole in the case for it to peek out of
[08:23:07] <LeoNerd> So I can reprogram it in-field without opening the case :_
[08:23:07] <LeoNerd> :)
[08:23:11] <zerowidth> LeoNerd: oh awesome, that looks great
[08:24:00] <LeoNerd> zerowidth: :) At some point I'll reach a board iteration where I'll be offering them on tindie
[08:24:08] <zerowidth> LeoNerd: i'm thinking about a board that connects to the nrf alonside it (or in a cutout) since i want to put it in a really short (height) box and can't stack two boards
[08:24:14] <LeoNerd> Plus a lump of code to act as a base for the program
[08:24:55] <Lambda_Aurigae> so, your nrf is on a carrier board that connects to this one?
[08:25:14] <LeoNerd> Oh.. yeah.. It's one of those dirt-cheap £1 thingies
[08:25:16] <LeoNerd> One mo
[08:25:27] <zerowidth> Lambda_Aurigae: yeah, nrf boards are super cheap, cheaper than buying the nrf chip itself on mouser or digikey
[08:25:42] <LeoNerd> http://www.amazon.co.uk/Vktech-NRF24L01-Antenna-Wireless-Transceiver/dp/B00J7I0NU8/ref=sr_1_1?ie=UTF8&qid=1426683869&sr=8-1&keywords=nrf24l01 these things
[08:25:45] <LeoNerd> Hah
[08:25:48] <Lambda_Aurigae> I got a bunch of the first gen nrf boards before they got dirt cheap.
[08:25:51] <LeoNerd> Forget mouser/digikey... Amazon have them
[08:26:10] <LeoNerd> 4 for £4
[08:26:16] <zerowidth> yes!
[08:26:18] <Lambda_Aurigae> I got mine from sparkfun some time back.
[08:26:22] <Lambda_Aurigae> way back when.
[08:26:44] <Lambda_Aurigae> got them with the onboard trace antenna, some with the chip antenna, and some with external antenna connection.
[08:27:09] <zerowidth> LeoNerd: oh interesting, you have a diode to isolate one of the nrf pins?
[08:27:35] <LeoNerd> zerowidth: the INT pin, yeah
[08:27:38] <Lambda_Aurigae> ok..so the NRF goes on the 2x5 header...what goes on the 1x7 header?
[08:28:13] <LeoNerd> The nRF's IRQ pin is a full push/pull; that diode turns it into an open-drain effectively, so that the INT pin on the ATtiny can be wire-OR'ed together with other hardware via the INT pin on the header
[08:28:31] <LeoNerd> Lambda_Aurigae: that's just offboard connections. See the silkscreening :)
[08:28:43] <LeoNerd> It'll be hand-wired up to LEDs and buttons in the case.
[08:29:09] <Lambda_Aurigae> same for the 1x7 SPI connection at the bottom?
[08:29:19] <LeoNerd> Yeah. That's not really needed in this particular application
[08:29:27] <LeoNerd> Another application I have though will use it (I'm reusing boards for lots of things)
[08:29:42] <zerowidth> LeoNerd: this is really cool. do you have a box you're putting it in already?
[08:29:44] <LeoNerd> It breaks out the SPI port + PA7; so you can attach another SPI device onto it
[08:29:50] <Lambda_Aurigae> ok....cause, I was thinking, I would turn that into a 1x8 and add the /RST there and just use that as an extra programming header.
[08:30:11] <LeoNerd> Or via super-cheeky hackery of the USI module on the 'tiny, I actually use the MOSI + PA7 as an I2C port for a sensor
[08:30:11] <Lambda_Aurigae> and get rid of the 2x3
[08:30:22] <LeoNerd> Well, ... with any luck I won't need the 2x3 100mil pins
[08:30:29] <Lambda_Aurigae> yeah...
[08:30:39] <LeoNerd> This is v0.2; it's an experimental iteraion
[08:30:56] <Lambda_Aurigae> that's why I was thinking you could do without it completely by adding the reset pin on that bottom header as an option.
[08:31:06] <LeoNerd> But then I'd need a custom adapter
[08:31:11] <Lambda_Aurigae> just trying to think of ways to eliminate things.
[08:31:15] <LeoNerd> Which I know I oculd make, but I do *have* a standard 2x3
[08:31:40] <LeoNerd> Also it would remove the 2x3 from the board, but it wouldn't save me any actual board area, because I can't make the board narrower or shorter
[08:31:46] <LeoNerd> The radio is already so big ;)
[08:32:08] <LeoNerd> zerowidth: notyet. I've ordered a few of different sizes from Amazon. I'm constrained by the battery module though
[08:32:16] <LeoNerd> http://lifepo4wered.com/ <== 76mm long
[08:32:18] <Lambda_Aurigae> you could make that a 2x4 at the bottom, giving you 8 pins there, with the reset being optional.
[08:32:33] <LeoNerd> But then I couldn't fit it on a breadboard
[08:32:34] <Lambda_Aurigae> just thoughts running through my feverish brain here.
[08:32:46] <LeoNerd> The current arrangement is breadboard-friendly if you just stick downward-pointing pin headers in it
[08:32:52] <Lambda_Aurigae> aahh.
[08:34:11] <Lambda_Aurigae> man I hate being sick...but at least I got to stay home from work...have a fever but can't sleep so sitting here in my recliner under a heavy blanket with a hot tea and my computer.
[08:36:08] <aandrew> LeoNerd: old message, but I've used the 24L01+ if you have any questions
[08:36:16] <LeoNerd> zerowidth, Lambda_Aurigae: This board will have LEDs + buttons on and battery powered; as part of a theatrical control cue-lights system. But other plans I have for more of them involve temperature/etc.. sensors at home, and also some control of appliances
[08:36:23] <zerowidth> Lambda_Aurigae: ooh, battery too. you thinking about a built-in charger too?
[08:36:52] <LeoNerd> aandrew: Mostly just about being forced it seems, to FLUSH_TX after a failure (indicated by the MAX_RT flag), and thus lose all the other packets in the outbound queue
[08:37:05] <aandrew> hm
[08:38:02] <Lambda_Aurigae> zerowidth, ummm...no...but LeoNerd might be as it's his toy.
[08:38:43] <martinus> Lambda_Aurigae | or toaster oven reflow >> Just don't use silver solder -_-
[08:39:46] <Lambda_Aurigae> martinus, hehe...yeah. I don't own any of that. some years back I was able to buy several multiple pounds of nice thin resin core lead solder before the whole lead free thing took hold.
[08:40:02] <Lambda_Aurigae> bought 4 rolls of 5 pounds each.
[08:40:07] <Lambda_Aurigae> have not even gone through one roll yet.
[08:41:02] <martinus> The numbe rof friends I've had to lamentably tell I couldn't fix their Playstation 3 I could count on both hands (I don't have reball equipment).
[08:41:25] <LeoNerd> aandrew: that LiFePO4 module already has the full charging controller on it. It's great :)
[08:41:35] <LeoNerd> Er
[08:41:40] <LeoNerd> zerowidth: that LiFePO4 module already has the full charging controller on it. It's great :)
[08:42:16] <aandrew> I don't recall having that issue on nrf24l01 but I also don't remember getting a tx failure
[08:43:16] <LeoNerd> Ah; try moving further away from the receiver then ;)
[08:53:04] <aandrew> LeoNerd: :-)
[08:54:02] <LeoNerd> aandrew: I'm goin to solve it by just never having more than one packet outstanding.. I'll wait for it to finish one beofre I do the next
[09:03:36] <LeoNerd> Right. Zip file packed, sent to OSHpark, paid and done. I should have some shiney new toy^W development boards in a couple of weeks time :)
[09:04:50] <zerowidth> LeoNerd: ohh awesome, so you have an external plug for charging, but it's all separate
[09:04:57] <LeoNerd> Yeah.. they're lovely
[09:05:05] <zerowidth> LeoNerd: i just submitted my first board to oshpark yesterday, really excited
[09:05:18] <LeoNerd> I so far don't know how long my module will run on that battery. I have a minimum bounds though - it's been running since Saturday morning ;)
[09:05:29] <LeoNerd> Currently at 3.36V
[09:05:45] <zerowidth> both the nrf and attiny84 can be pretty low-power, at least that's my impression
[09:06:03] <LeoNerd> Yah. Especially as I'm sleeping most of the time ;)
[09:06:38] <zerowidth> what's the LiFePO4 module you're using?
[09:06:46] <LeoNerd> It's been something of an exercise in reshaping how I write the code though. I'm used to async/Futures in high-level languages with closures, GiB memory, etc...
[09:06:52] <LeoNerd> The ATtiny has 512bytes :)
[09:07:07] <LeoNerd> See link above; it's on the site I mentioned
[09:07:11] <LeoNerd> They only do one
[09:07:14] <zerowidth> ah cool, thanks
[09:07:18] <zerowidth> oh yeah, no kidding. same here. and dropping the arduino toolchain for more memory...
[09:07:37] <LeoNerd> Eh, I've never really liked the Arduino stuff. I just write straight C
[09:07:58] <LeoNerd> That's why my board pins are labeled PA0 PA1 PA2 PA3 PA7, and not silly numbers
[09:08:03] <zerowidth> yep
[09:08:12] <zerowidth> i started with arduino, then rewrote it all for straight avr
[09:08:18] <zerowidth> on this latest project
[12:17:38] <Tekkkz> hello
[12:17:50] <vsync_> hello
[12:17:55] <vsync_> achtung
[12:18:10] <Tekkkz> can anybody give me a tip why my code isnt working (maybe my timer init is wrong, but i rechecked with datasheet two times already
[12:18:11] <Tekkkz> http://ix.io/gXJ
[12:18:18] <Tekkkz> vsync_: rly ..?
[12:18:21] <Lambda_Aurigae> hmm...maybe it's not correctly written?
[12:18:26] <vsync_> lebensraum!
[12:18:38] <Tekkkz> lebensraum?
[12:19:30] <vsync_> deutsches reich
[12:19:45] <Lambda_Aurigae> douchebags are rich?
[12:19:52] <Lambda_Aurigae> oh..reich,,,rule?
[12:19:58] <Lambda_Aurigae> never could get german down.
[12:20:11] <vsync_> goebbels, ja ja
[12:20:23] <Tekkkz> vsync_: before you are hating me, maybe you know what i did wrong?
[12:20:51] <Lambda_Aurigae> Tekkkz, looking it over...gonna find you a tutorial on it.
[12:21:01] <Tekkkz> hm? what?
[12:21:27] <vsync_> wtf is iocomfort
[12:21:39] <Lambda_Aurigae> I am looking over your code and will find you a site or two to look at.
[12:21:41] <Tekkkz> ah
[12:21:56] <Tekkkz> its my macros for simpler port operations
[12:25:07] <Tekkkz> so what is wrong at init?
[12:25:34] <Lambda_Aurigae> http://www.protostack.com/blog/2010/09/timer-interrupts-on-an-atmega168/
[12:25:53] <Lambda_Aurigae> older code, uses older ISR config,
[12:25:58] <Lambda_Aurigae> your timer config looks right.
[12:26:26] <Lambda_Aurigae> except maybe, and I'm not sure on this and would have to dig into datasheet, but, OCR0A needs to be moved down?
[12:26:48] <Tekkkz> moved down??
[12:27:10] <Lambda_Aurigae> order of operations...I could be out of my mind there.
[12:28:53] <Tekkkz> hm ill check this, but now i need to restart pc, see you
[12:29:06] <Lambda_Aurigae> not sure what,,,,,errr...nevermind
[12:29:32] <Lambda_Aurigae> no clue why he is toggling that timer0_oc0b thingie..
[12:29:35] <Lambda_Aurigae> oh well.
[13:04:36] <Tekkkz> hey, im back
[13:04:43] <Tekkkz> i have found the problem maybe
[13:05:04] <Tekkkz> is it possible, that the isr fails at the adafruit CDC bootloader?
https://github.com/adafruit/lufa-lib/tree/master/trunk/Bootloaders/CDC
[13:05:14] <Tekkkz> cause everything without isr works fine
[13:06:04] <N1njaneer> Without looking in-depth, are you sure the ISR table is being relocated correctly when moving in and out of the bootloader?
[13:06:25] <N1njaneer> Easy to overlook, causes weird problems :)
[13:06:52] <Tekkkz> what do you mean?
[13:06:58] <N1njaneer> What processor are you using?
[13:07:20] <Tekkkz> atmega32u4 with
http://www.adafruit.com/product/296
[13:08:31] <Lambda_Aurigae> see, you never mentioned a bootloader.
[13:08:47] <Lambda_Aurigae> does the bootloader redirect the interrupt table when it exits?
[13:08:54] <Tekkkz> i dont know yet
[13:09:06] <Lambda_Aurigae> so look at the code for your bootloader and see.
[13:09:12] <N1njaneer> Tekkkz: Please check out section 9.1.1 in the datasheet to see if this might be what's causing you difficulties.
[13:09:20] <Tekkkz> and if it doesnt do this?
[13:09:30] <N1njaneer> Tekkkz: It explains the ISR relocation select.
[13:10:14] <Tekkkz> The General Interrupt Control Register controls
[13:10:16] <Tekkkz> the placement of the Interrupt Vector tabley
[13:10:19] <N1njaneer> It's also important to do things correctly if you are jumping from application to bootloader space - a jmp 0x0000 can get you in to very subtle controls :)
[13:10:30] <N1njaneer> subtle +problems
[13:10:36] <Tekkkz> yes
[13:10:43] <Tekkkz> i know that their bootloader is shit
[13:10:47] <N1njaneer> Anyhow, some stuff to check.
[13:10:54] <Tekkkz> it also just turns off the wd globally and so on
[13:11:43] <N1njaneer> Bootloaders aren't always a "one size fits all" so useful to have ones you can customize.
[13:12:28] <Tekkkz> im eating
[13:12:43] <Lambda_Aurigae> and it seems this one is particularly nasty...based on lufa and all.
[13:13:16] <N1njaneer> You can always just write your own from scratch instead :)
[13:13:52] <Lambda_Aurigae> and I don't see the source for the bootloader on the site...at least not readily available.
[14:53:50] <Tekkkz> im back
[14:54:01] <Tekkkz> Lambda_Aurigae: i sent a link to their bootloader source
[15:10:16] <Tekkkz> So how can i fix my interrupt vectors?
[15:10:22] <Tekkkz> i dont know how to do this
[15:35:18] <Tekkkz> noone who caan help me?
[15:42:38] <malinus> Tekkkz: the datasheet should have info about setting the interrupt vectors :)
[15:43:00] <Tekkkz> sorry im just 16 and my english is really bad, can you give me a hint?
[15:47:51] <malinus> Not really, never done it before. Look in the datasheet :)
[15:49:32] <Tekkkz> ahh wait
[15:49:35] <Tekkkz> i found sth out
[16:15:56] <dearhawk> AES or Serpent? Do you think NSA has backdoored AES?
[16:16:00] <dearhawk> wrong window
[16:16:44] <Lambda_Aurigae> of course they have.
[16:16:59] <Lambda_Aurigae> Tekkkz, I don't see a link for the bootloader source..
[16:17:26] <Tekkkz> https://github.com/adafruit/lufa-lib/tree/master/trunk/Bootloaders/CDC
[16:17:57] <Tekkkz> but i cant fix it, i dont have the necessary know-how
[16:19:35] <Tekkkz> can anyone of you guys help please? i want to have this board working with a (fucking) ISR (sry for verbal)
[16:21:25] <Lambda_Aurigae> well, it looks like they pull the interrupt vector into the bootloader section manually at line 223 of the bootloaderCDC.c file
[16:21:48] <Lambda_Aurigae> but they never move it back after the bootloader resets...and not sure if a watchdog timer reset does that or not.
[16:21:57] <Lambda_Aurigae> on a normal boot, it should be set to the main section
[16:22:07] <Lambda_Aurigae> unless they have it also set to the bootloader section in the fuses.
[16:22:27] <Tekkkz> so what must i change?
[16:22:40] <Tekkkz> remvove this set o bootloader?
[16:23:03] <Lambda_Aurigae> well, first we have to find out what the fuses are set to.
[16:23:26] <Lambda_Aurigae> for that you will either need a program that reads the fuses and outputs them somehow, either over USB or USART or something.
[16:23:41] <Lambda_Aurigae> or you will need an AVR programmer and avrdude(or atmel studio)
[16:24:37] <Tekkkz> yes wait
[16:24:46] <Tekkkz> if i flash sth on it avrdude says
[16:24:56] <Tekkkz> avrdude: safemode: Fuses OK (E:C3, H:D0, L:FC)
[16:25:00] <Tekkkz> so there are the fuses
[16:25:14] <Lambda_Aurigae> and what is the chip?
[16:25:15] <Tekkkz> but look at their makefile from teh bootloader, there the fuses are set diff
[16:25:20] <Tekkkz> atmega32u4
[16:29:18] <Lambda_Aurigae> only thing that changes is the extended fuse.
[16:29:33] <Lambda_Aurigae> and it doesn't look like FC and F3 make any changes which is strange
[16:29:54] <Flipp__> there are registers that control where the interrupt table is
[16:30:04] <Lambda_Aurigae> yeah..they do change.
[16:30:48] <Tekkkz> okay, up to here i understood
[16:31:21] <Lambda_Aurigae> HWBE is the interrupt table location, yes?
[16:32:11] <Tekkkz> if you say so ;)
[16:32:19] <Lambda_Aurigae> am pulling the datasheet.
[16:32:36] <Lambda_Aurigae> my network is slow due to downloads today and I'm slow due to sinus headache.
[16:32:59] <Tekkkz> oh ok
[16:33:22] <Tekkkz> whats HWBE?
[16:33:32] <Lambda_Aurigae> am looking it up.
[16:33:36] <Lambda_Aurigae> but it's not what I thought it was.
[16:33:48] <Flipp__> no, hwbe is the fuse
[16:33:51] <Lambda_Aurigae> it turns the ALE pin into the /HWB pin
[16:34:09] <Flipp__> the location of the bootloader table is set by setting two bits in a register (at least on an mega2560)
[16:34:13] <Lambda_Aurigae> so when you pull the ALE/HWB pin low on reset it goes to bootloader mode.
[16:34:24] <Flipp__> "The MCU Control Register controls the placement of the Interrupt Vector table,"
[16:34:32] <Lambda_Aurigae> Flipp_, yes...but what about the,,,,there's it.
[16:34:33] <Lambda_Aurigae> hehe
[16:34:33] <Tekkkz> yes
[16:34:53] <Lambda_Aurigae> I think you have to control that register from software...somehow I thought it was a fuse setting...or could be a fuse setting.
[16:35:00] <Flipp__> tekkkz: you're looking for MCUCR bits 0 and 1
[16:35:08] <Flipp__> page 63 of the datasheet
[16:35:12] <Tekkkz> yes
[16:35:26] <Lambda_Aurigae> 307 for this particular chip Flipp_
[16:35:37] <Lambda_Aurigae> or at least, the datasheet I have has it on that page.
[16:35:39] <Flipp__> ? atmega32u4?
[16:35:54] <Lambda_Aurigae> is also on page 67
[16:35:55] <Lambda_Aurigae> yeah.
[16:35:58] <Flipp__> http://www.atmel.com/images/doc7766.pdf
[16:36:03] <Flipp__> that's the one I'm goin' off of O.o
[16:36:06] <Flipp__> ok
[16:36:08] <Flipp__> either way
[16:36:10] <Flipp__> it's MCUCR :)
[16:36:16] <Lambda_Aurigae> yeah.
[16:36:24] <Flipp__> note: you have to set the bits
[16:36:31] <Flipp__> within four (4) CLOCK CYCLES
[16:36:37] <Flipp__> not just instructions
[16:37:31] <Lambda_Aurigae> there it is...BOOTRST fuse bit
[16:37:34] <Tekkkz> IVSEL IVCE? before app_start or where?
[16:37:35] <Lambda_Aurigae> that's what I was looking for.
[16:37:59] <Lambda_Aurigae> but that doesn't do the interrupt table.
[16:38:06] <Flipp__> ah, yeah. BOOTRST tells the chip what memory address to start at
[16:38:26] <Lambda_Aurigae> that's what I couldn't remember...whether there was a way to set the reset vector from fuse...there isn't..
[16:38:27] <Flipp__> and note that BOOTRST is in *words* btw, not bytes... that's gotten me before :)
[16:38:37] <Flipp__> nope :)
[16:38:40] <Lambda_Aurigae> so, generally it should start with the interrupt table in normal section.
[16:38:45] <Lambda_Aurigae> so, my idea is out of the water.
[16:38:46] <Flipp__> unless you set the boot protect somehow
[16:38:56] <Flipp__> (can't remember offhand)
[16:39:49] <Flipp__> tekkz: it's wherever you want it
[16:40:02] <Lambda_Aurigae> so, why the FC vs F3 fuses difference, no clue...it does make a major change between the two though..both in hardware boot enable and brownout detect level.
[16:40:06] <Flipp__> IVSEL/IVCE is what controls where the interrupt table
[16:43:02] <Lambda_Aurigae> Tekkkz, you need to go back to something more basic and make sure that your program is actually running, then move up the ladder to interrupt driven from an external int pin, then try the timer interrupt thing.
[16:43:51] <Tekkkz> i already did this on other boards
[16:43:51] <Tekkkz> its just the bootloader
[16:43:54] <Tekkkz> but i have still no clue how toget it works
[16:44:20] <Lambda_Aurigae> other identical boards?
[16:44:23] <Lambda_Aurigae> same chip?
[16:44:27] <Lambda_Aurigae> with the same bootloader on it?
[16:44:59] <Tekkkz> nopr
[16:45:12] <Lambda_Aurigae> so what is different?
[16:45:53] <Tekkkz> what do you mean?=
[16:46:06] <Lambda_Aurigae> you said nopr...I'm assuming that means nope or no.
[16:46:26] <Lambda_Aurigae> it works on other boards, yes?
[16:46:32] <Tekkkz> yes, it means nope
[16:46:33] <Lambda_Aurigae> so, what is the same and what is different?
[16:47:30] <Tekkkz> it works on atmega328p, same code
[16:49:23] <twnqx> megal0maniac: around?
[16:50:00] <Lambda_Aurigae> Tekkkz, odd and strange...in theory it should work...something odd is causing problems on that board I'm guessing.
[16:50:12] <Tekkkz> whatever, im off today, maybe we can have a look again tomorrow?
[16:51:50] <Tekkkz> so are you onl,ine tomorrow and remember me?
[16:51:54] <Tekkkz> *remmebr what we talked about?
[16:52:00] <Lambda_Aurigae> I'm always online but not always at my computer.
[16:52:13] <Lambda_Aurigae> normally this time of day I'm at work.
[16:52:24] <Lambda_Aurigae> for another hour or so.
[16:53:00] <Lambda_Aurigae> today I stayed home from work with a bad headache.
[16:53:56] <Tekkkz> ok, we weil see, im away, good night
[17:10:35] <Lambda_Aurigae> http://chuckleaduck.com/comic/stylin/
[19:07:53] <Flipp__> is there a trick to using a global function pointer?
[19:08:06] <Flipp__> if I declare void (*funcptr)( void ) = 0x0000; on the stack, followed by ()
[19:08:49] <Flipp__> err, followed by funcptr() it correctly translates to "ldi r30, 0x00; ldi r31, 0x00; eicall"
[19:09:14] <Flipp__> but if I declare void (*funcptr)( void ) = 0x0000; in the global scope
[19:09:30] <Flipp__> it becomes "ldi r30, 0x0200; ldi r31, 0x0201; eicall"
[19:13:37] <Flipp__> which is, possibly coincidentally, exactly 0x800000 away from the start of .data at 0x800200
[22:04:02] <aczid> Flipp__: you have figured out how the stack is mapped in relation to the global SRAM variables ;)
[23:15:51] <Flipp_> aczid: I guess I need one more piece before I fully get it though. I know the stack grows from the end of RAM and global variables are put in .data, but I'm not sure where the 0x0200/ 0x0201 come from
[23:17:44] <Flipp_> and I'm not sure why does the global function call not dereference correctly to a jump to 0x0?
[23:20:20] <Flipp_> I see precedent for other global function pointers dereferencing correctly
[23:20:23] <Flipp_> e.g.
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168.c#L270
[23:20:42] <Flipp_> line 270 shows a global definition for app_start that's called later on line 288
[23:23:55] <Flipp_> aczid: ah, got it, nevermind
[23:24:25] <Flipp_> aczid: just figured out the difference between opcode lds and ldi :)
[23:34:15] <Flipp_> admittedly a bit surprised though that I can't mark it as constant and have avr-gcc just use LDI 0 instead of LDS 0x0200 :/
[23:40:30] <Flipp_> although, wait, it's loading the address 0x0200 when I'm in the bootloader. that doesn't seem right... I'm way above there
