Back
[03:34:41] <redspl> hi
[06:38:34] <Haohmaru> Q: am i right to think that ports A and B on an xmega (which are analog.. ADC/DAC) can be used as digital IN/OUTs?
[06:39:56] <LeoNerd> Yes; prettymuch every PORT pin still has a basic digital IO driver
[06:40:16] <Haohmaru> *phew*
[06:40:47] <LeoNerd> I only know of one chip that has analog-only pins that can't do digital; and that's ADC6/7 on the 32pin variants of the ATmega832p
[06:41:11] <Haohmaru> cuz otherwise i'll have to imagine some 12 pins out of nowhere x_x
[06:41:19] <Haohmaru> uh
[06:41:27] <Haohmaru> i haven't even seen such atmega
[06:41:34] <Haohmaru> or did you mean 328?
[06:41:54] <LeoNerd> Er.. yes.
[06:41:59] * LeoNerd blames fingers
[06:42:05] <LeoNerd> I got all the right digits...
[06:51:25] <inflex> Can you read/clone an ATTINY13 even if the lock-bit is set?
[06:53:22] <Lambda_Aurigae> no
[06:53:35] <Lambda_Aurigae> if the lock bit is set then the flash is read protected.
[06:53:45] <Lambda_Aurigae> that's what the lock bit is for.
[06:53:55] <Lambda_Aurigae> to keep people from copying your software off the chip.
[06:55:41] <inflex> Figured as much. I see if they forget to set DWEN then it's still potentially possible.
[07:20:22] <Haohmaru> i thought they can still read it with a programmer
[07:20:39] <Lambda_Aurigae> no
[07:20:49] <Lambda_Aurigae> that's the whole reason for the lock bits.
[07:20:58] <Lambda_Aurigae> you lock it so you can NOT read it.
[07:21:33] <Haohmaru> hmz
[07:23:14] <Lambda_Aurigae> debugwire might possibly get around it..I haven't studied debugwire as I don't have any debugwire debugging device.
[07:23:57] <Lambda_Aurigae> but by disabling debugwire with the lock bits locked I bet you can't re-enable it without doing a chip erase.
[10:32:19] <Hexum064> good morning
[14:11:08] <redspl> hi
[14:21:09] <Strangework> hey, redspl!
[14:26:26] <Jartza> hiya
[14:26:59] <Strangework> hoyo!
[14:30:14] <m3chanical> good afternoon
[14:37:03] <zezba9000> Hey wondering if its possible to get the max stack memory size that will be created via the avr gcc?
[14:37:09] <zezba9000> Or better via C++
[14:39:10] <tpw_rules> not really. the compiler would have to execute your program as much as possible and hope it triggered max usage conditions
[14:40:13] <zezba9000> What about via the GCC?
[14:40:23] <tpw_rules> no
[14:40:30] <zezba9000> Then I could have CPU targets. Trying to create a bit vector the size of the stack
[14:40:45] <tpw_rules> the stack will grow as big as RAM
[14:40:47] <zezba9000> ok guess I just have to assume the bit vector size
[14:40:54] <tpw_rules> what are you concerned about?
[14:41:04] <zezba9000> For avr platforms only of course?
[14:41:23] <tpw_rules> the worst case is the stack gets too big and starts overwriting the heap. but whether that happens depends on how big the heap is (global variables) and how your program uses the stack
[14:41:26] <zezba9000> I just wanted to create a bit vector as small as possible was all
[14:41:58] <tpw_rules> i'm not sure what you want to do. the stack will get as big as it needs to
[14:42:29] <zezba9000> Its for an experimental GC that could run on low memory devices
[14:42:30] <tpw_rules> if it gets bigger than the available RAM, your program crashes. if it runs into the heap, your program will behave strangely and likely crash
[14:42:41] <zezba9000> I would like to mark whats a GC object via a bit vector on the stack
[14:43:10] <zezba9000> So a bit vector would take up almost nothing even if it mapped all 2kb of ram
[14:43:10] <tpw_rules> doesn't that mean you'd have to make a bit vector that's the size of the stack / 8?
[14:43:14] <tpw_rules> that's a lot of memory
[14:43:27] <zezba9000> no it would be 2048 / 8 = 256 byte
[14:43:34] <tpw_rules> that's a lot of memory
[14:43:38] <zezba9000> each bit, not byte
[14:44:02] <tpw_rules> to be honest, i'm not sure of the application of this. most of my programming is done in C and some projects are entirely asm because of speed
[14:44:06] <zezba9000> ya its not a replacment for C++ and what people might need there.
[14:44:19] <tpw_rules> i don't use c++ at all because of the amount of memory it uses
[14:45:26] <zezba9000> I'm making a C# to C++ transpiler. Now please don't get on my case for that, its a hobby project and its not meant to replace c++
[14:45:48] <zezba9000> Its so I can write simple hobby games for Arduino based handhelds
[14:46:10] <tpw_rules> what if it was a VM?
[14:46:14] <tpw_rules> it would be slower
[14:46:17] <zezba9000> Even if it eats a little more ram and requires a less complex app isn't really the point
[14:46:27] <tpw_rules> https://github.com/xen2/SharpLang and
https://github.com/avr-llvm/llvm maybe?
[14:46:36] <tpw_rules> use LLVM to compile c# for avr
[14:46:51] <zezba9000> No that wouldn't work, there GC will never run in 2kb ram
[14:47:02] <zezba9000> Even Java can run in 1kb but its interpreted
[14:47:13] <zezba9000> mine would run almost as fast as C++
[14:48:03] <tpw_rules> well the end answer is you can't be certain of the amount of stack a program uses before you run it
[14:48:03] <zezba9000> tpw_rules: I'm also not trying to create a whole new .NET runtime just a simple C# subset using the new open source syntax tools from MS
[14:48:26] <zezba9000> ok I was kinda thinking that
[14:48:28] <tpw_rules> how does that work?
[14:48:33] <tpw_rules> does it simply tokenize it for you?
[14:48:59] <tpw_rules> or does it give you bytecodes?
[14:49:06] <zezba9000> Well in C# GC roots can be static objects or stack references
[14:49:09] <tpw_rules> what if you had your own alloc and free functions and didn't use a garbage collector?
[14:49:17] <zezba9000> o ic, no its called Roslyn
[14:49:23] <zezba9000> Its the C# compiler
[14:49:32] <zezba9000> I can use it to analize the C# tree
[14:50:21] <zezba9000> tpw_rules: Well then I might as well just use C++
[14:50:37] <tpw_rules> exactly
[14:50:38] <zezba9000> But this was more to get something working because I just find it cool
[14:50:44] <tpw_rules> sure
[14:51:11] <zezba9000> Even if its not the best for everyone. There are tons of 32-128kb devices as well that would work just fine with it
[14:52:26] <tpw_rules> https://www.youtube.com/watch?v=UN-JXHHlgcY
[14:52:45] <zezba9000> yes i know I have one :)
[14:52:55] <tpw_rules> oh
[14:53:08] <zezba9000> But I wanted to target 8-bit 16-bit devices or MIPS and SPARC cpus
[14:53:22] <zezba9000> So its more then just for low mem stuff
[14:53:29] <tpw_rules> those are rather different classes of instrument...
[14:53:43] <zezba9000> But I like to test with the basline as it would run even if it did eat a little more ram
[14:53:56] <zezba9000> tpw_rules: Well on those I use a different GC
[14:54:33] <zezba9000> But I wanted to make my own first as i'm learning a lot trying to do so
[14:55:26] <zezba9000> Also keep in mind .NET micro is interpreted, this would run a lot faster so I should probably run the idea by those folks
[14:55:39] <zezba9000> tnx for the answer though
[15:07:31] <Jartza> all three attiny85s are still in sync (the vga) after 11 days. The synchronization only happens once when the thing starts and after that they just rely on the fact that they run with same clock.
[15:20:14] <inkjetunito> Jartza: using builtin oscillators?
[15:22:53] <Jartza> inkjetunito: no way :D
[15:23:14] <Jartza> they wouldn't be accurate enough
[15:23:23] <inkjetunito> just trying to be optimistic :)
[15:23:34] <Jartza> even external oscillators wouldn't stay in sync
[15:23:58] <Jartza> no, they are using The Same Clock, daisy-chained
[15:27:20] <zezba9000> tpw_rules: Hey just wanted to point out there is an API for this on OS based devices via "getrlimit"
[15:27:25] <zezba9000> http://linux.die.net/man/2/setrlimit
[15:27:26] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxZ3BlZTg3OWw3dVE/edit?usp=docslist_api
[15:27:45] <Jartza> I mean this. color-vga with three attiny85s
[15:27:57] <zezba9000> tpw_rules: To get the max stack size
[15:28:02] <Jartza> I was on holiday trip for 11 days and they are still in sync
[15:28:06] <Jartza> veey nice
[15:28:18] <tpw_rules> yeah, that applies on an OS
[15:28:41] <zezba9000> tpw_rules: But for non OS devices I understand it doesn't exists.
[16:18:29] <dmitescu> I have a question regarding defined constants. for example if ADC_CH_START_bp, has the terminating string 'bp', which stands for 'bit position', what does '_gc' stand for?
[16:19:57] <dmitescu> also, the ASF library defines one constant as 0x00 << 5. Isn't this practically 0? I fail to see how this is useful in any way.
[16:51:55] <zezba9000> I have a question about stack memory on avr after looking at this link:
http://playground.arduino.cc/Code/AvailableMemory
[16:52:12] <zezba9000> It says stack memory is creted from top to bottom
[16:52:54] <zezba9000> So if I have a stack pointer and I offset it should I deincrement the pointer instead of incement it like you would of a normal desktop?
[16:53:16] <zezba9000> .. if I wanted to scan the stack from bottom to top
[16:53:49] <zezba9000> This is the line I was reading: The stack pointer starts at the top of RAM and grows downwards. The heap pointer
[16:53:49] <zezba9000> * starts just above the static variables etc. and grows upwards.
[16:57:30] <Hexum064> correct
[17:01:26] <zezba9000> Hexum064: Do you know of any other device types that do this? Is there a API you can check to see what direction the stack is layed out in?
[17:01:52] <Hexum064> Not usually an API that I am aware of.
[17:01:53] <m3chanical> Doesn't the stack for X86 code also "grow" downward? While heap grows upward?
[17:01:57] <Hexum064> Just documentation
[17:02:10] <zezba9000> m3chanical: Ya thats a good questions
[17:02:11] <Hexum064> it at least used to in x86
[17:02:16] <zezba9000> I'll test a C app to see
[17:02:51] <m3chanical> You could probably jam some .exe into Ollydbg (if Windows) and check pretty easily
[17:04:52] <m3chanical> This link:
https://en.wikibooks.org/wiki/X86_Disassembly/The_Stack confirms my thought. "The stack 'grows' downward, from high to low memory addresses"
[17:05:11] <Hexum064> You could probably get the max ram and see if the stack pointer is really close to that address when the program first starts
[17:05:48] <zezba9000> Ok Ubuntu the stack goes low to high
[17:05:53] <zezba9000> did a test in C
[17:08:55] <zezba9000> Aww dur I know how to get the stack order at runtime. Just do what I did in my test C app lol
[17:09:42] <zezba9000> So in void main you get the stack pointers of two vars x & y and compare there offset to check for stack order
[17:10:07] <zezba9000> easy peasy
[17:18:16] <Hexum064> what are you doing that you need to manipulate the stack pointer?
[17:52:00] <zezba9000> Hexum064: Its for a GC
[17:52:11] <zezba9000> So for scanning the stack
[17:54:09] <zezba9000> So each time a stack var is created it will mark a bit-vector (1 bit per mark) in the relitive position of its pointer.
[17:55:12] <zezba9000> Then I can scan the bit-vector for GC object types offset from there into stack memory and actually mark something as alive if its on the stack as all stack GC objects are counted as roots
[17:55:57] <zezba9000> And when the method ends they de-mark the bit-vector as they are no longer valid root pointers.