Back
[00:46:01] <ferdna> i need help with an led...
[00:46:17] <ferdna> i have this voltage regulator... however my led is way too bright...
[00:46:29] <ferdna> i had a 300ohms resistor on it...
[00:46:33] <ferdna> now i have a 1.5k ohm...
[00:46:45] <ferdna> and still too bright... can i take it down a little more?
[00:48:48] <Casper> go for 10k?
[02:23:03] <rue_bed> ferdna, is it white?
[02:23:24] <rue_bed> and your trying to make it be just a nightlight or so?
[02:23:37] <Casper> rue_bed: do you have experience with 2 stroke engines?
[02:24:44] <rue_bed> yes
[02:25:00] <rue_bed> are you having a problem with an engine?
[02:25:40] <Casper> johnson boat engine from I think '79, 6hp, twin cylinder. No gas going to the cylinder, pump is working, the bowl get fuel, it do not overflow
[02:26:20] <Casper> if I drip fuel in the intake, the engine work
[02:26:41] <rue_bed> take the carb apart and find the hole thats supposed to be in the aluminum piece, but corroded shut
[02:26:42] <Casper> carburetor appear clean
[02:27:04] <Casper> compressed air appear to pass throught every single hole
[02:27:09] <rue_bed> there is a tiny hole in something brass or aluminum thats plugged
[02:27:33] <rue_bed> and its close to the bowl
[02:27:52] <Casper> all the tiny holes appear fine
[02:28:14] <Casper> there is 2 in front of the throttle plate (engine side), 1 bigger behind, and 2 more behind
[02:28:14] <rue_bed> well, I'v told you what it is, the rest is up to you
[02:28:25] <Casper> plus a pipe in the middle
[02:28:53] <rue_bed> that or the needle valve for the float is stuck
[02:29:01] <ferdna> rue_bed, no its not white... its green...
[02:29:05] <rue_bed> which is less likley
[02:29:23] <rue_bed> ferdna, you want it really dim?
[02:29:27] <ferdna> yes
[02:29:34] <Casper> the needle valve is fine
[02:29:44] <Casper> I emptied the bowl, and it filled up fine
[02:29:50] <Casper> and do not overflow
[02:29:55] <Casper> so it open and close
[02:30:00] <rue_bed> Casper, you didn't notice the plugged hole
[02:30:14] <rue_bed> its small, like 24 gauge wire small
[02:30:21] <rue_bed> prolly 2 of them
[02:30:38] <rue_bed> ferdna, 10k makes an led pretty dim, even a high efficiency one
[02:30:41] <Casper> 5 holes on the top... none on the bottom it seems
[02:31:04] <ferdna> rue_bed, casper suggested that...
[02:31:10] <rue_bed> Casper, you missed it, till you scour the pipe, your not gonna find it
[02:31:14] <ferdna> but will it be too dim?
[02:31:27] <rue_bed> how the hell should I know how dim you want it?
[02:31:39] <rue_bed> why dosn't everyone just TRY the advise they been given!?
[02:31:58] <ferdna> its an indication light so it has to be visible to human eye...
[02:31:59] <rue_bed> atleast I consider other peoples advise
[02:32:10] <ferdna> i mean tou have to be able to see that it is on
[02:32:23] <rue_bed> ferdna, 10k on a high eff led is visable, but rather dim
[02:32:33] <rue_bed> you can see that there is light
[02:33:12] <rue_bed> the amount of light observed depends on the led, the voltage of the power supply, the resistor, and the blindness of the human observing it
[02:33:19] <ferdna> rue_bed, awesome that is what i need :)
[02:33:48] <rue_bed> all humans are blind, too, just incase someone was gonna argue that
[02:34:03] <ferdna> hahaha
[02:34:08] <rue_bed> sometimes its mental blindness
[02:39:05] <rue_bed> ferdna, I usually run leds at 3.6mA, which is usually quite visable, but it can be too bright for high efficiency leds. some of them produce a lot of light at just 0.12mA
[02:40:17] <ferdna> yeah
[02:40:19] <ferdna> :P
[02:41:02] <Casper> as I said, try and see
[02:41:21] <Casper> nobody knows what you want exactly, and what led efficiency you have
[02:42:02] <ferdna> thank you, thank you :)
[03:24:25] <EI24> Hi, i'm reading through the schematics of euzebox in order to understand the resistor DAC used to output color to scart. The MCU is a atmega644 in DIP package, i had read through the datasheet trying to find the output voltage of the I/O pins, but didn't find anything. Though i found on the arduino page the current of the current of the I/O pins on the atmega328. Does anybody know the voltage of the I/O pins on atmega644?
[03:26:01] <EI24> im happy if anybody could point to a section in the datasheet that describes this
[03:26:19] <Xark> EI24: Same as VCC (so likely 5v for UzeBox). The ones I have seen (NTSC) use an encoder chip (and are overclocked to ~27MHz).
[03:28:45] <EI24> Xark, ok thx! Yes the AD725, seems like a nice chip. though scart is easier for me
[03:29:21] <Xark> Cool (I have no SCART displays).
[03:33:29] <EI24> Xark, i would like to use composite if i could. though when i read a little about how it works, i realized it's not as simple as it seems. Though i am thinking of ordering a ad725
[03:35:26] <Xark> It is possible to do color NTSC without encoder, but it is tricky (and usually limited to ~16 colors etc.). Encoder makes it much easier (and better quality).
[03:36:06] <EI24> yep thats what i read
[03:36:33] <EI24> (that it was tricky) didnt know it was limited to 16 colors
[03:40:13] <Xark> Doesn't have to be, but that makes it easier (like Apple II etc.) ->
http://hackaday.com/2013/03/27/color-ntsc-video-directly-from-an-avr-chip/
[03:41:41] <Xark> Some nicer stuff here (but more components) ->
http://sagargv.blogspot.com/2014/07/ntsc-demystified-color-demo-with.html
[03:47:33] <EI24> Xark, cool! though a AD725 i think reduces alot of work from the MCU. I want the MCU to work as a simple dedicated GPU
[03:47:47] <EI24> and another MCU that sends what to be outputted where
[06:59:38] <aditya3098> Hi, I am working on a small project that requires me to read the data from 5 seven segment displays through an atmega32 or similar. There seems to be an 8051 mcu behind the ssd (I cant mess with it), and it seems to switch between the 5 ssds with a select pin. Any help?
[07:01:54] <Lambda_Aurigae> aditya3098, read data from a 7 segment display?
[07:02:04] <Lambda_Aurigae> it's a display, not something easily readable.
[07:02:13] <Lambda_Aurigae> need more detail on what you are trying to do.
[07:03:52] <aditya3098> I have an electric meter, that has 5 seven segment "digits" on it. I need to be able to use a seperate mcu to figure out what number is being shown on a given display
[07:04:46] <Lambda_Aurigae> tie into the lines that drive the display and read them.
[07:04:48] <LeoNerd> Ah, you're probably building a similar thing to me then
[07:04:50] <Lambda_Aurigae> but that's gonna be fun.
[07:04:59] <LeoNerd> A matrix scanner
[07:05:01] <Lambda_Aurigae> because most meters do scanning
[07:05:13] <Lambda_Aurigae> they don't just turn on all the segments on all 5 at once..
[07:05:25] <Lambda_Aurigae> they turn on one digit at a time.
[07:05:30] <aditya3098> The thing about the lines is that they are only on for 20% of the time.
[07:05:34] <aditya3098> Exactly
[07:05:38] <LeoNerd> Yah
[07:05:39] <Lambda_Aurigae> you could use a bunch of photodiodes or phototransistors.
[07:05:40] <LeoNerd> It's doable
[07:06:12] <aditya3098> Also, each has 7 lines, and thats 5 digits, 7x5=35 input lines!
[07:06:17] <Lambda_Aurigae> I would still tie into the LED drive lines, including the digit enable pins, and read those.
[07:06:26] <Lambda_Aurigae> bah..
[07:06:37] <Lambda_Aurigae> just do 7 segments and 5 driver lines..
[07:06:40] <LeoNerd> Er.. it's 5+7 = 12
[07:06:48] <Lambda_Aurigae> you don't need to read every segment.
[07:06:56] <LeoNerd> Being the entire point of a matrix-driven display
[07:06:57] <Lambda_Aurigae> read it the same way it displays it.
[07:07:19] <aditya3098> You mean like interrupts?
[07:07:31] <Lambda_Aurigae> you could use interrupts to do it
[07:07:45] <Lambda_Aurigae> or you could just watch the i/o pins constantly.
[07:08:14] <Lambda_Aurigae> when one of the row pins goes low(or high depending on how its setup) you read the segment pins.
[07:08:19] <aditya3098> Actually I have a main loop that does some stuff with a GSM module. Ok, here's the project:
[07:08:34] <aditya3098> I have an electric meter I got after a lot of legal issues
[07:08:35] <Lambda_Aurigae> sounds like someone's homework to me.
[07:08:50] <aditya3098> No, its not
[07:09:10] <aditya3098> I want to build something that sends you an SMS about your daily consumption
[07:09:36] <aditya3098> So, I got the sim900, and figured the 40pin dips would be the best I could do
[07:09:36] <Lambda_Aurigae> I would put a camera on it, feed the data from the camera to a computer or rPI, and use an OCR program to read the display data.
[07:10:33] <aditya3098> Too pricy, I actually want to submit this to a science fair. (I actually did that a few days ago, but then I read the price restrictions on the fair's website)
[07:10:35] <LeoNerd> A segment reader isn't hard, if you have electrical access to it
[07:10:36] <LeoNerd> Really
[07:10:44] <LeoNerd> I do it on my dishwasher :)
[07:11:19] <Lambda_Aurigae> too pricy....an old p-4 computer someone was going to throw away, an old webcam someone was going to throw away, free software.
[07:11:21] <Lambda_Aurigae> all free.
[07:11:43] <aditya3098> I am in india
[07:12:00] <Lambda_Aurigae> so do it with an old 486 someone was going to throw away.
[07:12:06] <aditya3098> Also, it needs to be practical for regular households
[07:12:18] <LeoNerd> Eh.. I'm going ot give up shortly
[07:12:28] <Lambda_Aurigae> see,,you keep throwing in more and more "requirements"
[07:12:31] <LeoNerd> I say it's easy enough to do. Lambda_Aurigae says not to bother. *shrug*
[07:12:51] <Lambda_Aurigae> I made one suggestion on doing it with the microcontroller
[07:12:57] <Lambda_Aurigae> which was much the same as yours LeoNerd
[07:13:06] <Lambda_Aurigae> row/column reading.
[07:13:12] * LeoNerd nod
[07:13:21] <Lambda_Aurigae> easily doable with an atmega88 or similar.
[07:13:36] <Lambda_Aurigae> I was also throwing out alternate methods.
[07:13:38] <LeoNerd> Mine's done with a tiny 2313, only because I happen to have some sitting around
[07:13:48] <Lambda_Aurigae> that works too.
[07:14:06] <LeoNerd> Huge great 20pin chip with basically hardly any RAM, flash or other peripherals. so it's good for this sort of custom IO expansion
[07:14:15] <Lambda_Aurigae> could do it with an attiny85 and a couple of pcf8574 chips too.
[07:14:30] <aditya3098> I actually had an idea, but I wanted some advice before trying to mess with a lot of transistors, but I was thinking of putting smoothing caps on the lines to and feed them to a bc548 to get a clean 5v output
[07:14:30] <LeoNerd> Ugh.. I dislike those.
[07:14:39] <LeoNerd> They're also really expensive for what they do, as compared just getting a 20pin 'tiny
[07:14:51] <Lambda_Aurigae> LeoNerd, yeah..they are pricy but they work really well.
[07:14:58] <LeoNerd> aditya3098: Eh.. just make a matrix scanner, really
[07:15:03] <Lambda_Aurigae> aditya3098, why do you want to smooth out the output?
[07:15:11] <Lambda_Aurigae> it's lots of digital pulses...read the pulses..
[07:15:20] <LeoNerd> Lambda_Aurigae: I looked at them once but I couldn't honestly work out why I'd use one... the size and cost just don't pan out against just getting a chip with more GPIO lines
[07:15:39] <LeoNerd> I have some 16-line MCP chips that I might play with and see, but even then...
[07:15:44] <aditya3098> So I can then feed it into some kind of multiplexer to finally read it with 12 (5+7) pins
[07:15:45] <Lambda_Aurigae> one i/o pin per segment and one per digit..12 lines.
[07:15:57] <LeoNerd> aditya3098: Yes; the multiplexer does *NOT* want the lines smoothed
[07:16:02] <LeoNerd> That's exactly the opposite of what you want
[07:16:09] <LeoNerd> You need to throw that clean digital feed right into it
[07:16:13] <Lambda_Aurigae> don't need a multiplexer...just read the segments each time a digit is selected.
[07:16:33] <LeoNerd> Yah - it's a demuxer, effectively. You're making the exact *opposite* of a display mux
[07:17:13] <aditya3098> So I need to find some way of selecting which segment to read from
[07:17:20] <Lambda_Aurigae> it's already there!
[07:17:21] <LeoNerd> No, read *all* of it
[07:17:22] <LeoNerd> Fah
[07:17:23] <LeoNerd> Gah
[07:17:27] <aditya3098> I guess that is kind of the reverse of multiplexer
[07:17:36] <LeoNerd> Seriously... 5 column selects, 7 rows. On each column, read all the rows into RA<M
[07:17:37] <LeoNerd> RAM
[07:17:39] <LeoNerd> This is trivial
[07:17:43] <Lambda_Aurigae> read ALL 7 segments each time a digit is selected.
[07:17:50] <LeoNerd> Each time one of the CSes is active, read the 7 segment lines into a byte of RAM
[07:18:02] <LeoNerd> After a full cycle, those 5 bytes of RAM contain the entire visual state of the display
[07:19:16] <aditya3098> Collecters of bc548s from each segment 1 to input1 with emmiter, seg2-inp2, etc, and all the gates of one digit to the line selector
[07:19:20] <aditya3098> Thanks
[07:21:10] <Lambda_Aurigae> actually, I would tie to the base side, but, whatever.
[07:41:34] <LeoNerd> Afternoon RikusW
[07:41:48] <RikusW> hi LeoNerd
[07:42:00] <LeoNerd> So, I tried a QFN32 package the other week. It.. er.. didn't exactly work
[07:42:15] <LeoNerd> I have it mounted on the board (mega88), but it doesn't talk ISP. I think I may have cooked it
[07:42:18] <RikusW> hard to solder ?
[07:42:20] <LeoNerd> Or shorted some of the pins. I can't easily tell
[07:42:33] <LeoNerd> I don't believe any of the pins are shorted, but it's hard to tell
[07:42:35] <RikusW> I only did tqfp so far
[07:42:37] <twnqx> measure them?
[07:42:38] <hackvana> Is it drawing any power?
[07:42:52] <LeoNerd> hackvana: Well, it draws so little in ISP mode *anyway* that I'm not sure I'd know
[07:43:07] <LeoNerd> I don't yet have an accurate enough current meter. Working On It. ;)
[07:43:07] <twnqx> it's not that hard to put the tips of a meter on to them
[07:43:10] <hackvana> One sign you've cooked the chip is excessive power draw
[07:43:19] <LeoNerd> Ah. I don't think it draws *anything* significant
[07:43:19] <RikusW> LeoNerd: no mA meter ?
[07:43:26] <twnqx> mA is not really sufficient
[07:43:33] <LeoNerd> Well, not one I can really put inline on the ISP pins, no
[07:43:41] <twnqx> but really, LeoNerd, just meaure the resistance between neighbouring pins
[07:43:52] <twnqx> also, between pins and the other end of the trace
[07:43:53] <LeoNerd> Oh well that I've done, and there's no pin-pin shorts on the board
[07:44:01] <hackvana> LeoNerd: Have the fuses been set? Do you have an oscillator you can use?
[07:44:05] <LeoNerd> Ohyeah. huhh.. I could do that couldn't I ;)
[07:44:07] <hackvana> Right, good.
[07:44:10] <twnqx> 'cause i had quite a few cases of no contact from qfp pins and the other end
[07:44:17] <LeoNerd> hackvana: In its default state; I haven't yet been able to talk ISP to it at all
[07:44:35] <LeoNerd> But I did bake it with the heatgun somewhat ill-advisadly set at 300C, so there's a chance I just plain cooked the chip
[07:44:41] <RikusW> by default it is usually on the internal osc
[07:44:43] <LeoNerd> I might try another.. I do have 3 in total
[07:44:45] <LeoNerd> Yah
[07:44:50] <hackvana> I see. Bit hard to set fuses to "I won't talk without an oscillator" if it's never talked ISP :-)
[07:44:55] <LeoNerd> So I can't even observe if it's oscillating on the xtal pins
[07:45:13] <LeoNerd> There's an xtal on board, soldered in;.. just the chip's default state is internal oscillator
[07:45:13] <hackvana> You still might get a signal on those pins
[07:45:16] <LeoNerd> Hmm
[07:45:17] <RikusW> LeoNerd: did you preheat the board first ?
[07:45:22] <LeoNerd> RikusW: no.. ;/
[07:45:49] <RikusW> hold the heatgun further away, and preheat for 1min or so
[07:46:07] <LeoNerd> Mmm.. OK
[07:46:34] <hackvana> Or use oven or hotplate method
[07:46:41] <RikusW> 260C should be enough heat
[07:46:56] <LeoNerd> Is 260 a bit hot though? Doesn't that risk cooking the chip?
[07:47:03] <hackvana> I don't like that idea
[07:47:04] <LeoNerd> I couldn'd find soldering curve suggestions in the DS
[07:47:28] <hackvana> Soak temperatures are usually a long way below that.
[07:47:33] <RikusW> 260C is the final peak temperature you need
[07:47:38] <RikusW> soak is like 100C
[07:47:42] <hackvana> For Pb solder, yes
[07:47:48] <LeoNerd> My solder says 183C
[07:47:50] <hackvana> Bit more for soak, IMO
[07:48:02] <LeoNerd> So surely I don't need to go above about 200C really?
[07:48:47] <hackvana> Soak has two purposes. First is that the flux kicks in at that temperature, and reduces oxides to straight metal. Second is that it ensures that you end up with less stress in the finished joints.
[07:48:59] <RikusW> you'll have to heat until the paste becomes shiny
[07:48:59] * LeoNerd nod
[07:49:14] <LeoNerd> Sure... I'm aware of the general procedure :)
[07:49:22] <LeoNerd> I just don't know what temperature to set the gun at
[07:49:40] <LeoNerd> As long as it's >183, it will eventually melt the solder. But would take longer, the cooler it is
[07:49:44] <hackvana> There are several people in #hackvana who use hot air. Asking them might help.
[07:49:55] <LeoNerd> Hotter makes it melt quicker, but too hot and it'll cook the chip. I suspect I may have done that, at 300
[07:50:02] <hackvana> I've seen examples of peak temp 20-40C over the melting point.
[07:50:03] <RikusW> what kind of heatgun do you have ?
[07:50:51] <LeoNerd> RikusW: Oh, just one of the standard dirtcheap 858D clones that eeeeeveryone has
[07:51:05] <LeoNerd> http://www.amazon.co.uk/dp/B00Y0HYDE8
[07:51:25] <LeoNerd> I think my main problem was the paste I had. The first lot was *terrible*
[07:51:26] <phryk> I'm on an atmega2560. I have this table in the datasheet for UART baud rates and corresponding UBRR values.
[07:51:36] <RikusW> I've set mine at 275C or so and then controlled the temperature using distance to pcb
[07:51:52] <phryk> All good and fine thus far, but I have to set UBRHH low and high. How do I get that from the one UBRR value?
[07:52:05] <phryk> s/UBRHH/UBRR/
[07:52:35] <RikusW> phryk: break it up into 8 bit values
[07:52:58] <RikusW> use hex calculator
[07:53:07] <phryk> RikusW: will the "left" part be H or L?
[07:53:15] <RikusW> HHLL
[07:53:26] <phryk> i.e. i have an UBRR of 3. so H is 0?
[07:53:52] <phryk> ah, should be. thanks. :)
[07:53:53] <RikusW> eg 1234 -> hex -> 4d2 -> high=4 low=d2
[07:54:16] <RikusW> H is 0 indeed
[07:54:38] <phryk> okay, then the error values. 0.0% obviously seems good, but what the heck is up with the negative error values?
[07:55:06] <LeoNerd> I think that just means error in the fast or slow direction
[07:55:09] <RikusW> probably when its higher or lower than the actual baud
[07:55:33] <phryk> Okay, so a negative value is bad, too. :)
[07:55:46] <RikusW> keep it below 4%
[07:56:03] <phryk> I'll probably want to use parity bits at some point then
[07:56:11] <phryk> since I want to do this stuff 100 times a second
[07:56:30] <RikusW> what baudrate will you be using ?
[07:56:34] <LeoNerd> 4?? Hah - I don't do anything above about 1.
[07:56:53] <LeoNerd> I usually use a 14.7456MHz crystal on serial-talking boards. Then it divides nicely
[07:57:01] <phryk> trying to figure that out right now. I know i need at least 57.6k, but had issues with that
[07:57:12] <RikusW> 4 is just an example ;)
[07:57:31] <phryk> don't really know what the issue is but sending always worked, but the atmega just wouldn't answer in like 90% of the cases
[07:57:47] <phryk> so I'm trying to go from setbaud.h to completely manual configuration for better debugging
[07:57:52] <RikusW> which buffer chip are you using ?
[07:58:01] <phryk> buffer chip?
[07:58:05] <RikusW> MAX232 etc ?
[07:58:13] * twnqx likes is 2mbit serial connections
[07:58:16] <RikusW> do you use a real serial port or usb ?
[07:58:22] <phryk> I don't know, this is some "seeeduino" thing, should be equivalent to an arduino mega afaik
[07:58:24] <twnqx> at least i don't need weird crystals for that
[07:58:33] <phryk> I'm using usb.
[07:58:49] <twnqx> huh?
[07:58:50] <RikusW> with usb to serial converter chip ?
[07:58:53] <LeoNerd> twnqx: DMX-512 is nice like that. 250kBaud; so a clean division from 16MHz
[07:59:25] <twnqx> if you mean usb straight into the µC, you don't fiddle with bit rates at all as it's all virtual anyway
[07:59:26] <phryk> RikusW: yeah, i think it's called an FTDI, but I'm not sure whether that's the actual name or just like people say "amd64" to all 64 bit x86 cpus…
[07:59:33] <twnqx> ftdi is a vendor
[07:59:34] <RikusW> phryk: I've used 115k2 baud with no problems
[07:59:53] <twnqx> and i use exactly ftdi chips with 2mbit serial :3
[08:00:08] <RikusW> phryk: there are many different usb to serial chips, ftdi is just one brand of many
[08:00:10] <phryk> RikusW: yeah, but I also have to make sure fucking pyserial supports that baudrate on freebsd… i tried 250kbaud and that didn't work :F
[08:00:28] <RikusW> 115k is very common
[08:00:28] <twnqx> 250 doesn't exist afaik
[08:00:42] <RikusW> 230k is not....
[08:00:44] <twnqx> 115k2, 230k4, 1m, 2m (on linux)
[08:00:45] <phryk> twnqx: it exists according to the datasheet. but yeah, pyserial complains about it being non-standard.
[08:00:47] <LeoNerd> It may require some weird custom setup
[08:00:55] <phryk> but i couldn't find a list of "standard" baudrates anywhere :/
[08:00:57] <LeoNerd> Those silly B*number* constants.. meh. :(
[08:01:03] <twnqx> standard ends at 115k2
[08:01:07] <LeoNerd> It should have just been an ioctl that takes the baud rate as an int.
[08:01:11] <twnqx> after that it's all extended
[08:01:25] <twnqx> LeoNerd: would be pointless as the chips to dnot support arbitrary settings :3
[08:01:30] <LeoNerd> Sure
[08:01:32] <RikusW> phryk: 9600 19200 56700 115200 are some of the common ones
[08:01:38] <twnqx> 38400!
[08:01:43] <LeoNerd> But then the ioctl could fail for what's not supported by the speicfic hardware
[08:01:48] <phryk> twnqx: 250k had this nice 0.0% error rate, that's what made it seem attractive
[08:01:55] <LeoNerd> Currently, even if the hardware *does* support odd rates, the interface hsa no way to reques tit
[08:02:01] <twnqx> but i doubt the usb->serial can do it
[08:02:12] <phryk> RikusW: i can find common ones just fine, but can't find whatever "standard" is referring to…
[08:02:12] <twnqx> so go for 1mbit
[08:02:21] <twnqx> at least the ftdis can do it :§
[08:02:22] <twnqx> :3
[08:02:37] <LeoNerd> There is currently no way to ask for 250kBaud. At all. If the ioctl took an int, then you could just request 250k and if the hardware doesn't like it you'll get EINVAL, but if it *does* then great.. you can use it.
[08:02:46] <phryk> oh yeah, 1mbit is the top thing of the atmega and 0.0% error rate too :)
[08:02:59] <twnqx> 2m works on atmega
[08:03:03] <RikusW> imo driver interfaces for setting baud sucks :/
[08:03:04] <twnqx> with that double freq bit :3
[08:03:19] <phryk> yeah
[08:03:26] <twnqx> just, when you code your program
[08:03:29] <twnqx> stop reading bytes :P
[08:03:30] <phryk> imo pretty much everything about avr sucks :P
[08:03:40] <twnqx> won't work.
[08:03:45] <twnqx> (at those rates)
[08:03:48] <phryk> twnqx: "stop reading bytes"? what do you mean?
[08:04:01] <twnqx> don't fgets() on the serial port :P
[08:04:20] <phryk> twnqx: you're talking about the atmega side (not pc), right?
[08:04:24] <twnqx> PC side.
[08:04:37] <RikusW> ironically I found it was easier to code libusb stuff on Linux than to write serial port code for CDC usb stuff
[08:04:39] <twnqx> i couldn't read 2mbit/s with fgets() code
[08:05:08] <twnqx> the syscalls take several µs each, with made buffers overrun
[08:05:43] <phryk> twnqx: I'm using python, i just do something like serial_device.readline()
[08:05:52] <twnqx> yeah, readline will do
[08:06:05] <phryk> as long as pyserial itself doesn't fuck things up :P
[08:06:16] <phryk> okay, i have two more questions:
[08:06:22] <twnqx> i hate python too miuch to care
[08:06:35] <phryk> a) the datasheet table says UBRR for 1M is 0. So low and high values are the same? how is this supposed to work?
[08:06:44] <RikusW> I used the raw terminal interface in Linux, its just... weird
[08:07:14] <RikusW> 0x0000 -> 00 00
[08:07:17] <twnqx> case 'P':
[08:07:17] <twnqx> switch (intarg) {
[08:07:17] <twnqx> case 1: devicerate = B230400; break;
[08:07:17] <twnqx> case 2: devicerate = B460800; break;
[08:07:17] <twnqx> case 3: devicerate = B1000000; break;
[08:07:18] <twnqx> case 4: devicerate = B2000000; break;
[08:07:20] <twnqx>
[08:07:25] <RikusW> 0x0102 -> 01 02
[08:07:26] <twnqx> we forgot a baudrate :P
[08:08:11] <phryk> I can't make sense of what you people just said^^
[08:08:21] <RikusW> phryk: since avr is 8 bit you only have 8 bit registers
[08:08:42] <RikusW> L and H is combined again in hardware
[08:08:56] <phryk> RikusW: I'm aware of that. But UBRR = 0 should still mean that high and low are the same, right?
[08:09:05] <RikusW> yes
[08:09:34] <twnqx> why would that be a problem for you?
[08:09:47] <RikusW> its a special case where both will be the same
[08:09:52] <phryk> I thought it would be the value for the high and low values (0 and 1). Won't that just lead to random shit because a "value" of 0 on the cable would stand for both 1 and 0?
[08:10:11] <twnqx> ... no
[08:10:16] <RikusW> UBRR is a divisor for generating the baud clock
[08:10:23] <twnqx> high and low are high and low bytes of the clockrate divider
[08:11:08] <phryk> Ah, okay. I don't exactly get what that means yet, but it's a setup/config thing, that's good enough for me right now :P
[08:11:34] <twnqx> basically, both together form a 16bit number
[08:12:01] <twnqx> you have your chip clock, divided by 2(or 4, based on that other mode bit), then divided by that number, to get your serial clock rate
[08:12:04] <twnqx> +- details
[08:12:51] <RikusW> read the datasheet USART -> Clock generation part to better understand
[08:12:55] <twnqx> wrong, divided by 8 or 16
[08:13:11] <phryk> oh wait, I'm just so inured to setbaud.h that i completely overlooked that the UBRR is the one thing where you actually set the baudrate.
[08:13:21] <RikusW> eg baud = fosc / (16*ubrr)
[08:13:29] <twnqx> void uart0_init (const uint32_t rate) {
[08:13:29] <twnqx> uint8_t u2x = (rate >= 1200);
[08:13:29] <twnqx> uint32_t ubrr = F_CPU / ((u2x?8:16) * rate) - 1;
[08:13:41] <phryk> Just kinda thought the atmega would be aware of my #define BAUD
[08:13:44] <RikusW> err baud = fosc / (16*(ubrr+1))
[08:14:37] <phryk> Okay, (hopefully) last question: the U2X flag. If I set it I get double the speed. That *does* mean that on the other side I have to select a baud rate 2x as high, right?
[08:14:56] <twnqx> yes
[08:15:06] <phryk> perfect, thanks a bunch.
[08:15:30] <twnqx> which is why RikusW's formulat is almost correct :P
[08:15:42] <twnqx> as it misses the u2x bit
[08:16:36] * RikusW took the first one from the datasheet
[08:16:56] <LeoNerd> I've never *quite* worked out the reason for having a U2X bit, as compared having more bits in the UBRR register
[08:17:00] <LeoNerd> Er.. the UBR register
[08:17:08] <twnqx> yeah
[08:17:25] <twnqx> probably because it's really implemented as seperate dividers
[08:17:58] <RikusW> U2X does cause the avr to take less samples when receiving
[08:18:12] <twnqx> oh right
[08:18:21] <twnqx> it reduces the oversampling, not the divider
[08:18:22] <LeoNerd> Hmm...
[08:18:24] <LeoNerd> Ah, I see
[08:18:56] <twnqx> keep forgetting/ignoring that
[08:20:13] <phryk> oversampling?
[08:20:30] <twnqx> avrs don't use edge detection
[08:20:41] <twnqx> they sample the input x times per time unit
[08:20:52] <twnqx> if it's more 1s than 0s during that time, the output is 1
[08:20:55] <twnqx> else it's 0
[08:21:04] <twnqx> digital oversampling
[08:21:04] <LeoNerd> In non-U2X mode, the receiver runs 16 ticks per bit, and samples the input during ticks 7/8/9
[08:21:09] <LeoNerd> Uses majority voting
[08:21:19] <twnqx> just during 3?
[08:21:20] <twnqx> wow
[08:21:26] <twnqx> crap hardware
[08:21:31] <LeoNerd> Yah; to account for slew rates and stuff
[08:21:32] <day> this is the atmega8 spi example from the datasheet. i only changed the port name (DDRB) and the pins (PB3 and PB5). any idea why this isnt working?
http://dpaste.com/140PJSY
[08:21:49] <LeoNerd> It means your transmitter can have quite a slow line driver, and poor transition times, and still works fine
[08:22:09] <LeoNerd> Keeps EMI down
[08:22:10] <day> activating the SPI + setting it to master + writing a byte to SPCR should be sufficient from what i understand :/
[08:22:21] <twnqx> day: you are using hardware SPI; are you sure the pins you selected are the hardware SPI pins?
[08:22:36] <day> twnqx: PB3 == MOSI, PB5 == SCK
[08:23:00] <phryk> Mhhh, at least doing avr stuff gives me a bit more of a feeling for how fucking flimsy all tech is :F
[08:23:19] <LeoNerd> Gaffer tape and wet string..
[08:23:21] <phryk> Not like I didn't think of everything in computing as being horrible already… :P
[08:23:31] <twnqx> flimsy?
[08:23:38] <twnqx> not quite the term i'd have used
[08:23:46] <phryk> Yeah, I'm not a native speaker.
[08:23:57] <RikusW> I'd call it esd sensitive ;)
[08:23:59] <phryk> Even though my native tongue is already more withered than my english /o\
[08:24:04] <twnqx> day: are you not getting anything, as seen by a logic analyzer, or does your target just not work?
[08:24:18] <RikusW> s/esd/esp :-D
[08:24:42] <RikusW> phryk: what is you native tongue ?
[08:24:58] <twnqx> day: you could use a simple voltmeter connected to SCLK to see if it's half your VCC - if it is, your problem is somewhere else :)
[08:25:03] <day> twnqx: im not getting anything on the analyzer. i can read the programming process just fine
[08:25:18] <twnqx> mh
[08:25:31] <twnqx> what chip are you suing? said mega8?
[08:25:35] <day> yes
[08:26:31] <phryk> RikusW: German.
[08:26:44] * RikusW is Afrikaans
[08:27:40] <phryk> Back when I was like in 5th grade, classmates couldn't understand the shit I said because I was constantly speaking like academia level German… Now I can't string two coherent sentences together in that language :F
[08:28:24] <phryk> Curse you English! Damned most practical language of the world. :F
[08:28:49] <phryk> RikusW: I only know Afrikaans from Dookoom and Die Antwoord ^^
[08:29:23] <RikusW> I've heard of "Die Antwoord", though its not my type of music
[08:29:51] <phryk> Usually not my type of music, too.
[08:29:52] <RikusW> translated "The Answer"
[08:30:12] <phryk> But in the last 2 years or so I got a bit into that rap-ish stuff.
[08:30:20] <phryk> RikusW: basically the same in german: "Die Antwort"
[08:30:51] <day> twnqx: its stranger than i thought. the program stops somewhere in the init routine o0
[08:31:11] <RikusW> there is another that is popular among the younger people too, "Fokofpolisiekar" :)
[08:31:16] <RikusW> ;)
[08:31:30] <RikusW> see if you can translate that ;)
[08:31:53] <RikusW> there songs are somewhat rude afaik
[08:32:17] <twnqx> day: wow. did you even tell the compiler that you are using a mega8 so that your includes are correct? :P
[08:32:22] <phryk> RikusW: "Fuck off police car"?
[08:32:27] <RikusW> indeed
[08:32:32] <day> twnqx: yes :P
[08:32:35] <day> twnqx: DDRB = (1<<PB3)|(1<<PB5);
[08:32:36] <phryk> That's more english than german in it, tho :P
[08:32:45] <day> twnqx: thats where it stops
[08:32:46] <phryk> RikusW: but what is "Kak Stirvy"?
[08:32:59] <twnqx> day: that should be, like, impossible
[08:33:02] <day> :D
[08:33:20] <twnqx> unless maybe you cause a short circuit
[08:33:25] <day> i toggled a pin down/up. before and after that line. before it works. after it doesnt
[08:33:35] <day> no way
[08:33:54] <RikusW> phryk: kak = shit the second part I don't recognize
[08:34:12] <phryk> RikusW: great, then you're getting just as far as I do^^
[08:34:29] <twnqx> afrikaans is just another of those stuck-between-german-and-english languages :X
[08:34:48] <phryk> yeah, it sounds quite a bit like dutch.
[08:35:08] <phryk> Mhh, you could probably view these "colonial" languages like ring species…
[08:35:17] <RikusW> its dutch + german + english, and some asian too
[08:35:48] <RikusW> we use some malay words etc
[08:36:37] <phryk> Hybrid languages probably make it easier for their speakers to learn the languages they drew from…
[08:36:38] <RikusW> and some words of the indigenous african languages too
[08:37:04] <RikusW> I can sort of read dutch and german
[08:37:09] <phryk> RikusW: only a few? I'd have expected indigenous language to mix quite a bit into it over time…
[08:37:19] <RikusW> hearing what is said is _hard_
[08:38:22] <phryk> then again apartheid "ended" like what? 20 years ago?
[08:38:35] <RikusW> there is this ->
https://en.wikipedia.org/wiki/Fanagalo
[08:38:42] <RikusW> 1994 yes
[08:39:11] <RikusW> http://www.salanguages.com/
[08:39:38] <phryk> fanagalo sounds interesting
[08:39:50] <phryk> there's a whole bunch of languages i find interesting, but no one to learn them with
[08:40:03] <phryk> I'd love to speak lojban, too^^
[08:40:29] <RikusW> I live in an area where both Zulu and Sesotho are spoken
[08:43:51] <phryk> language is very monotone here… there's a few dialects, but pretty much the only people with more than 1 language are immigrants.
[08:44:13] <phryk> we have english in school of course, but most people just suck at it.
[08:45:43] <phryk> bavarian might count as its own language tho. :P
[08:47:16] <twnqx> offf
[08:47:18] <twnqx> pffffff*
[08:47:53] <twnqx> saxonian and whatever they speak around cologne are languages of their own, too
[08:48:02] <twnqx> and don't get me started on plattdeutsch
[08:48:32] <phryk> plattdeutsch is a different language officially, i think.
[08:49:23] <phryk> saxonian and kölsch i can understand with a bit of difficulty, bavarian is often impossible.
[08:49:32] <twnqx> s/often//
[08:49:42] <twnqx> like deper austrian.
[08:49:53] <twnqx> deeper*
[08:50:03] <phryk> no clue about deeper austrian, i just know a few of the vienna things.
[08:50:21] <phryk> like ur*, waach and breit
[08:50:26] <phryk> urzach^^
[08:56:37] <RikusW> phryk:
http://www.dontwatchthat.tv/2013/10/dookoom-kak-stirvy/
[08:57:01] <phryk> RikusW: that's the reason i asked :P
[08:58:12] <RikusW> we also have ->
https://www.daggacouple.co.za/history/ :-P
[09:00:22] <phryk> RikusW: did they have any success in getting weed legalized?
[09:00:37] <RikusW> still busy it seems
[09:00:53] <RikusW> over here dagga = weed
[09:01:35] <RikusW> seems locals like it a lot
[09:01:59] <phryk> cool, new name for weed learned :3
[09:02:59] <phryk> another one is "creepy". apparently that's what good weed is called in costa rica :P
[09:03:31] <RikusW> the stronger stuff is known as swazi or skunk
[09:03:48] <phryk> that are distinct (groups of) strains
[09:03:55] <phryk> like swazi gold, skunk one, etcetc :P
[09:04:43] <RikusW> I don't think the quality over here is quite the same as indoor types
[09:04:55] <phryk> SA has no indoor grows?
[09:05:37] <RikusW> there probably are, but its highly secretive, so I wouldn't know
[09:05:45] <phryk> ah, right.
[09:06:21] <RikusW> seems over here the stuff isn't properly dried
[09:06:22] <phryk> i think over here the vast majority is indoor grows. openly growing that stuff outside is something pretty much nobody risks
[09:06:48] <phryk> :F
[09:07:28] <RikusW> I think medical use should have been legalized worldwide years ago
[09:07:43] <phryk> the stuff never should've gotten illegalized
[09:07:51] <phryk> the story of that is totally surreal.
[09:07:52] <RikusW> indeed
[09:08:03] <day> twnqx: figured it out... unbelievable. you HAVE TO use the SS pin as an output otherwise the chip assumes you want to be the slave, even though you told it that its the master..
[09:08:10] <phryk> US paper industry, I mean who in their right mind would actually believe that when they first heard it?^^
[09:08:46] <RikusW> day: it remains master until something pulls the SS pin low, including the PORT output..
[09:11:06] <RikusW> phryk: that part of history is pretty screwed up...
[09:13:29] <phryk> many parts are. i think it's a systemic problem.
[09:16:01] <RikusW> have you seen
http://www.alternet.org yet ?
[09:17:47] <phryk> yeah, can't say I read it tho :P
[09:18:02] <phryk> some articles pop up some places near me sometimes :P
[09:18:55] <RikusW> there are a lot of American politics on it as well...
[09:19:27] <phryk> I watch
http://stimulator.tv for fun and info. The guy seems to be a primitivist, though…
[09:20:08] <RikusW> I only have a GPRS connection, so no video streaming...
[09:21:46] <phryk> Aww. I mostly watch it for the burning riot cops anyways. :P
[09:22:41] <twnqx> phryk: where do you actually live now if you lost your german? :>
[09:23:02] <phryk> I live in Germany. :P
[09:23:23] <phryk> But most of my communications (as you can see) is in english. Most music, movies, serials, books, etc. too.
[09:25:10] <twnqx> well yes
[09:25:31] <twnqx> i also prefer my games in english, and english subtitles on my anime instead of german ones :P
[09:26:17] <phryk> there's just waaaaay more stuff done in english. and i find german dubs horrible for the most part.
[09:27:14] * RikusW prefer english computer terminology too
[09:28:23] <phryk> That was my initial reason to get into english. most of it just is in english, so everything that has to do with computers is way more accessible if you're versed in english.
[09:33:23] <tpw_rules> i know some computer german!
[09:33:52] <tpw_rules> netzwerkfehler
[09:34:13] <RikusW> network filter ?
[09:34:33] <phryk> network error
[09:34:59] <tpw_rules> ^
[09:35:02] <tpw_rules> drucker
[09:35:03] <phryk> Kein Weltraum links vom Gerät. :F
[09:35:19] <RikusW> is fehler connected to fail somehow ?
[09:35:41] <tpw_rules> i know it as failure
[09:35:53] <phryk> no clue, but might very well be.
[09:37:09] <RikusW> network failure then :)
[09:38:12] <eballetbo> hi, sorry, is this the correct place to ask for xmega uC?
[09:38:20] <tpw_rules> yes
[09:38:33] <LeoNerd> There aren't *many* xmega users around, but here's a reasonable place
[09:39:07] <tpw_rules> this is our "world languages hour"
[09:39:13] <tpw_rules> but feel free to ask
[09:39:40] <eballetbo> oh, well maybe someone can help me, i'm experimenting an odd issue, note that i'm completely newbie, heh
[09:40:18] <eballetbo> i'm just trying to configure the SPI on an atxmega16d4
[09:41:07] <eballetbo> the xmega is slave, and on the other side i've a linux machine
[09:43:20] <eballetbo> what i did is something like this
[09:43:22] <eballetbo> http://pastebin.com/taDqw3ST
[09:43:53] <eballetbo> the main is only a infinite loop
[09:44:45] <eballetbo> on linux machine i do "spi_write" and two "spi_read", so the idea is send to avr 1 byte and receive 2 bytes
[09:45:15] <twnqx> why are so many people today have SPI issues :P
[09:45:31] <eballetbo> and this works, but when I append a new case it starts to fail
[09:45:36] <twnqx> on SPI you have to do dummy writes to read data
[09:46:15] <twnqx> dunno if that helps though :X
[09:46:39] <eballetbo> hmm, so to read one byte i need to do a spi_write / spi_read on the master side ?
[09:46:49] <tpw_rules> what library are you using on linux?
[09:47:04] <twnqx> the linux side should automatically do dummy writes
[09:47:42] <twnqx> but you might overwrite your rx_byte accidentally, not sure (i don't have time to walk over your code in detail)
[09:48:38] <eballetbo> tpw_rules, on linux i'm programming a kernel module, using spi library
[09:49:04] <eballetbo> basically is a call to spi_write and spi_read
[09:49:26] <eballetbo> https://www.kernel.org/doc/htmldocs/device-drivers/API-spi-write.html
[09:50:24] <eballetbo> what i'm doing is spi_write(byte), spi_read(byte), spi_read(byte)
[09:51:26] <eballetbo> but accordingly to your comments maybe this is buggy, should be spi_write(byte), spi_write(dummy) spi_read(byte), spi_write(dummy) spi_read(byte) ?
[09:51:41] <tpw_rules> no i think linux handles that itself because it's a common pattern
[09:52:15] <eballetbo> I think so too
[09:52:38] <tpw_rules> oh, you aren't receiving any data in state 1
[09:54:09] <tpw_rules> i think you might want to empty it into a temp register
[09:55:47] <eballetbo> hmm, so on every state need to send receive data
[09:56:33] <phryk> Okay, so I figured out the maximum baudrate supported by the atmega and pyserial on freebsd: 115200. I made UBBR0H = 0; UBBR0L = 8; U2X0 = 0; which should corresponed to 115200 bd at 16Mhz clock (according to the datasheet table). Still I get an answer to less than 10% of the messages I send it…
[09:58:47] <phryk> https://github.com/phryk/colorvomit/blob/master/main.c this is the firmware
[09:58:57] <phryk> https://github.com/phryk/colorvomit/blob/master/daemon/daemon.py and this is the thing that talks to it from my machine
[10:09:25] <tpw_rules> what chip is this?
[10:09:33] <phryk> atmega2560
[10:09:54] <tpw_rules> oh i don't have the datasheet handy
[10:10:01] <tpw_rules> does it improve if you send them slowly?
[10:10:17] <phryk> you mean at lower bauds?
[10:10:26] <tpw_rules> no i mean like delay between letters
[10:10:47] <phryk> how much delay should i test with?
[10:10:50] <phryk> 1ms enough?
[10:10:58] <tpw_rules> do like 100 just to be sure
[10:11:06] <phryk> ksec
[10:12:38] <RikusW> phryk: I used U2X = 1 and UBRR = 16 for 115k with 16MHz crystal, it works just fine
[10:13:04] <phryk> tpw_rules: nope, the readline() in the python script just seems to time out most of the time
[10:13:10] <phryk> RikusW: okay, lemme try that
[10:14:00] <tpw_rules> double check your fuses then. perhaps it isn't actually running at 16mhz
[10:14:55] <RikusW> like div8
[10:14:55] <tpw_rules> write a quick program that toggles an led every half second and see if it actually blinks at 1 hz
[10:15:08] <phryk> I made sure of that at the very beginning
[10:15:14] <phryk> the c code just has #define F_CPU 16000000UL for that
[10:15:25] <tpw_rules> that doesn't change your fuse
[10:15:25] <phryk> there might be some magic in the Makefile, not sure anymore
[10:15:37] <tpw_rules> if the avr is actually running at 4mhz, then things like delay_us will be 4x as slow
[10:17:05] <tpw_rules> anyway, gotta go. be real certain of your clock speed. the define doesn't actually tell the chip what speed to run at, it tells the program what speed the chip is running at
[10:17:05] <eballetbo> tpw_rules, arght, didn't work can you see this code if you have time, please
[10:17:17] <tpw_rules> eballetbo: sorry, gotta run. i'll see when i get back
[10:17:30] <eballetbo> tpw_rules, np thankyou
[10:17:57] <phryk> mhh, so where are those mysterious fuses set?
[10:20:58] <RikusW> phryk: be real careful with the fuses, it can brick the chip
[10:21:12] <RikusW> avrdude or avrstudio can do it
[10:21:35] <phryk> then that's one of the things i did with help in the makefile
[10:21:36] <LeoNerd> You can't *brick* it with the fuses.
[10:21:39] <RikusW> CKDIV8 can be overridden in firmware too
[10:21:53] <phryk> basically the very first thing I did. first it was running at 8mhz iirc
[10:21:53] <LeoNerd> "bricking" refers to permanently destroying it. You can, however, put it into a mode that ISP itself might not be able to recover from
[10:22:11] <RikusW> and then you'll need HVPP
[10:22:38] <LeoNerd> Yah
[10:22:57] <RikusW> LeoNerd: if it is smd it may be practically bricked, since HVPP is impossible
[10:23:17] <RikusW> unless you find a way to connect all 21 wires
[10:23:20] <LeoNerd> Mmmm
[10:23:26] <LeoNerd> Fair point I suppose
[10:24:04] <phryk> HRRRRNNG
[10:24:05] <RikusW> if only the clock is stopped applying a clock to XT1 will make ISP work again
[10:24:25] <phryk> if i use /dev/ttyU1 it shows the fucked up behavior i explained. if I however use /dev/cuaU1, it works -_-
[10:24:47] <phryk> or does it?
[10:25:02] <phryk> anyways, got my foot into *some* door, might as well pry it open^^
[10:27:21] <RikusW> good luck
[10:28:51] <eballetbo> I've a SoC with linux and connected to an xmega throught spi,
[10:28:55] <eballetbo> on the linux part i've a kernel module that on load does two spi tests (increment test and bit flip test) 100 times,
[10:28:58] <eballetbo> code is as is
http://pastebin.com/PCnyZjJA
[10:29:01] <eballetbo> on the xmega part i've this
http://pastebin.com/uFd4H6tX
[10:29:05] <eballetbo> the thing is, if the code around XMEGA16D4_TEST_NEW (#if 1) is enabled test flip fails randomly,
[10:29:10] <eballetbo> if the code around XMEGA16D4_TEST_NEW (#if 0) is disable test flip success always.
[10:29:14] <eballetbo> any clue will be welcome, thanks
[10:29:23] <eballetbo> tpw_rules ^
[10:29:36] <phryk> yup, seems to work.
[10:29:54] <phryk> now to kill any artificial delays and clean this up again :3
[10:30:11] <eballetbo> There is a limit of code to put inside the ISR ? looks like a overflow
[10:31:00] <RikusW> ISR code needs to be kept short...
[10:34:58] <eballetbo> RikusW: do you think my ISR code too long ?
[10:36:21] <Strangework> Aside from making for visibly slow program flow, why does an ISR need to be executed quickly? Should only be a problem if the global interrupt flag is switched back on.
[10:36:43] <RikusW> it seems quite short actually
[10:37:19] <RikusW> you could miss or delay the next ISR...
[10:42:47] <eballetbo> what has no sense is why if i remove the code around XMEGA16D4_TEST_NEW all works and if I add this code test flip fails, note that the master side runs the same program
[10:56:58] <phryk> YUS
[10:57:13] <phryk> Got it working perfectly (0% error rate) on 57.6kbaud <3
[10:57:18] <tpw_rules> hi
[10:57:39] <phryk> tpw_rules: long time no see :P
[10:57:59] <tpw_rules> eballetbo: it could be that you're not responding fast enough. you need to have the byte in the SPI register ready to go by the time the linux side starts reading
[10:59:49] <tpw_rules> what happens from the linux side is when you call a function, the byte in the linux buffer and the byte in the xmega buffer exchange places, then the interrupt occurrs
[11:00:23] <tpw_rules> so the interrupt needs to put the low byte into the SPI buffer before the linux side tries to do anything again
[11:06:08] <tpw_rules> eballetbo: ^ try adding a few ms delay in linux between spi calls
[11:12:13] <tpw_rules> phryk: did you figure out the problem?
[11:13:19] <tpw_rules> RikusW and LeoNerd: there's a mightyohm hvpp shield that fits on an arduino and can program the 28/20/8 pin devices. it's like $20 if you solder it yourself
[11:14:11] <LeoNerd> I suspect you don't mean HVPP and 8pin
[11:14:19] <tpw_rules> well it will also do hvsp for those
[11:14:39] * LeoNerd already has an HVSP programmer anyway
[11:14:41] <tpw_rules> and it has a built-in dc/dc thing for Vpp
[11:14:45] <LeoNerd> Yah..
[11:14:57] <tpw_rules> i was happy with it. i melted a chip trying to make my own
[11:14:59] <RikusW> I once made and "adapter" to connect to a custom pcb with a mega128 on it, only jtag was connected to a header and someone messed with the fuses and turned it off, and programmed a bunch of boards...
[11:15:30] <RikusW> s/and/an/
[11:16:02] <RikusW> that was basically my first AVR experience :)
[11:16:03] <tpw_rules> oooops
[11:16:15] <RikusW> I used a real STK500 and my adapter to recover those
[11:16:17] <tpw_rules> phryk: why are you using ascii and string handling functions?
[11:16:44] <tpw_rules> i'd just use python's struct module and blast that over there
[11:19:43] <tpw_rules> also re line 8, you still need a resistor. you'll melt the avr too
[11:28:07] <phryk> tpw_rules: i have 1 ohm in front of every led
[11:28:23] <tpw_rules> that's too little
[11:28:23] <phryk> or where is this resistor supposed to be?
[11:28:36] <phryk> i have constant voltage sources
[11:28:46] <tpw_rules> they should be constant current
[11:28:56] <tpw_rules> also are you driving it from a special driver or just the avr pin
[11:29:09] <phryk> the whole thing seems to work flawlessly and nothing getting too hot
[11:29:25] <phryk> 12 nfets, each directly connected to one of the hardware pwm pins of the atmega
[11:29:32] <tpw_rules> oh, ok
[11:29:40] <phryk> the whole thing is tested, but I haven't heard anything about melting avrs before
[11:30:13] <tpw_rules> i thought you were trying to drive them all directly, in which case you'd be trying to source way too much current
[11:30:34] <tpw_rules> i'm not sure the led is enough though. see if you can find a datasheet that says their max current
[11:31:35] <phryk> "the led is enough"? what do you mean?
[11:31:47] <tpw_rules> lol. 1 ohm i meant to say
[11:32:12] <phryk> that works. i had all channels on 100% for two of the four leds i have for about an hour
[11:32:23] <phryk> got to like 50°C, but no problems
[11:32:40] <phryk> I yet have to test with a power supply that doesn't limit itself though
[11:32:51] <phryk> which is what I'll later hopefully do
[11:33:05] <tpw_rules> the problem is that the LED has no current limitation. it's basically a short
[11:33:24] <tpw_rules> so you might fry the LEDs immediately if you put a beefier supply on, or in a few hours/days if you run them constantly overcurrent
[11:33:45] <tpw_rules> what voltage are you using?
[11:34:22] <phryk> iirc what i was told is that the current the leds can pull corresponds to the voltage, which is constant.
[11:34:27] <tpw_rules> no
[11:34:31] <phryk> i have 3 different voltages, one for each color (rgb leds)
[11:35:11] <tpw_rules> they're diodes. once the voltage gets up above the drop out voltage, they become pretty close to a short circuit
[11:35:33] <tpw_rules> are they just arbitrary rgb leds? can you find a datasheet?
[11:36:01] <phryk> nope, far as I can tell one doesn't exist.
[11:36:06] <tpw_rules> where did you get them
[11:36:13] <phryk> dx.com
[11:36:23] <tpw_rules> do they have a page there
[11:36:49] <phryk> 10W rgb leds. someone gave me a formular to calculate the maximum current and I set the voltages so the current (following that formula) does not exceed 350mA
[11:37:13] <phryk> http://www.dx.com/p/10w-450lm-colorful-rgb-led-emitter-metal-plate-66291 Should be these.
[11:37:33] <phryk> oh, the page even says 350mA now
[11:37:49] <tpw_rules> oh 10 watt. okay. i thought they were the little standard ones that can't take more than 10
[11:38:05] <tpw_rules> if you want the best, see if you can get a constant current supply
[11:38:10] <phryk> lol no. this is a big ass setup for a first project :P
[11:38:34] <phryk> maybe in the pcb version, right now I'm hacking on the prototype i want to bring to camp next month
[11:38:59] <tpw_rules> also why the ascii serial
[11:39:33] <phryk> well, didn't know about passing structs, will have to look that up.
[11:39:40] <tpw_rules> look at python's struct module
[11:39:47] <phryk> it's a tiny bit inspired by mpd. i always liked how I could just talk the protocol directly
[11:40:15] <tpw_rules> basically you can receive x bytes into a char array, then cast it to a struct on the AVR side to access its members
[11:40:20] <tpw_rules> this also doesn't result in any more code
[11:40:40] <tpw_rules> i just think including string functions on a microcontroller is dirty :P
[11:41:24] <tpw_rules> call me old fashioned
[11:41:33] <phryk> I kinda liked how strtok did things in a way that directly corresponds how i wanted to parse stuff
[11:41:44] <tpw_rules> it would also make it a lot faster
[11:41:44] <phryk> but I heard that string functions are partly insecure in C.
[11:41:55] <learath> eh?
[11:42:00] <phryk> how you should never use strcpy or somesuch thing if you care about itsec
[11:42:01] <tpw_rules> lol that's not a problem. an avr is immune to it
[11:42:19] <tpw_rules> because it can't execute code from ram. (well you can still get creative, but yeah)
[11:42:20] <phryk> yeah, but might be a bad habit anyways
[11:42:29] <phryk> nice to know
[11:42:36] <tpw_rules> which is very sad imo
[11:42:42] <tpw_rules> goddamn harvard architecture assholes
[11:43:19] <tpw_rules> anyway the advantage is that you can receive data without any processing on the avr side. it'll be faster since there's less data too
[11:44:07] <phryk> but i wont be able to test stuff with just some random serial console tool
[11:44:47] <tpw_rules> that's why they invented programming languages :P
[11:46:33] <phryk> i want as easy as possible "interfacability"
[11:47:10] <phryk> and since the avr won't really do anything else, it's (probably) not like I'll end up with a bottleneck
[11:48:53] <phryk> Oh pancakes, you my hero.
[11:56:06] <eballetbo> tpw_rules, thanks to answer, i'll test asap
[11:58:43] <martinus> tpw_rules | also why the ascii serial >> Forgive a noob question but what alternatives are there?
[11:59:29] <phryk> martinus: apparently, passing structs, like tpw_rules said. :)
[12:02:01] <leehambley> hi all - I'm building a data logger with an atmega328 at the core, I thought about using a ESP8266 to add wifi, to download the logged data, but I see that that might be tricky, since I'd have to negotiate through the ESP8266 to the mcu to the flash storage, and get all the timing/etc just right… but something occurred to me
[12:02:27] <leehambley> from what volume # can you count on having the manufacturer pre-flash your chip firmware for you ?
[12:06:48] <martinus> phryk: Thanks, I'll take a look. I've been sending exclusively ASCII over serial as binary data seemed like a huge jump.
[12:12:29] <eballetbo> tpw_rules, need to test better but guess adding a delay helped, thanks for your help
[12:18:35] <RikusW> basically the STK500 uses a struct, or rather a packet with a header
[12:19:26] <RikusW> the header contains the length 2 magic numbers and a checksum
[12:19:39] <RikusW> iirc its passed as big endian
[12:21:12] <RikusW> the protocol is documented in appnote AVR068 on atmel's site
[12:59:58] <tpw_rules> or just send bytes
[13:06:10] <eballetbo> sorry if this is a silly questin, it's safe call functions inside a ISR ?
[13:39:49] <antto> eballetbo yes.. but it's generally not wise to do lots of stuff inside an ISR
[15:40:34] <eballetbo> antto, thanks
[18:23:42] <phryk> Any of you ever fiddle with a 'Seeeduino Mega'?
[18:23:59] <phryk> All the doc I can find is this:
http://www.seeedstudio.com/wiki/index.php?title=Seeeduino_Mega
[18:25:20] <phryk> https://paste.xinu.at/XEDRg8/ I also found this thing, and it has enabled me to find the right pins for 3 of the timers I'm using. But OCR5[A-C] are supposed to be "pwm 38" to "pwm 40" and the pins labeled "pwm" on the actual board just go to 13…
[18:33:47] <phryk> err pwm 46-44
[18:36:49] <Lambda_Aurigae> I don't fiddle with anything arduino.
[18:42:43] <phryk> good for you :P
[18:44:44] <Lambda_Aurigae> I am of two minds for the arduino stuff...it's an interesting concept and gets people started....but I hate that whole wiring interface and the bloatware....
[18:46:26] <Tom_itx> they're for ppl too lazy or dumb to write their own stuff
[18:46:36] <Lambda_Aurigae> hehe.