Back
[00:44:40] <johnwalkr> vent
[00:45:12] <johnwalkr> that was a weird window focus thing
[04:34:01] <abcminiuser> https://www.youtube.com/watch?v=gN36qXzS2RY&feature=youtu.be
[09:26:46] <sleipnir> hi guys, would it be appropriate to ask about analog electronics here?
[09:27:34] <jacekowski> sleipnir: not really
[09:27:36] <tzanger> we're mostly idle, I don't see the harm in it although you might not get as much help here as elsewhere
[09:27:38] <jacekowski> sleipnir: ##electronics
[09:28:29] <sleipnir> I figured, but that channel is way offtopic :(. my question just sunk into oblivion :P
[09:29:02] <jacekowski> sleipnir: you will have to try again later
[09:29:11] <sleipnir> :)
[09:29:26] <tzanger> just ask here, worst it will get ignored. if it's a quick question we might be able to help quickly
[09:29:48] <sleipnir> tzanger, thanks, just wanted to be polite: hi, I am designing very sensitive (200nV) sensing product. This will be powered from batteries and communication will be isolated via fiber. My question is shoul I connect the case to the GND of the circuit? or leave it floating?
[09:29:56] <jacekowski> on some channels it's instant ban when you ask something offtopic
[09:30:12] <tzanger> yeah but this isn't one of them
[09:30:16] <jacekowski> on #debian, mentioning ubuntu will get you banned
[09:30:21] <tzanger> heh
[09:30:51] <tzanger> most times the PE and circuit return is connected via a high impedance DC ground and a low impedance AC ground
[09:31:07] <tzanger> i.e. a 1Mohm resistor and a 0.1 or 0.01uF capacitor in parallel with the resistor
[09:31:38] <jacekowski> sleipnir: at that sort of voltages you will need quite a lot of shielding
[09:31:39] <sleipnir> tzanger, what is "PE"
[09:31:45] <jacekowski> sleipnir: protective earth
[09:32:01] <tzanger> take a look at how they connect the chassis to other battery powered circuitry. a really good source would be to look at open source EKG circuitry
[09:32:02] <sleipnir> jacekowski, I assumed a metal case would be enough, no?
[09:32:05] <jacekowski> and case should generally be grounded
[09:32:40] <sleipnir> jacekowski, right, ground the case via low impedence, but to what? AC ground? won't that be noisy?
[09:33:29] <tzanger> they do some insanely crazy things to guard the inputs and get clean signals
[09:33:49] <tzanger> 200nV sensing means you'll have to be very careful with circuit generated noise as well
[09:34:37] <sleipnir> tzanger, right, the ADC will be completley isolated, it will have its onw ground and power plane.
[09:35:19] <sleipnir> I am debating if I should put a guard fence around the ADC section which is connected to the case. what do you think?
[09:35:45] <jacekowski> generally you shield all the input circuitry separately
[09:36:15] <jacekowski> and ADC should be outside that
[09:36:31] <jacekowski> so you have your 200nV input, amplify that, then go into ADC
[09:37:32] <tzanger> most super sensitive inputs I've seen (I haven't ever had to design for that) uses guard rings and a lot of very careful attention is paid to grounding and shielding
[09:37:37] <tzanger> there are a lot of good books on the subject
[09:37:52] <sleipnir> jacekowski, sorry, if I wasn't clear. I won't be measuring 200nV signals. I am trying to achive a 200nV noise figure
[09:38:41] <sleipnir> tzanger, I am aware of the use of triaxial cables, with buffered guards to prevent leaking. But that is more of an issue when measuring incredibly high impedence systems
[09:38:53] <sleipnir> could you suggest such a book?
[09:40:42] <tzanger> http://www.amazon.com/Grounding-Shielding-Circuits-Interference-Techniques/dp/0470097728 might be good
[09:40:54] <tzanger> www.calex.com/pdf/4ground_shield.pdf
[09:41:20] <tzanger> I'm just googling grounding and shielding
[09:41:46] <sleipnir> oh, I thought you had first hand experience
[09:42:08] <sleipnir> :) I appricate the help though, that book looks very interesting
[10:48:57] <naftilos76> Hi everyone, i am working on a mega168 and using AVR studio 4.19 to set the lock bits protection for the application area. I basically need to protect the chip from being read. However after setting the lock bits in both AVR studio and CodevisionAVR i can still read the .hex code and save it! Is there a bug or am i doing anything wrong? Can anybody guess?
[10:53:17] <naftilos76> Anybody?
[10:53:51] <myself> IRC response times are usually measured in hours, not minutes :) grab a coffee, stick around!
[10:54:31] <naftilos76> :-)
[10:54:33] <synic> naftilos76: what programmer?
[10:55:24] <naftilos76> AVRISP MKII USB
[10:55:54] <naftilos76> I just read this:
http://support.atmel.no/bin/customer.exe?action=viewKbEntry&id=394
[10:56:05] <naftilos76> which seemed pretty straightforward
[10:56:39] <naftilos76> I used AVR studio to set both application and bootloader space bits
[10:56:46] <naftilos76> they seem to be set
[10:57:02] <naftilos76> when i read them back they appear as set
[10:57:35] <naftilos76> however when i try to read the flash and save it i can do it without any warnings
[10:59:02] <naftilos76> The part that works is when i try to re-program the lock bits while being set to protect flash and boot space
[10:59:25] <naftilos76> When i try to do that i cannot
[10:59:46] <naftilos76> but the reading of the flash memory still works
[10:59:55] <theBear> you sure you set anti-read and not anti-write ? you using the fuse definitions from the right chip ?
[11:01:12] <naftilos76> well what i see in AVR Studio is this: Further programming and verification disabled
[11:01:31] <naftilos76> Both LB bits are set
[11:01:51] <naftilos76> which as per the link above provide protection for read tries as well
[11:02:19] <naftilos76> Yes it is the right chip
[11:03:43] <naftilos76> I just tried programming and reading. They both work while they shouldn't
[11:04:24] <naftilos76> I am not erasing the device before doing any of the two because that would remove the lock bits protection
[11:07:51] <naftilos76> This is my AVR studio settings window:
http://naftilos76.net/avrstudio.png
[11:08:07] <naftilos76> regarding the lock bits
[11:13:58] <Casper> naftilos76: check to be sure that the read code is valid
[11:14:27] <Casper> I recall some early tool that was still reading, but was reading blank
[11:14:35] <Casper> i.e. silently fail
[11:15:08] <naftilos76> let me see that
[11:20:01] <naftilos76> Casper: It doesn't seem blank at all. It's got numbers and letters (hex code)
[11:25:11] <Casper> hmmm
[11:25:23] <Casper> did you power cycled? who knows..
[11:29:21] <naftilos76> I tried reading the hex code and reloading that to the chip which seems to work
[11:29:37] <naftilos76> That is, no protection applies at the moment
[11:32:40] <naftilos76> I 'm gonna leave it for tomorrow. Thanks for your time guys
[11:46:50] <bss36504> rue_house and WormFood: Any updates on the website idea?
[11:48:56] <WormFood> nope
[11:49:08] <WormFood> I was waiting to hear from rue_*
[11:55:52] <bss36504> ah ok
[11:56:28] <bss36504> topic change: I know people have overclocked the xmegas, but has anybody ever overclocked them at low voltages (like 1.8)?
[11:57:23] <WormFood> I've never had a low voltage AVR
[11:58:17] <bss36504> Well running it at 12MHz at 1.8V is the top of the speed grade for that voltage. I'm curious if I could slap a 1Mhz crystal on there and start overclocking.
[11:58:51] <OndraSter_> do it
[11:58:53] <OndraSter_> I overclocked only on 3.3V
[11:58:56] <bss36504> Obviously you'll have more stability at 3.3 volts, which is what the guy did here:
http://goo.gl/6OeHlU
[11:59:22] <bss36504> I think I might do that.
[11:59:33] <WormFood> it's rated at 12Mhz, and you want to start "overclocking" at 1Mhz?
[11:59:50] <bss36504> WormFood: with the PLL I want some room to play
[12:00:05] <WormFood> oh. You're gonna use a PLL to drive the clock?
[12:00:28] <bss36504> yeah, pretty sure that's the best way. Maybe I'm wrong though.
[12:00:34] <WormFood> DSS maybe?
[12:00:41] <WormFood> or is that DDS?
[12:01:16] <bss36504> Definately less of a pain for a couple of reasons: 1) the chip resets to a lower, stable clock, so I can always change the program, and 2) I'd rather not have to add and remove crystals
[12:01:31] <bss36504> Not sure what DSS is either
[12:01:41] <WormFood> yeah, it's DDS
http://en.wikipedia.org/wiki/Direct_digital_synthesizer
[12:01:58] <WormFood> I remember "direct digital"...can never remember that last word
[12:02:09] <OndraSter_> let's say just a square wave gen
[12:02:22] <WormFood> wouldn't a PLL be a sine wave?
[12:02:35] <WormFood> well...I suppose it doesn't need to be a sine wave
[12:02:40] <Roter> Well, its me again, i have almost finished with the led flashing as a first small test. The code:
http://pastebin.com/ztZmCAHA . The problem, is that the led flashes, but for much longer, about 16 seconds.
[12:02:42] <OndraSter_> you can always process it further
[12:02:54] <bss36504> WormFood: The PLL is built into the Xmega.
[12:02:55] <WormFood> the PLLs I worked with professionally, were always a sine wave
[12:03:05] <WormFood> ok, you're talking about THAT PLL :P
[12:03:10] <bss36504> PLLs for square waves are used in literally every processor
[12:03:12] <OndraSter_> of course
[12:03:13] <bss36504> yes
[12:03:30] <Roter> I have a mcu, that can be programmed at 2000mhz, so i set it to 57khz(in atmelstudio) so it should work normaly?
[12:03:33] <WormFood> I worked on 2-way radios. That is where my PLL experience comes from.
[12:03:48] <WormFood> 2 Ghz?
[12:03:59] <bss36504> Roter: lol thats one fast 8 bit micro
[12:04:06] <WormFood> no shit bss36504 ;)
[12:04:12] <amee2k> sine wave + schmitt trigger = square wave :3
[12:04:16] <WormFood> fastest I've ever seen
[12:04:26] <bss36504> Roter: just set your programming clock to super low, set up your fuses then try to move the clock up
[12:04:26] <WormFood> amee2k, there are a number of ways to do it
[12:04:33] <Roter> well, it says at the speed grade: 0-20MHz @ 4.5V - 5.5V
[12:04:59] <amee2k> i wonder if you can make like a 2GHz Z80 on an FPGA >_>
[12:05:00] <WormFood> the error voltage generate needs to be able to read the output, and adjust accordingly...that is all
[12:05:08] <bss36504> Roter: But it doesnt magically run at 20Mhz. you need a crystal if you want to go at 20Mhz, also there is a Clock/8 fuse that is usually set from the factory
[12:06:21] <bss36504> So if its a brand new part, set the ISP clock as low as possible, make sure you can read the chip ID, then configure your fuses (you may need to do a flash erase first though). Then set the clock higher if you want, but only go up to 1/4 of FCPU, like the programming dialog says.
[12:42:52] <bss36504> How noisy is the DAC on the Xmegas? I've read in a few places that its pretty bad.
[13:05:30] <Roter> ok i have a problem, i removed the fuse that devides the clock by 8, and now it is working in 8MHz
[13:06:15] <bss36504> Whats the clock source set to?
[13:06:26] <bss36504> Perhaps the internal 8Mhz RC oscillator?
[13:06:41] <Roter> yes
[13:06:53] <bss36504> Ok so what's the problem
[13:07:11] <Roter> but should i set the clock generator to something higher then 2MHz? because the max is 3 Mhz
[13:07:26] <Roter> its about 2 seconds out of sync
[13:07:40] <Roter> a 1 sec sleep takes about 2 seconds
[13:08:16] <bss36504> No, there is no "Clock generator". The RC oscillator is factory calibrated to 8MHz. What chip are you using and what are you trying to do?
[13:08:42] <Roter> ATMEGA 88
[13:09:00] <Roter> i am trying to make, that the led would blink every second
[13:09:21] <Roter> but it only blinks every 2 seconds
[13:09:25] <Roter> or wait a moment
[13:09:30] <Roter> ill use a chronometer
[13:09:30] <bss36504> so you're using the util/delay.h library? Did you define F_CPU to be 8000000?
[13:09:36] <Roter> oh
[13:09:40] <Roter> i didnt
[13:09:53] <bss36504> it should throw a warning about that
[13:10:13] <bss36504> if it's undefined that is, otherwise it just is doing exactly what you told it to
[13:11:14] <Roter> i set it to the number you said, but wait a bit ill try to get a chronometer, maybe its actualy 1 second, and my aproximations are wrong
[13:11:19] <Roter> also soory for the broken english
[13:11:35] <bss36504> Not a problem :)
[13:11:56] <bss36504> The fact that you made it blink without trouble is better than lots of people haha
[13:12:13] <tzanger> indeed
[13:12:32] <tzanger> "my AVR is smoking can you help me figure out why?"
[13:12:52] <bss36504> Ha, that would be funnier if it didnt happen so much
[13:13:16] <tzanger> it'd be even funnier if we told them they had to flip the 120/220V efuse bit :-)
[13:13:29] <bss36504> hahahaaha nice
[13:20:09] <Roter> i once forgot to connect a wire in my psu and i thought something was wrong with the psu, i saw a 220-120V switch, and i though maybe something related to power on and off, so i clicked it, turned on the computer and then... BOOM
[13:20:17] <Roter> also it is at 2 secs
[13:21:19] <tzanger> haha
[13:21:25] <tzanger> yeah 120->220 isn't a problem
[13:21:28] <tzanger> going the other way doesn't end well
[13:24:05] <Roter> code is here:
http://pastebin.com/sV2xzzjW . So i believe then i have set something wrong with the isp clock
[13:25:23] <Roter> its shows 57,6 khz so its actualy is at 200khz
[13:25:35] <bss36504> Do you have an oscilloscope
[13:25:37] <bss36504> ?
[13:25:47] <Roter> external no
[13:26:05] <Roter> im going to take a picture
[13:26:06] <Roter> 1s
[13:29:33] <Roter> http://imgur.com/4Qwm3nF
[13:29:36] <bss36504> So you dont have a scope?
[13:30:17] <monode> I'm trying to understand how fault tolerant microcontroller systems would work; i'm imagining say - a safe thingie or a door lock - you get some sort of input - a keyboard or maybe an IR receiver, a solenoid for an output, and a microcontroller (I usually use avrs).
[13:30:46] <bss36504> Fault tolerant in what way?
[13:30:57] <monode> Granted, the buttons might wear out and the solenoid could jam, but those could be replaced or have a scheduled maintenance
[13:31:03] <bss36504> Basically just design your system so that the unpowered state is "safe"
[13:31:18] <bss36504> Thats a rule of thumb for any system, whether it's small or industrial
[13:31:27] <monode> well, I'm thinking more of having multiple microcontrollers, so the system would still work if one fails
[13:32:04] <Roter> scope?
[13:32:06] <bss36504> "safe" of course, depends on what you need. If a safe's "safe" state is locked, then thats what you do. A crane on the other hand, probably shouldnt drop it's load if it shuts off.
[13:32:13] <bss36504> Roter: Oscilloscope.
[13:32:20] <monode> I like my safe/door example, because there is no "safe" state. You can't unlock it, because then you won't be able to get inside or unauthorized people might get in, and you can't have the safe state as "locked", because you'll have to physically remove the door
[13:32:32] <Roter> nope
[13:32:40] <Roter> so yeah, im puzzled too
[13:32:44] <bss36504> monode: But no amount of redundancy will solve all problems.
[13:33:00] <bss36504> Roter: Can you screen capture your fuse settings so we can see them?
[13:33:14] <monode> Well, yes, but if a safe's "safe" state is locked, and when the avr fails, the solenoid will be pulled into a locked position by a spring, then there's no way to service the avr
[13:33:49] <monode> yeah, but I'm guessing it's going to add a few more zeros after the decimal point of the %chance of failure
[13:34:03] <bss36504> monode: Yeah, and that sucks. But there are countless known ways that it could fail, and countless more that you dont know about. Just design for the most likely failures and go from there.
[13:34:31] <bss36504> Engineering is rarely black and white. Almost every "how should I do..." question can be answered with "depends on the situation"
[13:34:59] <monode> indeed, it could fail in a way to render all the redundant avrs unable to work
[13:35:06] <monode> hmm.
[13:35:22] <bss36504> monode: Do you know what the Segway is?
[13:35:32] <monode> I guess what I don't know is what sort of failures I'm looking for with avrs, given that the code itself is tested and guaranteed to work
[13:35:32] <monode> yeah
[13:35:59] <monode> not sure how that fails while the user moves :)
[13:36:39] <bss36504> I've talked to the owner of the design firm that did the gyro stabilization for it. They used a triple redundant system to keep people from flopping onto their faces. However, they probably didnt design for the motors spontaneously seizing up and causing the person to fall on their face.
[13:37:51] <monode> I'm guessing that's entirely possible if a transistor in the power driver fails
[13:37:55] <tzanger> it'd be difficult to proteect against motor siezure
[13:38:03] <tzanger> I mean if you're zipping along and the motor locks, you're kind of fucked
[13:38:04] <monode> iirc, the motors are bldcs
[13:38:11] <tzanger> you can't use the motors to prevent it
[13:38:14] <monode> heh
[13:38:18] <monode> it could short open too!
[13:38:25] <bss36504> Yeah, exactly, but its super unlikely too, so they were probably like "fuck it, we did our best"
[13:38:36] <tzanger> mind you, you can prevent it by monitoring bearing temp and simply shutting down if the bearings are too hot, before they sieze
[13:38:37] <monode> so you'd do a ... hmm.. i think 1/6*360 sudden acceleration on just one whell
[13:38:46] <bss36504> tzanger: $$$
[13:39:06] <monode> hmm, this is interesting
[13:39:12] <tzanger> bss36504: eh? a pair of $0.10 thermistors is too expensive?
[13:39:24] <monode> tzanger's argument is the motor locking due to temp issues
[13:39:25] <tzanger> hell make it $5 for mounts, cabling, connectors, etc.
[13:39:42] <tzanger> motors only lock due to that. a brushless motor has nothing else to fail but bearings
[13:39:51] <monode> mine was due to some transistor failing
[13:39:59] <tzanger> and aside from sheer mechanical failure which is practically unheard of if you're operating in the SOA of the motor, the only things that fail are the bearings
[13:40:00] <monode> and i'm guessing yours was entirely different
[13:40:16] <bss36504> okok off topic here, the point is, we can conceptualize failures all day, but you can only design for some of them
[13:40:37] <monode> ok then
[13:40:56] <monode> I guess my issue is - given that everything else around the avr is fault-tolerant, what sort of failures can i expect from an avr?
[13:40:57] <tzanger> bss a transistor locking will cause the motor to potenitally brake but one transistor failing does not cause severe braking force
[13:41:07] <tzanger> I used to design BIG motor controls
[13:41:13] <tzanger> frac through 20k-hp motors
[13:41:22] <monode> niice
[13:41:34] <tzanger> we did soft starting/stopping/jogging/braking and full-blown VFD systems
[13:41:53] <bss36504> monode: Not sure, I've never personally seen an "in-the-field" fail.
[13:42:15] <monode> really? lol
[13:42:24] <bss36504> you could start by looking at the reliability data from Atmel such as the 20 years retention at whatever temperature etc
[13:42:36] <tzanger> in the lab we got a motor to actually flip with dc injection braking. the rotor stopped immediately and the motor itself did a 1/4 turn on its side :-)
[13:42:51] <monode> that could easily be improved by say, having a bootloader rewrite the flash
[13:42:56] <bss36504> tzanger: Thats pretty gnarly
[13:43:08] <monode> tzanger: holy fuck man
[13:43:09] <bss36504> monode: Well not really, it's the same flash
[13:43:15] <tzanger> nah gnarly was when they destroyed a big wound rotor motor with a software bug
[13:43:19] <tzanger> customer motor too, was not a good day
[13:43:30] <bss36504> monode: you're talking about building a software BIST on top of the hardware BIST.
[13:43:40] <tzanger> generally unnecessary
[13:43:54] <bss36504> You;d be better off building the rest of your system so that the safe state was better.
[13:43:56] <monode> I'm going to take your word for it
[13:44:06] <monode> but I'd really like to understand why it's unnecessary
[13:44:08] <tzanger> you apply standard failure analysis
[13:44:20] <monode> I'm not exctly sure what the "safe state' is better
[13:44:33] <tzanger> you take each subsystem and analyze its failure modes, then you take each of those and dig into the components and identify what happens if the component fails short/open
[13:44:44] <monode> for example, if it's a door, the safe state is "controlled by the user" :)
[13:44:47] <tzanger> it can get very unwieldy very fast but depending on your need it could be absolutely necessary
[13:44:56] <monode> permanently locked or permanently unlocked is bad
[13:45:22] <monode> my first guess, which seems to be right, is that I can't share any IO
[13:45:39] <bss36504> monode: It's unnecessary because statistical data from atmel says that in a large sample population, my flash will have 20yrs of retention. If you're making a power door, dont make it have an uncontrolled state that would cause it to crush somebody
[13:45:42] <monode> which means extra gates... but doesn't that mean extra ICs that could fail?
[13:46:05] <bss36504> monode: wait, what about not sharing IO?
[13:46:19] <tzanger> generally you don't design the electronics to be failsafe; you design the mechanics. cone gears, ratcheting systems, etc.
[13:46:26] <bss36504> right.
[13:46:28] <monode> bss36504: i'm not alking about a power door, i'm talking about some random issue that suddenly causes the software to lock and the door being unable to open/lock
[13:46:46] <bss36504> monode: twas an example
[13:46:58] <monode> yep.
[13:47:04] <monode> maybe i've taken my own example to the extreme
[13:47:15] <tzanger> monode: you probably want to look at code coverage and fuzzing techniques to make sure the software operates correctly as a general rule and then start screwing with inputs/esd/power and see where it breaks
[13:47:26] <tzanger> this is part of HALT/HAST testing too
[13:47:26] <monode> I guess the "safe" state would technically be "alert the security guys the door has failed, open"
[13:47:28] <bss36504> The logic carries to any other system. If you have it running with power and the micro is doing it's job fine, and you rip it out of the board, or kill power or whatever, what does your output device do.
[13:48:04] <bss36504> is your metaphorical power door going to metaphorically kill someone.
[13:48:47] <monode> let's just call it a metaphorical lock
[13:50:48] <monode> to be honest, I've never had an avr fail either
[13:50:50] <bss36504> Well breaking into things is what locksmiths are for
[13:51:21] <monode> the longest test i've run (and still do) is a bigass LFSR that's been running for two years so far
[13:51:27] <monode> the only thing i'm seeing is clock drift :)
[13:52:25] <monode> well yes, but what if it doesn't have standard mechanical locks, only electronic ones
[13:53:07] <monode> granted, I have a major dislike for any improvment that introduces microcontrollers over mechanical systems and completely phases out the mechanical systems
[13:56:49] <Roter> well, its late for me, so i will be going to sleep, will be back at the same time tommorow, and will try to see if i can fix the problem with the blinking
[13:56:53] <Roter> bye
[13:57:20] <monode> if caps and num lock are blinking in sync, something is def wrong
[14:00:21] <bss36504> monode: If you have purely electronic locks with no mechanical interaction whatsoever, you should be talking to a digital forensics person.
[14:03:19] <monode> no, of course not, i'm talking about a lock with an avr at its heart, with actual mechanical components (say, a solenoid, and a keyboard).
[14:03:37] <monode> maybe thinking the avr was the most failure-prone component was bad :)
[14:14:48] <braincracker> hello my friends :)(
[14:27:03] <illumer> Hi
[14:27:16] <illumer> I'm facing SPI issue
[14:28:33] <illumer> in proteus
[14:29:43] <megal0maniac_afk> OndraSter: Decent xmega documentation is a pain in the ass to find
[14:29:52] <monode> illumer: what issue
[14:29:54] <megal0maniac_afk> So I am using
http://myxboard.net/reference.html
[14:29:56] <monode> i played quite a bit with proteus
[14:30:59] <monode> tne SPI scope has some bugs iirc, but the hardware implementation for avr, pics and LPC20xx-s works
[14:31:08] <OndraSter> lol megal0maniac_afk
[14:32:03] <illumer> when I add specific block of code in the master code
http://pastebin.com/UeqBpk9t I get message in the SPI debugger "13.139ms SS Active"
[14:32:39] <megal0maniac_afk> OndraSter: The defines are funny and bit manipulation is weird. Datasheet doesn't help much because it's avrgcc I have issues with, not the operation of the device itself
[14:33:02] <megal0maniac_afk> It's easier to migrate to PIC than to xmega :/
[14:33:34] <braincracker> just... start over
[14:33:47] <monode> that's not an error, right click on the avr and configure diagnostics
[14:34:35] <illumer> what in diagnostic I have to configure?
[14:34:52] <monode> what's your error
[14:35:01] <illumer> it causes the SPI not to run perfectly
[14:35:13] <monode> if it bugs you that it says "SS active" disable SPI messages in the diagnostics dialog
[14:35:22] <illumer> the third motor in the slave micro does not run
[14:36:03] <monode> uhm, that sounds like a code issue, not an isis issue though
[14:37:19] <illumer> actually I had this before
[14:37:19] <illumer> and I got rid of it in very strange way
[14:37:34] <illumer> I got it when I add a global variable in the Master code
[14:38:12] <illumer> then to get the SPI work again as well as getting rid of the above message..
[14:38:31] <illumer> I add a dump variable to the slave code
[14:38:44] <illumer> with the same size
[14:39:25] <illumer> also I faced when I included stdlib.h in the Master code
[14:39:40] <monode> hmm, that actually sounds like a memory issue
[14:39:44] <illumer> again I had to add stdlib.h in the slave code
[14:40:11] <illumer> really
[14:40:24] <illumer> did I go beyond the programming memory?
[14:40:30] <monode> I recall at some point I was messing with an sd card and some longer midi messages
[14:40:48] <monode> my guess is ram
[14:41:04] <illumer> it is atmega32
[14:41:16] <monode> the stack can easily overwrite your variables if it underflows
[14:41:22] <monode> uh.. that's 2k iirc
[14:42:19] <illumer> yes, so
[14:42:24] <monode> i don't think your code could do that, I don't see any big buffers or anything, but i'm just skimming through it
[14:42:38] <monode> 300 lines is hardly something you'd expect someone to dig into :P
[14:42:53] <illumer> :)
[14:43:12] <monode> idk man, tbh I'd try a much simpler thing at first, to see how the system reacts
[14:43:24] <illumer> I didn't do it in one day either
[14:43:32] <monode> use two lines as motor_plus/motor_minus per slave
[14:43:43] <monode> at first, wire them to different pins on the master
[14:44:00] <monode> actually, you can use the CLK/MOSI lines on the slaves :)
[14:44:19] <monode> if motor_plus for a slave goes up.. the slave does motor_plus
[14:44:54] <monode> i'm guessing slaves are something fancy like at90pwm
[14:45:04] <monode> and you're simulating them with something else?
[14:45:30] <illumer> you mean controlling the motors?
[14:45:39] <monode> yeah
[14:46:02] <illumer> yeah I'm using PWM with 16 bit counter
[14:48:16] <illumer> I didn't get what you are trying to do
[14:49:36] <monode> me, nothing
[14:50:02] <illumer> what you said up
[14:50:14] <monode> I just chipped in, because you said you were using proteus, and very few people do
[14:50:35] <monode> ah nothing
[14:50:48] <monode> i was simply thinking if you could test your whole thing without spi
[14:51:11] <monode> maybe it's not a spi error after all; a lot of times i get weird errors it turns out to be a wiring thing :D
[14:51:36] <illumer> you mean to get it work individually in micros
[14:52:19] <illumer> ??
[14:53:11] <illumer> if you are talking about testing the each motor, then no need as I build it bottom-up
[14:53:36] <illumer> after testing each functionality I add the new one
[14:53:57] <monode> makes sense
[14:54:02] <monode> so what exactly did you add then
[14:54:20] <monode> before you were getting the 'ss active' message
[14:54:49] <illumer> the commented out code from line 276 to 296
[14:55:30] <illumer> actually I add the serial functionality either
[14:55:35] <illumer> but I tried to surround the error arround specific area
[14:56:02] <illumer> and that was 276-296
[15:02:58] <illumer> anyone has an idea about an SPI issue in proteus
[17:19:21] <hjohnson> I'm having the fun of getting FreeRTOS up and running on the xmega. :)
[17:38:50] <balrog-k1n> what's the best way to jump to the bootloader from my program?
[17:39:25] <bss36504> I think you need to force the watchdog to overflow.
[17:39:27] <Lambda_Aurigae> do a jump to the beginning of bootloader memory....
[17:39:34] <bss36504> or that.
[17:39:34] <bss36504> lol
[17:39:46] <balrog-k1n> i tried jumping to 0x3800 (the bootloader address indicated by the default fuse bits on atmega328p) but didn't seem to work
[17:39:55] <Lambda_Aurigae> but you need to switch the interrupt table first or it will have fits if you use any interrupts in the bootloader.
[17:39:57] * bss36504 goes back to control systems homework...
[17:40:07] <balrog-k1n> bss36504: the problem with a watchdog reset is that th ebootloader detects a watchdog reset and jump right back to the start of the program
[17:40:15] <balrog-k1n> because that's how it implements the timeout
[17:40:50] <balrog-k1n> Lambda_Aurigae: no, the bootloader doesn't enable interrupts
[17:41:07] <Lambda_Aurigae> it doesn't use any interrupts for communications or anything?
[17:41:17] <bss36504> balrog-k1n: Could you set a bit in the main program before forcing the wdt to overflow and check for the bit in your bootlader ?
[17:41:34] <balrog-k1n> it uses uart and spi, but it polls instead of using interrupts
[17:41:59] <balrog-k1n> bss36504: i guess i could
[17:42:08] <bss36504> Might be the easiest way
[17:42:24] <bss36504> just remember to reset it before you continue with the main program
[17:43:52] <Lambda_Aurigae> do you need to do anything to make the bootloader work on powerup? like press a button?
[17:45:02] <Lambda_Aurigae> if so, you will need to do the same thing when jumping directly to the bootloader at 0x3800...or have some way for the bootloader to know it was called from the main program like setting a memory location or something.
[17:48:30] <balrog-k1n> Lambda_Aurigae: no, it's like the arduino bootloader, the reset triggers it to run for 1s and listen for commands
[17:56:16] <balrog-k1n> ahhh no, the bootloader checks if the reset reason was anything other than external reset, that's why it didn't work..
[17:56:42] <balrog-k1n> i guess there's no way to trick it without modifying it
[17:59:00] <balrog-k1n> well... i *could* jump to right after the reset reason check, but that's even uglier
[18:06:30] <bss36504> Anybody seen N1njaneer on here lately?
[18:52:44] <hjohnson> hrmm.. so why isn't code autocompleting
