Back
[03:22:36] <inflex> any geniuses in the house... I've got MOSFETs screeching at me and burning up.
[03:23:05] <inflex> https://www.youtube.com/watch?v=_29IFFLT8Rw
[03:23:30] <inflex> These are just normal DCIN/BAT isolator MOSFETs (pch), they're not clocked for PWM/SMPS or anything
[03:23:51] <inflex> but for some reason, 75% of the time when I plug in the power with the battery, they screech like that
[03:23:59] <inflex> ( and if I let them go, they'll pop / burn )
[03:37:43] <theBear> you got a gate cap ?
[03:37:48] <theBear> and gate resistor
[03:47:48] <inflex> yeah, they've got all that, there's a whole lot of trickery hanging off them, so it seems like I've something leading/lagging too much and it's creating this slowish cycle (I say slow, compared to the 670~800kHz of the other SMPS MOSFETs elsewhere )
[03:51:49] <inflex> happening with multiple brands, MOSFETs, and controllers
[04:04:07] <avrdude> There is something I don't understand. I have my mcu read an ADC 8192 times as fast as it can, and then dump the data to an SD-card (also as fast as it can). I do this for about a minute, and get a few million samples
[04:04:39] <avrdude> However, there is obviously not a continuity in these samples - no samples are read while its dumping to the SD-card
[04:05:32] <avrdude> so, to make it more stable, i made a timer-based interrupt that samples the ADC at a certain interval, and then the main loop writes to the SD-card as soon as my buffer is full
[04:05:59] <avrdude> I have two buffers so that one is being filled up with data, while the other is being written to the SD-card, and so on
[04:06:51] <avrdude> However, using this method i'm not able to get nearly as many samples as i did on the first approach - why the hell not?
[04:07:19] <avrdude> My buffer is basically overflowing long before the other one has been written to the card
[05:05:38] <skz81> avrdude, because while your MCU executes ISR code, it does NOT execute your ADC reading code... Unsure if ADC can run in background, but I bet value storing into RAM is done by software...
[05:06:14] <skz81> You would need some DMA mecanism, or store in external RAM (but access to ext.RAM is slower)
[05:07:10] <avrdude> what? but my ISR code *is* is the adc-reading code
[05:07:59] <avrdude> i should mention i'm using an external ADC through SPI
[05:09:31] <skz81> ok sorry, just reverse my statement.
[05:09:50] <skz81> hum maybe not actually
[05:10:50] <avrdude> i know it will not be writing to the SD-card while sampling the ADC, but surely it will be nice interleaved, right?
[05:11:00] <avrdude> nicely*
[05:11:11] <avrdude> as in, the total time to do both should remain the same
[05:11:50] <skz81> As I read you design, is it should, except timing / buffer overflowing problems that makes you loose data, I guess
[05:12:16] <skz81> "yes, it should"*
[05:13:18] <skz81> you mean you still see regularly sampled data for a while, then a gap, and regular samples again ?
[05:13:47] <skz81> while excepting less frequent samples, but no gap, I read /understand well ?
[05:13:57] <skz81> expecting*
[05:14:23] <skz81> avrdude, ^ ?
[05:15:08] <avrdude> it starts overwriting data that hasnt been written to the SD-card yet
[05:15:22] <skz81> and don't you CLI or something while you write to SD card ?
[05:15:55] <avrdude> even though if i dont use interrupts, its able to sample way more samples and write them to the card, in the same time that i try with interrupts
[05:16:45] <avrdude> no thats the whole point, it should keep sampling the ADC while writing to the card
[05:17:00] <avrdude> brb gotta go to lunch sorry
[05:18:08] <skz81> ok no prob... Don't have much clue anyway... Unsure to understand exactly your design and the problem you're experiencing...
[05:18:49] <skz81> actually, I think I _basically_ understood the design, but the problem doesn't sound very clear to me
[05:38:10] <Jartza> pllllop
[06:34:07] <avrdude> skz81: Say that I sample the ADC 10,000 times, then write the data to an SD-card. I do this over and over again, 500 times. All this takes time T1 to complete.
[06:35:03] <avrdude> Then, when I try using an interrupt to do the sampling, while the SD-card is being written to, I can not achieve the same number of samples in the same time, not even close
[06:36:16] <avrdude> Scenario1: sample - sample - sample - sample - SD-card - SD-card - SD-card - SD-card
[06:36:41] <avrdude> Scenario2: sample - SD-card - sample - SD-card - sample - SD-card - sample - SD-card
[06:41:28] <cehteh> hardware sdi or bitbanged?
[06:42:17] <cehteh> and smaller transactions have higher transaction overhead
[06:49:00] <avrdude> it's the same sd-card transaction
[06:49:05] <avrdude> hardware spi
[06:49:55] <avrdude> i mean, its the same transaction, but it keeps getting interrupted to sample the ADC every now and then
[06:58:26] <skz81> avrdude, you mean that "sample - SD-card - sample - SD-card" gives a smaller overall sampling rate than " sample - sample - sample - sample " ?
[06:58:44] <avrdude> skz81: yes
[06:59:34] <avrdude> well, the sample rate i control by setting the interval between the interrupts, but in this case it's not able to write the data fast enough to the card
[06:59:40] <skz81> 1) do you use naked interrupt ? 2) Do you use the same SPI bus for ADC and SD card ?
[06:59:58] <avrdude> 1) don't know what that is, 2) no
[07:00:49] <skz81> 1) it could help ! It means the compiler doesn't generate prolog nor epilog for your ISR written in C
[07:00:56] <skz81> do you write it in C ?
[07:01:32] <skz81> it written naked, it can be in pure ASM (what I'm used to do) but it can be done in C as well
[07:40:17] <avrdude> it's all written in C
[07:52:42] <skz81> avrdude, ok then consider 1) decompiling your image to inspect assembly code of your ISR 2) changing optim level and back to 1) 3) if needed write a naked ISR (pure ASM or using C ISR_NAKED macro)
[07:53:19] <skz81> I'm sure it could help to increase the sample rate.
[07:54:59] <skz81> but anyway, i'm pretty sure your sampling decreases somewhat because you're interleaving SD-card code... Isn't "overall" (mean) sample rate the same ?
[07:56:37] <skz81> I mean you do N sample by doing "sample - sample - sample - sample" during T1, then "SD-card - SD-card - SD-card - SD-card" during T2 ===> sample_rate1 = N / ( T1 + T2 )
[07:57:11] <skz81> Then you read M sample doing "sample - SD-card - sample - SD-card - sample - SD-card - sample - SD-card" during T3 ====> sample_rate2 = M / T3
[07:57:29] <cehteh> you drive the adc by timer?
[07:57:37] <skz81> I would expect sample_rate1 and sample_rate2 to be approx the same
[07:58:20] <skz81> cehteh, AFAIUnderstand, yes he does
[07:59:46] <cehteh> whats your goal anyway? to sample and write as fast as possible or as precise as possible?
[08:04:27] <avrdude> skz81: i expected that too, but they're not the same
[08:04:46] <avrdude> cehteh: both :p
[08:06:04] <cehteh> both is impossible :) pick one
[08:07:05] <Lambda_Aurigae> not impossible but not doable with current setup I would say.
[08:07:07] <cehteh> also SD cards can have some unpredictable latencies
[08:07:17] <skz81> avrdude, the overhead MAY BE due to ISR prolog/epilog versus inlined code in a while() loop for example
[08:07:28] <Lambda_Aurigae> some kind of fifo memory...like dual port vram maybe.
[08:07:40] <cehteh> doublebuffering
[08:08:18] <cehteh> but you need hard gurantees that write speed matches (or is better) than your sample speed
[08:08:34] <Lambda_Aurigae> double buffering with two microcontrollers would be how I would go at it..a pair of AVRs and a pair of 1Mb serial srams.
[08:08:40] <cehteh> and your buffers cope with the worst possibly latency
[08:09:18] <Lambda_Aurigae> one avr reading ADC and writing to ram...one ram chip at a time..when it's full, signal the other avr to start dumping and switch to the other ram chip.
[08:09:41] <avrdude> well, i've already manufactured and populated my PCB, so that's kinda too late ;_;
[08:09:51] <Lambda_Aurigae> oops
[08:10:09] <Tom_itx> time for rev 2
[08:10:21] <avrdude> i was hoping for around 100kS/s, but i can only get around 70 with the interrupt method
[08:10:34] <avrdude> around 130 if i dont use interrupts
[08:10:49] <Lambda_Aurigae> interrupts in C throw a lot of overhead at you.
[08:11:02] * skz81 **whistles**
[08:11:05] <skz81> Lambda_Aurigae, I suggested external memory 3 hours ago ^^ (what implied a second MCU to write to flash)
[08:11:14] <cehteh> if you opt for a steady rate which is within your (worst) expected latency, maybe 95-99% to have some headroom, it should work well
[08:11:23] <Lambda_Aurigae> skz81, 3 hours ago I was swimming..sorry..hehe
[08:11:54] <cehteh> and yes memory is tiny on avr's .. but still double buffering (or a cyclic buffer) should be doable
[08:11:57] <avrdude> why cant they just make mcus with buttloads of ram
[08:12:05] <Lambda_Aurigae> they do
[08:12:09] <skz81> Lambda_Aurigae, I'm trying to race you... I'm just glad we came to the same idea
[08:12:13] <Lambda_Aurigae> just not low end avr
[08:12:24] <skz81> NOT* trying to race
[08:12:28] <Lambda_Aurigae> atmega1284p has 16K of sram
[08:12:37] <Lambda_Aurigae> pic32mx270f256b has 64K sram.
[08:12:47] <cehteh> the trick is to find the right batch size, possibly not write every byte to the sdcard, but do it at the SDcards prefered block size
[08:12:57] <Lambda_Aurigae> those are both dip package too.
[08:13:09] <cehteh> but at least decouple writing from sampling
[08:13:13] <Lambda_Aurigae> sd card preferrs 512 bytes at a time for best write as I recall.
[08:13:47] <cehteh> things differ, some want more some less
[08:13:53] <Lambda_Aurigae> skz81, microchip serial srams rock for this kind of thing too. you can run them in 1,2, or 4bit mode.
[08:18:04] <skz81> Hey, let's do a 4 channel logic analyzer for cheap ? ^^
[08:27:31] <avrdude> [14:43] <Lambda_Aurigae> pic32mx270f256b has 64K sram.
[08:27:35] <avrdude> are you a wizard?
[08:27:50] <avrdude> i'm using the pic32mx170f256b actually :p
[08:28:10] <Lambda_Aurigae> next chip up from that...love that chip.
[08:28:37] <Lambda_Aurigae> the 270 has hardware usb.
[08:29:16] <avrdude> it's the first non-avr chip i use actually, so it was kind of a pain to get going
[08:29:23] <avrdude> the datasheet is a bit shit tbh
[08:29:37] <Lambda_Aurigae> datasheetS
[08:29:47] <Lambda_Aurigae> as in, what, 50 or so documents?
[08:30:06] <avrdude> after 2 weeks of debugging i realized that some of the config registers were write-protected
[08:30:23] <avrdude> i punched a wall
[08:30:44] <avrdude> yea true, you need a million documents to be covered
[08:31:06] <Lambda_Aurigae> thankfully I work for a place where I can print stuff for no cost....test prints doncha know.
[08:31:07] <Lambda_Aurigae> hehe
[08:31:11] <avrdude> in the main one it just says "to unlock this very essential register, see section bla bla bla, in this other document"
[08:31:18] <avrdude> and that document didnt actually exist
[08:31:34] <avrdude> i just had to google it and luckily found it on an old forum post
[08:31:36] <Lambda_Aurigae> I bet it does..you just gotta go on a hunt to find it.
[08:50:12] <hetii> Hi ;)
[08:50:16] <hetii> Q: I have some old ATX PSU that is broke, with active pfc, can I use that PFC to other PSU that have passive PFC(huge inductor) ?
[08:50:46] <twnqx> "probably not"
[08:52:52] <specing> A: if you know what you are doing
[08:53:36] <twnqx> aren't the active PFC these days usually integrated with the primary side controllers?
[08:55:51] <hetii> this that I have is in separate board and seams that is plugged in place of diode bridge
[08:59:36] <hetii> its based on this IC \
http://www.datasheetdir.com/STMICROELECTRONICS-L6561+Power-Factor-Controllers
[09:05:05] <Lambda_Aurigae> hetii, the circuitry in the two power supplies is different...the active PFC module does not just replace a diode bridge. It replaces some other passive filtration components as well.
[09:05:24] <Lambda_Aurigae> it is not just a plug and play solution...there is a whole circuit design around it.
[09:07:51] <hetii> on my passive PSU there is not much component before diode bridge, just one caps, fuse and varistor
[09:09:18] <hetii> in active PSu there was additional inductor and smal transformer before PFC so I can grab it also from that board
[09:09:34] <hetii> cause in my non active psu have places for it
[09:23:40] <rue_house> the PFC is just a boost supply that rides the AC better than a bridge will
[09:24:18] <hetii> so can I replace it or it is designed just for specific ATX board ?
[09:24:20] <rue_house> instead of only drawing current for about 5-10% of the wave peak, the boost supply will draw current for about 70% or so of it
[09:24:55] <rue_house> PFC is used for high power supplies, whats your wattage need to be?
[09:25:16] <rue_house> about 600+ watts
[09:26:01] <hetii> well in my case I will just use this PSU to power odroid xu4 + atmega + around 2m of ws2812b led strip and 1m regular RGB led and 1m white led
[09:26:33] <rue_house> that not much power, maybe 3 or 4 A
[09:27:11] <rue_house> even a woos computer supply should do that
[09:27:14] <hetii> as I read spec for this led 1m 30 leds with ws2812b need 3.6A
[09:27:30] <rue_house> !? for 1m?
[09:27:49] <hetii> so for 2m around 7.2A just on 5v rail regarding leds
[09:27:51] <hetii> yep
[09:28:12] <rue_house> didn't know those things were THAT power hungry
[09:28:48] <hetii> 18W per 1m @5v
[09:29:58] <twnqx> they are
[09:30:48] <hetii> so I have around 12 or more ATX psu, most of them dead. but one if it is from my old pc, more modern, that don`t need load resistor at 5v rail to get stable 12v
[09:30:52] <hetii> thats why I decide to use it
[09:31:04] <hetii> but its passive PFC
[09:32:35] <rue_house> well, the load rating on the 12V rail is uaulyl about 12A or better
[09:32:41] <specing> I have single led flashlight that does 25W peak
[09:32:45] <rue_house> and the 5V is ususaly at 23A or better
[09:33:03] <specing> 1m led strip taking 18W is nothing
[09:33:40] <rue_house> how many of hte supplies are by "One day" or was it "Won day" or Delta?
[09:33:50] <rue_house> the dead ones
[09:33:54] <rue_house> who made them
[09:36:13] <rue_house> I cant recall the other name to avoid, S-------
[09:38:47] <specing> LC Power
[09:39:05] <rue_house> that rings a bell as being a bad one
[09:39:11] <specing> yup
[09:39:14] <specing> LC Fire
[09:40:38] <rue_house> I came to the conclusion at some point that bad caps on either the motherbaord or the power supply can kill the other caps
[09:41:01] <rue_house> this is rue being late for work
[09:41:02] <rue_house> ARG
[09:41:18] <rue_house> If I didn't ahve to eat and sleep this wouldn't be an issue
[09:42:51] <hetii> I have EMI filter design similar to this:
https://www.electronicspoint.com/attachments/atx-jpg.20184/ is it important of T1 inductor ? Can it be after T5 ?
[09:43:03] <Lambda_Aurigae> rue_house, yes, they can...one goes, it puts a heavy load on the others and they go.
[09:43:48] <rue_house> T1 should be before C4
[09:43:55] <rue_house> its easing the current to it
[09:44:15] <rue_house> and C4 should be on the input to T5...
[09:45:13] <hetii> well in the board with active pfc where this T5 was there is no C4 at all just one coil on AC side and varistor
[09:45:25] <rue_house> isn't it great how closing that one connection makes it a voltage doubler?
[09:46:08] <rue_house> often they cheap out and just remove parts for unimportant things like power filters that only extend product life
[09:47:09] <hetii> true.
[09:47:25] <hetii> so I don`t have place for T1 on AC side
[09:47:29] <rue_house> 3-5c/device right into their pocket
[09:47:59] <hetii> just can put it after T5 instead fuse (the fuse itself I put on front panel)
[09:48:01] <rue_house> thats $30 on 1000 units
[09:48:50] <hetii> but if you said that it make no sense to give it after T5 than I can drop it.
[09:49:14] <rue_house> its like "why bother writing programs that dont ahve memory leaks, people have lots of ram and aren't going to laeave the program running long enought o have a problem anyhow/"
[09:49:57] <hetii> well good question, but I like to improve things if possible :_)
[09:50:56] <rue_house> and why make a product that lasts more than 16 months? nobody uses anything for more than 16 months and for the small percentage that do, just give them a warranty replacement
[09:51:01] <rue_house> money in your pocket
[09:51:34] <rue_house> its not like you have to deal with the waste generated by all that junk
[09:52:16] <rue_house> ship, profit, and forget
[09:52:31] <rue_house> and if you get trouble, just close the company and start another one
[09:53:04] <hetii> In my case I love long term hardware
[09:53:39] <rue_house> hard to find with the attitudes of almost all manufacturers these days
[09:54:12] <rue_house> "people wont use more than 400w, but they want bigger numbers, put a 1200W label on these 400W supplies"
[09:54:45] <hetii> last days I clean coffee grinder and food processor both have over 30 years and still perfect condition
[09:55:10] <hetii> the motors inside works much better then brand new one that I saw
[09:55:34] <twnqx> rue_house: speaking of PSUs, any idea how to make one that takes 12VDC to 250VAC at ~120W? :>
[09:56:01] <rue_house> gtg bye!
[09:56:04] <twnqx> i keep thinking that a pfc stage should not care even at DC input.
[10:03:06] <hetii> I wonder what is inside my passive PFC:
http://hardwareinsights.com/wp/wp-content/uploads/2011/11/Fake-PFC-1.jpg
[10:03:38] <hetii> What`s the point for manufacturer to even add such crap :/
[10:03:58] <twnqx> make more money
[10:05:03] <hetii> sure but they will earn even more when don`t put this fake coil
[10:05:20] <twnqx> but everyone you see that there's nothing then
[10:05:38] <twnqx> this way they put a real one nto the demo parts, and use the fake in mass delivery
[10:06:52] <hetii> imho if someone know something about ATX PSU then will select one with active PFC.
[10:07:19] <twnqx> most people do not know shit and go by price though
[10:07:48] <hetii> thats true, thats why for them is not important if they have fake PFC or none :)
[10:12:39] <hetii> I wonder if for my leds setup need to have fan on that PSU
[10:18:55] <hetii> hmm something tell me that yesterday I spend half day to put wire from my TV to box where this PSU will be for nothing...
[10:19:57] <hetii> My plan was to use 4 wire of CAT5e to power this leds behind TV
[10:20:58] <hetii> but now probably the voltage drop will be massive on it
[10:38:22] <hetii> Q: Why some EMI filters have reistor parallel to coils ? some of them have on one side some on both side, some just capacitors ?
[10:38:31] <hetii> or none
[10:43:38] <avrdude> i would ask in ##electronics
[10:43:51] <bss36504> or on electronics.stackexchange\
[10:49:51] <specing> hetii: throw propaganda display away and you wont have these problems anymore
[10:50:41] <hetii> well I like to know,
[10:51:16] <hetii> on this site you can see most of different configuration
http://danyk.cz/s_atx_en.html
[10:51:50] <hetii> so there must be some reason why in such and not other way of design it.
[10:59:48] <bss36504> I mean, the simple answer is that the designer needed the filter to behave a certain way, so it was designed to do that.
[10:59:55] <bss36504> I realize that's a half-assed answer
[11:00:07] <bss36504> but I imagine the why varies on a case by case basis.
[11:16:07] <twnqx> http://i.imgur.com/d36ou7L.png so i made this schematic too long ago. anyone with an idea what the diodes on the right could be for? something like freewheeling diodes to drive inductive loads?
[11:18:06] <bss36504> what are you trying to do?
[11:18:16] <bss36504> Just looks like a bunch of transistors and resistors without context
[11:31:48] <twnqx> driving higher voltage loads from a microcontroller
[11:32:00] <twnqx> that part works (as per simulation at least)
[11:33:26] <twnqx> µC signals (3.3V) on the left, amplified outputs on the right (24V/a few 100 mA)
[11:35:23] <twnqx> the rightmost part is just driver circuitry to drive the p-channel mosfets on the right
[11:35:29] <twnqx> errr leftmost part*
[11:51:48] <bss36504> Any particular reason to use PFETs for the output?
[15:40:58] <twnqx> bss36504: sorry, had to hit the road. i can't really remember, sadly. just as with the diodes.
[15:49:16] <bss36504> No worries. I know you're not planning on tons of current, so power dissipation isnt as much of an issue, but that setup is going to switch considerably slower than if you used a gate driver (with boost) or NFETs on the low side
[15:50:40] <twnqx> speed is even less of an issue :P
[15:50:53] <twnqx> i expect MAYBE 10 toggles/day
[15:53:01] <bss36504> oh lol. alright then
[15:53:06] <bss36504> whatever floats your boat
[16:00:13] <Lambda_Aurigae> usually water
[16:01:38] <bss36504> Unless your boat is made of aluminum foil and is floating on a sea of sulfur hexaflouride.
[16:03:48] <antto> they see me floatiiin', they hatiiin
[17:51:10] <joebobjoe> in the ATtiny85 datasheet, table 20-2 says debugWire is disabled with both lock bits set, but then above that it says debugWire is enabled when both lock bits are set
[17:51:13] <joebobjoe> I'm confused
[17:55:24] <specing> Huh? Its time to debug the debugging part of the datasheet. Makes for some debug-ception
[17:56:53] <joebobjoe> specing: do you see what I'm saying though?
[18:02:30] <joebobjoe> even chapter 18 of the datasheet implies debugWire is disabled when lock bits set
[18:02:32] <joebobjoe> I'm confused
[18:03:14] <joebobjoe> and weirdly the fuse high byte table says that after debugWire is enabled the device can be programmed via high-voltage serial mode only
[18:03:28] <joebobjoe> even though debugWire section says it can program memory...
[18:03:29] <joebobjoe> wut
[18:04:00] <joebobjoe> you'd think the sections of the datasheet that involve topics that can actually brick your device in production would be crystal clear
[18:28:41] <Casper> joebobjoe: there is some weird stuff going on with the fuses... see, an unset fuse is 1, so a set one is 0, but default value can be 0 and you enable it with 1, or enable with 0....
[18:28:50] <Casper> which lead to some nice confusions
[18:31:05] <specing> I call it job security! :D
[18:36:05] <joebobjoe> I call it I'm just gonna use PIC
[18:37:27] <specing> joebobjoe: go one step further and grab a stm32
[18:38:34] <specing> where you actually get a working debugger for less than $5
[18:38:57] <joebobjoe> specing: then why are you in #avr ;)
[18:40:08] <specing> I'm backwards compatible
[18:41:03] <joebobjoe> great so I just wasted all my time learning about avr
[18:42:51] <specing> pretty much. I date back to a time when PIC and AVR were all the cool kids were using (used both myself)
[18:44:17] <joebobjoe> specing: well PIC is still good for 8 bit right?
[18:45:19] <specing> LOL
[18:45:38] <specing> there is not even a proper C compiler for that, let alone an Ada one
[18:46:47] <joebobjoe> specing: what do you mean
[18:46:53] <joebobjoe> specing: you're forced to write assembly?
[18:46:59] <joebobjoe> avr 8 bit has a c compiler
[18:48:16] <specing> joebobjoe: there is the SDCC and various turds you can get in commercial packages (microc,...)
[18:48:52] <specing> for AVR and cortex-m architectures you have full gcc support
[18:49:51] <joebobjoe> wow I thought everybody was recommending PIC. but there is no standards compliant C compiler for it?
[18:50:09] <Lambda_Aurigae> standards?
[18:50:12] <Lambda_Aurigae> compliant?
[18:50:15] <Lambda_Aurigae> for anything?
[18:50:15] <specing> :D
[18:50:23] <Lambda_Aurigae> there is a C compiler..several actually...for pic.
[18:50:35] <specing> GNAT GCC is a standards compliant Ada compiler
[18:50:36] <Lambda_Aurigae> not an open source one that's really usable though.
[18:50:54] <specing> sdcc is usable (used it a decade ago)
[18:51:07] <Lambda_Aurigae> but just because the compiler for pic is not free doesn't mean it's not a real C compiler.
[18:51:14] <specing> It is not hard to produce a standards compliant C compiler
[18:51:22] <specing> as the standard is pretty slim
[18:51:43] <Lambda_Aurigae> pic is usable for certain things...pic32 much better.
[18:51:58] <specing> if you read the 250 pages of K&R (other languages have 1000+), there are "implementation defined" and "undefined behaviour" on almost every page!
[18:52:02] <Lambda_Aurigae> not sure where joebobjoe got the "everybody was recommending PIC" thing though.
[18:52:21] <Lambda_Aurigae> K&R is my programming bible!
[18:52:33] <specing> its a bible alright
[18:52:41] <specing> with so many things left to reader's imagination
[18:52:47] <joebobjoe> people say pic is easier to use
[18:52:55] <joebobjoe> avr has alike a million instructions
[18:53:48] <Lambda_Aurigae> pic has NEVER been easier to use.
[18:53:50] <joebobjoe> I wonder why SPIEN and RSTDISBL are separate fuses. when would you ever want SPI disabled but RESET enabled
[18:53:54] <joebobjoe> oh
[18:53:59] <specing> Why is that a metric for you? Are you interested in being an assembly programmer?
[18:54:05] <Lambda_Aurigae> spien and rstdisbl do Different things
[18:54:07] <joebobjoe> well maybe their datasheets are easier to read and not full of typos
[18:54:21] <Lambda_Aurigae> AVR datasheets are much better than PIC any day.
[18:54:26] <joebobjoe> really?
[18:54:40] <Lambda_Aurigae> SPIEN enables the ISP programming mode.
[18:54:44] <specing> I'm pretty sure that ATMEL datasheets are the best there is
[18:54:49] <Lambda_Aurigae> RSTDISBL disables the reset pin.
[18:55:03] <Lambda_Aurigae> pic has been around for the hobby world longer than avr.
[18:55:04] <joebobjoe> Lambda_Aurigae: but you need RESET to do ISP
[18:55:12] <Lambda_Aurigae> no...
[18:55:21] <Lambda_Aurigae> well..yes
[18:55:22] <Lambda_Aurigae> but
[18:55:23] <joebobjoe> you need RESET enabled
[18:55:42] <Lambda_Aurigae> you can use the RESET pin with 12V instead of 5V if the reset pin is disabled
[18:56:00] <joebobjoe> Lambda_Aurigae: but that has nothing to do with SPIEN
[18:56:00] <Lambda_Aurigae> you just have to use HVSP or HVPP rather than ISP
[18:56:50] <Lambda_Aurigae> SPIEN disables the ISP interface...meaning you have to use JTAG or DW to program the chip.
[18:56:56] <joebobjoe> Lambda_Aurigae: the only reason I can think of to disable ISP when RESET is enabled is if you want to do reset without inputs on the USI pins interferring
[18:57:13] <joebobjoe> Lambda_Aurigae: the chip doesn't support JTAG
[18:57:17] <joebobjoe> ATtiny85
[18:57:25] <Lambda_Aurigae> then it probably supports something like debugwire
[18:57:34] <joebobjoe> yea but what good does that do
[18:57:37] <joebobjoe> you're just limiting yourself
[18:57:56] <Lambda_Aurigae> bingo
[18:58:02] <Lambda_Aurigae> to keep people from reprogramming the chip
[18:58:05] <joebobjoe> I think it has more to do with what I said previously. since ISP pins share with USI pins, you don't want those pins interferring when you've reset
[18:58:15] <joebobjoe> Lambda_Aurigae: but people can just use HVSP
[18:58:27] <Lambda_Aurigae> yes, but makes it more difficult.
[18:58:43] <joebobjoe> Lambda_Aurigae: I think only the lock bits matter for security
[18:59:15] <Lambda_Aurigae> lock bits prevent reading the chip.
[18:59:20] <joebobjoe> yea
[18:59:33] <joebobjoe> why would I care if someone programs the chip
[18:59:44] <joebobjoe> as long as they can't read my code
[19:00:40] <Lambda_Aurigae> not sure.
[19:00:54] <Lambda_Aurigae> you sure HVSP works with SPIEN disabled?
[19:01:51] <joebobjoe> Lambda_Aurigae: 100%
[19:01:54] <joebobjoe> according to datasheet
[19:02:07] <joebobjoe> you can *always* reprogram with HVSP
[19:02:10] <joebobjoe> you just have to chip erase
[19:02:45] <Lambda_Aurigae> then the use for it...unknown.
[19:02:57] <joebobjoe> now I'm kind of confused between RSTDISBL and DWEN... do I need to keep RSTDISBL unprogrammed to use debugWire?
[19:03:23] <Lambda_Aurigae> ummm...dunno.
[19:03:30] <joebobjoe> Lambda_Aurigae: I figured out the use. I said twice earlier. you don't want external inputs to program the chip if you're doing a reset in-circuit
[19:04:07] <Lambda_Aurigae> ok
[19:06:01] <joebobjoe> that makes sense right?
[19:06:16] <Lambda_Aurigae> yup.
[19:06:18] <Lambda_Aurigae> kinda
[19:06:30] <Lambda_Aurigae> it's a very specific set of pulses to go into programming mode properly.
[19:06:47] <Lambda_Aurigae> I suppose you could reproduce it by accident.
[19:11:41] <joebobjoe> I want to make a HVSP with my raspberry pi!
[19:13:14] <Lambda_Aurigae> you will need a 12V source.
[19:14:00] <Lambda_Aurigae> I was able to fake one with a max232 chip once.
[19:15:08] <joebobjoe> I just connect my car battery ok
[19:16:08] <Lambda_Aurigae> sure.
[19:18:49] <enhering> carabia no more?
[19:20:04] <Lambda_Aurigae> he got kicked and never came back.
[19:20:29] <Lambda_Aurigae> I wouldn't have thought he could take a hint..guess I misjudged him.
[19:20:49] <joebobjoe> what did he do
[19:21:01] <Lambda_Aurigae> got mouthy with the wrong person.
[19:21:05] <enhering> Is he still around? I'd like to talk to him.
[19:21:20] <Lambda_Aurigae> that makes one of us.
[19:21:47] <Lambda_Aurigae> I've had him on ignore for a while.
[19:22:04] <joebobjoe> what is ignore
[19:22:17] <Lambda_Aurigae> so I can't see anything he posts.
[19:22:19] <enhering> How do I call on private? /msg?
[19:22:27] <Lambda_Aurigae> enhering, yes.
[19:22:28] <joebobjoe> oh, that's rude
[19:22:38] <Lambda_Aurigae> joebobjoe, yes.
[19:22:44] <Lambda_Aurigae> but he is annoying as hell.
[19:23:03] <enhering> I am too, Lambda_Aurigae.
[19:23:07] <joebobjoe> how can someone be annoying enough to actually not want their messages to show up in a multi-user room
[19:23:12] <Lambda_Aurigae> enhering, nowhere near.
[19:23:33] <Lambda_Aurigae> joebobjoe, his messages would show up in the room...but I wouldn't see them.
[19:23:41] <enhering> Got his email address, Lambda_Aurigae?
[19:23:49] <Lambda_Aurigae> why would I have his email?
[19:23:58] <enhering> no idea. Just asking.
[19:24:31] <Lambda_Aurigae> I wasn't his friend.
[19:24:53] <enhering> I ask questions here and get lots of biased answers, disguised as unbiased. I prefer undisguised biased, like his answers.
[19:25:13] <Lambda_Aurigae> so go chat with him.
[19:25:20] <enhering> Not available.
[19:25:30] <enhering> Probably offline, or under another nick
[19:25:52] <enhering> You give good answers, Lambda_Aurigae. By the way.
[19:26:00] <Lambda_Aurigae> bah.
[19:26:05] <Lambda_Aurigae> I'm a bastard and admit it.
[19:26:12] <Lambda_Aurigae> I'm biased all to hell.
[19:26:32] <enhering> Better an assumed bastard than a lamb
[19:26:58] <joebobjoe> if he is so annoying then why do people want to talk to him
[19:27:17] <enhering> I'll go to hell, but I do not know how long they will let me stay there. I'm just behaving to understand the environment.
[19:27:41] <enhering> Question, I've got one.
[19:27:46] <enhering> By the way.
[19:28:28] <Lambda_Aurigae> joebobjoe, dunno...I wouldn't want to do so.
[19:28:58] <Lambda_Aurigae> if you have a question, ask it.
[19:30:15] <rue_house> anyone actually talking about anything?
[19:30:45] <joebobjoe> is this true? The SPI Interface is only capable of reading fuses, reading signature and performing a chip erase when the DWEN fuse is un-programmed.
[19:30:48] <joebobjoe> http://www.atmel.com/webdoc/atmelice/atmelice.connecting_debugwire.html
[19:31:06] <joebobjoe> that doesn't make sense
[19:31:06] <rue_house> dw?
[19:31:13] <rue_house> maybe for the small chips
[19:31:22] <enhering> I tried to develop a protocol for transmitting data through SPI, but I'm struggling so much with it that I'm thinking of adopting the same system as sensor manufacturers use. Call a number, get a byte, call another number, get another byte. The question is if there is a proved working way of communicating multi byte transmissions via SPI.
[19:31:37] <rue_house> for the larger ones you ahve to make sure not to turn off spi, whicn you can only do via jtag
[19:31:57] <rue_house> enhering, which chip?
[19:31:59] <Lambda_Aurigae> rue_house, through jtag or HVPP
[19:32:09] <enhering> ATmega328p
[19:32:19] <rue_house> I did a slave adc with a tiny26 and it was a nightmare, so I modified my protocol
[19:32:33] <rue_house> the 328 should have a full blown proper spi system
[19:32:54] <rue_house> isn't hvpp spi disabled with disabled spi?
[19:32:57] <enhering> rue_house: I read something about using Atmel ICE in debug mode, requiring a special fuse setting before actually doing any debug
[19:32:58] <Lambda_Aurigae> rue_house, I think his problem is not communication but knowing what to read how/when for multi-byte data
[19:33:00] <Tom_itx> MAX662 will get you the 12v you need
[19:33:04] <Tom_itx> for HVPP
[19:33:22] <rue_house> DO NOT DEBUG USING THAT SUPID DEBUG SYSTEM
[19:33:23] <rue_house> arg
[19:33:31] <Lambda_Aurigae> rue_house, was my qiestion
[19:33:31] <joebobjoe> rue_house: shouldn't it say "...when the lock bits are enabled" not "when teh DWEN fuse is un-programmed"
[19:33:46] <rue_house> Lambda_Aurigae, exactly, I ahve a two byte packaet, and so i have a special sync system
[19:34:08] <rue_house> Lambda_Aurigae,
[19:34:26] <enhering> rue_house: I have a four byte packet, and my system is loosing sync due to mystical reasons.
[19:34:32] <rue_house> oh I didn't post it
[19:34:47] <rue_house> enhering, you didn't build sync into the protocol?
[19:35:05] <enhering> Say it again in english, please, rue_house
[19:35:11] <rue_house> Lambda_Aurigae, oh, its not yours its his
[19:35:28] <Lambda_Aurigae> yeah..
[19:35:29] <enhering> it is mine, indeed.
[19:35:31] <rue_house> enhering, your packet does not have a way of you knowing which byte is which?
[19:35:32] <Lambda_Aurigae> I just use i2c.
[19:36:18] <rue_house> 0CCCCVVV
[19:36:18] <rue_house> 1VVVVVVV
[19:36:19] <rue_house>
[19:36:19] <rue_house> C = channel 0->10
[19:36:19] <rue_house> V = value
[19:36:21] <enhering> rue_house: it should. Was designed to. But it is loosing sync and I'm too stupid to understand why
[19:36:38] <rue_house> enhering, if you get a byte that starts with a 0, its the first byte of the packet
[19:36:46] <enhering> This is what I do.
[19:36:55] <enhering> Ah, no.
[19:36:58] <rue_house> are you using 115200 baud?
[19:37:12] <rue_house> (are you usig more than 19200 baud?)
[19:37:18] <enhering> I use a zero as a start, not a byte with a zero as the first bit
[19:37:40] <enhering> I'm using fsck/4
[19:37:54] <Tom_itx> why you cussin out 4?
[19:37:57] <enhering> and FCPU as 8MHz
[19:38:21] <rue_house> enhering, is it synchronous or async serial?
[19:38:25] <enhering> Because the datasheet of atmega 328 says fsck/4 is the maximum recommended for master spi
[19:38:31] <enhering> it is SPI
[19:38:34] <rue_house> k
[19:38:41] <rue_house> what are you talking to?
[19:38:42] <Tom_itx> rue_house
[19:38:48] <Tom_itx> i found my program
[19:38:52] <rue_house> ah
[19:39:00] <rue_house> I'm falling asleep :/
[19:39:04] <Tom_itx> i completely forgot about it
[19:39:12] <enhering> I can show you some code. But it would make you sleep earlier
[19:39:16] <rue_house> pdftk
[19:39:17] <rue_house> you said
[19:39:22] <Tom_itx> yeah
[19:39:30] <Tom_itx> works really well
[19:39:37] <rue_house> cool
[19:39:42] <Tom_itx> did like 300 pages
[19:39:46] <enhering> Lost sync here
[19:39:48] <rue_house> I took the stuff to stay awake
[19:40:01] <Tom_itx> it'll kick in around bedtime
[19:40:16] <rue_house> enhering, and you dont process the bytes in the interrrupt, right, you just stack them for main loop to handle, right?
[19:40:50] <enhering> Master asks without interrupt. Slave is interrupted to answer, but slave works ok
[19:41:06] <rue_house> at full master rate?
[19:41:16] <enhering> rue_house: fsck/4
[19:41:27] <rue_house> 250kbytes/sec
[19:42:18] <enhering> https://gist.github.com/enhering/6df351d7a76ab76c1c5aeb9ecc3c3a5f
[19:42:27] <rue_house> you have 16 instructions to deal with the byte before the next one arrives
[19:42:39] <rue_house> er 32 instructions
[19:42:50] <enhering> Not many.
[19:43:56] <rue_house> thats not the code that happens on interrupt is it?
[19:44:04] <enhering> slave side:
https://gist.github.com/enhering/d1180c0deb732c3158078ef0d37fb9cd
[19:44:27] <enhering> Nope. This is the interrupt managed code.
[19:45:24] <enhering> I cannot see why bytes are being missed, but some are.
[19:45:43] <rue_house> void AMGP::ManageSPIRequest() will never be fast enough
[19:46:14] <rue_house> slow the transfer rate down to about fsck/256 and see if it works
[19:46:39] <enhering> It is answering well, up to freq/4 to an arduino that blindly asks for that in the right sequence.
[19:46:41] <rue_house> your interrupts are taking too long, and their getting burried
[19:47:01] <rue_house> ok, dont check it at a slower speed
[19:47:11] <rue_house> you ahve 32 __instructions__ to process the byte
[19:47:13] <enhering> I'll do that now.
[19:47:19] <rue_house> not C++ lines
[19:47:25] <rue_house> __instructions__
[19:47:34] <rue_house> less if there is a jump or branch
[19:47:35] <enhering> I understand
[19:47:38] <rue_house> ok
[19:47:44] <enhering> Thanks.
[19:47:49] * rue_house puts the wiffle bat away
[19:48:23] <enhering> I hope to learn enough english to understand what is a wiffle bat
[19:48:39] <rue_house> and have debugging OFF when you do the test
[19:48:51] <rue_house> debugging will screw things up
[19:49:07] <rue_house> (part of the reason not to use the on-chip debugging)
[19:49:46] <enhering> I can check the code via uart. I ask questions to the master microcontroller via uart and it shows me the data.
[19:50:14] <enhering> I also have a blinkg led to help me.
[19:50:27] <enhering> blinking...
[19:50:37] <enhering> Thanks.
[19:50:53] <joebobjoe> I wish there was a way to tell C "only compile this function if you can do it in less than x instructions, or less than y microseconds (based on clock setting or something)"
[19:51:26] <enhering> I wish I could tell the compiler not to optimize a function.
[19:52:00] <enhering> I lost one week with a stupid problem that disappeared when I switched off size optimization
[19:54:39] <joebobjoe> then you were probabl relying on undefined behavior
[19:58:01] <enhering> Please explain, joebobjoe
[20:00:49] <joebobjoe> compiler optimizations rely on behavior not defined by the C specification
[20:01:16] <enhering> You do not use them?
[20:01:27] <joebobjoe> you're not supposed to but it's often unavoidable
[20:02:00] <joebobjoe> like for example, converting an unsigned to a sign is implementation specific if the unsigned value can't fit into the signed
[20:02:13] <joebobjoe> that's not really undefined behavior, but its cousin, implementation specific behavior
[20:03:14] <enhering> Hum...
[20:03:18] <enhering> Makes sense
[20:05:19] <joebobjoe> can you link the function?
[20:05:33] <enhering> which one?
[20:13:17] <joebobjoe> nvm
[23:19:03] <enhering> Hi.
[23:19:07] <enhering> Good news.
[23:19:09] <enhering> https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller/log/53084-sensor-data-via-wifi-and-serial-connection
[23:19:17] <enhering> Thanks for all the help and patience.
[23:25:43] <enhering> Lambda_Aurigae?
[23:26:05] <enhering> No comments at all?
[23:26:06] <enhering> :)
[23:49:43] <CapnJ> Hello
[23:56:50] <enhering> Hi
[23:57:36] <enhering> Everybody seems to be sleeping here now
[23:58:25] <CapnJ> Weird
[23:58:48] <CapnJ> Why would they leave their user logged here?
