#avr Logs
Sep 21 2017
#avr Calendar
12:24 AM day__ is now known as daey
03:56 AM Emil: polprog: why would I need what in Yurop? Because I have a gun and I want it to perform well in SRA :D
03:57 AM Emil: habeangur: Lambda_Aurigae or LeoNerd did do programming using switches and leds
03:57 AM Emil: DaRkV0rt3X: ah, damn, but it's okay
04:03 AM Emil: Whoever claimed that there is no 64 bit data type in avr is wrong
04:13 AM habeangur: Lambda_Aurigae: confirm what Emil said
04:14 AM habeangur: I watched the Video, he used a 555 and 2 leds for 0 or 1
04:14 AM habeangur: 2 push buttons not leds
05:56 AM habeangur: which one is better?getting a PCI card to add parallel port and then making my stk programmer for about 12 + 2 dollars or getting a usbasp programmer for about 4 dollars?
06:05 AM LeoNerd: get the polulu one. it's nice
06:12 AM Lambda_Aurigae: I would not recommend usbasp to my worst enemy.
06:12 AM Lambda_Aurigae: but, if you have to get a usbasp, make sure you have a second programmer to update the firmware on it.
06:17 AM Emil: habeangur: buy 3 usb asp programmers for like 6 euros
06:18 AM Emil: That includes the adapter
06:18 AM Emil: Lambda_Aurigae: pfft
06:18 AM Emil: USBASPs work just fine
06:20 AM Emil: The sheer volume reported just on this one eBay seller speaks tons
06:20 AM Emil: http://www.ebay.com/itm/USBASP-USBISP-AVR-Programmer-Adapter-10-Pin-Cable-USB-ATMEGA8-ATMEGA128-Arduino-/310506909410?hash=item484ba76ee2:g:yJQAAOSwrqlZhZ4S
06:22 AM Emil: http://www.ebay.com/itm/10-Pin-Convert-to-Standard-6-Pin-Adapter-Board-USBASP-USBISP-AVR-Programmer-USB-/311565595115?hash=item488ac1b1eb:g:TTYAAOxyF19SGbJr
06:22 AM Emil: http://www.ebay.com/itm/USBASP-USBISP-AVR-Programmer-USB-10-Pin-Convert-to-Standard-6Pin-Adapter-Board-/201556066592?hash=item2eedad8120:g:mv8AAOSwKflZOSam
06:47 AM _abc_: Hello. Has anyone got any experience with this: http://www.riosscheduler.org/ (scroll down for AVR version)
06:54 AM _abc_: Reading at 'AVR Complete Example', I see in the ISR they manipulate SREG.I directly as if the ISR is interruptible? I assume this is to accommodate 'other' AVRs than the one they code for in that example? I think only Mega+ has interruptible ...
06:54 AM _abc_: ... interrupts? @ ISR(TIMER1_COMPA_vect) ...
06:55 AM _abc_: Anyway I like the code, it is terse and simple.
06:55 AM _abc_: [Comments] ? <commentards wanted :)>
06:57 AM Cracki_: isrs can be interruptible, if you reenable interrupts
06:57 AM _abc_: Yes but they do not do that
06:57 AM Cracki_: uh ok what do they do
06:58 AM _abc_: Look at the code?
06:58 AM _abc_: Anyway it is okay to do what they do to 'futureproof' the code
06:58 AM Cracki_: omg that site, do they use frames?
06:58 AM _abc_: Anyway, I am at a loss trying to understand how the previous task is swapped out.
06:58 AM Cracki_: this? http://www.cs.ucr.edu/~vahid/rios/rios_avr.htm
06:58 AM _abc_: Frames?
06:59 AM _abc_: http://www.riosscheduler.org/ is direct link
06:59 AM Cracki_: whatever that "rios" is, it looks odd
06:59 AM Cracki_: "direct link"
06:59 AM Cracki_: that's a frame wrap
06:59 AM _abc_: It seems very okay. Direct as in parent, containing above rios_avr.html link
07:00 AM _abc_: It does not look like a frame wrap here. Whatever
07:00 AM Cracki_: if that's a real preemptive scheduler, it should have assembly somewhere that pushes and pops all registers
07:00 AM Cracki_: I don't see that
07:00 AM _abc_: Ah okay so they actually exec the thread INSIDE the isr with interrupts on
07:00 AM _abc_: Cracki_: the whole point of that trick is to avoid that!
07:01 AM Cracki_: uh
07:01 AM Cracki_: so they get the compiler to generate that
07:01 AM _abc_: No, it's trickyer than even that
07:01 AM Cracki_: non-naked isrs save all registers
07:01 AM _abc_: Yes but if you do what they do you sort of get away with it because the 'tasks' are returning before the next sheduler tick
07:02 AM Cracki_: what kinda task "returns" within a time slice?
07:02 AM _abc_: Which is a nasty hack without instrumentation to make sure they do indeed return before 'midnigtht'. Yet, adding such instrumentation is not too hard.
07:03 AM _abc_: Cracki_: If you would care to read the code I am discussing... you would know...
07:03 AM Cracki_: help me out here
07:03 AM Cracki_: you point to the root of a site, not a specific page
07:03 AM _abc_: 'Complete AVR example.' <- search in page
07:04 AM Cracki_: ...
07:04 AM Cracki_: nevermind
07:05 AM _abc_: Cracki_: seriously
07:05 AM Cracki_: "preemptive multitasking capabilities for cooperative tasks" contradictive
07:05 AM Cracki_: they sure do some nice tricks
07:05 AM _abc_: I am trying to wrap my head around that ISR() how it works when the running thread is interrupted.
07:06 AM Lambda_Aurigae: looks a little complex.
07:06 AM _abc_: Essentially if the 'next' tick comes in while the thread is still running, the ISR is re-entered.
07:06 AM Lambda_Aurigae: I did mine a bit differently.
07:07 AM Lambda_Aurigae: I used multiple stacks...the avr having a movable stack is nice for that.
07:08 AM _abc_: So: assume thread finished, all is well, assume not finished: ISR is called, saves registers as usual(!) - these are the interrupted thread's assuming no other ISR was interrupted - then it starts another thread, then the new thread either runs to ...
07:08 AM Cracki_: the two examples on the front page only show non-preemptive/cooperative "tasks", that are bounded-time pieces of code that do a bit more than compute state transitions
07:08 AM _abc_: ... completion before tick and yields, thus yielding to the interrupted thread from just before ISR, or it, itself, is interrupted as above.
07:08 AM Lambda_Aurigae: each routine had its own full stack...
07:08 AM _abc_: Brilliant.
07:08 AM _abc_: Please read what I wrote before commenting :) Lambda_Aurigae following what you are saying, reading now
07:09 AM Cracki_: I _can not_ find what you describe on that site
07:09 AM _abc_: Okay, I think rios is brilliant. Only trick is one has to be fast and frugal in threads because any contention will fill the stack in a jiffy and crash
07:09 AM Cracki_: that site has only one other page, and that's the avr-specific one
07:09 AM Lambda_Aurigae: Cracki_, there's a link to the AVR stuff just below the code example.
07:09 AM Cracki_: yes
07:09 AM Cracki_: and there is no mention of yield so far
07:09 AM _abc_: Cracki_: On the avr secpfic page search ISR(
07:09 AM Cracki_: yes, i see the isr
07:10 AM _abc_: Cracki_: I mentioned yield
07:10 AM _abc_: Cracki_: yield means return from thread function.
07:10 AM Lambda_Aurigae: that avr code is a bit,,,,twisted.
07:10 AM _abc_: Lambda_Aurigae: yes... very cleverly twisted.
07:10 AM _abc_: wicked in fact.
07:10 AM Cracki_: that code is tame compared to other RTOS
07:10 AM _abc_: I saw this elsewhere before I think
07:11 AM _abc_: Cracki_: yes, it is lightweight and nicely done for small projects. Which is my dish. Win.
07:11 AM Lambda_Aurigae: I played with the whole rtos/multitasking os thing on avr 12 years ago.
07:11 AM _abc_: That being said, I *really* *really* need instrumentation at least in the debug phase to see how deep that stack gets.
07:11 AM _abc_: Lambda_Aurigae: and? Was it a bad experience?
07:12 AM Lambda_Aurigae: well,,,all depends on how "realtime" you need your rtos to be.
07:12 AM _abc_: It is safeish to read the SP in an ISR on avr? I need to look at lst asm code
07:12 AM Lambda_Aurigae: as a multitasking processor...or,,rather,,task switching processor, it works well.
07:12 AM Lambda_Aurigae: reading stack pointer is fine..no problems.
07:12 AM _abc_: Lambda_Aurigae: avr is so dog slow popping and pushing all those registers it's a shame
07:13 AM Lambda_Aurigae: writing it will cuse you some,,,fun.
07:13 AM Lambda_Aurigae: cuse/cause
07:13 AM _abc_: Lambda_Aurigae: almost any other cpu even from 1980s is faster, on account of fewer registers to save.
07:13 AM Cracki_: I don't think this rios code is completely aware of what it's doing
07:13 AM Lambda_Aurigae: _abc_, use naked ISR
07:13 AM Lambda_Aurigae: doesn't pop/push as much.
07:13 AM _abc_: Cracki_: being a university they have all the students in the world to test it and all the time in the world to play with it.
07:13 AM _abc_: Lambda_Aurigae: I know, but in the context of the rios hack you want that.
07:14 AM Cracki_: I judge it from the same position
07:14 AM Lambda_Aurigae: well, kinda.
07:14 AM * _abc_ mumbles about ##electronics having become a cesspool of crackpots and various non electronics related sh*t
07:14 AM Cracki_: right now I'm making sure I understand the behavior of AVR interrupts, specifically whether they can be interrupted themselves at all
07:14 AM Lambda_Aurigae: doing it with multiple stacks, not really...as each task would have its own stack and you don't want the isr pushing stuff on random stacks.
07:15 AM _abc_: Cracki_: they can be if you re-enable interrupts in the ISR. Which they do.
07:15 AM Lambda_Aurigae: _abc_, that happened to ##electronics 15 years ago.
07:15 AM Cracki_: they do, which can cause a bunch of trouble
07:15 AM _abc_: I missed the sneaky way in which that is used in that code Cracki_
07:15 AM Cracki_: so the tasks have to be shorter than a tick
07:15 AM _abc_: Lambda_Aurigae: let's say the cesspool flux is peaking right now imo
07:15 AM Cracki_: if they are not, trouble
07:16 AM _abc_: Cracki_: nope, SOME need to be shorter. When they are not they get interrupted!
07:16 AM Lambda_Aurigae: I left that place many years ago...
07:16 AM _abc_: Cracki_: they land on the stack, the next task is sheduled, as before, exits, THEN the interrupted task restarts.
07:16 AM Cracki_: and it piles up
07:16 AM _abc_: Cracki_: yes. And they have some means to keep track of it, and I said I need more means :)
07:16 AM Lambda_Aurigae: with my multitask OS I just had a set time slice and each task got the same amount of time...didn't do any idle tasks or anything.
07:16 AM _abc_: That GCD increment in the time is one
07:17 AM Cracki_: and I haven't identified that means yet
07:17 AM _abc_: Lambda_Aurigae: Procustean sheduling is simplest yes.
07:17 AM Lambda_Aurigae: it worked.
07:17 AM Cracki_: ah, .running
07:17 AM _abc_: Cracki_: tasks[i].elapsedTime += tasksPeriodGCD;
07:17 AM Cracki_: not that.
07:18 AM Cracki_: that's just the period
07:18 AM _abc_: Cracki_: yes but by that means the next shedule is pushed ahead far enough that no bad things will happen if they have not already.
07:18 AM Lambda_Aurigae: all depends on what one needs said multitasking for....most people don't really need true multitasking, just interruptable tasks.
07:19 AM Emil: Not to mention true multitasking is impossible on an AVR
07:19 AM Emil: You always need cores for that
07:19 AM Emil: moar cores
07:19 AM Lambda_Aurigae: that's multithreading
07:19 AM Lambda_Aurigae: multitasking is kind of a misnomer really...
07:20 AM Cracki_: the worrisome part is that they use cli()/sei() for presumably "critical" code inside the ISR, but they use it like they're unaware after ISR entry the bit is cleared
07:20 AM Emil: Multitasking - doing many things at the same time
07:20 AM rue_bed: yea, ##electronics went wrong a long time ago
07:20 AM Cracki_: so after a loop, the bit is set, so the loop itself can be interrupted
07:20 AM Cracki_: which shouldn't even be needed
07:20 AM _abc_: rue_bed: It does have lucid moments, depending on who is on at the time.
07:21 AM Lambda_Aurigae: Cracki_, yeah...that whole system there just makes me cringe.
07:21 AM _abc_: rue_bed: but the ops completely dropped the ball, intentionally apparently. There should be ##electronics-defocus
07:21 AM Lambda_Aurigae: ok...time to go break some copiers!
07:21 AM Cracki_: "true multitasking", sounds like the distinction between concurrency and parallelism
07:21 AM _abc_: Cracki_: the only place where it is cleared 'in vain' is the 1st clear after ISR entry.
07:21 AM Emil: Cracki_: that's what it is, though
07:21 AM _abc_: Cracki_: all the others are valid and needed
07:22 AM Emil: concurrency always requires that you relax your timing requirements
07:22 AM Cracki_: Emil, I think we all agree on the merits of the abstraction that is context switching
07:22 AM _abc_: True multitasking is when your female significant other does more than one thing at a time and gets at least one of them right without spillage, crashing something, stains, or other mishaps.
07:22 AM Cracki_: oh dear
07:22 AM _abc_: Okay, applause time.
07:23 AM _abc_: Back to the task at hand: re: rios sheduler: It is a wicked hack imo, but real projects seem to have been based on it and they work in a student context at least.
07:23 AM _abc_: So opinions? Upvote/downvote this hack for some application?
07:25 AM Cracki_: as for per-task stacks and "you don't want the isr pushing stuff on random stacks", that's exactly what happens in every preemptive scheduler, avr, arm, x86, ...
07:26 AM _abc_: Cracki_: and now I get what you meant about that frame redirect. It tried to open youtube video in the window too. Strange I have noscript on and frame redirects should be caught. But goopile uses them to track people too, some links in their search ...
07:26 AM _abc_: ... results are modified frame redirects so they can go through their logs...
07:26 AM Cracki_: unless the cpu has register files or other capability
07:26 AM _abc_: Cracki_: strictly, no, since there is always the 'in use' task which belongs to the current task. When the sheduler runs it does indeed switch to another stack and loads the registers from there.
07:27 AM Cracki_: huh?
07:27 AM _abc_: Iow the last interrupted task will have it's own registers saved in it's own stack
07:27 AM Cracki_: in use stack you mean?
07:27 AM Cracki_: right
07:27 AM Cracki_: and that's ok
07:27 AM _abc_: Yes, and it's true for all tasks, really.
07:27 AM _abc_: Now, the rios sheduler above, ... does what you said.
07:28 AM Cracki_: the isr can't really check if the tasks stack has enough space for the register set, that's a blind operation, but an MMU can keep trouble in check
07:28 AM Cracki_: *MPU/MMU
07:28 AM Cracki_: the rios scheduler has a single stack
07:28 AM _abc_: MMUs are a non avr topic :)
07:28 AM Cracki_: there is no modification of a stack pointer
07:29 AM _abc_: Cracki_: you can think of the rios sheduler as a continuation factory... continuation by interrupt...
07:29 AM Cracki_: things are just carefully handled on that single stack
07:29 AM _abc_: Or coroutine even
07:29 AM Cracki_: not really, because those require the idea of a "stack tree"
07:30 AM Cracki_: where things can wind up and down freely. that requires pointers between stack frames, not a linear stack
07:30 AM _abc_: Hmm.
07:30 AM Cracki_: also refcounting, at least.
07:30 AM Cracki_: or you remove a stack frame that's still referenced from another coroutine
07:30 AM _abc_: Well the refcount is always 1 in this case, i.e. rios.
07:30 AM _abc_: or 0
07:31 AM Cracki_: because rios might interrupt a running task with its ISR, but the task is allowed to continue executing, so that's more like "sorry for the interruption, carry on" rather than a preemption
07:31 AM habeangur: Emil: these are not available for my location
07:32 AM habeangur: LeoNerd: parallel?
07:32 AM _abc_: Cracki_: yep
07:32 AM habeangur: and I was just asking, I really don't want to do this(I don't know maybe I want...)
07:32 AM _abc_: Cracki_: moreover, if things get out of hand, and tasks are long running, then the same task can be re-sheduled while an instance of itself is interrupted. THAT is going to be fascinating.
07:33 AM LeoNerd: habeangur: USB
07:33 AM _abc_: Cracki_: so, as I was saying, some instrumentation would be crucial there.
07:33 AM Cracki_: uh, I don't see that.
07:33 AM Cracki_: priorities aren't shared.
07:33 AM _abc_: Cracki_: apropos refcount, f.ex. guarding calls to the thread function in the ISR.
07:33 AM Cracki_: if there are tasks with the same function, one will always finish before the other can ever start
07:34 AM Cracki_: "finish" in terms of tick execution
07:35 AM Cracki_: http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
07:35 AM _abc_: Cracki_: assume 2 tasks, A B, A gets sheduled, runs long, interrupted, B runs short finishes bf. tick in ISR, ISR returns to A, A still runs, ISR ticks, next to be sheduled would be A... unless the sheduler removed it from the candidate list (I think ...
07:35 AM Cracki_: restorestate
07:35 AM _abc_: ... it does that)
07:35 AM Cracki_: if B is higher priority, then that's the case
07:36 AM _abc_: Also yes one must assume the tasks are distinct, and that the same task function is never sheduled as 2 different tasks
07:36 AM Cracki_: but your example assumes unequal running times
07:36 AM Cracki_: or unequal intervals
07:36 AM _abc_: They are unequal in their example.
07:36 AM Cracki_: also function-static variables need to be considered
07:37 AM _abc_: there is " && (!tasks[i].running) // Task not already running (no self-preemption) " in there, so they are taking care of loose ends in a good way
07:37 AM Cracki_: right
07:38 AM Cracki_: so the ideas of this code are good to keep in mind
07:38 AM _abc_: Another interesting wrinkle is, there is a for() loop IN the ISR trying to run all sheduled tasks which are of higher priority than the one currently interrupted by the ISR. Which makes my head spin a bit.
07:39 AM _abc_: Let's just say that whoever uses this had better have a thick hide and be pedantic about timing optimization and global volatiles and other stuff.
07:39 AM _abc_: Personally, I find it a mind bending hack but it is very nice and portable. No messing with asm.
07:40 AM Emil: habeangur: eh?
07:40 AM Emil: habeangur: you mean ebay?
07:40 AM Emil: lol wtf
07:42 AM _abc_: Iirc AVR ISR alone needs >64 clocks and >32 bytes to just save registers? Then one calls the real task in this stack context, another 32 bytes of stack at least. So stack size for 3 tasks alone as shown in the examples should be at least 3*32 and with ...
07:42 AM _abc_: ... more interruptable tasks n*3*32? 10 tasks 'deep' sheduler load = 960 bytes? Half a '328's ram?
07:44 AM _abc_: Backtracking a bit, say 4 tasks 'deep' sheduler stack at most ~ 370 bytes ram for stack. Scary.
07:45 AM _abc_: Maybe I am overdoing it with 3* but I want to see where this goes.
07:45 AM _abc_: Okay so this is noted as an interesting hack. Maybe to be tried out in the next project.
07:48 AM Cracki_: http://www.freertos.org/implementation/a00015.html
07:48 AM Cracki_: I remember them having an exact cycle count of that too
07:48 AM Emil: It's the reason why you don't really do rtos on avr
07:48 AM Cracki_: oh, people do freertos on avr :)
07:49 AM Cracki_: when you have to, you have to
07:49 AM Emil: Yes
07:49 AM Emil: But this is why you shouldn't
07:49 AM Emil: it's wholly inefficient
07:49 AM Cracki_: it's an abstraction
07:49 AM Cracki_: of course it has a cost. but a benefit too.
07:49 AM Emil: sigh
07:50 AM Cracki_: besides, let's say 64 cycles, that's a few microsecs.
07:50 AM Cracki_: the same kind of inefficiency you encur on any processor
07:50 AM Cracki_: it's just on avrs you have less cpu cycles to burn :)
07:50 AM Emil: you need some 40 cycles to enter and 40 cycles to return from an interrupt
07:51 AM Emil: if you call shit
07:51 AM Cracki_: huh?
07:51 AM Cracki_: 40 cycles for what now?
07:51 AM Emil: pushing all the registers and sreg
07:51 AM Emil: entering the isr
07:51 AM Cracki_: sure.
07:51 AM Emil: and so on
07:51 AM Cracki_: (non-naked isr)
07:52 AM Cracki_: tho I have seen gcc optimize non-naked isr register saving to just what the ISR actually touches
07:53 AM Emil: If you don't call anything it does that
07:53 AM Emil: if you call it pushes all
07:53 AM Cracki_: jup
07:54 AM Cracki_: I season my code with inline directives for the smaller funcs in the hopes that gcc heeds my advice
07:54 AM _abc_: Sometimes when coding the 17th interleaved FSM to diddle something or other on an AVR you start really longing for just putting each FSM into a task function and let it rip the bad old way, using yield() for delay() etc
07:55 AM _abc_: So yes multitasking sucks but other things suck more.
07:55 AM _abc_: (on avr)
07:55 AM LeoNerd: I do everything on AVR with little tasklets
07:55 AM _abc_: I actually saw avr-gcc optimize 2 isr's calling the same function by simply NOT saving all regs. The function saved them.
07:55 AM _abc_: LeoNerd: with what shedulerish thing?
07:56 AM LeoNerd: A little one I wrote myself
07:56 AM _abc_: LeoNerd: asm type stack var manipulation or rios kind of "riot"?
07:56 AM LeoNerd: A static array of tasklets, each has an ID and a function, and a "is runnable" flag. The main scheduler just sleeps until interrupt, then when it wakes up it checks and runs any of the tasks that are marked runnable
07:57 AM Cracki_: aren't functions, by calling convention, supposed to save what they touch?
07:57 AM LeoNerd: So usually ISRs and so on just mark a task as runnable, which then runs them
07:57 AM LeoNerd: No crazy asm stuff no. It's all plain C
07:57 AM _abc_: Cracki_: yes but gcc was smart enough to save everything in the function, since it was basically called by two naked ISRs, and I did not mark them naked, gcc did
07:57 AM Cracki_: ic
07:58 AM _abc_: Cracki_: it saved at least 30 instructions like that.
07:58 AM Emil: LeoNerd: share it?
07:58 AM Cracki_: sounds like optimization down to not having to save _anything_
07:59 AM _abc_: Cracki_: it does that too! -Os and put in any function (!) it decides it won't use, the function will be gone byebye once it is detected in 'dead' code.
07:59 AM _abc_: I once spent more than an hour poring over asm lst output trying to find out what makefile error made my code "not compile". Haha-
07:59 AM _abc_: brb
07:59 AM Cracki_: yes, from compiler class, I remember the approach. generate correct code first (full register set push), then strip out what's not needed (pushing any of those).
08:00 AM LeoNerd: Emil: http://paste.debian.net/987106/
08:00 AM LeoNerd: This one is my second-generation version. It also steals timer1 to do timed delays on scheduling
08:02 AM Cracki_: refresh my memory, what's GPIOR0? r0? a port?
08:02 AM LeoNerd: Oh, it's a register sitting in the IO space that the CPU core itself doesn't use for any purpose. It's free for user use
08:03 AM LeoNerd: So if you put commonly-used data in there it's slightly faster to access
08:03 AM Cracki_: wait, wasn't r0 the register that's always "supposed" to be 0? :D
08:03 AM LeoNerd: Yah this isn't r0
08:03 AM Cracki_: ah
08:03 AM Cracki_: neat
08:04 AM Cracki_: very sleep-aware code
08:05 AM _abc_: LeoNerd: the sleep saves power or what?
08:05 AM LeoNerd: Yah
08:05 AM Emil: It's better than busylooping
08:05 AM _abc_: Yes
08:05 AM LeoNerd: I use this scheduler, for example, on a radio remote button thingy that runs off a LiFEPO4 cell. I can get about 4 days off a charge
08:06 AM Cracki_: haven't had to do that much yet. always industrial applications with "infinite" power supply
08:06 AM LeoNerd: And that's with pulsing an LED every 10 seconds, and operating an nRF radio every single second
08:06 AM Cracki_: nice
08:06 AM Emil: https://emil.fi/jako/kuvat/2017-09-21_15-35-02_d60Xeecn.png
08:06 AM Emil: What the fuck are these really for
08:06 AM Cracki_: sounds like sram, but not sram, and register, but not register
08:06 AM _abc_: Not loading
08:06 AM Cracki_: so fair game to anything
08:07 AM Cracki_: 12.5.1. General Purpose I/O Registers
08:07 AM Emil: Cracki_: yeah, but the naming is strange
08:07 AM _abc_: Emil: ok, it's my browser, old certs, can't hs with your new https
08:07 AM Emil: hs?
08:07 AM Cracki_: The device contains three General Purpose I/O Registers, General Purpose I/O Register 0/1/2 (GPIOR 0/1/2). These registers can be used for storing any information, and they are particularly useful for storing global vanables and Status Flags. General Purpose I/O Registers within the address range OxOO - Oxi F are directly bit-accessible using the SBI, CBI, SBIS, and SBIC instructions.
08:07 AM Emil: _abc_: update your browser? ;)
08:07 AM _abc_: Cracki_: more importantly, they are not used by the avr-gcc for anything so you can rely on them
08:07 AM Emil: lol wtf
08:07 AM Cracki_: I'll remember those registers
08:08 AM Emil: Yeah same
08:08 AM Emil: dat single cycle access doe
08:08 AM LeoNerd: Yah. This is why I use them for my task status flags
08:08 AM LeoNerd: 1-cycle access ;)
08:08 AM Emil: What I want to know, though
08:09 AM Emil: is what are the reserved register areas used for
08:09 AM Emil: in the core
08:09 AM Emil: What sikrits lie there
08:09 AM LeoNerd: In case of future devices adding more "fast" peripherals?
08:09 AM _abc_: Emil: NSA codre readout, China chip protection breaking enterprise use, etc :)
08:09 AM Cracki_: ok so what distinguishes 0-2 from 0x00-0x1f?
08:10 AM _abc_: Emil: most current mcu's have and had special code access modes used in the factory in theory to run destructive testing and reliability testing on internal flash and other things.
08:10 AM Emil: Also someone should scan how the fuck does the fucking ptc work on m328pb
08:10 AM _abc_: Emil: this is not documented anywhere but well known.
08:10 AM Cracki_: ah, gpio0/1/2 are strewn about within 00-1f
08:10 AM _abc_: ptc?
08:10 AM Cracki_: or not even
08:10 AM Emil: _abc_: hmm, that might expalin it
08:10 AM Cracki_: ptc = thermo resistor
08:11 AM Emil: _abc_: peripheral touch controller
08:11 AM Cracki_: or that
08:11 AM _abc_: Emil: factory flash etc testing implies faster/slower reads etc to determine 'speed grade' etc.
08:11 AM _abc_: Emil: this necessarily must allow out of spec timing on access. Guess how one cracks flash?
08:11 AM _abc_: brb
08:11 AM Emil: _abc_: that's a good point
08:13 AM Cracki_: ok so gpior0 is 0x1e, so bit-addressable, the other two are 2a and 2b, so not bit-addressable
08:13 AM _abc_: One story which has no proof I have seen yet is, that the ICD/debug commands of many mcu's are 'secret' as in unpublished because they are also usable for the above purposes in the factory.
08:13 AM Cracki_: (328p)
08:13 AM LeoNerd: Yah; it still annoys me that debugWire isn't publicly documented by Atmel^WMicrochip
08:14 AM _abc_: And never will be.
08:15 AM LeoNerd: RikusW and I have *some* progress at blackboxing it, but some details are still hazy
08:15 AM Cracki_: when I skipped around in the tiny817 sheet, it contained all the details of that UPDI single-wire debug protocol
08:15 AM Cracki_: all the command etc
08:15 AM _abc_: Emil: what is the PTC you referred to?
08:15 AM LeoNerd: Yes, well those four new tinies are *toooooootally* different from any other AVR chip
08:15 AM Cracki_: capacitive touch for on-pcb touch "buttons"
08:15 AM LeoNerd: They're really more like PICs with an AVR8 CPU at the core
08:15 AM Cracki_: I'd say they took a tiny and beefed up the peripherals
08:15 AM _abc_: Really? Is that a good thing?
08:15 AM Cracki_: the peripherals are awesome
08:16 AM Cracki_: event system
08:16 AM Cracki_: before, similar thing only on xmegas
08:16 AM _abc_: Oh okay, new 'enhanced' PIC peripherals are. I go back with pic's all the way to pic16c54 you know. EEPROM memory, JW cerdip, UV lamp, 20 minute cycles ...
08:16 AM Cracki_: "programmable logic", two 3-bit LUTs
08:16 AM _abc_: Cracki_: PsOC has some things which fly hoops around pic and avr together
08:17 AM _abc_: And they have been around since 2000s and before.
08:17 AM Cracki_: you can "wire" all that up howevery you like. timers, the LUTs, analog comparator, even the DAC (8 bit)
08:17 AM _abc_: Also probably not by accident Cypress was and is one of the major fast flash/ram makers. Seriously fast, like 2nsec
08:17 AM Cracki_: psoc? i"ll go look
08:18 AM Cracki_: ah, cypress
08:18 AM _abc_: 8051 core on old ones, ARM or 8051 on new
08:18 AM _abc_: (80 MHz 1 clock/instruction 8051 iirc)
08:18 AM Cracki_: how do the cypres psoc compare to other arms?
08:19 AM Emil: _abc_: 2017-09-21 15:39:52 +0300 < Emil> _abc_: peripheral touch controller
08:19 AM _abc_: I don't know. I never used an arm PSoC but I do know they are and were used by the gazillion, the 8051 model I think. 90% of Microsoft mice seemed to have used a PSoC+optical chip. USB on chip too.
08:19 AM _abc_: Emil: yeah thanks
08:19 AM Cracki_: heh wikipedia makes them sound very configurable
08:20 AM _abc_: Cracki_: it's an analog array plus digital array.
08:20 AM _abc_: Cracki_: makes you wonder what exactly Microchip were being inspired by with their new enhanced peripheral arrays...
08:20 AM Emil: _abc_: the point is that the ptc, which is supposedly hardware, is not documented at all
08:20 AM _abc_: There's a quick intro to PSoC you should read Cracki_, it's a presentation.
08:21 AM _abc_: Emil: do you think it's different from the usual 'touch channel' interfaces?
08:21 AM Emil: _abc_: but if it's a real thing they must shout into undocumented registers
08:21 AM Cracki_: programmable interconnect...
08:21 AM Cracki_: good stuff
08:21 AM Emil: And those calls are easily visible when looking at the asm
08:21 AM _abc_: https://en.wikipedia.org/wiki/File:Psoc_blocks.PNG Cracki_ this pic is just an intro. It gets much better.
08:22 AM Cracki_: aye
08:22 AM _abc_: Cracki_: note you have PGAs there and more.
08:22 AM _abc_: And adc/dac galore
08:22 AM Emil: _abc_: is that how you configure those?
08:22 AM * Emil throws up internally
08:23 AM _abc_: Emil: I don't know. Everyone suddenly has 'touch channels' on old mcu's too. I looked at the sample code and app notes from Microchip, it's just capacitive sensing.
08:23 AM _abc_: Emil: there's a gui of course or you can do it textually.
08:23 AM Emil: _abc_: no I mean that link you posted
08:23 AM Emil: capacitive sensing is super easy on any avr
08:23 AM _abc_: Cue FUNNYBUSNAME_X78_Y92 = CRAZY_BITMASK|MORE
08:23 AM Emil: digital or adc
08:23 AM Cracki_: graphical configuration (model-based development) is the future :P
08:24 AM Emil: lolno
08:24 AM Cracki_: all the HDL/fpga crowd uses it
08:24 AM Cracki_: matlab/simulink uses it
08:24 AM _abc_: Emil: the link I posted is I presume a screenshot from a presentation or from the configurator gui
08:24 AM Emil: Because the faggots at $vendor push them
08:24 AM Cracki_: it's very engineery, quite foreign to programmers
08:24 AM Emil: because the ultrafags in marketing push them
08:24 AM Emil: _abc_: ah
08:24 AM Emil: _abc_: because I've seen some idiotic shit
08:25 AM _abc_: Cracki_: if you see which gui config connection is ticked in a 1024x64 matrix with 18 or more colors on screen, after half a day of work, I'll give you the Aspie cookie.
08:25 AM Cracki_: ;)
08:25 AM _abc_: Emil: Microchip's peripheral config tool is not much better either.
08:26 AM _abc_: Also Silabs's 8051s are really trippy in peripheral config. They use a 'first asked first served pin' assignment. Makes pcb test design NOT fun
08:26 AM _abc_: Cracki_: As you can see the PSoCs really push the density up there, very soon you will need to go back to doing things properly with a script and verification and such.
08:27 AM _abc_: Cracki_: which is what the real people who fo FPGA and HDL do. Scripting ad nauseam, frequently in Tcl, which gui Java jockeys hate, and I love.
08:27 AM _abc_: Tcl is the Modelsim's scripting language too. And many other thing's
08:28 AM _abc_: I once met a m0r0n who wanted to port the fpga/hdl etc scripting to Python because Tcl sucks (it was designed precisely for this initially). I am still laughing inside because of that. Never heard of the guy egain.
08:28 AM Cracki_: verification, I wish there were more of that
08:28 AM _abc_: *a
08:28 AM _abc_: Oh you get to write your own benches.
08:29 AM Cracki_: there's no way around tcl in the HDL tools ecosystem
08:29 AM _abc_: Oh, yeah, and, GUI entry verification? What do you mean, verification? >;)
08:29 AM Cracki_: I know people try to build HDLs in python, haskell, what have you
08:29 AM Emil: TCL is KÄNSER
08:29 AM _abc_: KÄNSER?!
08:29 AM Cracki_: kartoffel detected
08:30 AM Emil: Cracki_: yes, you should, if you are sane, notice how potato tcl is
08:30 AM Cracki_: I haven't touched tcl yet
08:31 AM _abc_: Potato? /me detects a C++/Java jockey who hates SICP and Prolog
08:31 AM Cracki_: read a bit about its principles (again) a few days ago
08:31 AM Cracki_: anyone who can make an Ä without effort must be speaking Deutsch
08:31 AM Emil: äöå
08:31 AM Cracki_: seems tcl has been evolving
08:31 AM _abc_: µø
08:32 AM Emil: It depends on what you mean by "without effort"
08:32 AM _abc_: Cracki_: tcl+tk are actively developed and supported. The real developers are on freenode at #tcl
08:32 AM Emil: äöå are single press
08:32 AM Cracki_: switching layout
08:32 AM Emil: ü is double
08:32 AM _abc_: ü is not double here :) Nor is ß.
08:32 AM _abc_: Let's stop this.
08:33 AM Cracki_: the wikipedia article on tcl was not as precise as I need to understand the execution and data model of tcl
08:33 AM Cracki_: or the semantics of its syntax
08:33 AM Cracki_: I'd have to play with a repl to get a feel for it
08:33 AM _abc_: Cracki_: data model? Here's a simple take: everything is a string. Always, unless it is temporarily coerced into a list or integer.
08:34 AM _abc_: Cracki_: syntax: balance curly braces including in comments, there's at least space after every keyword including before the next opening (not closing) curly brace.
08:34 AM _abc_: That's about it.
08:34 AM Cracki_: nope
08:34 AM Emil: Sounds like javashit
08:34 AM Cracki_: [] have meaning
08:34 AM Cracki_: what that meaning is exactly, I haven't gleaned from wikipedia
08:35 AM Cracki_: also there's {}
08:35 AM Cracki_: and the interpolation rules for variables...
08:35 AM Cracki_: and when something is evaluated how
08:35 AM Cracki_: and when something is deferred, and how
08:35 AM _abc_: Cracki_: LISP '(a b c) is Tcl {a b c}; Lisp a b c is Tcl [a b c]
08:35 AM Cracki_: scoping rules... i hope they have lexical scoping
08:35 AM _abc_: yes.
08:35 AM Cracki_: uh lisp a b c is individual executions of read
08:35 AM _abc_: yes
08:36 AM _abc_: it's actually a with params b and c. Lambda?
08:36 AM Cracki_: so is [a b c] a string?
08:36 AM _abc_: yes. Also functions are first class objects, and strings...
08:37 AM Cracki_: and what that string means depends on how it's parsed
08:37 AM Cracki_: ?
08:37 AM Cracki_: functions are strings, you mean?
08:37 AM _abc_: [a b c] means execute procedure a with params b and c, return value of a suitable for rhs use
08:37 AM _abc_: Cracki_: everything is a string.
08:37 AM _abc_: (apparently)
08:37 AM Cracki_: great
08:37 AM polprog: this is more fucked up than haskell tbh
08:37 AM _abc_: Anyway off topic. #tcl
08:38 AM _abc_: polprog: someone referred to Tcl as Scheme on acid. Probably right.
08:38 AM Cracki_: > set sum [expr 1+2+3+4+5]
08:38 AM Cracki_: so this is parsed into "set" "sum" "[expr...]", then set is evaluated, passed the strings, ...?
08:38 AM Cracki_: and set evaluates the second arg, sees it's something to execute (the []), parses and evaluates?
08:39 AM Cracki_: ugh this can be fun...
08:39 AM polprog: dear god
08:39 AM Cracki_: I was meaning to learn perl too, just for the perversity of it
08:39 AM _abc_: expr is eval'd deepest, it solves 1+2+3+4+5, returns the result as a string. set is eval'd with sum arg1 and result arg2
08:39 AM Cracki_: ah, so I guessed
08:39 AM polprog: oh god scheme uses polish notation for maths
08:39 AM _abc_: There are also continuations in modern tcl and generators and...
08:40 AM Cracki_: scheme, all lisps, are really nice
08:40 AM Cracki_: at least pairs and >=1 number type
08:41 AM Cracki_: I was thinking what to implement on AVR that gives users programmability
08:41 AM Cracki_: forth maybe
08:41 AM Cracki_: TCL maybe not :P tho I've seen TCL on another embedded thing my embedded thing has to talk to
08:42 AM Cracki_: (they also do web stuff and json, which can be done on AVR too...)
08:58 AM _abc_: tinytcl lookup
08:59 AM _abc_: also tcl runs AT LEAST on anything that runs python, being simpler.
08:59 AM _abc_: Jsonish is a native data format in tcl. You import json simply by setting an array variable to the json data.
09:00 AM _abc_: it does not enforce the usual json delimiters like dquotes.
09:00 AM _abc_: http://wiki.tcl.tk/40053 libs are provided for 'real' json use.
09:02 AM _abc_: http://core.tcl.tk/tcllib/doc/trunk/embedded/www/toc.html libs you get installed with any normal tcl install on pc/linux/android (!)
09:29 AM _abc_: http://www.freertos.org/implementation/a00015.html What are 0xEE 0xFF at the top of the stack? Dedicated markers put there by something? avr-gcc?
09:30 AM remkooo1 is now known as remkooo
09:35 AM Cracki_: no clue, sounds plausible
09:35 AM Cracki_: also, doesn't the stack grow down?
09:35 AM Cracki_: are they confused as to which direction the memory map goes?
09:35 AM Cracki_: (guessing higher addresses go down in their imagination)
09:37 AM Cracki_: tasks aren't allowed to just return, they must use an exit call. they could have implemented that for a return too, just prepare the task stack
09:53 AM habeangur: Emil: yes ebay, amazon, all of these
10:17 AM JanC is now known as Guest54020
10:17 AM JanC_ is now known as JanC
11:32 AM sdsda: hello there, i am having difficulties connecting to my atmega328p, it gives me the error: stk500_getsync(): not in sync: resp=0x00 -.-, anyone want to help?
11:33 AM sdsda: i use a ftdi adapter, i've connected gnd, vcc, rxi, tx0, tr.. but no result
11:54 AM Emil: habeangur: how can you not have eBay/Aliexpress/Banggood? :D
11:56 AM LeoNerd: sdsda: Does your chip definitely have the right UART bootloader on it?
12:00 PM Casper: sdsda: a FTDI is not a programmer
12:01 PM Casper: it is a usb to serial (uart) adapter
01:13 PM Cracki_: they always disappear so quickly
01:30 PM polprog: my server just asked me if im on drugs
01:30 PM polprog: sudo insults ftw
01:35 PM antto: and your answer was? "i want a lawyer."
03:18 PM DaRkV0rt3X: Hello
03:18 PM DaRkV0rt3X: guys
03:18 PM DaRkV0rt3X: one question I'm still trying to figure out
03:19 PM DaRkV0rt3X: when we setup an AtMega328p ADC
03:19 PM DaRkV0rt3X: do we still need to set the ADC pins we will use as input pins?
03:19 PM DaRkV0rt3X: Or they are input pins just by setting up the ADC itself?
03:27 PM polprog: keep them as input just in case
03:27 PM polprog: besides, you can try to read from a pin that is set as high output
03:27 PM polprog: and see what happens
03:32 PM polprog: imo, enabling adc should enable PORT value override and other necesary stuff
03:32 PM polprog: see alternate port functions in the datasheet
03:34 PM polprog: huh, actually not... at least in atmega 16 :P
03:35 PM polprog: look for overriding signals for alternate functions
03:39 PM Emil: polprog: why should enabling adc enable port value? :creepy moon face:
03:39 PM Emil: port override*
03:42 PM DaRkV0rt3X: The catch is that in my project, back when I started, I could read some non-sense values there (because I need t replace a pair of diodes)
03:42 PM DaRkV0rt3X: but as I started adding features
03:42 PM DaRkV0rt3X: to the code and the project
03:42 PM DaRkV0rt3X: now, I can't read any value from the ADC
03:43 PM DaRkV0rt3X: It is just printing a default value I set in case of any nagtive values were coming out from the additional math I have
03:43 PM DaRkV0rt3X: dinner time
03:43 PM DaRkV0rt3X: brb
03:44 PM polprog: Emil: that just seems logical to me.. but there's probably a good reasogn they did it like that
03:51 PM polprog: Engrish from Toshiba's datasheet: "Don’t touch TESTMODE registers"
03:51 PM polprog: lol
04:05 PM Emil: polprog: I mean, from the primitive standpoint it's understandable to want to override port functionality
04:05 PM Emil: polprog: but from a more advanced viewpoint it's actually better to allow more functionality
04:06 PM Emil: The expense is one or two cycles of more operation
04:06 PM Emil: But it allows for more advanced designs
04:09 PM LeoNerd: Ohgreat. :/ One of the chips I use is declared "end of life", with no suggested replacement
04:09 PM LeoNerd: So now I feel I have to buy a £100 tray of them
04:12 PM Emil: LeoNerd: ayy
04:12 PM Emil: I ran into that issue, too
04:12 PM Emil: fucking annoying but that's what you get for buying (almost) the cheapest part :D
04:16 PM LeoNerd: This isn't the cheapest. This is a fancy one. It was the only chip I could find that comes even close to the spec I wanted
04:16 PM Emil: What chip is that?
04:17 PM LeoNerd: MAX9643U
04:18 PM LeoNerd: https://www.maximintegrated.com/en/products/analog/amplifiers/MAX9643.html
04:18 PM LeoNerd: The chip I use on the "Plus" version of the scope current adapter
04:21 PM Emil: I don't quote understand the typical operating circuit
04:22 PM Emil: But it's a ccvs
04:23 PM Emil: And I understand the purpose
04:23 PM LeoNerd: Oh I don't know what that suggested circuit is for either. I just use it to output to an oscilloscope
04:24 PM bss36504: Its a current sensing circuit
04:24 PM Emil: The idea of the suggested circuit is simple to decipher
04:24 PM Emil: I can't just see how it's supposed to work :D
04:25 PM Emil: The suggested circuit is feedback to a boost power supply if I'm not mistaken
04:25 PM bss36504: What about it? Lots of switching topologies like to use inductor-current measurements as part of the control scheme
04:25 PM bss36504: yeah
04:25 PM Emil: bss36504: the issues is that
04:25 PM Emil: that sense resistors is small as fuck
04:26 PM Emil: and it's connected to two low pass filters
04:26 PM Emil: And there is no input power supply
04:27 PM bss36504: I'll give them a pass on no input supply.
04:27 PM bss36504: It's not like it's a technically accurate schematic
04:27 PM Emil: I know
04:27 PM DaRkV0rt3X: So, what you guys think about my question?
04:27 PM Emil: but usually typical operating circuits are super easy to understand
04:27 PM DaRkV0rt3X: Is it supposed to be needed to set them as input?
04:27 PM DaRkV0rt3X: I did it
04:27 PM bss36504: Yeah, just stop being dumb, Emil ;)
04:27 PM DaRkV0rt3X: but not sure if it was needed
04:27 PM Emil: bss36504: T.T
04:28 PM bss36504: gotta go, ttyl yall
04:28 PM Emil: bss36504: cya
04:28 PM DaRkV0rt3X: cya laterzz
04:28 PM Emil: DaRkV0rt3X: yeah set the pin as input
04:28 PM Emil: DaRkV0rt3X: also remember to zero the pullup
04:29 PM DaRkV0rt3X: Emil: by software or hardware?
04:29 PM DaRkV0rt3X: I mean, I did nothing else than to set up the ADC as the datasheet suggests plus setting ADC0 and ADC1 as input
04:30 PM DaRkV0rt3X: DDRC &= ~(1 << OAF_OUT); // Set ADC0 as input
04:30 PM DaRkV0rt3X: DDRC &= ~(1 << OAR_OUT); // Set ADC1 as input
04:30 PM DaRkV0rt3X: where OAF_OUT is ADC0
04:30 PM DaRkV0rt3X: and AOR_OUT is ADC1
04:31 PM Emil: why not do the in the same step btw?
04:32 PM Emil: DaRkV0rt3X: if you used those pins as output previously oyu might have the pullup set
04:32 PM Emil: you should also clear the PORTx register
04:32 PM Emil: for those pins
04:32 PM Emil: to disable the pullup
04:32 PM Emil: But this assumes that you used those pins previously
04:32 PM Emil: if you have not you don't have to do anything
04:33 PM Emil: DaRkV0rt3X: to use the ADC you have to configure ADMUX, ADCSRA and ADCSRB
04:34 PM Emil: Assuming you are using 328pb
04:34 PM Emil: 328p*
04:36 PM DaRkV0rt3X: I think that's what I have
04:36 PM DaRkV0rt3X: ADCSRA |= (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0);
04:36 PM DaRkV0rt3X: ADMUX |= (1 << REFS0);
04:36 PM DaRkV0rt3X: PRR &= ~(1 << PRADC);
04:37 PM DaRkV0rt3X: ADMUX &= ~(1 << ADLAR);
04:37 PM DaRkV0rt3X: ADMUX |= (1 << adc_ch);
04:37 PM DaRkV0rt3X: ADCSRA |= (1 << ADEN);
04:37 PM DaRkV0rt3X: ADCSRA |= (1 << ADSC);
04:37 PM DaRkV0rt3X: This is what I'm using
04:37 PM DaRkV0rt3X: adc_ch is to be able to change ADC channel where I'm reading
04:37 PM Emil: You can't edit ADCSRA after starting ADC iirc
04:38 PM DaRkV0rt3X: PRR is to set Single Mode
04:38 PM Emil: the change doesn't take effect
04:38 PM DaRkV0rt3X: hum
04:38 PM Emil: Also, why not configure them in a single line
04:38 PM DaRkV0rt3X: Need to read about that then
04:38 PM DaRkV0rt3X: Those lines are in 2 different functions
04:38 PM Emil: Also what is PRR?
04:38 PM DaRkV0rt3X: Single mode
04:39 PM DaRkV0rt3X: That register is about Power Reduction Mode
04:39 PM DaRkV0rt3X: but needs to be unset to select Single Mode
04:39 PM Emil: matey
04:39 PM DaRkV0rt3X: If I understood correctly what I've been explained
04:39 PM Emil: why are you unnecessarily editing it? :D
04:39 PM Emil: Unless you change it somewhere else
04:40 PM DaRkV0rt3X: I don't know in which mode the ADC is if I don't set it up like that
04:40 PM DaRkV0rt3X: so I set that bit also
04:40 PM Emil: ...
04:40 PM Emil: Stop
04:40 PM Emil: All registers start at 0 unless noted otherwise
04:40 PM Emil: They are cleared by hardware
04:41 PM Emil: It introduces unnecessary complexity and information into your code if you fiddle with everything when it's not needed
04:41 PM DaRkV0rt3X: hum, ok
04:41 PM DaRkV0rt3X: I followed some guide I found in AVR Freaks forum
04:42 PM DaRkV0rt3X: and they used Free Running mode
04:42 PM DaRkV0rt3X: but I didn't wnated to use that mode
04:42 PM DaRkV0rt3X: so I explicitely unset that bit
04:42 PM DaRkV0rt3X: I need to read about that what you said
04:42 PM DaRkV0rt3X: about not being possible to change channel
04:42 PM Emil: don't enable the autotrigger if you don't want to use the autotrigger
04:43 PM Emil: no need to touch PRR
04:43 PM DaRkV0rt3X: What bit is auto-trigger?
04:43 PM DaRkV0rt3X: autotrigger*
04:43 PM DaRkV0rt3X: Ah, you mean the Free Running mode?
04:44 PM Emil: The ADC is in single mode by default
04:44 PM Emil: if you want auto trigger you enable that
04:44 PM Emil: Which probably just sets ADATE
04:46 PM Emil: Sorry
04:46 PM Emil: ADSC
04:47 PM Emil: Also you can of course start conversion after enabling adc
04:47 PM Emil: It might be that someone just told me lies about not being able to edit ADCSRA after enabling it or something
04:48 PM Emil: But usually registers are set in a single go
04:48 PM DaRkV0rt3X: ok
04:48 PM DaRkV0rt3X: but from those lines I pasted here
04:48 PM DaRkV0rt3X: the last 3 are in a different function
04:48 PM DaRkV0rt3X: that's why they are not set in a single line
04:48 PM Emil: ah
04:48 PM DaRkV0rt3X: but I need to figre out that about changing channel
04:49 PM Emil: to change a channel you just write another value to admux
04:49 PM Emil: the first read might be trash depending on your source
04:49 PM DaRkV0rt3X: It's like I set the bits I need to set and stick with them
04:49 PM DaRkV0rt3X: then in another function
04:49 PM DaRkV0rt3X: I send the channel I want to read
04:49 PM DaRkV0rt3X: and set ADMUX according to that parameter
04:49 PM Emil: yeah that's fine
04:49 PM DaRkV0rt3X: then I start the conversion
04:50 PM DaRkV0rt3X: and enable the conversion
04:50 PM DaRkV0rt3X: or better the other way around
04:50 PM DaRkV0rt3X: enable the conversion and start it after enabling
04:50 PM DaRkV0rt3X: void adc_start(uint8_t adc_ch){
04:50 PM DaRkV0rt3X: ADMUX |= (1 << adc_ch);
04:50 PM DaRkV0rt3X: ADCSRA |= (1 << ADEN);
04:51 PM DaRkV0rt3X: ADCSRA |= (1 << ADSC);
04:51 PM DaRkV0rt3X: }
04:51 PM Emil: DaRkV0rt3X: matey
04:51 PM Emil: You can't just OR ADMUX
04:51 PM DaRkV0rt3X: maybe I could shrink that to two lines
04:51 PM DaRkV0rt3X: no?
04:51 PM Emil: You need to clear the previous bits from there, too ;)
04:51 PM DaRkV0rt3X: hum, ok
04:51 PM Emil: what does 0b00000001|2 do?
04:52 PM DaRkV0rt3X: 0b00000011 I guess
04:52 PM Emil: it results in 0b00000011 and not 0b00000010
04:52 PM Emil: yeah
04:52 PM DaRkV0rt3X: hum, ok I see
04:52 PM Emil: so to edit just the ADMUX channelk
04:52 PM DaRkV0rt3X: that's probably why I'm not getting anything out of the ADC
04:53 PM Emil: you need to do something like ADMUX=(ADMUX&UPPERNIBLE)|(CHANNEL&LOWERNIBBLE);
04:53 PM Emil: You don't need the lowernibble and if you make sure CHANNEL is always within reason
04:54 PM Emil: Uppernible is 255-15 and lower nibble is 15
04:54 PM Emil: 0b11110000 and 0b00001111 respectively
04:54 PM Emil: or 0xF0 and 0x0F
04:57 PM DaRkV0rt3X: that needs some attention by me
04:57 PM DaRkV0rt3X: :|
05:16 PM DaRkV0rt3X: Emil: thanks for those tips
05:16 PM DaRkV0rt3X: I'm going to think a bit about them
05:16 PM DaRkV0rt3X: and try to change my code according to that
05:23 PM Emil: Np
10:12 PM enh: Good night
11:02 PM ferdna: i have a question, maybe unrelated to this channel...
11:03 PM ferdna: i am trying to load firmware to my board, but it seems that the firmware starts at 0x08003000 instead of 0x08000000
11:04 PM ferdna: and i believe that is an error from the publisher
11:04 PM ferdna: but i am not 100% sure...
11:04 PM ferdna: https://imgur.com/a/7XG7q
11:31 PM rue_house: did you use my makefile?