Back
[02:32:59] <eszett> I have a question, how do i properly decouple VREGIN and VOUT33 pins? on each of them one bulk cap (2.2µF), and one high freq cap (0.1µF), is that correct?
[02:34:49] <Casper> the most important one is the 0.1
[02:34:53] <Casper> close to the pin
[02:35:40] <eszett> ye
[02:37:45] <eszett> and what about the larger 2.2 ones? do i need them close to the USB VBUS (which goes to VREGIN), or close to the VREGIN pin?
[02:49:40] <Casper> does it even need the 2.2?
[03:13:32] <eszett> ye that is the question
[03:13:59] <eszett> the application notes are rare and hard to find
[03:14:17] <eszett> at least that ones that are helpful in that matter..
[03:14:43] <eszett> I try to learn and copy from other guys' schematics that use the same MCU
[03:15:26] <eszett> but the problem with schematics is, that they dont' tell to which pin the decoupling caps belong to. schematics dont show that.
[05:14:48] <skz81> <twnqx> given that it seems impossible to get sub-MB c++ binaries on x86 i'd say they don't exist, though >> you mean, with MSVC ?
[05:15:40] <skz81> Leviator >> basically, no problem with C++ support BUT exceptions
[05:16:36] <skz81> it is because exception need to walk through the call stack, which is called "unwinding", and THAT is not supported on AVR
[05:16:45] <skz81> AVR8 at least, dunno for AVR32
[05:19:26] <skz81> Levitator, I just read your fake-exception solution, you seem to be axare of the topic :)
[05:19:35] <skz81> aware*
[05:22:12] <Levitator> Eh?
[05:22:36] <Levitator> Anyway, I decided it was probably too complicated, at least for what I'm doing. I mostly just need to make sure my allocations are not null.
[05:23:39] <Levitator> On a different subject, how do you get gdb-avr to work? Will it not work if your AVR program uses the UART?
[05:38:38] <Levitator> Woot. 1804 bytes of RAM free under a minimal program using malloc, getchar, and printf.
[05:39:19] <Levitator> On an Arduino Nano, anyway
[05:43:06] <skz81> Levitator, you mean for on-chip debug ? As far as I know, you have to use the debugWire protocol (over /RST pin)
[05:43:41] <skz81> the cheapest device I know able to do that is the AVR Dragon
[05:43:57] <skz81> http://www.atmel.com/webdoc/avrdragon/avrdragon.dw_description.html
[05:44:48] <skz81> you can also use a simulator as the backend (I used SimulAVR, I read simAVR is also able to work as a gdb be)
[05:45:07] <Levitator> Interesting. Thanks.
[05:45:37] <Levitator> Also, I am getting __gxx_personality_sj0 when I compile my debug build. I wonder if it's because I'm using malloc.
[05:46:56] <Levitator> Ah, was missing -g at the linker.
[05:48:28] <antto> isn't -g for debug symbols?
[05:49:16] <Levitator> Yeah. I forgot you need it at link as well as compile.
[05:49:40] <Levitator> Well, now I have a debug build, but I guess I need more hardware to use it.
[05:52:20] <Lambda_Aurigae> Levitator, to use gdb you need a debugger....either something that does debugwire for those chips that support it or something that does jtag for the chips that support that.
[05:53:00] <Lambda_Aurigae> if you are using windows then you can use atmel studio simulator to debug.
[05:53:12] <Lambda_Aurigae> or, you can run simulavr and gdb on linux.
[05:54:42] <Levitator> Thanks. Simulator could come in handy.
[05:55:51] <Levitator> debugWire is funky single-wire bidirectional interface. I wonder if you could program a second AVR as a debugger.
[05:56:20] <Lambda_Aurigae> debugwire has not been completely reverse engineered as far as I know.
[05:56:56] <Lambda_Aurigae> there has been some work on it but not a whole lot.
[05:57:10] <Levitator> Yeah, but I wonder if you could just convert to serial and bridge that to USB, or maybe there is more to that.
[05:57:21] <Lambda_Aurigae> back when I used windows I played with avr studio and the simulator..found it annoying.
[05:57:32] <Lambda_Aurigae> it's more than just a serial connection.
[05:57:48] <Levitator> Lame.
[05:58:24] <Lambda_Aurigae> I've been doing avr, pic, and 8052 development as a hobby for 15ish years and never needed a debugger.
[05:58:48] <Lambda_Aurigae> but, I come from a time when we found other ways to debug code,,,like feed data out the serial port or use i/o pins and LEDs to display status.
[05:58:52] <Levitator> Heh.
[05:59:41] <Levitator> You could write a debugger that runs inside the AVR and knows how to talk to GDB.
[05:59:44] <Levitator> That would be an adventure.
[06:00:35] <Levitator> Oh, wait, that probably wouldn't work with the Harvard architecture.
[06:00:46] <Levitator> You can't execute data, and you can't trivially modify code.
[06:01:43] <Levitator> Unless there was some way to execute an interrupt on each clock pulse, or instruction, which there might be.
[06:07:43] <Levitator> I made a Vector class which implements copy-on-write.
[06:08:22] <Levitator> And it is a base class for my String class, so you can mix dynamic and const strings in IO queues without performing copies and allocations for the constant ones.
[06:08:25] <twnqx> skz81: i have no idea about anything microsoft related, except how to play steam games
[06:08:30] <Lambda_Aurigae> use jtag.
[06:11:21] <Levitator> Hrm. "JTAG" doesn't even appear once in the 328p documentation:
http://www.atmel.com/Images/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_datasheet.pdf
[06:11:32] <Lambda_Aurigae> might not be on the new chips.
[06:11:39] <Levitator> Extra lame.
[06:12:41] <Lambda_Aurigae> the atmega1284p has jtag.
[06:12:53] <Lambda_Aurigae> that's pretty much the only AVR I use these days.
[06:14:01] <Levitator> The AVRs are neat products, and I guess the $50 debug addon isn't terrible.
[06:14:14] <Levitator> For that Dragon thing, apparently.
[06:14:18] <skz81> http://www.atmel.com/webdoc/avrdragon/avrdragon.jtag_description.html
[06:15:07] <skz81> unsure if the DS doen't mention it or of it is actually NOT supported...
[06:15:27] <Lambda_Aurigae> atmega328p does not have jtag but does have dw.
[06:15:36] <skz81> ok
[06:15:39] <Lambda_Aurigae> atmega1284p has jtag but no dw
[06:18:32] <cehteh> debugging on avr is not much fun anyway
[06:18:53] <Lambda_Aurigae> just write code without bugs.
[06:19:37] <skz81> ha, THAT's the trick ! Thanks.
[06:20:09] <Lambda_Aurigae> or use old fashioned methods.
[06:20:35] <Lambda_Aurigae> code review, or send status messages out of the serial port or out i/o pins.
[06:21:10] <cehteh> yes
[06:21:21] <cehteh> just blink led is often enough
[06:21:43] <Lambda_Aurigae> yup.
[06:22:00] <Lambda_Aurigae> or 4 or 8 to give you a but more information.
[06:22:56] <Lambda_Aurigae> s/but/bit
[06:23:36] <cehteh> on most avrs the buildin debugging functions (DW) flash breakpoints and restore the original instruction later iirc
[06:24:03] <cehteh> there are no debug/breakpoint registers in the mpu
[06:56:24] <Emil> I hold the opinion that you have to do some really huge convoluted project or some really god damn time critical work if you need real debugging on avr ;)
[06:57:03] <Lambda_Aurigae> agreed.
[06:57:16] <Lambda_Aurigae> anything under 5K lines of code,,,just deal with it.
[06:57:31] <cehteh> avrs are just to small to have huge projects
[06:57:33] <Lambda_Aurigae> and even with the time critical stuff,,,
[06:57:41] <Lambda_Aurigae> just look at the octapentaveega..
[06:58:03] <Emil> Lambda_Aurigae: yeah, timecritical is the land of scopes. Once you debug you lose time critical execution
[06:58:05] <Lambda_Aurigae> attiny85 generating VGA signal and bitbanging 9600bps usart at the same time.
[06:58:49] <Lambda_Aurigae> I don't recall Jartza saying anything about debugwire while developing that.
[06:59:01] <Emil> Probably because he didn't use it
[06:59:09] <Lambda_Aurigae> prezaktly.
[08:45:47] <daey> i dont get the big advantage of debug interfaces. what is the advantage over usart debugging_
[08:46:55] <daey> only platform where i actively used the debug interface was android. and then i used it like im using usart debugging 'pipe strings to the debug interface to see whats going on'
[08:58:49] <skz81> daey, can be useful for instance for memory corruption, but can probably be studied in a simulator, too.
[08:58:49] <skz81> Memory corruption is often why I attach a "living" process with gdb (not on AVR)
[08:59:14] <skz81> deadlocked process to, but we donit have threads...
[08:59:19] <skz81> too*
[09:01:37] <skz81> Also, at a point, the extra code and data (text messages) can saturate your flash, if you're already short.... Were you only add few bytes for BREAKs using external debugger.
[09:32:14] <Casper> daey: the debugger can look at the memory, not just variable but the full memory. So you know exactly what's going on... Remember, AVR have a very small memory and no safeguard against stack overflow... Chance is that your program variable (bottom to top) clashes with the stack (top to bottom). With the debuger you can see what's going on exactly instead of guessing. Also, it do not change your code, so it do not change how it react, won't slow
[09:32:15] <Casper> down (unless you debug), don't take ram, and so on...
[09:33:11] <daey> Casper: cant i simply usart the stackpointer values?
[09:33:40] <Casper> I had issue with my debugging once due to that... I was more tight in memory than I tought, the about 50 bytes of ram for the buffer and printf was too much and that caused corruption
[09:34:10] <Casper> you can, probably, but that won't tell you the full story
[09:34:33] <Casper> but most likelly it work
[09:34:35] <daey> yes. i see that at some point a debug interface is nice to have
[09:34:58] <Casper> personally, never used them, I don't really see the point...
[09:35:07] <skz81> daey, Casper if use heap/malloc, memory will be fragmented, so unsure if SP will be useful ?
[09:35:34] <Casper> however, there is some time where DW would have been very usefull...
[09:35:50] <Casper> ... like on that tiny... 8 pins total, including power
[09:36:05] <Casper> malloc should be avoided on avr, too costly
[09:36:21] <FL4SHK> Might be okay if you do it like during initialization
[09:36:32] <FL4SHK> not in real time though
[09:39:19] <FL4SHK> It really depends on what you're doing
[09:39:53] <FL4SHK> but, in all honesty, on an AVR, what do you need malloc for?
[09:39:59] <daey> skz81: how do you do it?
[09:40:21] <daey> int *ptr = rand(); ? :D
[09:40:27] <Casper> on that avr... I have zero pin left to debug... 3x PWM output + 1x serial input + 1x input + reset + power...
[09:40:47] * Casper wonders how costly rand() is on the avr...
[09:41:06] <FL4SHK> it depends on what you're doing
[09:41:16] <FL4SHK> I wouldn't say to avoid it outright
[09:41:27] <FL4SHK> but... what would you do to seed it?
[09:41:38] <FL4SHK> I suppose you could use an RTC chip or something
[09:41:45] <FL4SHK> I usually seed PRNGs with time
[09:42:27] <skz81> daey, with a custom alloc, yes, you can master allocated space, check stack size at this moment, etc. with standard avr-libc malloc(), i just dunno what is the actual implementation
[09:43:13] <daey> idk i never had speed issues with avrs. they were either way to fast or way to slow
[09:43:28] <daey> but i never encountered a borderline situation
[10:09:02] <anonnumberanon> Using UART does not rely on timer 0 1 2 on atmega328, right?
[10:12:30] <LeoNerd> The USART units have their own baud-rate divisor, yes. They're independent from the timer units
[10:19:02] <anonnumberanon> Thanks LeoNerd Hofdstader.
[10:27:51] <anonnumberanon> Just asking cause I'll be testing some timing with nops instruction so if that gets interrupted it would deny all goals of the test.
[12:48:38] <Levitator> Hrm. I wish there were an explicit facility for atomic operations, beyond just disabling interrupts.
[12:49:26] <Levitator> Otherwise, I guess your other options are to thumb through the instruction set reference and see what operations are uninterruptible.
[12:50:33] <Levitator> Are any opcodes non-atomic?
[12:57:40] <Levitator> "Atomic" never occurs in the instruction set reference, and no instance of "interrupt" discusses anything about what happens when an interrupt occurs during an instruction.
[12:58:10] <LeoNerd> I suspect all instructions are atomic in that sense
[12:59:11] <Levitator> I expect that, but assumptions are the path to obscure hair-pulling bugs.
[13:01:31] <skz81> i assume simulators use this assumption too :)
[13:02:25] <LeoNerd> Mmm.. meta-assumptions
[13:04:18] <Levitator> Ah. There are standard C calls for atomic operations.
[13:04:46] <Levitator> I didn't know that. I live in mostly C++ land. Shouldn't be too wild an assumption that those either work, or should be disabled.
[13:05:08] <Levitator> I mean, they tell you up front that exceptions are unsupported, at least.
[13:13:48] <Levitator> Hrm. Just had a thought for a lock system that queues interrupts in case of contention and then calls them when the lock is released.
[13:14:57] <Levitator> A) Main program locks B) ISR fails to lock on contention. Queues itself. Returns. C) Main program unlocks and flushes queue D) ISR gets called again without contention
[13:15:31] <sebboh> Levitator: (re: how many times do I want to hit enter...) Once. I figure there's some way for the thing to hit its own CLK each time some operation is done, until there are no more operations. This can be done in the case of an adder (well, the textbook one).
[13:16:05] <Levitator> You said you wanted "ENTER" to be your clock. That doesn't make a lot of sense.
[13:16:06] <sebboh> But I really have only an allegorical understanding of how digital circuits work!
[13:19:05] <sebboh> Levitator: sorry. I don't know the words for what I'm thinking. But you know I thought of an example, maybe there is already a name for this kind of machine... A cheap calculator from the early 90s.. Like the kind powered by a button cell or solar panel. The circuit in those things doesn't change state at all unless you push a key, right? There's no oscillator that's running all the time? Whatever you call that kind of machine,
[13:19:05] <sebboh> I'd like to have a modern PC built on the same principle.
[13:19:12] <Levitator> But even better than that, would be a lockless queue, and then it's way simpler.
[13:20:02] <Levitator> Moder computers already have low power modes.
[13:20:33] <Levitator> You will find that the stumbling block in that design is software design, and not hardware.
[13:21:29] <sebboh> great, I'm not a hardware guy. ;)
[13:22:37] <Levitator> Even if you have a piece of software that does a lot of blocking operations which you could conceivable sleep the CPU on, modern operating systems are multi-tasking, so they can't fall asleep just because the foreground process is taking a nap.
[13:26:52] <Levitator> So, you would have to turn the entire OS design inside out, and probably the interface inside out, and for little gain.
[13:28:26] <PoppaVic> OK, Yet-Another-Silly-Question.. Running in app; call to spm/ret up in BLS; once complete, do I return (as expected) to appspace and execution, or did I screw up and need to enable RWW before I return?
[13:30:43] * PoppaVic sighs
[13:33:26] <LeoNerd> Ah, afternoon PoppaVic :)
[13:33:33] <PoppaVic> hi LeoNerd
[13:33:57] <sebboh> Levitator: thanks for the encouragement! And yes, it would be from scratch. The first app would be a calculator... Followed by an email client. A separate unit would be needed to talk to a network, another one for handling a display... etc.
[13:34:10] <PoppaVic> I modded optiboot to add a simple SPM\nRET\n, but I keep hanging.. Makes me think I missed something, leo.
[13:36:46] <LeoNerd> Ah.. I'm not too familiar with SPM myself
[13:37:15] <Levitator> It really doesn't make much sense to do. What are you trying to accomplish? Power savings?
[13:37:31] <PoppaVic> me?
[13:37:31] <Levitator> Just configure the OS to go to sleep after a delay. Whoopdie do.
[13:37:34] <PoppaVic> oh.
[13:37:35] <Levitator> No, not you.
[13:38:28] <PoppaVic> LeoNerd: Yeah. Trying to create a tether/umbilical to the Uno. I knew the SPM part was gonna' be the whore.
[13:38:39] <Levitator> Systems already have sleep support, and they can wake on interrupts. So what is the difference between that and what you are proposing?
[14:04:36] <sebboh> Levitator: it's not my fault that you took what I described and turned it into an OS with sleep support. ..That's really not related.
[14:06:02] <sebboh> it's really about making a "computer" that is as predictable and reliable and consistent as a hammer or a hand-crank can opener is. That's why I'm interested in microcontrollers, not the latest multi-core intel/amd chip.
[14:06:40] <PoppaVic> heh.. want my can-opener? the only predictable is un. ;-)
[14:06:44] <sebboh> it's really about making a computer in which the mental model that the user forms to understand how to use it just happens to be actually what happens.
[14:06:53] <Levitator> That's what RTOS and micrcontrollers are for.
[14:07:09] <Levitator> However, they are intended for performing operations that actually benefit from that. A calculator does not.
[14:07:11] <PoppaVic> from what I've seen, even RTOS is hueg
[14:07:16] <sebboh> PoppaVic: ah, yes, a poor implementation. ;)
[14:07:16] <PoppaVic> huge
[14:07:55] <Levitator> You do not need millisecond, much less microsecond timing to satisfy human demands on a calculator.
[14:08:06] <PoppaVic> sebboh: actually, I think the poor thing is just worn-out.. BUT, it's amusing that that stupid-little-key I was issued in the service always worked.
[14:08:48] <sebboh> Levitator: it's not my fault you are making presumptions about what I'm asking for instead of thinking about the answer to the original question: has anybody heard of a computer that doesn't run on a loop but rather starts and stops on demand.
[14:09:26] <Levitator> Most modern computers can do that.
[14:09:29] <Levitator> I already told you that.
[14:09:35] <PoppaVic> sebboh: yes, I turn the power on/off on the calculator ;-)
[14:10:01] <Levitator> It's the software that isn't designed that way because it's not sensible for anything other than a very specialized usage, which I have yet to comprehend from your description, which makes no sense.
[14:10:02] <sebboh> PoppaVic: yeah, the kind that looks like some -- OH FFS Levitator leave me alone. You are asking questions or offering information you're just telling me I'm wrong but you don't know what I'm talking about.
[14:10:26] <sebboh> you are = you are not, whoops.
[14:10:48] <Levitator> You have a stupid idea and you don't want people to question it. Got it.
[14:11:08] * PoppaVic returns to his spm-issue.
[14:14:34] <anonnumberanon> sebboh what is sleep mode
[14:14:47] <sebboh> Levitator: here are some sample questions: if only the enter key makes the machine do anything, how will it respond to a ping? Answer, it won't. If only the enter key makes the computer do anything, how will it ever display an animation that loops forever? Answer, it won't be capable of doing that, unless you tell it to "loop until I hit interrupt". Why would you want such a thing? Because those strict limitations, constraints,
[14:14:47] <sebboh> make it easy to reason about the machine.
[14:15:28] <sebboh> anonnumberanon: the machine I envision has no sleep mode (why would it?)
[14:15:55] <Levitator> Turning off the clock IS sleeping.
[14:16:17] <Levitator> And you don't need to turn off the clock to get deterministic behavior anyway.
[14:16:21] <anonnumberanon> the clock is not turned off
[14:16:45] <PoppaVic> And, still wondering about SPM - any takers?
[14:16:54] <anonnumberanon> since timer work with the clock and there are timer interrupts to wake from sleep mode
[14:17:15] <anonnumberanon> wats SPM?
[14:17:17] <Levitator> Well, at any rate the processor is not listening to the clock, so what the hell is the difference?
[14:17:18] <sebboh> ok, what are the requirements for deterministic behavior? (O
[14:17:47] <Levitator> The one which is relevant to this conversation is the lack of race conditions.
[14:17:49] <sebboh> s/(O//
[14:18:17] <Levitator> Which you are already accomplishing using a single-tasking machine, which is how AVRs are often configured.
[14:18:49] <Levitator> The code runs in straight line, except for interrupts, which you can disable.
[14:20:02] <sebboh> That sounds great.
[14:20:44] <sebboh> Probably much simpler than eliminating the oscillator. It would just have long strings of NOPs inbetween operations given by the user.
[14:21:05] <sebboh> That's how the c64 worked, for example.
[14:21:26] <sebboh> Well, that had interrupts but the user could guess when they'd occur... there was a short list.
[14:22:08] <Levitator> How else are you going to know when the user does something?
[14:22:44] <Levitator> On an AVR, I know of two options; poll an IO register in a loop, or service an interrupt.
[14:23:18] <PoppaVic> s/the user/the outside-world/
[14:24:19] <PoppaVic> polling only works "well" when yer dealing in synchronized IO
[14:24:35] <Levitator> Polling is the lame way to do it unless you have absolutely nothing better to do than spin.
[14:24:58] <PoppaVic> I disagree
[14:25:22] <PoppaVic> as soon as you said "lame way" - I lost interest
[14:25:33] <Levitator> I don't know why you would think that halting the clock would be a sensible way to increase determinism or responsiveness. The machine has to wake on some sort of external signal, so how is that different from an interrupt?
[14:25:34] <anonnumberanon> i love polling
[14:26:07] <anonnumberanon> but my way to do it requires good aynchronous timing
[14:26:15] <Levitator> If you have something else to do, then you are needlessly burning cycles which you could have spent on something productive. So that is lame by any sensible standard.
[14:26:18] <anonnumberanon> synchronous
[14:26:59] <anonnumberanon> give an example..
[14:27:43] <Levitator> Uh, like say you have some time-sensitive phase-based triggering you need to do, but you have network IO to do at the same time.
[14:28:07] <Levitator> Do you really want to spin on a long-running non-time critical operation while doing something that is?
[14:29:09] <anonnumberanon> the critical stuff takes priority by interrupting. are u talking about if you were polling but with interrupts off?
[14:29:42] <Levitator> That could work if you only have two things to do.
[14:30:37] <Levitator> If you have multiple time-critical things, then you want to avoid polling for all of those. You can put slow, sequential junk in a poll loop if you really want to.
[14:31:27] <Levitator> But once you put stuff in a poll loop, you've now designed it in a way that is difficult to alter if your priorities change when you add more parallel tasks. So, also lame.
[14:31:30] <anonnumberanon> then allocate a finite amount of time to each of these time critical things
[14:31:53] <anonnumberanon> don't run them at the same time
[14:33:52] <PoppaVic> there is no goddamned "same time" - I wish people would stop that.
[14:34:12] <Levitator> It's clear from context what "same time" means here.
[14:34:28] <Levitator> The point here is that it's not always obvious upfront how you're going to use code.
[14:36:03] <Levitator> I like code reuse, although that is not as easy in a real-time setting.
[14:36:11] <Levitator> *like to reuse code
[14:37:44] <anonnumberanon> by same time i meant you have aeveral interrupts that can trigger, and then end up with a queue of interrupt service routines waiting to be serviced sequentially
[14:38:58] <PoppaVic> I love the concept of queued-ints, but there is an issue with some needed some extra-op to clear.
[14:40:57] <anonnumberanon> what is that toad-croaking term you are using? extra-op
[14:43:15] <Levitator> I was just musing about stuffing interrupts in a queue.
[14:43:38] <Levitator> You could put the garbage collection on the slow-side of the queue.
[14:43:59] <PoppaVic> oh, gc.. hehahahahaha
[14:44:12] <anonnumberanon> As an anecdote I've sadly come to the realization that an ISR takes a long time to open, service and close; certainly longer than I would have wished it to last while trying to make everything fit within less than a microsecond.
[14:44:52] <Levitator> Manual says that on a 328p, it takes 4 cycles to enter an ISR. That's not much.
[14:45:45] <anonnumberanon> That's entering. At 62.5 ns yes its good but I only have 16 cycles to fit in a us.
[14:46:09] <Levitator> What are you doing that's that time-critical?
[14:48:01] <anonnumberanon> Sending 15 pwm on regular pins. Resolution should be smallest possible. So creating a virtual clock and polling it until it says the pwm should go low.
[14:48:28] <anonnumberanon> Virtual clock is made by using timers.
[14:49:02] <DKordic> ``polling''!?
[14:50:08] <anonnumberanon> well in this case asking over and over "is this the right time to end this pwm?"
[14:51:48] <Levitator> Yeah, that's sensible if that's what your entire application is dedicated to.
[14:54:13] <Levitator> Oh, just had an idea to implement mutexes on something like an Arduino.
[14:54:46] <Levitator> Couldn't you use setjmp to jump around from process to another and suspend and resume that at will?
[14:56:20] <Levitator> So, you lock a resource. An ISR runs and finds conention, so it puts itself in the mutex queue, the main thread releases the mutex, which flushes its queue, which resumes all queued setjumps sequentially.
[14:57:41] * PoppaVic sighs
[15:02:56] <Levitator> Hrm. I don't think that's going to work based on how setjmp works, and I'm not visualizing how it could fit in the stack either.
[15:05:29] <Levitator> You would probably have to have multiple stacks, and there's not a lot of room for that inside 2048 bytes.
[15:09:09] <anonnumberanon> Just try it!
[15:10:46] <Levitator> Nah. Sounds like a suck idea. Say I allocate 1024 for the heap, and I want to support four threads, so that's 256 stack bytes per thread.
[15:10:50] <Levitator> That's asking for trouble.
[15:11:38] <Levitator> You can barely fit the binary for an empty program in 256 bytes.
[15:12:51] <Levitator> 2kB is already claustrophobic enough.
[15:14:21] <Levitator> Ahahah.
[15:15:09] <anonnumberanon> Someone here had an OS for the 328p. Don't remember who it was.
[15:15:30] <Levitator> I must be insane. Ok. The problem here is ok, main thread blocks, ISR stack is layered under that. If you resume the main thread and it allocates stack, then it eats the ISR stack.
[15:16:22] <anonnumberanon> Wait what?
[15:16:28] <Levitator> But maybe you could get around that by saving the ISR stack frame, resuming main, then restoring the ISR frame. But no, that won't work, because then you can only restart the ISR frame if its address space is free, since it's not relocatable.
[15:17:01] <Levitator> And that is possible, but it's not well defined, so it's no good.
[15:18:35] <Levitator> I read somewhere that the 328p does support external memory, though. Hrm. I wonder if it has any memory virtualization features. That would solve this problem.
[15:19:42] <anonnumberanon> ISRs have priorities that are by design but I don't know how that works. You're in an ISR, isr2 fires and then isr3 fires, both of them inside the original first isr. Now if my understanding is correct, the original isr terminates and then one of isr2 or 3 gets serviced right after, but which one? Is it the one that has more priority on the interrupts priority list in the datasheet?
[15:20:28] <Levitator> I believe the priority only determines which interrupt gets priority if they occur simultaneously.
[15:21:15] <Levitator> Assuming the stack grows down with each ISR, then you cannot switch between them once they are started. You have to finish the current one before you can go back to a previous one.
[15:21:21] <sebboh> in this case it's less clear what simultanously means... to me anyway.
[15:21:30] <anonnumberanon> Yes but the physically cannot happen exactly at the same time. Right poppavic?
[15:21:56] <Levitator> It might be possible for them to happen during the same clock cycle.
[15:22:16] <Levitator> But even if it isn't, it's possible for multiple interrupts to happen while the global interrupt enable is off.
[15:22:25] <anonnumberanon> Nick Gammon please be here and start speaking whenever you're ready.
[15:22:36] <Levitator> I believe that that is where interrupt priorities would be applied.
[15:23:15] <Levitator> So, like, you have three or four interrupt flags all on at the same time, and the MCU has to decide which one to service first.
[15:23:49] <Levitator> But I was wanting to switch back and forth among ISRs as if they were threads, and you can't do that if they share a stack. Previous routines will eat the stack of later routines.
[15:24:32] <sebboh> hm, according to a quick internet search, the non-priority interrupts will be ignored. like, the priority system is like the "global off" flag you mentioned, but more fine grain. The implementation is still like "off" though, not "later".
[15:24:41] <anonnumberanon> But what is the use case of that silly thought exercise? :3
[15:24:58] <Levitator> I wanted to implement mutexes.
[15:25:35] <Levitator> The implementation is not "off". Some interrupts have flags, and those with flags are queued for later if they occur while global interrupts are off.
[15:25:50] * PoppaVic sighs
[15:25:51] <anonnumberanon> Ah I forgot about mutexes and semaphores since operating systems class. Mostly cause I never practiced them.
[15:26:06] <sebboh> oh, ok.
[15:26:25] <anonnumberanon> PoppaVic do you have an answer to my question?
[15:43:30] <Emil> You know what is ironic
[15:43:39] <Emil> How I bashed about needing debug
[15:43:41] <Emil> Well fuck that
[15:43:47] <Emil> How the fuck is this behaviour even possible
[15:44:07] <Emil> What was the command to get clean dissassembly again?
[15:48:04] <Levitator> seboh: You will be excited to hear that the 328p manual specifies a "wake-up on pin change" feature.
[15:50:03] <anonnumberanon> Apparently any interrupt will wake it up but don't quote me on that.
[15:50:26] <anonnumberanon> Not just pin change interrupts.
[15:50:30] <Levitator> Is there any way to get an interrupt on a page access?
[15:51:01] <anonnumberanon> lol
[15:51:14] <Levitator> Actually, I want something even more ambitious than that, which is to remap addresses, and I doubt the 328 will do that.
[15:52:47] <cehteh> actually there are no doubts .. it wont work :D
[15:53:11] <Levitator> What about memory segmentation? Is there a segment register anywhere?
[15:53:18] <cehteh> nope
[15:53:25] <cehteh> some avrs can handle external memory
[15:53:38] <Levitator> I thought I read somewhere that this one will.
[15:53:45] <cehteh> and you can do some purely software paging
[15:54:00] <Levitator> Which one would think might leave a hook open allowing you to segment the memory space somehow.
[15:54:23] <theBear> paging dr software .. dr software to emergency theatre 3 .. stat !
[15:54:31] <cehteh> bootloaders do some address and interrupt mapping .. but its very limited
[15:54:43] <Levitator> So, you mean like memcpying pages one byte at a time.
[15:54:47] <carabia> what theBear said.
[15:55:09] <cehteh> paging on access should be pretty hard to impossible
[15:55:45] <theBear> doctor ! his gate is saturating ! he's gonna lock into an arrest any minute now !
[15:55:50] <cehteh> and only ram .. havard greets you, paging program would mean reflashing which wears out the flash
[15:56:04] <theBear> and that wouldn't be so flash
[15:56:06] <Emil> I would really appreciate any help with this
[15:56:08] <Emil> https://www.youtube.com/watch?v=ZVuEXsEON8A
[15:56:13] <Levitator> I'm only interested in RAM right now.
[15:56:25] <Emil> And continuation
https://www.youtube.com/watch?v=MbgZgDYpc2I
[15:56:34] <LittleFox94> hi there
[15:56:39] <anonnumberanon> hi
[15:56:49] <cehteh> i was thinking about having some facility to store the state in EEprom on sane shutdown and restore on boot
[15:56:51] <Emil> The title is in Finnish but don't worry, it's me and my rally English
[15:58:17] <Emil> cehteh: doable
[15:58:23] <anonnumberanon> post that youtube link again my irc crashed
[15:58:29] <cehteh> yes
[15:58:36] <cehteh> but not trivial
[15:58:39] <anonnumberanon> (user-induced)
[15:58:41] <Emil> Server's are love <3
[15:58:47] <Emil> https://www.youtube.com/watch?v=ZVuEXsEON8A
[15:58:50] <Emil> And continuation
https://www.youtube.com/watch?v=MbgZgDYpc2I
[15:59:09] <Emil> servers*
[15:59:20] <Emil> cehteh: eh, I think it is pretty easy
[15:59:22] <LittleFox94> can anyone tell which fused to program to get an external 3.6864mhz crystal working with my atmega328p? I've tried
http://www.engbedded.com/fusecalc/ but already bricked 2 chips with wrong settings :(
[15:59:26] <carabia> Emil: source please
[15:59:41] <PoppaVic> so, my app calls SPM/RET in the BLS. Do I need to reenable RWW there, or will I return proper and be able to do that from app-space?
[15:59:43] <Emil> We are talking about register states, right?
[15:59:46] <cehteh> Emil: what about hardware states, i/o registers etc
[16:00:11] <cehteh> just dumping all or some ram to eeprom wont give you a sane state
[16:00:24] <Emil> I don't see a problem there
[16:01:19] <cehteh> its not a problem, but it needs some work to get it running
[16:01:22] <Emil> LittleFox94: which chip?
[16:01:28] <Emil> cehteh: yeah, it's not fast :D
[16:01:40] <LittleFox94> Emil, atmega328p
[16:01:42] <Emil> Two or was it three instructions to push to ram
[16:01:53] <Emil> A single byte
[16:02:15] <Emil> LittleFox94: Also, your devices are not bricked in the least
[16:02:48] <LittleFox94> bricked with the tools I have at hand currently
[16:02:50] <LittleFox94> ^^
[16:03:44] <anonnumberanon> high voltage programmer to unbrick, get one
[16:03:55] <LittleFox94> I know you can give it external clock to get it back to live
[16:04:06] <LittleFox94> yeah, also hvpp
[16:04:12] * anonnumberanon is projecting and needs to get/make one
[16:04:38] <Emil> LittleFox94: -U lfuse:w:0xfc:m -U hfuse:w:0xd8:m -U efuse:w:0xff:m
[16:04:42] <Emil> Those should be fine
[16:04:51] <Emil> but it's still on you to make sure everything works
[16:04:57] <Emil> http://www.engbedded.com/fusecalc/
[16:05:07] <carabia> Emil: i'm pretty sure there's just an error-by-one somewhere and you're overflowing. Difficult to say without source.
[16:05:34] <Emil> carabia: but how the fuck is that possible :D
[16:05:40] <Emil> Eh, the codes's nothing special
[16:05:41] <Emil> lemme paste it
[16:05:44] <carabia> Emil: I'm not sure, gimme source and I'll check.
[16:05:55] <carabia> I really can't be bothered reading the code off the video, heh
[16:06:23] <LittleFox94> Emil, is boot reset vector right when not having a bootloaderß
[16:06:24] <LittleFox94> ?
[16:06:27] <Emil> https://emil.fi/jako/sb.c.txt
[16:06:38] <Emil> LittleFox94: if you don't have a bootloader then you don't need it
[16:06:59] <Emil> carabia: haha, I used to do that with piano notes :D
[16:07:11] <Emil> Learning from youtube was a pain but oh so rewarding :D
[16:07:21] <carabia> Heh, alright lemme see...
[16:07:57] <carabia> so putb is a binary out and putn is decimal?
[16:08:13] <Emil> yeah
[16:08:36] <Emil> Hmm, putd could be a better name
[16:09:26] <Emil> Disregard the volatile bc, I tried using different variables and whatnot after making that video today
[16:09:33] <carabia> does it randomly throw 255 or on certain keys?
[16:10:24] <Emil> On all keys
[16:10:34] <Emil> On every keypress
[16:10:35] <carabia> alright, let's see
[16:10:43] <Emil> I updated it a bit to reflect the video better
[16:10:58] <carabia> same link?
[16:11:02] <Emil> Yeah
[16:11:16] <Emil> Just changed the main
[16:11:18] <Emil> Nothing else
[16:11:35] <Emil> What you are seeing there now works
[16:12:00] <Emil> But should I take away the second space and binary output it starts to push out 0b11111111 255 :D
[16:13:17] <Emil> I even thought about stray capacitance and cmos undefined behaviour
[16:13:25] <Emil> And tried it with pullups but nah, didn't change a thing
[16:14:03] <carabia> hmmm
[16:14:08] <carabia> interesting
[16:15:01] <Emil> I've been trying to troubleshoot this for the past 3 hours and it's getting pretty ridiculous :D
[16:15:18] <Emil> I couldn't believe that it would be a bug in the avr-c compiler
[16:15:50] <Emil> I can not believe that it could be*
[16:16:16] <carabia> have you tried with different optimizations?
[16:16:21] <Emil> Nope
[16:16:28] <carabia> I guess that's worth a shot then
[16:16:28] <Emil> Just with -Os
[16:16:38] <carabia> oh, well in that case...
[16:17:04] <LittleFox94> maybe I wasn't to silly to set the right fuse bits - it seems the crystal is br0ken
[16:17:24] <LittleFox94> is there any way to check it without osciloscope or something?
[16:18:20] <LeoNerd> multimeter with a frequency counter?
[16:18:37] <LittleFox94> I don't have a frequency counter in my multimeter :/
[16:21:06] <Emil> carabia: tried it with -O3
[16:21:10] <Emil> Didn't work
[16:23:12] <carabia> yeah, wouldn't really expect it to magically work with more optimization ;D
[16:23:28] <carabia> this is very intriguing
[16:24:00] <carabia> is this like super black magic, do you actually need the space character also? :D
[16:25:39] <carabia> also, what if you just send out the decimal?
[16:25:42] <Emil> iirc no, lemme do a quick check
[16:26:49] <Emil> Space not needed
[16:27:02] <Emil> Fixes it with or without it
[16:27:26] <carabia> and what if you only send out the decimal
[16:29:00] <Emil> Works :D
[16:29:15] <carabia> Alright
[16:29:56] <carabia> that's good... that's progress
[16:31:41] <Emil> Nah, it just's more black magic
[16:32:19] <carabia> nono
[16:33:02] <Emil> How the heck can the combination of these functions cause this
[16:51:36] <Emil> Well
[16:51:50] <Emil> Adding a 1ms delay at the end of the main and it now seems to work
[16:51:54] <Emil> fuckme
[16:52:18] <Emil> Perhaps I should just do it async
[16:53:37] <hetii> Hello :)
[16:54:01] <hetii> Q: I use such simple code for attiny45
http://paste.ubuntu.com/23217655/
[16:54:23] <hetii> but when I plug led it blinks in random period of time
[16:54:28] <hetii> any clue why ?
[16:57:44] <Emil> Well, at least I figured out my bit mapping was the wrong way
[16:57:52] <Emil> MSB-LSB switched
[16:58:38] <Emil> hetii: are you sure if DDB0 and such are actually defined properly?
[16:59:09] <Emil> And is your blinking cyclic?
[16:59:47] <Emil> Also that return(0) is redundant
[17:00:12] <hetii> it works odd, like blinks 8 times fast and then one longer
[17:00:34] <Emil> Looking at those settings and if I'm reading this correctly you put the leds in between the pins?
[17:00:56] <Emil> No wonder if blinks erratically because you are using different settings for them
[17:01:04] <Emil> The output modules
[17:01:11] <Emil> also, you do have a resistor, right?
[17:01:54] <hetii> no, I connect it between GND and via 220ohm to PB0 or PB1
[17:02:09] <Emil> Well, that's strange
[17:02:18] <hetii> I based on this:
https://www.youtube.com/watch?v=O_Yqf_cugwE
[17:02:41] <hetii> and change also uC to new one that should have default fuses
[17:02:57] <hetii> F_CPU is set to: 1000000UL
[17:04:10] <cehteh> that shoudnt matter for that code .. but are you sure your set the right compilation flags for the target mcu
[17:04:34] <cehteh> and that the WGM and other flags are correct (i dint checked that)
[17:11:15] <cehteh> i dont have a fuse calculator in my head :D
[17:11:20] <cehteh> just check for yourself
[17:11:27] <cehteh> but enabled watchdog can cause this
[17:11:57] <cehteh> aka you have some not pretty accurately timed reboot loop
[17:11:59] <hetii> Based on this:
http://www.engbedded.com/fusecalc/
[17:12:03] <hetii> should be disabled
[17:13:08] <cehteh> how does the blinking look like? some pattern or completely random?
[17:14:43] <cehteh> and how fast is it actually, try to increase the prescaler to make it slowmo, you may even change the main clock prescaler to halve the clock from the current value
[17:16:37] <cehteh> aah ,,,
[17:17:08] <cehteh> and most importantly: do you have a 100nF decoupling cap between gnd on vcc .. close to vcc on the board?
[17:17:36] <LeoNerd> "Think of a number of decoupling caps you need. Then double it. Then add two for good measure"
[17:18:07] <cehteh> when the blinking is random then you get resets ..
[17:20:48] <hetii> cehteh, you found the reason :/
[17:21:04] <hetii> I don`t add caps and it cause that issue
[17:21:25] <cehteh> today is the day you learned something important :D
[17:21:39] <hetii> its a bit odd cause I use maybe 20cm strip cable to my avrprog and never had such issue
[17:22:41] <cehteh> that doesnt switch loads
[17:23:01] <cehteh> and the programmer has caps on board for sure
[17:27:28] <hetii> ok thank you for help :)
[18:11:04] <antto> if you open up the virtual serial port (FTDI) at 57600 - that causes the chip to switch to that bitrate also at the other end of the pipe, towards the mcu, even if the mcu is not set to that bitrate, right?
[18:31:00] <cehteh> bitrates on serial are not negotiated
[18:35:07] <Lambda_Aurigae> if you set the ftdi chip to communicate at 57600 then you have to set the device connected to it at the same speed.
[18:40:59] <cehteh> i never looked at the ftdi datasheets, but this usb-serial converters come with some fairy dust, they are somewhat tolerant to baudrate errors, but of course not comletely off baudrates
[18:52:23] <carabia> fairy dust sounds right about plausible explanation.
[19:11:10] <Evidlo> Is multiplication via a sequence of bitshifts and additions likely to be faster than normal multiplication with avr-gcc?
[19:25:29] <cehteh> gcc optimizes very well
[19:26:27] <cehteh> just make sure that one operand is a constant, maybe look at the assembler or profile it
[19:26:48] <antto> cehteh i mean when you open the serial port on the computer side at 57600
[19:27:01] <cehteh> and not all AVR's can do multiplication in hardware
[19:27:18] <antto> i'd think the driver would talk to the ftdi about that, or am i wrong?
[19:28:05] <cehteh> yes
[19:29:17] <antto> so then, i wonder if the ftdi is set to 57600 via software, but the mcu on the other end is configured to 19200..
[19:29:43] <antto> if the computer transmits, ftdi relays, and this reaches the mcu RX..
[19:30:13] <antto> this will largly depend on the USART implementation
[19:30:21] <antto> in my case it's an atmega2561 and i'm not using any 2X or high-speed features
[19:31:20] <antto> crap, it will still parse 0x0F or so as valid chunks of a byte
[19:33:10] <cehteh> if baudrates dont match you'll see some garbage
[19:34:34] <antto> i want to boost the bitrate of my firmware, but i need to watch out for a primitive bootloader running at 19200
[19:35:01] <antto> that bootloader uses single byte commands, it's very easy to cause it to erase the chip
[19:35:03] <antto> meeeh
[19:37:06] <cehteh> your own bootloader?
[19:37:29] <daniel_54> antto, why don't you use an external programmer instead of the bootloader?
[19:37:49] <cehteh> at least not in such a fragile way :D
[19:38:05] <cehteh> even a simple checksum could fix that
[19:38:13] <antto> cehteh nope, it's supposedly one of the "standard" ones, avrdude knows about it
[19:38:41] <cehteh> check which protocol it uses, normally it should have some checksums
[19:39:03] <antto> daniel_54 this is about a device which is already circulating into the hands of hundreds of "normal" users who don't have any idea about programmers and stuff
[19:39:15] <antto> nope, no checksums
[19:39:32] <daniel_54> antto, oops:D
[19:39:34] <antto> iirc 'p' puts it into programming mode
[19:39:46] <cehteh> how ugly
[19:39:50] <antto> yeah
[19:40:05] <antto> it's a bootloader written in ASM which fits in 512kB flash
[19:40:14] <cehteh> well then up the uart speed at runtime via protocol
[19:40:28] <cehteh> bloatloader :D
[19:40:38] <antto> the issue is this..
[19:41:26] <cehteh> micronuleus is 2kb .. including v-usb :D
[19:41:41] <antto> i am writing an app for the computer, which is able to flash this bootloader, it can also flash another bootloader for an upgraded atmega (stk500v2 this time) ... AND the app also can talk to the actual firmware to do fancy stuff
[19:42:03] <antto> however, my app can do lots of fancy stuff with the FW, so it sends a pile of messages on connect
[19:42:35] <antto> if it happens that the device is running the old bootloader while my app is attempting to connect to the FW - boom, trouble
[19:43:16] <cehteh> cant you do it the other way around. the device sends some "HELO" and waits for some serial to connect
[19:43:20] <antto> i've figured a way to detect to some degree whether i'm talking to the old bootloader or not before proceeding with the fancy messages
[19:43:21] <daniel_54> antto: could you try identifying the device?
[19:44:01] <antto> but i need to do this at 19200 only
[19:44:24] <Evidlo> cehteh: This would be on an attiny, which does not have a hardware multiplier
[19:44:51] <antto> cehteh my own FW can, i can change it and make it do anything, but there are a pile of other FWs including discontinued ones, which won't adopt these changes, so that's not an option
[19:45:04] <cehteh> Evidlo: just try, usually gcc is fine, but i noticed some bad spots some time ago
[19:45:07] <antto> they don't send anything periodically like ping or whatever, just silence
[19:45:42] <cehteh> silence can be enough .. i suspect the bootloader has some timeout
[19:45:48] <cehteh> just wait for longer than that
[19:45:50] <antto> nope
[19:46:25] <cehteh> huh
[19:46:26] <antto> the old bootloader is terrible.. it has no indication that it's running, it has no response to the user..
[19:46:33] <daniel_54> antto, so you want to say that you have a family of almost compatible devices with different fw and you want to identify the ones with the weird bootloader? Maybe it's got a chip id command when it returns some info about the chip?
[19:46:54] <cehteh> and it stays in bootloader mode forever?
[19:47:02] <antto> yeah
[19:47:16] <cehteh> and can you do some safe querying ...
[19:47:42] <cehteh> ask for version or reading fuses, or reading anything else (flash, eeprom)
[19:48:02] <cehteh> when it responds you know you are in bootloader mode
[19:48:12] <antto> daniel_54 i've written a sequence of carefully crafted bytes which aren't harmful to the old bootloader, and if i send these to the FW it parses them as a packet with wrong checksum
[19:48:33] <antto> but this only works when both the BL and FW are running at the same bitrate
[19:49:00] <antto> and they are, however, i want to push the bitrate in my own FW up cuz i have lots of fancy features going on
[19:50:18] <antto> i guess when my app attempts to connect to the FW at 57600 - it should first connect at 19200, try to detect if this is the old BL or not, then if it's not - switch to 57600 and do the fancy stuff
[19:50:34] <cehteh> bump the bitrate at runtime
[19:50:48] <cehteh> start slow, give a command to bumb the bitrate
[19:50:55] <cehteh> resynchronize .. done
[19:51:17] <antto> you mean, to make the firmware always start at 19200 and switch to 57600 when the app says so?
[19:51:25] <cehteh> yes
[19:51:33] <antto> hm, that's actually clever
[19:51:39] <cehteh> and maybe fall back if it receives garbagge
[19:51:57] <antto> i'll have to have a timeout or something to bring it back down automatically
[19:52:47] <antto> but this might cause other kinds of inconveniecies
[19:52:57] <cehteh> heh
[19:53:15] <antto> there's no perfect option in this situation
[19:53:44] <antto> i want to support the existing BL and FW cuz they don't have a decent app at all