Back
[01:25:00] <vsync_> templeos guy amazing again, the train of thought was something like
[01:26:00] <vsync_> "my therapist says i'm not a neuroscientist" "he's a fucking moron, has he never heard of PLLs?" "he's a fucking moron ... nigger" .. then he proceeds to grab some random timer output -> "we'll take the last 5 numbers and go to the bible"
[04:24:09] <inflex> lo folks
[04:24:13] <vsync_> lo
[04:24:27] <inflex> quiet around here
[04:24:45] <inflex> all the 'trendy' participants moved on to Pi and STM's now?
[04:26:22] <inflex> Does this mean we can get back to programming AVRs with C and ASM, instead of that arduino stuff?
[04:26:58] * inflex goes back to screaming at kids to get off his lawn.. and tinkering with tiny10's and 555's on veroboard ;)
[05:17:38] <vsync_> inflex: i don't think the broke people switch over to stm
[05:18:31] <vsync_> atmel studio's too nice, stm doesn't provide anything
[05:19:13] <vsync_> you want something like crossworks, and then that's a lotta $$$... AS is great, even if you won't get KEIL... really
[05:19:37] <vsync_> crossworks, or ewarm ;(
[05:21:39] <vsync_> just stupid how atmel's devboards are 3-5x the price of stm's
[05:26:56] <twnqx> atmel studio is... crap
[05:27:09] <twnqx> it's windows software, can't be useful by choice of OS
[05:31:27] <Roklobsta> inflex: yes i have stm32 board now
[05:48:33] <vsync_> twnqx: well, there are alternatives for linux, but it's not _crap_.
[05:48:43] <vsync_> and mac users can go fuck themselves, pmuch
[05:50:53] * inflex is fine with AVR + linux toolchain
[05:50:59] <wulax> Could someone recommend a good free real-time kernel with preemption and some nice scheduler? Just for messing around.
[05:51:20] <twnqx> ... on avr 8bit? :S
[05:51:30] <inflex> not sure anything I've ever designed would fill more than a mega 168
[05:51:31] <RattusRattus> vsync_: why would a mac user be doing hardware / software development? lets face it they are conditioned to do waht apple tell them they should do, with apps apple have given them.
[05:52:33] <wulax> twnqx: sure, there seem to be several with avr support
https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems
[05:52:45] <twnqx> there are, sure
[05:53:16] <twnqx> and i admit, out of curiosity i looked at how they work
[05:53:20] <RattusRattus> wulax: the choice is based on what you want to achive. good for job x is not always good for job y
[05:53:23] <twnqx> and decided not to use them :P
[05:53:40] <twnqx> "context switch" latency on avr is so horrid...
[05:53:43] <vsync_> most software "engineers" (lol, resent the word software being used in conjunction with engineering) use macs... because. I don't know why
[05:54:10] <vsync_> you can get the coolest apps and colors
[05:54:17] <wulax> RattusRattus: I want to achieve learning :-)
[05:54:17] <inflex> haha
[05:54:22] <vsync_> i guess it's a design thing
[05:54:27] <wulax> Maybe I should try writing my own
[05:54:34] <RattusRattus> wulax: then start by writing your own scheduler
[05:54:34] <inflex> I'm technically a SE, but hate the term too. I do not believe that writing software is the same as engineering
[05:54:44] <inflex> otoh, electronics/electrical engineering is more apt
[05:54:44] <twnqx> wulax: the most minimal ones that do nothing else are superbly simple
[05:55:07] <vsync_> inflex: yup
[05:55:07] <wulax> Alright, thanks twnqx RattusRattus
[05:55:12] <twnqx> timer interrupt, save all registers to the current context, load all from the new context, return from interrupt
[05:55:27] * RattusRattus suspects that you don't want an OS, just a scheduler and perhaps some semaphores and messaging....
[05:55:37] <wulax> RattusRattus: yes
[05:55:52] <twnqx> iirc i looked at freertos
[05:57:26] * RattusRattus racks brain trying to remember the right books to recomend.... almost cirtainly it will be by Jack G. Ganssle
[05:58:18] <RattusRattus> http://www.amazon.co.uk/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=Jack%20Ganssle
[05:58:53] <Roklobsta> instead of trying to learn freertos i made my own premptive scheduler for avr. way too many pushes and pops though.
[05:59:42] <wulax> Looks interesting RattusRattus
[06:00:11] <RattusRattus> IIRC
http://www.amazon.co.uk/Art-Programming-Embedded-Systems/dp/0122748808/ref=sr_1_6?ie=UTF8&qid=1426156638&sr=8-6&keywords=Jack+Ganssle
[06:01:05] <RattusRattus> 2nd hand at £5.50 is pretty good. old book so covers small embedded systems (as opposed to a full blown OS on a 1GHz SoC)
[06:01:42] <RattusRattus> I have a lot of his books.... and keep going back to them
[06:06:00] <wulax> My uni recommended
http://www.amazon.com/Real-Time-Systems-Programming-Languages-International/dp/0321417453 for a real-time programming course we took. I never got to read it since it was sold out pretty much everywhere affordable here. :-|
[06:06:09] <Roklobsta> read ths
http://wiki.osdev.org/Getting_Started
[06:07:22] <wulax> Well, I have to go. Thanks for the book recommendations.
[06:15:21] <proteusguy> You really only need pre-emptive scheduling when you don't have full control/awareness of what's running on your system. I doubt that is ever the case for an avr environment. Generally you might have one or two (at the most) items that need to pre-empt other parts of the system and that can still be checked co-orperatively at a guaranteed frequency to ensure real-time responsiveness.
[06:16:51] <LeoNerd> preëmption is a really really hard structure to work with
[06:16:57] <LeoNerd> Far easier is to write almost anything else
[06:17:29] <proteusguy> I'd recommend writing code using co-routines which are easy to implement in asm and don't have all the call structure and process saving overhead.
[06:19:04] <proteusguy> You can look up continuations as well for a style of resuming work where a function left off that doesn't require any of the normal overhead that an "RTOS" might require for threads/processes.
[06:21:24] <LeoNerd> That's all somewhat nontrivial to implement on an AVR; doubly so from C
[06:27:16] <RattusRattus> LeoNerd I disagree - preemption is no more dificalt that round robin or any other scheduler schema to implement. all require a context switch, and getting that right is the hard part
[06:27:33] <LeoNerd> RattusRattus: Yes. The ctx switch is the _really_ hard bit to implement on AVR
[06:28:14] <RattusRattus> and of cause you need to define your ABI and STICK to it :-)
[06:29:55] * RattusRattus must be wired up wrong. I think schedulers are fun :-)
[06:51:20] <proteusguy> RattusRattus, sure context switching is not difficult to implement but compared to what? You're paying a lot in overhead complexity and cycles and guaranteeing that you will, at best, get soft-real time rather than hard real-time.
[06:52:16] <proteusguy> If you're trying to coordinate dozens of threads of various priorities than pre-emptive multitasking makes sense. A general use computer like a desktop or laptop needs that. But for an avr embedded app I haven't seen the use case that makes sense for it at all.
[06:53:00] <LeoNerd> Indeed. E.g. my ATtiny84-based radio module uses a little event loop using a primitive inspired by ppoll()
[06:55:14] <Lambda_Aurigae> played with a couple of RTOSs a while back...never found a good use for them.
[06:56:20] <RattusRattus> proteusguy I think you have missed what I was saying. I made the claime that Preemption is no more dificalt than any other form of scheduling. I did not say that having a scheduler to switch dozens of threads would be the correct way to go on an avr embedded app.
[06:58:14] <RattusRattus> indeed on most designs I put togeather that require some real time componant I will dedicate a small MCU (more often than not an AVR) to the task. then I use a larger SoC running a full blown OS as the general compute engine, mass storeage, analitics and UI
[07:03:06] <RattusRattus> but I will aslo ask what you mean by hard and soft real time.... I find the terms get overloaded and mean differant things to differant people. I use them to mean (a) hard real time. predictable, garenteed performance within pre-allocated slots and (b) soft real time - task is compleated within the required time frame, but exactly when the task happens, and how long it takes (provided it is still within required time frame) is not predictable ...
[07:03:13] <RattusRattus> ... (or does not need to be predicted for the given case)
[07:05:11] <proteusguy> RattusRattus, but it is far more difficult than not needing scheduling at all. :) Which using co-routines you effectively implement an event-based system that works within a single thread of execution. You don't need an OS at all. Go bare metal and simple.
[07:05:42] <RattusRattus> indeed but that was not the question at hand
[07:06:19] <RattusRattus> I don't think I am arguing against you....
[07:06:46] <proteusguy> RattusRattus, if your question was purely theoretical than I understand. If your question was practical then I expect you're asking the wrong question. ;) (no worries... it's a good discussion)
[07:09:03] <RattusRattus> not my question.... thread started at approx 10:30 in responce to 2015-03-12 10:30 GMT < wulax> Could someone recommend a good free real-time kernel with preemption and some nice scheduler? Just for messing around.
[09:29:14] <rue_house> I'm gonna assume thats not for an 8 bit avr
[09:30:58] <proteusguy> RattusRattus, ah I see... yes I missed the initial starting question.
[09:37:28] <RattusRattus> no problem
[10:09:58] <Steffanx> Where's this rikusw guy?
[10:12:19] <LeoNerd> He pops in from time to time
[10:12:35] <LeoNerd> He's often not around... Usually most vexingly when I'm after him for something :P
[10:24:55] <Steffanx> used to talk with him once i a while, but haven't done that lately :)
[10:25:00] <Steffanx> * :(
[13:28:51] <silbo> jo
[13:30:19] <silbo> how to find a 3.3V zener diode lol
[13:30:46] <silbo> was trying to measure the breakdown voltage and trying to decrypt the text on them, no luck
[15:32:30] <DKordic`> silbo: Hello. Maybe I can help. What text? URL? You mean how to buy it?
[15:39:21] <wulax> I think he means he has a box of unsorted diodes and wants to find one that meets the specs...
[15:39:52] <DKordic`> wulax: Oh, thanks.
[15:44:56] <silbo> DKordic`: I am just googling names now what I found here
[15:44:59] <silbo> will figure it out
[16:28:03] <silbo> is it important ot have 3.3 or 3.6v zeners here
http://codeandlife.com/wp-content/uploads/2012/03/schematic.png
[16:30:49] <malinus> silbo: what do you think?
[16:31:12] <silbo> I mean I have 3V zeners
[16:31:19] <silbo> should also work I think
[16:36:39] <silbo> epic it works :D !
[16:36:47] <silbo> mouse was going randomly on screen lol
[16:37:12] <malinus> silbo: worked with 3v on data lines?
[16:38:43] <silbo> malinus: 5v
[16:38:57] <silbo> malinus: I power everything from USB
[16:38:59] <malinus> you have 5V on usb data lines?
[16:39:19] <silbo> I tought it should be 5 right ?
[16:44:14] <malinus> silbo: what do you think the diodes do?
[16:47:04] <silbo> I am a electronics noob sorry
[16:47:15] <silbo> ok they cut the signals to 3V >D
[16:57:29] <DKordic``> silbo: Can You calculate aproximately how much current will PB2 source when high?
[17:16:19] <durrrp> hello i have one silly question
[17:16:35] <durrrp> is there any way to heat up avr (besides powering it from wrong pins)?
[17:17:36] <durrrp> i know that running some bigger processes (cpuburn,stress) heat up normal x86/x86_64 cpu
[17:21:24] <Xark> durrrp: If you kept it really busy at ~20MHz you *might* be able to notice a bit of warmth. Nothing like x86 though. :)
[17:22:14] <LeoNerd> I've never seen anyone put a heatsink on an AT{tiny,mega,Xmega} chip
[17:22:24] <LeoNerd> That may help answer your question
[17:23:24] <Xark> Pretty much designed to run flat-out in a dishwasher (or whatever) without getting warm.
[17:24:23] <LeoNerd> I've never known a chip to warm up at all even on 100% CPU spin
[17:24:27] <silbo> DKordic`: 3.3v and 83ohm ? 36 mA ?
[17:24:39] <LeoNerd> SLEEP is for preserving battery life, not for "make the chip not melt" :)
[17:24:42] <silbo> or 5V
[17:25:08] <specing> meh AVR
[17:25:17] <specing> 16 MHz in 2015
[17:25:18] <specing> come on
[17:25:31] <Xark> specing: It is 20MHz. :)
[17:26:24] <DKordic``> specing: Good enough :) .
[17:27:43] <specing> cortex-m goes to 200 MHz
[17:29:41] <specing> 450 DMIPS
[17:36:43] <Lambda_Aurigae> I've run 20MHz AVRs at 33MHz and had them heat up quite a bit.
[17:37:03] <Lambda_Aurigae> and if you draw too much current through the I/O pins they can overheat.
[17:39:15] <durrrp> so, heating them up into 50-60C is basically not possible?
[17:40:01] <Lambda_Aurigae> oh, it is possible.
[17:40:13] <Lambda_Aurigae> but if you remain within operating specifications, it shouldn't happen.
[17:41:49] <Lambda_Aurigae> specing, hey, I can browse the web on my C-64 at 1MHz! 16MHz rocks!
[17:43:05] <durrrp> anyway, thanks for the answers :)
[17:45:49] <specing> Lambda_Aurigae: I can outbrowse you by a factor of 4000
[17:45:56] <Lambda_Aurigae> probably.
[17:46:06] <DKordic``> silbo: Acording to schematic.png: VCC = 5V, zener: V_ZD = 3.6V, R1 = 68ohm. I_PB2 = (VCC - V_ZD) / R1 = 20.6mA. Calculations are very inaccurate but still more than maximum GPIO source current! Or am I wrong?
[17:46:38] <Lambda_Aurigae> DKordic``, and you have just hit on one of the biggest problems with v-usb.
[17:48:00] <DKordic``> Lambda_Aurigae: I still don't see it :) . Transient currents?
[17:48:38] <Lambda_Aurigae> generally the pulses on those pins are short enough that you don't have to worry about the max current draw.
[17:50:41] * Lambda_Aurigae must learn to fully read people's nicks
[17:50:54] <Lambda_Aurigae> somehow my mind added an extra "t" in there.
[18:23:14] <LeoNerd> ATtiny84. (8Ki flash, 512 bytes RAM): How afraid of function pointers should I be?
[18:24:50] <LeoNerd> Ideally I'd like a future/promise/thing, but that's going to be tricky... so just passing in a function pointer as a kind of continuation is sortof the next best thing
[18:28:59] <specing> LeoNerd: ?
[18:29:22] <specing> what do function pointers have to do with amount of FLASH and RAM?
[18:29:39] <LeoNerd> Space considerations?
[18:29:49] <LeoNerd> Just thinking about what's the nicest way to do this
[18:30:54] <specing> C and function pointers sounds like a great way to do UB
[18:31:07] <Lambda_Aurigae> UB?
[18:36:53] <specing> undefined behaviour
[18:38:29] <twnqx> nothing wrong with function pointers
[18:40:11] <Lambda_Aurigae> oh.
[18:40:35] <Lambda_Aurigae> yeah...we used to use structs of pointers to functions and pointers to variables before object oriented languages existed.
[18:40:53] <specing> in the context of C, no. In the context of world, C is an extremely crappy language that gives you a nuke to shoot yourself in the foot with.
[18:41:02] <Lambda_Aurigae> yup.
[18:41:09] <Lambda_Aurigae> we did that in C actually.
[18:41:31] <Lambda_Aurigae> before I knew about C++...probably before C++ was available.
[18:41:49] <Lambda_Aurigae> it was back in 1988, 1989ish
[18:41:52] <specing> C++ just adds a whole new set of problems above C
[18:42:09] <Lambda_Aurigae> yeah.
[18:42:13] <specing> I am very close to having a working Ada crosscompiler for AVR
[18:42:15] <Lambda_Aurigae> I never liked C++.
[18:42:30] <Lambda_Aurigae> I thought you could compile ada compiler into gcc.
[18:42:57] <Lambda_Aurigae> never cared for ada myself though.
[18:43:05] <Lambda_Aurigae> I'm an old C weenie from way back.
[18:43:15] <Lambda_Aurigae> military tried to make us convert stuff to ada back in the day.
[18:43:21] <Lambda_Aurigae> what a clusterfuck that was.
[18:43:38] <Lambda_Aurigae> pascal, fortran, and C...converted to ada..
[18:43:52] <Lambda_Aurigae> millions of man hours wasted.
[18:44:23] <Lambda_Aurigae> specially when they finally decided that it didn't provide any advantage and let us go back to the old ways.
[18:45:02] <specing> How come it didn't provide any advantage?
[18:45:33] <Lambda_Aurigae> well, for starters most of the converted programs had issues.
[18:45:42] <specing> and yes, Im trying on getting the GCC Ada compiler working
[18:45:58] <Lambda_Aurigae> as we didn't know ada well enough to do a proper conversions.
[18:47:17] <Lambda_Aurigae> and the ada compilers of the time were nowhere near optimized enough so the stuff that did get converted didn't run as well...the code ended up being rather convoluted to just make things work.
[18:47:42] <Lambda_Aurigae> I'm sure modern ada compiler would be much better...and people with plenty of experience writing ada code too.
[18:48:14] <Lambda_Aurigae> it was one of those government knee jerk decisions....convert everything to this new programming language and it will be much better!....
[18:49:53] <specing> it would probably work if they trained people
[18:50:01] <Lambda_Aurigae> oh, they trained us.
[18:50:10] <Lambda_Aurigae> but it takes experience too.
[18:50:14] <Lambda_Aurigae> that we didn't have.
[18:51:00] <Lambda_Aurigae> heck, me and several of the guys I worked with actually went to a local university to take ada programming classes.
[18:51:13] <Lambda_Aurigae> paid for by ye olde US Military.
