Back
[02:22:00] <blathijs> scoy: Casper: Technically, the "interrupt mark" you talked about (which is usually called an interrupt flag) is not cleared at the end of the ISR. Usually it is cleared at the start of the ISR, but sometimes also when a specific condition is met (for UART RX, it's cleared when the UDR register is read IIRC)
[06:28:18] <OndraSter_> yey somebody's selling on czech-ebay-like website something that looks like telephone switching or something.. digital one
[06:28:30] <OndraSter_> DTM Data TeleMark GmbH 64 - 2 - 0173, D.I.C.A. 6400
[06:28:48] <OndraSter_> looking at the internet it is some ISDN converter
[06:29:08] <OndraSter_> but - it is in an eurocard form
[06:29:15] <OndraSter_> 19" rackmount
[06:29:38] <OndraSter_> ISDN MUX it is apparently
[09:18:26] <ColdKeyboard> What is the most efficient way to generate (pseudo) random number?
[09:33:58] <Fleck> ColdKeyboard: adc :D
[09:35:07] <PoppaVic> count gamma's
[09:35:09] <antto> ColdKeyboard the randomness depends on the algo
[09:35:22] <antto> depends what you need
[09:37:10] <antto> there are expensive algos like the MT, which have a long period
[09:37:42] <antto> but there are some cheaper algos (with just more taps) that give even bigger period than the MT
[09:44:29] <ColdKeyboard> I will use one in the stdlib.h rand(), if it doesn't work I will try to implement something with ADC or maybe Timer or something like that...
[09:44:39] <ColdKeyboard> I just need it not to repeat it self every time mcu powers up :)
[09:48:44] <PoppaVic> ColdKeyboard: so?
[09:49:03] <PoppaVic> rand takes a seed - an RTC is ideal
[09:51:17] <Fleck> seed from adc works good too!
[09:51:26] <Fleck> and you need to get it only once
[09:51:41] <Fleck> but, if you got RTC, sure, why not use RTC!
[09:51:59] <PoppaVic> the adc has to be attached to something, does it not?
[09:52:17] <Fleck> nope, floating works great :D
[09:52:41] <PoppaVic> ah=ha
[09:53:57] <hackvana> If you want pseudo-random, ask the NSA :-)
[09:57:10] <synic> I've been using the eeprom seed for a simple game, seems to work pretty well
[10:19:24] <Fleck> also you can use timer counter, if you have a start button or smtn like that...
[13:17:07] <illumer> Dears
[13:17:13] <illumer> I still having a situation
[13:19:51] <illumer> I'm having project that should work in two modes
[13:20:06] <illumer> manual and automated mode
[13:20:45] <illumer> my idea was to define a variable that been checked on periodically
[13:21:21] <illumer> inside the main (manual mode) and the interrupt routine(automated mode)
[13:21:33] <illumer> but it didn't work
[13:21:57] <illumer> some of them advised with volatile key word
[13:22:15] <illumer> but it even effected the functionality of the code
[13:23:02] <illumer> so, to simplify it..
[13:24:11] <illumer> imagine a system being controlled either manually(using push buttons for example)
[13:24:45] <illumer> or automated (state machine defined inside an interrupt routine)
[13:24:50] <illumer> any ideas
[13:25:38] <illumer> ?
[13:29:55] <spooq> you should use volatile if you are modifiing in the interrupt
[13:30:19] <Tom_itx> i told him that yesterday
[13:30:42] * spooq shrugs
[13:30:51] <illumer> I told you the whole code didn't work after that
[13:31:05] <Tom_itx> then you have something else drastically wrong
[13:31:05] <spooq> then you have other problems in your code that you should fix
[13:31:08] <spooq> heh
[13:31:09] <spooq> yeah
[13:33:38] <illumer> then shall you check it?
[13:33:58] <illumer> may be I'm missing some coding standards
[13:34:35] <illumer> anyway I updated the code using preprocessor directives
[13:35:25] <illumer> so to make work as recompiling everytime I need to change from mode to another
[13:35:57] <illumer> http://pastebin.com/9rxSEtWa
[13:36:12] <illumer> either using interrupt(automated mode)
[13:36:14] <illumer> or manual
[13:41:38] <Tom_itx> do you understand what the wizzard wrote for you?
[13:44:40] <illumer> which Wizard?
[13:44:54] <Tom_itx> This program was produced by the
[13:44:54] <Tom_itx> CodeWizardAVR V2.05.0 Professional
[13:44:54] <Tom_itx> Automatic Program Generator
[13:45:47] <Tom_itx> you don't need inline asm for SEI() either
[13:45:53] <Tom_itx> but it should still work
[13:47:03] <tzanger> eww, automatic code gen
[13:47:58] <Tom_itx> you should simplify your code until you know the variables are being updated inside the interrupt
[13:48:07] <Tom_itx> then make it all convoluted again
[13:54:12] <illumer> okk how can I simplify the code
[13:54:48] <illumer> you mean I write a code to do simple functionality?
[13:54:57] <illumer> like led control?
[13:59:05] <illumer> Dear using inline asm is a must
[13:59:27] <illumer> it doesn't work without it
[14:00:43] <Tom_itx> it certainly will
[14:01:39] <illumer> it takes 2 seconds and two slashes to remove it
[14:01:56] <illumer> so this a system reply
[14:02:11] <Tom_itx> sei();
[14:02:12] <illumer> it doesn't work without it
[14:02:16] <Tom_itx> works the same as what you had
[14:02:32] <Tom_itx> however you don't need the #asm qualifier
[14:07:07] <illumer> it led me to missed header errors
[14:07:20] <illumer> but anyway that is not the issue now
[14:07:47] <illumer> what do you think about working with sudo codes to fix the problem
[15:39:23] <illumer> what is the difference b/w using wizard or not for you guys?
[15:41:33] <OndraSter__> what kind of wizard?
[15:42:19] <illumer> codevision wizard
[15:42:34] <illumer> is it shameful kind of?
[15:42:54] <OndraSter__> codevision wizard?
[15:43:02] <illumer> yes
[15:43:53] <illumer> as I asked for a problem many times and they kept referring to I'm using the wizard
[15:44:13] <illumer> and that ends with leaving me with my problem
[15:44:28] <synic> what is your purpose for using the wizard?
[15:44:57] <synic> is it because you don't understand how to write the code yourself, or is it because writing the code with the wizard is faster?
[15:45:00] <ThiefMaster> "to get a crappy codebase"? :D
[15:45:01] <ThiefMaster> 151.248.99.242
[15:45:03] <ThiefMaster> err
[15:45:11] <ThiefMaster> that last one didn't belong here
[15:45:45] <synic> because if you don't understand how to write the code, then you definitely won't understand the code that it generates, and you won't have any idea how to debug said code
[15:46:05] <illumer> faster and I don't bother by searching the routines format as they use standard C format
[15:46:31] <ThiefMaster> so you are just lazy and a help vampire ("don't bother seraching", let's ask people instead!)
[15:46:31] <illumer> they don't*
[15:46:58] <illumer> ThiefMaster:do you know me?
[15:47:35] <illumer> synic
[15:47:42] <ThiefMaster> no, but i know the kind of users that talk/ask just like you do e.g. from stackoverflow. they usually expect others to do their work
[15:48:10] <illumer> I'm not that kind
[15:50:51] <illumer> anybody could help me in applying what I'm thinking of?
[15:54:33] <illumer> I need to know the technique of multi-mode coding
[15:55:34] <illumer> so I can control two type of functionality using button to switch between them while the micro is running
[15:59:36] <illumer> hello
[15:59:58] <illumer> am I asking for the impossible?
[16:01:10] <synic> seems like it'd be fairly easy, as opposed to impossible
[16:01:32] <illumer> really!
[16:02:24] <illumer> what if one of the modes is defined as state machine inside counter interrupt?
[16:03:31] <bss36504> I'm going to be graduating from school in May with a BS EE, and I've been working part time/full time (summers, vacations) for a company doing applications. You could say that I have about 2 years experience with embedded designs. I make peanuts compared to what I would be making if I wasn't in school, but I would like to talk to my boss about hiring me full time on salary when i graduate. Anybody have a ballpark salary I should b
[16:03:31] <bss36504> looking at? (I'm in the US btw, in a moderately technical region)
[16:04:28] <synic> illumer: why not?
[16:04:43] <synic> I feel like I'm walking into some sort of trap here
[16:04:56] <illumer> :D
[16:04:59] <synic> since the solution seems easy, but already two people who seem like they know what they are doing have tried to help you
[16:05:00] <illumer> never
[16:05:15] <bss36504> illumer: It's a simple state machine.
[16:05:42] <illumer> it seems I need to introduce myself here
[16:05:46] <synic> seems as easy as setting some global "mode" variable when you press the button
[16:06:08] <bss36504> illumer: toggle some control bit within your ISR for the button, then just loop around your state machine and switch states based on the bit.
[16:06:13] <illumer> I did the same even before coming to this room
[16:06:55] <synic> well why didn't it work?
[16:07:04] <illumer> :)
[16:07:18] <illumer> that is why I'm here
[16:07:53] <illumer> anyway I'm not help vampire as that guy said
[16:08:15] <illumer> I even read about programming micro by my own
[16:08:23] <synic> so you pressed the button, and then what happened?
[16:09:11] <illumer> either it switched to the interrupt mode and stuck
[16:09:30] <illumer> or it switches to the (main) mode and stuck
[16:09:55] <synic> so pressing the button changed the mode, but then it wouldn't change back?
[16:10:07] <illumer> exactly
[16:10:17] <illumer> I'm trying to make simple code for LED
[16:10:42] <illumer> so to regenerate the error again
[16:11:45] <synic> I don't suppose you have this code that did, in fact, change the mode, but only once
[16:12:24] <illumer> only once?
[16:12:45] <illumer> but the purpose is to make it mode switcher
[16:12:49] <synic> You said it would change the mode, but then wouldn't change back, correct?
[16:13:03] <illumer> yes
[16:13:06] <illumer> and I have the code
[16:13:41] <illumer> http://pastebin.com/EHSsMsnr
[16:14:34] <illumer> I modified it to make it functional again
[16:15:14] <illumer> but in the main I added condition of checking button the toggle between 1 and 0
[16:15:17] <synic> unsigned char mode = 0; ... is the mode variable, but it's never set anywhere except there
[16:16:09] <synic> also you're only ever checking for one state of mode
[16:16:54] <synic> I imagine in one state, you don't want your timer interrupt to be called
[16:17:23] <illumer> in mode 0 yes
[16:17:36] <synic> but you never disable your timer interrupt
[16:17:40] <illumer> I don't want to routine to be functional
[16:17:42] <synic> when mode is 0
[16:18:14] <illumer> no I didn't
[16:18:34] <synic> and you don't check the mode in your interrupt either
[16:18:48] <illumer> shall I disable it inside the while loop
[16:18:49] <illumer> ?
[16:19:02] <illumer> I do
[16:19:13] <illumer> in line 39
[16:19:27] <synic> ah, so you do
[16:19:35] <synic> but there's nothing ever setting the mode to 1
[16:19:50] <synic> and mode isn't volatile
[16:20:04] <illumer> yes that code I removed it when it struggle
[16:20:27] <illumer> this made the code unfunctional at all
[16:20:44] <illumer> volatile*
[16:20:58] <synic> what does "unfunctional" mean
[16:21:27] <synic> can't help debug code that doesn't exist
[16:21:59] <illumer> sorry english is not my language
[16:22:12] <illumer> that is pretty easy
[16:22:20] <illumer> I can add it in 5 mins
[16:23:45] <synic> I get what you're saying, your code didn't work, but that isn't a good description of the problem
[16:24:03] <synic> it didn't compile?
[16:24:13] <illumer> it do compiles
[16:24:20] <illumer> and it works
[16:24:49] <illumer> but I find myself recompile again and again
[16:25:00] <illumer> to switch between the two modes
[16:25:52] <illumer> like I'm commenting part of the code
[16:26:03] <synic> no, I'm asking how volatile made your program unfunctional (which is somehow different than the unfunctional where the button didn't work)
[16:27:57] <illumer> okk here is the result
[16:28:26] <illumer> when I add volatile the third motor stuck
[16:28:41] <illumer> that in the interrupt mode
[16:28:52] <illumer> means when I set mode to 1
[16:29:26] <illumer> when I remove volatile it works(the state machine in the interrupt)
[16:29:52] <illumer> that regardless of my main problem
[16:30:26] <synic> do you know what volatile does?
[16:31:42] <illumer> no
[16:33:24] <synic> would probably help to find out what it means
[16:33:39] <illumer> yes
[16:33:45] <illumer> I found out
[16:34:01] <synic> so why would you put it there
[16:34:19] <synic> and why would putting it there cause your code to break
[16:34:22] <illumer> because I didn't know about it before
[16:36:03] <illumer> that why I'm here
[16:36:27] <synic> no I'm asking you to tell me
[16:37:57] <illumer> I already told you
[16:38:08] <synic> knowing what volatile does and then still suggesting that it breaks your code, you can see why people got frustrated and stopped trying to help in any way
[16:38:10] <illumer> volatile key word I didn't use it before
[16:39:10] <illumer> that is not an excuse
[16:39:20] * synic bows out
[16:39:23] <illumer> you don't know my background
[16:39:27] <synic> good luck
[16:39:58] <illumer> thank you
[19:55:07] <TLoFP> hi does anybody know what the deifference between a ttyS and ttyACM serial port are under linux?
[19:55:15] <TLoFP> and what is USB with CDC?
[19:55:43] * TLoFP is playing with an ATmel Xplained board and is trying to learn
[19:56:05] <TLoFP> hey PoppaVic how are you
[19:56:43] <PoppaVic> still fighting hotkeys, arthritis, and a sliced finger - sorry I bounced
[19:57:05] <TLoFP> PoppaVic: keyboard giving you problems?
[19:58:01] <PoppaVic> I dislike hotkeys in Xchat - typing and suddenly noticing menu's popping up and enabling and disappearing- and I HATE this trackpad that can sense a thumb hovering over an inch away and THAT causing oddities
[19:58:50] <TLoFP> I hear you! that can be anoying
[19:58:51] <N2TOH> what machine?
[19:59:02] <TLoFP> I take it you are on linux?
[19:59:42] <PoppaVic> yeah. Ubuntu and this trackpad are truly annoying - when I boot doze (rarely) the trackpad is perfectly civilized.
[20:00:13] <N2TOH> is there not some config file where you can desense the track pad?
[20:00:49] <TLoFP> N2TOH: this is a hardware issue, the cpacitive sensing is sometimes just too darn sensitive
[20:01:32] <N2TOH> in windows there is or was a setting for how reactive the pointer was to mouse input
[20:02:23] <N2TOH> your trackpad might be outputting gaming refresh rates, when the OS thinks it's a common mouse
[21:34:11] <hala3ammi_ubuntu> how to read string from serial ?
[21:34:48] <hala3ammi_ubuntu> I can read bytes in ISR but need to read until /n/r
[21:35:04] <hala3ammi_ubuntu> anybody here ?
[21:48:27] <PoppaVic> no one there
[21:57:11] <xorm> lol idk
[22:12:13] <scoy> i'm learning that i can't clear an interrupt flag inside an interrupt and expect the main logic to continue
[22:12:24] <scoy> can anyone confirm that?
[22:12:29] <bss36504> just add a return.
[22:12:36] <bss36504> the flag is cleared automaticaly
[22:12:42] <bss36504> (if you're writing C)
[22:12:48] <bss36504> automatically*
[22:17:22] <scoy> bss36504, yep writing in C and i'm aware the flag is cleared automatically after return, but thanks. just wanted to see if i could clear the interrupt but continue processing inside the function. looks like that's a big NO
[22:17:44] <Tom_L> that's kinda asking for trouble
[22:17:50] <Tom_L> begging even
[22:17:55] <bss36504> Wait, you want to clear the flag in the interrupt and still run the ISR? I think you can, but it's not really a good plan
[22:17:57] <scoy> lol, good to know
[22:18:04] <bss36504> (nor can I think of why you would need to)
[22:18:05] * PoppaVic chortles
[22:18:28] <PoppaVic> don't screw around/dawdle inside an ISR - ever
[22:19:10] <scoy> haha, i've heard man people say that which made me investigate it more. that's what led me to this spot. good to know. just learning over here.
[22:20:19] <PoppaVic> yep major Learning Experience.. It's more common where folks don't screw with external-events
[22:21:11] <scoy> so what about something like using the ISR to set some sort of flag and then the main logic and continually checks that flags status and does whatever when it changes?.
[22:21:25] <bss36504> That's perfectly legitimate
[22:22:03] <scoy> ok, i am using external interrupts to "wake up" the IC so it can do something. seems like that flag idea will work. thanks a lot everyone
[22:22:14] <PoppaVic> yep
[22:22:29] <PoppaVic> similar to an event-queue
[22:23:16] <PoppaVic> (which would be handy for MCU's - if c++ wasn't forced over it)
[22:23:45] <bss36504> PoppaVic: Are you talking about a nested interrupt handler, like in the xmegas?
[22:23:54] <PoppaVic> no
[22:24:02] <bss36504> ok
[22:24:21] <PoppaVic> I mean a literal Queue for [prioritized] events which a handler loop would walk.
[22:24:41] <bss36504> thats literally what the round-robin event scheduler in the xmegas does.
[22:24:58] <bss36504> and the AVR32 IIRC
[22:25:01] <PoppaVic> means all the Interrupts would be short & sweet and leave the handler to do the work.
[22:25:15] <PoppaVic> I've not seen it, so I'll nod.
[22:25:42] <bss36504> So you're saying, basically build your interrupt handlers to simply set flags that get checked in some main loop?
[22:25:57] <PoppaVic> with a priority queue, however, you could have certain services shoved ahead of others that were already waiting
[22:26:09] <bss36504> I think this is called an RTOS :P
[22:26:21] <bss36504> at the very least, a scheduler
[22:26:22] <PoppaVic> the loop plucks the foremost event, executes, and goto 0
[22:26:57] <PoppaVic> the RTOS stuff I've seen seemed to be more involved in other dimensions
[22:27:49] <bss36504> not really. FreeRTOS is a shitstorm. works well, but kind of complicated. at it's core, an RTOS simply has a real-time ISR that runs a schedular, picks a task to run based on 1) if it needs servicing, and 2) if it has a high enough priority.
[22:28:31] <PoppaVic> <shrug> then the RTOS I saw was more like freertos - overkill.
[22:29:10] <DagoRed> It's necessary for certain applications. Overkill for 8bits though.
[22:29:53] <bss36504> FreeRTOS has some added features that make it nice for a super-stable, very predictable real-time system. It can be a real pain to even fit it on a small 8-bit, let alone be able to build anything with whatever memory is left.
[22:29:56] <DagoRed> If you need rtos, there are some serious applications going on.
[22:31:17] <bss36504> Check out femtoOS, I looked at it a while back. It's about as small as an RTOS can be. If you want just the scheduler, you can probably find one. What you're talking about though is not real-time, so you you'd either be trying to service things as fast as possible, or you dont care about when other things are serviced.
[22:31:38] <PoppaVic> Meanwhile, the loop and event-queue I mentioned should be doable most anywhere - and ain't.
[22:32:07] <bss36504> for sure, it would absolutely be helpful in certain situations too. Any time you had a lot of async requests into your micro it would be nice.
[22:33:39] <PoppaVic> Just thinking of how it would streamline and organize is nice ;-)
[22:33:51] <bss36504> always nice to do that.
[22:34:16] <PoppaVic> although, perhaps it's more like an Inner Loop and list. That too would fit
[22:34:20] <bss36504> Write up the lib, PoppaVic! Sounds like volunteering :P
[22:34:35] <PoppaVic> I'm too old to volunteer.
[22:34:49] <bss36504> I'm too young
[22:35:07] <bss36504> aint nobody got time to write a code library (unless you're dean)
[22:35:39] <PoppaVic> oh, I suppose I'll return to such eventually - too many years of futile typing.
[22:36:41] <bss36504> haha
[22:37:50] <scoy> interrupt based USI. master sends slave a request and the slave works on and answer. while it's working, should the master keep bumping bits through USI to poll for a response? maybe stop and request at intervals?
[22:38:27] <scoy> i feel like continually pushing bits through USI tie up the slave with USI interrupts
[22:38:34] <bss36504> well if you end up "distracting" the slave too much, dial back the frequency that you request.
[22:38:41] <scoy> right
[22:39:00] <bss36504> set up a RTI on the master to poll at some fixed delay without bringing the master's code to a halt.
[22:39:19] <scoy> RTI?
[22:39:19] <bss36504> it all depends on what reaction time you need out of the system.
[22:39:24] <bss36504> real-time interrupt
[22:39:27] <bss36504> timer interrupt
[22:39:43] <scoy> nothing crazy fast. timer interrupt sounds interesting
[22:39:46] <PoppaVic> or set the master up to "poll" everyone - and just collect and await replies with a sensible timeout - order shouldn't matter ;-)
[22:40:06] <PoppaVic> "Everyone speak up - I'm waiting".....
[22:40:15] <scoy> haha, i like that approach
[22:40:30] <bss36504> as long as there isnt any bus contention.
[22:40:41] <bss36504> you'd have to arbitrate the bus somehow.
[22:41:16] <scoy> yea, that's why i'm playing around with the external interrupts on the slave. pretty much SPI slave select.
[22:41:16] <PoppaVic> well, yeah - it depends on how the buss works. I was thinking "packets", but with MCU's and shit, I gotta' start thinking of signal bits/timeing/frames
[22:41:54] <PoppaVic> scoy: i was under the impression the master hit select, and then waited for a reply
[22:42:10] <PoppaVic> (prolly oversimplifying again)
[22:42:36] <PoppaVic> ..I need to experiment with several SPI and I2C thingies at once to learn this crapdoodle
[22:43:07] <bss36504> if you do a broadcast to all of the slaves and allow them to reply whenever, you no longer technically have a single master multi slave system. It's a multi-master system instead. So either you have a switch of some kind (like an ethernet switch) or you have some other means of making sure the bus is clear. My suggestion: Master asks, slave responds immediately.
[22:43:57] <rue_house> what library are we writing today?
[22:44:21] <scoy> well i want a few different things from the slave. so the process is 1) slave wake up (ISR) and then 2) Ask slave for something 3) wait for response (polling? RTI maybe?) 4) do something with it 5) profit
[22:44:22] <bss36504> A scheduler, and a multi-master USI library :P
[22:44:30] <bss36504> rue_house: ^
[22:44:50] <rue_house> you do not need a scheduler on a 8 bit microcontroller
[22:45:02] <bss36504> rue_house: yes, I was kidding
[22:45:06] <bss36504> It was thrown around
[22:45:14] <rue_house> good,
[22:45:31] <bss36504> scoy: Sounds pretty straight forward and predictable.
[22:45:37] <PoppaVic> There are absolutely no absolutes! I am positive
[22:45:44] <rue_house> who wants to submitt 1-3 line code snippets to evade being kicked from the channel?
[22:45:45] <scoy> PoppaVic, haha
[22:46:24] <PoppaVic> Begin: goto Begin;
[22:46:28] <PoppaVic> next?
[22:46:36] <bss36504> PoppaVic: NO GOTOS. BAD
[22:46:40] <bss36504> NEVER
[22:46:45] <PoppaVic> goto's good - programmers bad
[22:46:47] * rue_house slaps PoppaVic for using goto
[22:46:59] <rue_house> DDRA = (INPUT << PA0 | INPUT << PA1 |INPUT << PA2 |INPUT << PA3 |INPUT << PA4 |INPUT << PA5 |INPUT << PA6 |INPUT << PA7);
[22:47:02] <rue_house> there is my line
[22:47:11] <bss36504> I had some other engineers write some code at work, and I had to go strip out gotos later. It was a nightmare.
[22:47:54] <bss36504> rue_house: oookkkk....
[22:48:01] <rue_house> gotos can obfiscate code thats obfiscated otherwise by the compilers optimizer
[22:48:22] <bss36504> who actually looks at the disassembly anyway?!
[22:48:32] * rue_house raises hand
[22:48:39] <scoy> ISR(PCINT_vect) {for (;;) {usart_put("why is everything taking so long?");}
[22:48:45] <rue_house> hahaha
[22:48:52] <scoy> }
[22:49:05] <bss36504> rue_house: wait, I misinterpreted that at first. I'm with you know.
[22:49:18] <bss36504> I too, look at the disassembly, but only rarely.
[22:49:37] <bss36504> scoy: Is that a legit question?
[22:50:28] <scoy> bss36504, haha no. people were pasting (bad?) code so i figured i throw something out there
[22:50:37] <bss36504> ohh i gotcha
[22:50:45] <rue_house> its ok, I want newbs to see if and think
[22:51:06] <rue_house> AND we all can learn things, like I learned about default_vect
[22:51:12] <PoppaVic> and the pleasure of calculated-goto's is beauty ;-)
[22:51:44] <bss36504> technically though, rue_house's code isnt so bad. It would do the same thing as if(input) DDRA = 0xFF; else DDRA= 0x00;
[22:51:56] <rue_house> back int eh z80 days I would push return addresses on the stack to have functions call other functions before returning
[22:52:00] <bss36504> I'm para-coding (like paraphrasing)
[22:52:08] <PoppaVic> yep
[22:52:38] <bss36504> Well thats interesting...
[22:53:09] <rue_house> but cmon, lets see code snippets you think might be usefull for people
[22:53:19] <bss36504> hmm, let me think
[22:53:25] <bss36504> how many lines?
[22:53:29] <rue_house> 1-3
[22:53:33] <bss36504> ok
[22:54:30] <rue_house> #define IsHigh(BIT, PORT) (PORT & (1<<BIT)) != 0
[22:55:11] * PoppaVic sighs
[22:55:21] <rue_house> then up me
[22:55:51] <PoppaVic> you left out an extra set of parens - bad - and the !=0 is redundant.
[22:56:19] <rue_house> cmon then, post your better
[22:56:23] <bss36504> int foo(){ usart_print("hello"); bar( &foo) } bar(int (*fp)()) { usart_print("world"); fp(); }
[22:56:36] <rue_house> hah
[22:56:48] <bss36504> think i got that right lol
[22:57:07] <bss36504> mega recursion!
[22:58:04] <bss36504> damn, last bit should be (*fp)();
[22:59:13] <rue_house> #define NOP() asm volatile ("nop"::)
[23:00:03] <bss36504> what in the actual hell does that do?
[23:00:24] <bss36504> I get the whole asm("nop") deal, not sure why volatile, not sure what the :: is for
[23:00:26] <rue_house> nothing, even if you ahve optimization on
[23:00:53] <rue_house> the :: is part of the registers in, registers out, registers destroyed deal
[23:01:08] <rue_house> dunno why its volatile
[23:02:42] <rue_house> nobody else?
[23:03:09] <rue_house> I have to kick out everyone but bss36504 PoppaVic and scoy ?
[23:03:15] <rue_house> this is gonna be a busy night
[23:03:35] <bss36504> do you run this chan rue_house>
[23:03:37] <bss36504> ?*
[23:04:38] <rue_house> I have the green hat of pointyness!
[23:04:40] <rue_house> :P
[23:05:33] <bss36504> damn, did not know that. I've been a regular in here for like 8 months now (or longer?) and I never knew of any channel admins.
[23:05:41] <rue_house> BusError_, speak or be squashed!
[23:05:54] <rue_house> yea I'm a real attentive admin...
[23:06:17] <bss36504> I'm a little concerned that N1njaneer isn't on. He's ALWAYS on.
[23:06:26] <bss36504> Certainly he'd join in on the fun
[23:07:26] <rue_house> meh I'm gonna go to bed
[23:07:43] <bss36504> me too. It's getting late and I have an early class.
[23:07:48] <rue_house> I'll kick the lot of them out later
[23:07:56] <bss36504> haha