Back
[01:18:31] <Jartza> morning
[01:35:20] <cehteh> cold morning
[03:21:47] <Martin90> Is it possible to perform context switching on uCs like Atmega16a ?
[03:21:58] <Martin90> I mean how much I can do to simultae RTOS ?
[03:25:28] <jacekowski> quite a lot
[03:25:50] <jacekowski> google it
[03:25:58] <jacekowski> there are few operating systems running on avr's
[03:29:22] <Martin90> no I want to write my own
[03:29:59] <Martin90> I now there are systems but can we do more than just priority queue ?
[03:30:15] <Martin90> I am thinking about context switching and threads ?
[04:04:01] <Flutterbat> Martin90: what is stopping you from jumping around in your code?
[04:09:25] <Martin90> Flutterbat, well it's not that I just want to squeeze as much as possible from that uC
[04:09:33] <Martin90> writting osmek ind of OS
[04:23:00] <Flutterbat> Martin90: the main issue i see is, while you work at 'Y', the current state of 'X' needs to be kept somewhere, which is most likely increasing the RAM requirements, unless you waste extra time on moving the content somewhere else
[04:25:59] <Martin90> Flutterbat, yes I wonder abbout context switching on Atmega16
[04:26:10] <Martin90> how much I can do in this matter
[04:41:56] <cehteh> Martin90: i am working on a scheduler which calls functions from different queues (timer, realtime, background), with some limited support for calling the scheduler recursively for context switches.
[04:42:46] <cehteh> there are some 'full' implementations (rtos) for context switching available, but thats rather heavyweight when you consider that µC have quite limited RAM
[04:43:02] <Martin90> yes I know
[04:43:38] <Martin90> well I wrote priority queue as a main scheduler for my needs and it works nice
[04:43:54] <cehteh> yes same here
[04:44:04] <Martin90> do you have your implementation somewhere online ?
[04:44:26] <cehteh> yes git://git.pipapo.org/muos
[04:44:40] <cehteh> (i hope that url is right :D)
[04:45:45] <cehteh> very work in progress
[04:46:52] <Martin90> heh, do you have "normal" link
[04:47:01] <cehteh> no git there?
[04:47:07] <Martin90> no
[04:47:19] <cehteh> then install it :D
[04:48:06] <cehteh> well .. gitweb is at
http://git.pipapo.org/?p=muos
[04:48:46] <Martin90> is it this ->
https://github.com/zlj578/muos ?
[04:48:58] <cehteh> no
[04:49:11] <cehteh> heh funny didnt know that name is already taken
[04:49:13] <cehteh> damnit
[04:49:28] <Martin90> ;)
[04:49:38] <cehteh> i should start to use uuid's as project names
[04:51:25] <cehteh> anyway .. git, makefile, linux toolchain. i guess you are on windows, i havent cared yet to make it compileable from windows
[04:51:48] <cehteh> source is GPL
[04:53:53] <cehteh> currently the example binary is around 2500-3000 bytes, depending on what options are enabled, ram usage can be trimmed down to just a few bytes (not tested yet, i am planning to use it on a tiny85 as well)
[04:54:08] <Martin90> btw, what is "nicer cursor movemen" ?
[04:54:59] <cehteh> i added a 'line editor' for the serial console, improved a few terminal control sequences there
[04:55:48] <cehteh> master branch is a bit behind, i am working on the devel branch, but had no much time past days
[04:57:26] <cehteh> a txqueue comes next, queuing data for transmission in a smaller binary format instead bytes
[05:02:33] <Martin90> for what uC is it dedicated ?
[05:06:43] <cehteh> currently i develop on a atmega 328p (arduino nano) .. but eventually it should become portable, to most avr's (except for the smallest tinys) and possibly to embedded arm cores (stm32) as well
[05:07:02] <cehteh> but its more a fun and hack on demand thing, i just add whatever i need
[05:07:40] <cehteh> if anyone else wants to join the project, would be nice, i'd gladly accept any patches which improve it and make it more portable
[05:11:41] <cehteh> ..gtg, cu later
[05:13:05] <_abc_> Now that Mchip is buying Atmel, all sorts of bad old things are going to rear their ugly little faces again? Ref:
http://dangerousprototypes.com/2011/08/30/editorial-our-friend-microchip-and-open-source -- all comments are valid
[05:13:22] <_abc_> What does one expect to happen? Vanishing products and datasheets?
[05:13:41] <_abc_> No support for studio/etc?
[05:22:36] <Jartza> Martin90: well, context switching is possible. I made very crude & simple context switching led blinker for attiny85 just for fun
[05:26:41] <_abc_> In the package/file imavr-2.1.tgz/imavr/example/threads you can find an example of preemptive and cooperative thread / multitasking code by Brian S. Dean (aka abcminiuser here) -- note I am not him!
[05:27:26] <_abc_> Which covers context switching and pretty neat support for it in any gcc-avr source, with a small asm snippet to do the dirty work.
[05:27:33] <Jartza> https://gist.github.com/Jartza/3b869fa4b6a4afcc19b2
[05:27:40] <Jartza> that's very quick and dirty
[05:27:43] <_abc_> Has there been a discussion here on the Mchip buyout of Atmel yet?
[05:27:49] <Martin90> Jartza, heh do you have code somehwere online ?
[05:27:59] <Jartza> Martin90: see above
[05:28:13] <Jartza> _abc_: yeah, that's much more complete and nicer way :)
[05:28:18] <Martin90> ok I will check it
[05:28:37] <Jartza> mine is just switching between two tasks
[05:30:35] <Jartza> my example blinks two leds (visually) at the same time :)
[05:30:46] <Jartza> of course it could do something else too
[05:30:50] <_abc_> Isn't that kind of interrupt table manipulation a little dangerous?
[05:31:01] <_abc_> There is a specific way to return from interrupt, no?
[05:31:48] <_abc_> Because in C the caller must clean out the callee's stack and such?
[05:31:53] <Jartza> when interrupt happens, avr pushes the return address to stack
[05:32:11] <_abc_> And in an isr called like that bad things can happen if you allocate any local variables in the isr code?
[05:32:37] <Jartza> nope
[05:32:41] <_abc_> 0x1DD is what?
[05:32:43] <Jartza> both task has their own stack
[05:33:35] <_abc_> Jartza: Yes but BP is pointing at something wrong when entering an isr like that and any use of local vars could cause havoc. Have you tried to define a local var in an isr and use it? Does it still work? local var in task2?
[05:34:03] <Jartza> sure it works
[05:34:08] <_abc_> okay
[05:34:26] <_abc_> Then Mr. Dean overdid it in his example, which takes special care with that?
[05:35:13] <_abc_> See imavr-2.1.tgz/imavr/example/threads/thread_swtch.S
[05:35:40] <_abc_> Basically your code seems to work because gcc aggressively removes all indirect/BP based argument and locals access Jartza
[05:35:43] <_abc_> Or so I feel.
[05:36:09] <Jartza> the switcher pushes all registers to stack of interrupted task, stores the stack pointer, switches stack address to point to the other task's stack, pulls registers back from that stack and returns. now that the stack has changed to other task's stack, the return address also takes care of returning to correct place
[05:36:17] <_abc_> Also calling delay_ms() in an isr is really asking for trouble imho. Amazing it works.
[05:36:37] <_abc_> Jartza: your switcher or Dean's?
[05:36:42] <Jartza> mine
[05:36:56] <_abc_> Ah I missed task.S ;)
[05:37:01] <Jartza> yea
[05:37:07] <Jartza> that's the switcher
[05:37:07] <_abc_> I thought you only used the C file. Sigh.
[05:37:11] <_abc_> I apologize ;)
[05:37:14] <Jartza> oh, no :)
[05:37:27] <_abc_> There *is* a clean C task switcher written in... turbo C.
[05:37:40] <_abc_> Which uses the fact that one has register access in turbo C.
[05:37:51] <_abc_> I thought this was like that for a moment.
[05:38:07] <Jartza> the lines 56-59 in the C file are just ugly way of initializing the task_2 to be run as soon as we get first interrupt while in task_1 :)
[05:38:18] <_abc_> Yes I saw that.
[05:38:42] <_abc_> Also saving all registers is very wasteful. It is more useful to save only a subset in your case, since you want lightweight.
[05:39:31] <Jartza> sure
[05:39:50] <Jartza> that was just an example made for a friend while I explained context switching to him
[05:40:01] <Jartza> attiny85 was nice tool for that as I had one on breadboard ready :)
[05:40:24] <Jartza> it wasn't made for any practical purpose other than that
[05:58:27] <Martin90> Jartza, I will be back with comment on that later ;)
[06:09:22] <Jartza> Martin90: yea, just remember that's quick'n'dirty example
[06:10:58] <Martin90> ok, no problem ;
[06:25:04] <nikomo> https://goo.gl/photos/FzfKBHjnqNjkHE3z8 if I get these done today, I might have some fun with the attiny85 :3
[06:26:39] <Martin90> nikomo, take solder in hand and go fo it ;)
[06:26:58] <nikomo> Martin90: going to try and make soldermask + silkscreen when I get home
[06:27:08] <nikomo> that's why I have 4 of them :P
[06:28:56] <nuxil> nikomo, what are thouse boards for?
[06:29:14] * Martin90 have bad experience with home-made silkscreen
[06:30:01] <nikomo> nuxil: attiny85 + programming header + voltage reg, straight to breadboard
[06:30:02] <nuxil> i mean. what you gonna do with them except put a tiny85 on them
[06:30:12] <nuxil> ok
[06:30:16] <nikomo> so I don't have to wire up the programmer with male-male cables etc.
[06:32:13] <nikomo> oh hey - does the AVRISP mkII supply power to target? teacher had a problem with programming an AVR chip with one of those, but I haven't used one so idk
[06:33:34] <nikomo> I was thinking the VCC pin is just for sensing voltage. my usbtinyisp has a jumper to connect +5V to the VCC pin
[06:39:24] <nuxil> no idea
[06:40:05] <Tom_itx> your teacher should put a meter on the pins and see
[06:40:15] <Tom_itx> but i don't think it does
[06:53:57] <nikomo> the demoboard I made for him yesterday, I put a 7805 on there, just in case
[07:03:24] <nuxil> Jartza,
[07:03:27] <nuxil> (*(volatile unsigned char *)0x1DD) = 128;
[07:03:31] <nuxil> woot is that doing ???
[07:11:11] <_abc_> Sets the content of ram address 0x1DD to 128
[07:28:57] <Jartza> yes
[07:29:09] <Jartza> it stores "fake SREG" into stack
[07:29:17] <Jartza> basically, it stores the I bit
[07:29:26] <Jartza> otherwise task_2 would have interrupts disabled
[07:29:41] <Jartza> because AVR interrupts aren't nesting
[07:33:12] <Jartza> and I'm actually using separate SREG for both tasks too, just for completeness
[07:33:56] <Jartza> of course if you're making a "real context switching multitasking" you should have some kind of nice "create task" function
[07:34:05] <Jartza> my code was just quickn'n'dirty. especially the dirty-part.
[07:34:35] <Jartza> nikomo: depends of the avr isp mk2, is it "real one" or some clone?
[07:35:03] <Jartza> I had one from Olimex, which did provide power to ISP connector
[07:35:11] <Jartza> and there was a jumper to select either 3.3V or 5V
[07:35:15] <nikomo> Jartza: it's a real one from Atmel, teacher bought it directly from them
[07:35:59] <Jartza> ahh. I think that only uses VCC to sense the voltage, as it has internal level shifter (supports 1.8 - 5.5V)
[07:36:33] <Jartza> though I'm not 100% sure
[07:38:04] <Jartza> "The AVRISP mkII does not provide power on the Vcc pin, but uses this pin to sense the voltage on the target circuitry. Your circuit needs to be powered by external means to operate.
[07:38:09] <Jartza> straight from the manual
[07:38:21] <Jartza> http://www.atmel.com/webdoc/avrispmkii/avrispmkii.intro_connecting.html
[07:39:12] <Jartza> https://www.olimex.com/Products/AVR/Programmers/AVR-ISP-MK2/open-source-hardware
[07:39:27] <Jartza> this worked nicely. unfortunately I gave that programmer to Tagsu Manufacturer :)
[07:39:54] <nikomo> Jartza: nice
[07:39:56] <nikomo> lol
[07:42:04] <Jartza> also, that's much cheaper than atmel version :)
[08:06:50] <nikomo> Jartza: kinda wish I had something that could do debug, but it's not strictly necessary
[08:34:13] <Banai> anyone here familiar with msp430 ?
[08:34:41] <Banai> I'm trying to use inputs on Port 2, aswell as outputs on Port2, but for some unknown reason-inputs don't work
[08:34:52] <Banai> I got inputs and outputs to work on Port 1
[08:42:07] <nuxil> no idea. is it a bidirectional port? also we cant read your mind, so we dont know how your code looks like?
[08:50:24] <Banai> nuxil- here is the code I use to initialise the port
[08:50:26] <Banai> http://pastebin.com/7BAXHFsg
[08:56:25] <nuxil> heh. you have better hope with someone else. i have no idea about the msp430, and im not going to dig though the datasheet for it. sorry.
[08:56:41] <nuxil> stick around and someone else might be able to help you
[08:58:13] <Banai> thanks nuxil
[11:47:08] <julius> first packet from china arrived, yeah. now i can finally start building the next skynet....with a tea strainer
[12:26:57] <Casper> julius: there is a start for everything!
[14:17:04] <julius> Banai, i just google something about jtag and came over a presentation featuring the mcp430
[14:17:19] <julius> funny...maybe my subconcious picked the writing up here and googled for me
[14:21:13] <aandrew> oh my god
[14:21:13] <aandrew> http://hackaday.com/2016/01/20/microchip-to-acquire-atmel-for-3-56-billion/
[14:21:16] <aandrew> noooooooooooooooooooooooooooooooooooooooooooooooooooo
[14:23:11] <nikomo> aandrew: ffffffffffffffffffffffffFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFUUUUUUUU
[14:24:05] <nikomo> I was having an _okay_ day before you linked that
[14:28:14] <aandrew> sorry
[14:30:10] <nikomo> aandrew: guess we'll have to look at this way: now Microchip will have decent microcontrollers to sell
[14:30:51] <aandrew> yeah but I can almost smell the end of avrgcc and avarice. they're going to be ramming pickit and mplab down everyone's throat as hard as they can
[14:30:57] <inkjetunito> good news everyone. this channel will now merge with #pic
[14:32:16] <nikomo> funnily enough, I just ordered one of them clone pickit 3's on ebay a few days ago
[14:33:22] <MartinR90> Can we flash AVR with SPI ?
[14:37:46] <aandrew> hmph. I never thought to even look for clone Pickit3s
[14:39:42] <nikomo> aandrew: it'll be a cold day in hell before I buy a legit one of those things
[14:40:55] <nikomo> I'll say this though, they're much nicer regarding samples, than Atmel
[14:52:05] <LeoNerd> Is it just me, or do the Atmel AVR devices XML files not give default values for the fuses?
[15:32:00] <Lambda_Aurigae> just imagine, avr core with pic peripherals!
[15:32:20] <Lambda_Aurigae> LeoNerd, it's just you...I'm sure there is one out there for that...ask wormfood.
[15:33:06] <Lambda_Aurigae> MartinR90, sure...the avr ISP is an SPI-ish interface...it uses the SPI pins generally too.
[15:35:43] <nuxil> so its the end of atmel now?
[15:35:56] <Lambda_Aurigae> I doubt it...atmel has too many good things.
[15:36:08] <Lambda_Aurigae> but I bet you will see some merging of technologies in 3 to 5 years.
[15:36:23] <nuxil> i do really hate the name "pic" i do not hope they change the name of the chips to picNNN.
[15:36:25] <Lambda_Aurigae> atmel studio multiplatform would be nice.
[15:36:44] <nuxil> because "pic" means penis in my language dialect.
[15:36:57] <Lambda_Aurigae> and ko means cow in some language or another.
[15:36:58] <nuxil> i cant go tell my frends im messing around with my "penis"
[15:37:15] <nuxil> ^^
[15:37:16] <Lambda_Aurigae> but I still use KO instead of OK.
[15:38:12] <Lambda_Aurigae> sorry,,totally rambling here.
[15:38:34] <Lambda_Aurigae> I never liked pic or avr for product names but they weren't mine to choose.
[15:38:50] <Lambda_Aurigae> and I still want a 6502 based microcontroller.
[15:39:03] <Lambda_Aurigae> I have some 68000-ish based ones around here.
[15:39:56] <nuxil> 6502 is that like a old thingy from the 70's
[15:40:33] <Lambda_Aurigae> the processor in the commodore vic-20, c-64, and c-128 line...as well as all the apple-II and many other computers of the 80s.
[15:41:23] <nuxil> i see. its made by MOS Technology, and was introduced back in the 1975
[15:41:32] <Lambda_Aurigae> that's the chip I learned assembly on back in the day.
[15:41:32] <nuxil> wow.. thats a old chip :D
[15:41:55] <nuxil> :D nice
[15:42:14] <Lambda_Aurigae> first on apple-II at school then on my vic-20 at home
[15:42:37] <Lambda_Aurigae> even wrote a disassembler/assembler in basic for the vic-20.
[15:42:48] <Lambda_Aurigae> had to have my 16K ram expansion in for it though.
[15:42:51] <nuxil> o.0 seriouse ?
[15:43:04] <Lambda_Aurigae> yup.
[15:43:11] <Lambda_Aurigae> vic-20 only has 5K of ram.
[15:43:23] <Lambda_Aurigae> I was able to add a 16K and 8K at the same time.
[15:43:46] <Lambda_Aurigae> then later I got a cartridge that had a disassembler/assembler in rom that was much better than my one written in basic.
[15:44:11] <Lambda_Aurigae> and had to add another slot to my homemade expansion board to fit that and the memory boards in at the same time.
[15:45:09] <Lambda_Aurigae> those days were so much fun.
[15:45:15] <Lambda_Aurigae> almost miss them.
[15:45:26] <Lambda_Aurigae> except, that I still have a functioning vic-20 to play with.
[15:46:24] <nuxil> nice'
[15:46:44] <Lambda_Aurigae> omega race on 15 foot diagonal projection screen is awesome.
[15:46:50] <Lambda_Aurigae> and lunar lander is almost lifesize!
[15:49:42] <nuxil> 15 foot ?
[16:33:04] <LeoNerd> Ooooh.. I didn't realise this.. Some subtle wording in the mega328P datasheet suggests you can use a crystal oscillator faster than 20MHz, provided you leave CKDIV8 set to divide it down to something within 20MHz
[16:34:15] <learath> LeoNerd: interesting. Why would you do that?
[16:34:53] <LeoNerd> Dunno.. perhaps if that was the only crystal you had?
[16:39:50] <Valen> might be if you are using a clock rather than xtal perhaps?
[16:40:00] <Valen> (IE your board has a 40mhz clock on it or somehting)
[16:40:31] <Valen> or it might let you hit some weird frequency, like you want 5.25mhz, so you put a 21mhz xtal in /4?
[16:43:36] <WormFood> [05:07:37] <Lambda_Aurigae> LeoNerd, it's just you...I'm sure there is one out there for that...ask wormfood. <-- why as me about that? :P
[16:44:22] <aandrew> I thought the vic20 had about 3.5k of usable RAM
[17:14:41] <LeoNerd> WormFood: I'm looking for a device info XML file that gives the default values for fuses
[17:14:50] <LeoNerd> There was comment that you might have one
[18:02:35] <WormFood> LeoNerd, yeah, I understand that part, but I was asking, why ask me?
[18:03:45] <Lambda_Aurigae> WormFood, sorry...I was thinking the other site...just cross connected your avr baud calc.
[18:03:58] <Lambda_Aurigae> I forget who did the avr fuse calc site.
[18:04:00] <WormFood> I see
[18:04:20] <WormFood> I was looking into writing my own, but decided parsing their xml files are too much of a pain.
[18:04:32] <Lambda_Aurigae> my mind is all kinds of twisted, more than usual, from work and I just cross-indexed your site and the fuse calc site.
[18:05:09] <WormFood> Someone here commented a while ago, that I should write a fuse calculator page, that'd be better than that other page you're talking about
[18:07:51] <LeoNerd> I have parsing code... for the XML files. And it's working nicely to generate output
[18:08:07] <LeoNerd> The only problem is that the XML files don't have fuse defaults, so currently the user has to give values for every fuse field
[18:34:59] <Jartza> Lambda_Aurigae:
http://avrcalc.pl/
[18:38:52] <Lambda_Aurigae> Jartza, yeah..have seen it before....the whole conversation started as someone wanting to know about default fuses in the atmel xml files.
[18:39:22] <Lambda_Aurigae> there's gotta be a default set somewhere.
[18:42:12] <Jartza> ahh
[18:42:20] <Jartza> missed this conversation it seems :D
[19:05:00] <Lambda_Aurigae> and I referred to the wrong person, causing much confusion and consternation.
[19:11:47] <Jartza> heh