Back
[00:36:09] <rue_house> the duty of that thing wont be 100% at 100A, I'm sure of it..
[00:36:26] <rue_house> /*
[00:36:26] <rue_house> AAAAA
[00:36:26] <rue_house> F B
[00:36:26] <rue_house> F B
[00:36:26] <rue_house> F B
[00:36:27] <rue_house> GGGGG
[00:36:29] <rue_house> E C
[00:36:31] <rue_house> E C
[00:36:33] <rue_house> E C
[00:36:35] <rue_house> DDDDD dp
[00:36:37] <rue_house> */
[00:36:48] <rue_house> Casper, oh, wait, 240V?
[00:36:58] <Casper> yup
[00:37:08] <rue_house> hmm, maybe then
[00:37:23] <Casper> did you saw the pic?
[00:37:28] <rue_house> the curves usually fall pretty quick as you get to their peak rating
[00:37:32] <rue_house> yea, its a good kit
[00:37:34] <rue_house> all there
[00:38:08] <Casper> currently loaded with flux core mig wire, but I don't like the result, and the splatters
[00:38:28] <Casper> so I'm thinking more and more to get a C25 bottle
[00:38:55] <rue_house> yea, flux core sucks
[00:39:33] <rue_house> // PORTA
[00:39:34] <rue_house> #define A 0
[00:39:34] <rue_house> #define B 1
[00:39:34] <rue_house> #define C 2
[00:39:34] <rue_house> #define D 3
[00:39:34] <rue_house> #define E 4
[00:39:36] <rue_house> #define F 5
[00:39:38] <rue_house> #define G 6
[00:39:42] <Casper> also, I didn'T got good penetration at all
[00:40:18] <rue_house> unsigned char CG[] = {
[00:40:19] <rue_house> (1<<A|1<<B|1<<C|1<<D|1<<E|1<<F), /* 0 */
[00:40:19] <rue_house> (1<<B|1<<C), /* 1 */
[00:40:19] <rue_house> (1<<A|1<<B|1<<D|1<<E|1<<G), /* 2 */
[00:40:19] <rue_house> (1<<A|1<<B|1<<C|1<<D|1<<G), /* 3 */
[00:40:21] <rue_house> (1<<B|1<<C|1<<F|1<<G), /* 4 */
[00:40:23] <rue_house> (1<<A|1<<C|1<<D|1<<F|1<<G), /* 5 */
[00:40:25] <rue_house> (1<<A|1<<C|1<<D|1<<E|1<<F|1<<G), /* 6 */
[00:40:27] <rue_house> (1<<A|1<<B|1<<C), /* 7 */
[00:40:29] <rue_house> (1<<A|1<<B|1<<C|1<<D|1<<E|1<<F|1<<G),/* 8 */
[00:40:31] <rue_house> (1<<A|1<<B|1<<C|1<<D|1<<F|1<<G) /* 9 */
[00:40:33] <rue_house> };
[00:45:03] <Xark> rue_house: Sure be a lot cleaner to just #define a (1<<X) version. :)
[00:45:22] <Xark> Also you sure the precedence is OK?
[00:45:24] <rue_house> do show!
[00:45:40] <rue_house> prescedence wont matter on that one
[00:46:18] <rue_house> ... tho yea, I suppose the extra brackets would be a good idea...
[00:46:43] <Xark> It currently violates my "Id have to consult precedence chart" rule. :)
[00:46:55] <Casper> rue_house: what if the 7seg is connected to a sipo? >:¬]>
[00:47:24] <rue_house> Xark, your right, I'd normally have done that
[00:47:29] <Xark> Unless you use A B C D elsewhere, seems cleaner to just e.g., #define A (1<<0) then the table will be much easier to read.
[00:47:30] <rue_house> sipo?
[00:47:43] <Casper> serial in parallel out shift register
[00:47:44] <rue_house> oh, then you have to use that to the holding reg and not the port
[00:48:06] <rue_house> Xark, yea... your right
[00:48:06] <Casper> hence my evil smile with a pinch :D
[00:48:31] <Casper> #define SEGA 0
[00:48:51] <rue_house> #define SEGA (1<<0)
[00:49:21] * Xark pictures a loud blue hedgehog... :)
[00:50:49] <Casper> rue_house: for my welder, I decided to use a twistlock outlet for it instead of the real one, because the unit have a twistlock input, so I made some extension cord, that can now plug directly. If I need to connect to true welder outlet then I can use the cable provided with the unit, and if I need longer use my yellow extension and the provided cable D
[00:51:22] <rue_house> I'v made several levels of adapers myself
[00:51:45] <rue_house> I have a 4 prong (120/240) that I can break out as 120, 240, or to an outlet set
[00:52:01] <rue_house> and I ahve a 100' extension cord (heavy guage) in that
[00:53:36] <ThatDamnRanga> _BV()
[00:53:43] <Casper> my 2 extensions, one 25', one 75', are both #10
[00:53:58] <Casper> _BV() shouln't be used
[00:54:28] <ThatDamnRanga> grounds?
[00:54:43] <Casper> ?
[00:54:47] <ThatDamnRanga> 'why'
[00:55:13] <Xark> ThatDamnRanga: It is more typing that what it replaces for one. :)
[00:55:37] <Casper> _BV() was a dirty patch used because gcc had issue with the shifting and creating very unoptimised code
[00:56:04] <Casper> they fixed the issue, deprecated it, people complained, they de-deprecated it... unfortunatelly
[00:56:05] <ThatDamnRanga> len("_BV(D)") = len("(1<<D)")
[00:56:19] <ThatDamnRanga> I find it far easier to read
[00:56:38] <Casper> I find it hard to read
[00:56:42] <Xark> ThatDamnRanga: I disagree. Why be obscure with macro?
[00:57:08] <Casper> rue_house: strangelly, the 10/3 is the same size as the cable provided with the welder, which is 14/3 ...
[00:57:10] <ThatDamnRanga> Xark, it looks less busy on the screen?
[00:57:18] <ThatDamnRanga> to be honest, it's purely a personal preference
[00:57:25] <ThatDamnRanga> it is a one line macro
[00:58:27] <rue_house> see this is good conversation
[00:59:30] <Xark> ThatDamnRanga: To each his own, of course.
[00:59:31] <rue_bed> a debate that makes people question if their way is really better
[00:59:49] <ThatDamnRanga> indeed
[01:00:08] <ThatDamnRanga> for me with the above, there's so man '<' on the screen it gets busy and I have issues following it
[01:00:11] <rue_bed> I think that defining the values instead of all the shifting is leaner
[01:00:30] <rue_bed> however, as its all done compile time, its just about code readability
[01:00:38] <rue_bed> which cant be underestimated
[01:00:42] <ThatDamnRanga> and yes, I'd likely as not, in that situation actually just use a hexbyte.
[01:00:55] <ThatDamnRanga> but when setting/clearing configuration registers, I shift
[01:01:41] <rue_bed> its easier to read that 1 would be segB|segC
[01:01:50] <rue_bed> keep the shifting out of it
[01:02:52] <ThatDamnRanga> I'd probably just have '0xnn // -> A,B,C,D,E,F' etc.
[01:03:18] <ThatDamnRanga> but I mean, we're literally, at this point, talking about hairstyles and their practicality, it's all so close it barely matters :P
[01:03:28] <rue_bed> easier to make a bit position misake tho
[01:03:41] <ThatDamnRanga> indeed
[01:07:54] <Xark> Here is the crazy way I defined some fonts (to make them semi-editable as well as support little or big "bit" endianness) ->
http://hastebin.com/asoyipareq.coffee
[01:14:24] <rue_bed> nice tables
[01:15:14] <Xark> rue_bed: Of course a little utility kicks them out from a BMP. :) For stuff like
https://www.youtube.com/watch?v=Imk5ony8JHI
[01:18:07] <rue_bed> whats the basis for the 0-0x20 characters?
[01:18:28] <rue_bed> look like game peices
[01:18:51] <rue_bed> er the first set
[01:22:31] <Xark> rue_bed: Yes, they are actual "game" characters from my first computer (Ohio Scientific C-1P
http://www.technology.niagarac.on.ca/people/mcsele/OhioScientific.html ). Using them as handy 8x8 character set (looked like the top screen) ->
https://imgur.com/a/JO4Cq
[01:26:01] * Xark soldered Atari joysticks on his OSI-C1P and made tank games as a kid (setting him up for a lucrative career). :)
[01:26:29] <Casper> rue_bed: is EMT pipe weldable?
[01:27:09] <rue_bed> yea, make sure the zink cloud isn't anywhere near you
[01:28:10] <Casper> in a few years I may need to redo the stairs and rails... so I wonder if that is an option
[01:28:33] <Casper> 1" emt... if that is not too soft...
[02:04:34] <Casper> now I want C25 gas
[02:47:36] <cehteh> grr why do the gcc bugs always find me?
[02:52:42] <cehteh> or borked arduino bootloader .
[02:57:41] <cehteh> yay ... blame the bootloader, it doesnt call the C initialization properly
[03:16:38] <Jartza> https://www.indiegogo.com/projects/skrolli-a-printed-computer-culture-magazine
[03:16:44] <Jartza> cool
[03:16:53] <Jartza> I like Skrolli-magazine (in finnish)
[03:17:51] <Jartza> all the other computer-magazines are like meh... all these display-adapter-comparisons and stupid virus-protection-software-reviews.
[03:18:01] <Jartza> skrolli is the only magazine having anything interesting
[06:07:07] <Lambda_Aurigae> https://www.youtube.com/watch?v=O5bTbVbe4e4
[06:07:20] <Lambda_Aurigae> spaceX did it...landed a rocket like god and robert heinlein intended.
[10:51:30] <julius> hi
[10:52:03] <julius> do i get this correctly, when programming a avr with a programmer you connect MOSI -> MOSI, MISO -> MISO, RESET -> RESET .... ?
[10:52:28] <julius> its been some time and my usual usbasp programmer is at home
[11:13:14] <Haohmaru> julius yes
[11:27:06] <julius> thx
[12:05:58] <julius> well, look at that. looks like i flashed the "powerswitch" firmware instead of "usbasp"
[12:05:59] <julius> damn
[12:06:35] <LeoNerd> Oops :)
[12:06:45] <julius> months ago
[12:34:12] <julius> any idea if this fuse calculator works?
http://www.engbedded.com/fusecalc/
[12:37:03] <LeoNerd> It's a bit out of date, but if the chip you want is on there it should be fine
[12:37:10] <LeoNerd> You can always doublecheck with the datasheets
[13:06:27] <Lambda_Aurigae> try wormfood's fusecalc.
[13:06:46] <Lambda_Aurigae> oops
[13:06:48] <Lambda_Aurigae> nevermind
[13:06:54] <Lambda_Aurigae> his is baud rate calc, not fuse calc.
[13:07:24] <Lambda_Aurigae> nevermind me. I'm at work and getting my brain fried by lasers from copiers.
[13:07:32] <Lambda_Aurigae> that and inhaling toner and ozone all day.
[13:39:34] <julius> free drugs
[13:39:36] <julius> you lucky dog
[14:43:33] <julius> crap, programmer not responding :(
[15:12:26] <julius> lets order some china ones for 1,30$, usbasp. what could go wrong
[15:32:15] <balrog-k1n> hi, i've got a 3.3V I2C master and some 5V AVRs as a slaves, I can detect them when scanning all addresses but reading bytes through I2C only returns 0s and writing doesn't seem to work, how could this be possible?
[17:01:43] <Lambda_Aurigae> balrog-k1n, are the i2c devices 3.3V only or are they 5V tolerant?
[17:02:02] <Lambda_Aurigae> or, rather, the i2c master 3.3V device,,,is it 5V tolerant?
[17:13:48] <julius> im not really sure if my usbasp progger is not working, is there a way to test it with avrdude? i tried reading fuses from another chip: avrdude -p m32 -c usbasp -v -U lfuse:r:-:i but that didnt work
[17:13:59] <julius> cant communicate with programmer or someting
[17:14:42] <julius> im out for today, see you tomorrow guys
[17:21:00] <Lambda_Aurigae> it's usbasp...of course it's not working.
[17:36:30] <Jartza> hello
[17:36:41] <Jartza> made a tricoder-mode for my attiny85 vga
[17:36:46] <Jartza> especially useful in graphics mode :)
[17:37:39] <Jartza> and why, you ask? :)
[17:37:42] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxQkpMa1BDVlBUVjA/view
[17:38:07] <Jartza> 64x64 pixels, any pixel being any color (of the 8) you like!
[17:40:40] <ThatDamnRanga> Jartza, you appear to have some colour edge alignment issues :P
[17:41:21] <Jartza> yeah, had loose cable :)
[17:42:11] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxRGRCS1lKQjNpb3M/view
[17:45:26] <Lambda_Aurigae> now,,,can we switch between that mode and text mode?
[17:45:39] <Lambda_Aurigae> and/or half screen text and half graphics?
[17:45:41] <Jartza> sure
[17:45:45] <Jartza> or from any line you wish
[17:45:52] <Lambda_Aurigae> sweeeet.
[17:45:55] <Jartza> that "tricoder"-mode like I call it also works with text ;)
[17:46:03] <Jartza> it allows you to enter each R, G and B byte separately
[17:46:04] <Lambda_Aurigae> why tricoder?
[17:46:10] <Jartza> three bytes :D
[17:46:12] <Lambda_Aurigae> oh.
[17:46:27] <Lambda_Aurigae> so, pixel addressable graphics now?
[17:46:29] <Jartza> you can enter like "_FF" to get cyan F with red underscore in text mode
[17:46:41] <Lambda_Aurigae> nifty.
[17:46:45] <Jartza> yea :D
[17:46:55] <Lambda_Aurigae> I can see a use for having top half graphics and bottom half text..
[17:47:00] <Jartza> <esc>G enables "tricoder" and <esc>T disables it
[17:47:01] <Lambda_Aurigae> even in monochrome mode.
[17:47:22] <Jartza> <esc>[row] tells which row begins the text-mode (default 0)
[17:47:30] <Lambda_Aurigae> I first read that as "tricorder" and was wondering how startrek came into this.
[17:47:48] <Jartza> <esc>[16] = full graphics, <esc>[0] = full text, <esc>[8] = half graphics, half text... etc
[17:48:01] <Jartza> Lambda_Aurigae: hehe yea, I first called it tricorder :D
[17:48:15] <Jartza> of course, "drawing graphics" isn't that straightforward
[17:48:26] <Jartza> as each byte is transformed to 2x4 pixels
[17:53:10] <Jartza> but also "playing it wise" with text mode you can make some effects
[17:53:30] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxWWVNb2tsOE5nLWM/view?usp=sharing
[17:54:24] <Lambda_Aurigae> interesting.
[17:54:40] <Lambda_Aurigae> sending different characters to the same location on the different color chips, eh?
[17:55:23] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxd252TVdEajk2UkU/view
[17:55:24] <Jartza> yes
[17:55:34] <Jartza> in "tricoder" mode you send each "character" three times
[17:55:35] <Jartza> R, G and B
[17:55:48] <Jartza> each character (byte) is stored to different color chip
[17:56:10] <Jartza> that image shows the "random pic" just as characters
[17:56:28] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxTWRqWktBWU1lXzQ/view
[17:56:34] <Jartza> same pic, but upper half as graphics :)
[17:56:37] <Jartza> split-screen
[17:57:28] <Jartza> that split can happen on any row you wish
[17:57:40] <Lambda_Aurigae> will definitely have to play with that this weekend.
[17:57:57] <Jartza> https://www.youtube.com/watch?v=97m79zcx0Dk
[17:57:59] <Jartza> also on BW
[17:58:17] <Jartza> that shows that the graphics-text split-row is configurable and the switch is immediate
[17:59:38] <Jartza> :)
[17:59:40] <Lambda_Aurigae> looks good...one thing that catches my eye though.
[17:59:50] <Lambda_Aurigae> the "pixels" aren't all the same size.
[18:00:01] <Jartza> Lambda_Aurigae: I figured out, I don't just have 512 bytes of RAM, but with three chips I have 3 * 512 bytes, so why not allow modifying all of it?
[18:00:04] <Lambda_Aurigae> which isn't a game killer and I know why you did it.
[18:00:08] <Jartza> yes
[18:00:11] <Jartza> font is 6x10
[18:00:14] <Lambda_Aurigae> yeah.
[18:00:22] <Jartza> pixels are vertically 2, 3, 2, 3 pixels high :)
[18:00:31] <Lambda_Aurigae> yup.
[18:00:33] <Jartza> because one "character" is 2x4 pixels
[18:00:41] <Lambda_Aurigae> would be better to go 6x9, to me....but,,,
[18:01:10] <Jartza> yeah. that would leave stupid empty space up'n'down
[18:01:15] <Jartza> I wanted to use the whole 480 pixel screen
[18:01:29] <Jartza> 16 * 10 = 160 pixels, and I draw each horizontal line 3 times
[18:01:36] <Jartza> makes 480
[18:02:00] <Lambda_Aurigae> yeah.
[18:02:06] <Lambda_Aurigae> as I said, I know why you did it.
[18:02:11] <Lambda_Aurigae> it just looks kinda funky.
[18:02:15] <Jartza> hehe yea
[18:02:18] <Jartza> true
[18:03:22] <Jartza> the option would be to draw only 6x8 pixel font like originally
[18:03:38] <Jartza> then that's only 384 pixels of 480
[18:03:41] <Lambda_Aurigae> or even 6x9
[18:03:48] <Jartza> 9 isn't divisable by 4 either
[18:03:50] <Lambda_Aurigae> and draw each line 4 times.
[18:04:03] <Lambda_Aurigae> gives 468 lines.
[18:04:20] <Lambda_Aurigae> your pixels could be 2x3 on each character.
[18:04:26] <Jartza> 576 lines
[18:04:37] <Jartza> 16 * 9 * 4
[18:05:00] <Lambda_Aurigae> oh..I went 13 lines not 16.
[18:05:02] <Lambda_Aurigae> hmm.
[18:05:40] <Jartza> yeah. originally I had the 6x8 pixel font and I drew each hline 4 times
[18:05:41] <cehteh> pixelfonts with diagonals would prolly look much nicher than few more pixels
[18:06:04] <Jartza> diagonals?
[18:06:08] <cehteh> moment
[18:06:17] <Lambda_Aurigae> X and / and \
[18:06:20] <Jartza> ahh
[18:06:24] <Jartza> the font is freely editable
[18:06:29] <Jartza> (almost wrote edible)
[18:06:41] <cehteh> ◢ ◣
[18:06:44] <cehteh> yes
[18:07:06] <Jartza> nothing stops making those characters
[18:07:12] <cehteh> exactly
[18:07:35] <cehteh> also halfheight and 1:2 aspects etc
[18:07:40] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxQ1luNFhwcXl3QjA/view
[18:07:58] <cehteh> how many pixels do you currently emulate in your font?
[18:08:10] <Jartza> basically there are 32 "special" characters
[18:08:11] <Lambda_Aurigae> fonts are 6x10 picrld.
[18:08:14] <Jartza> the font ix 6x10
[18:08:16] <Lambda_Aurigae> pixels
[18:08:31] <Jartza> just a tiny problem with them
[18:08:32] <Lambda_Aurigae> the graphic mode is 2x4 pixels
[18:08:39] <Jartza> the last pixel column is like... almost 3 pixels wide :)
[18:08:42] <Lambda_Aurigae> but the graphic mode pixels are not all the same size.
[18:08:54] <cehteh> ah i thouht you made a fontset only for drawing pixels
[18:08:54] <Jartza> yeah. graphics 64x64 (full screen pixels)
[18:08:59] <Jartza> well I di
[18:09:02] <cehteh> ok
[18:09:03] <Jartza> because I was lazy
[18:09:05] <Jartza> :D
[18:09:18] <Jartza> so I just change font, I didn't have to rewrite my drawing code
[18:09:45] <cehteh> yes .. obliviously .. that also some kind of compression
[18:10:04] <Jartza> and I also had free space in flash
[18:10:09] <Jartza> Code : 3349 words (6698 bytes)
[18:10:15] <Jartza> that's the current full .hex
[18:10:21] <Jartza> 5120 bytes of that is font
[18:10:27] <Jartza> (or two fonts, pixel and "normal")
[18:10:39] <Jartza> the code is 1578
[18:15:44] <Jartza> anyway. it's not that bad that the pixels are different size.
[18:16:10] <Jartza> and that graphis-mode and "tricoder" was just a quick addition to that already "done" product, which required not-too-much-work :)
[18:17:57] <Jartza> it's already stupid project enough :D
[18:20:59] <Jartza> https://i.imgur.com/hIyNM7Q.png
[18:21:07] <Jartza> it's enough to draw pictures like that :D
[18:21:35] <Jartza> (yeah, just very quick'n'dirty -convert to that palette and 64x64 pixels)
[18:21:58] <Jartza> what it needs is web-based graphics editor!
[18:22:05] <Tom_itx> no axe to the head??
[18:23:12] <Tom_itx> is that your opening banner on startup?
[18:26:44] <Lambda_Aurigae> there ya go Jartza
[18:26:53] <Lambda_Aurigae> you need a splash screen stored in rom.
[18:32:19] <Jartza> Lambda_Aurigae: well. there's ansi-code to "save" and "restore" screen
[18:32:24] <Jartza> I'm still planning to implement that one
[18:32:41] <Lambda_Aurigae> hehe.
[18:32:41] <Jartza> whatever is on screen is stored to eeprom :)
[18:32:51] <Lambda_Aurigae> you have enough eeprom for it?
[18:32:57] <Jartza> full 512 bytes
[18:33:01] <Jartza> nothing there
[18:33:03] <Lambda_Aurigae> sweet.
[18:33:32] <Jartza> but yeah. some startup-screen would be nice.
[18:33:36] <Jartza> that still fits to flash
[18:33:47] <Lambda_Aurigae> only needs 512 bytes.
[18:33:50] <Jartza> yep
[18:33:58] <Lambda_Aurigae> load it into ram before you startup the video generator.
[18:33:59] <Jartza> 6698 bytes used so far
[18:34:04] <Jartza> yeah
[18:34:20] <Jartza> and oh, another one
[18:34:26] <Jartza> ansi-escape to "reset" to default mode
[18:34:41] <Jartza> which would reset all graphics, wraps and tricoder-modes to default
[18:34:48] <Jartza> now you need to remember manually reset those
[18:35:34] <Jartza> well no, that's vt100
[18:35:37] <Jartza> <esc>c
[18:35:38] <Jartza> :)
[18:36:14] <Jartza> anyhow, I think I pushed that vga already farther than I ever planned to
[18:37:15] <Lambda_Aurigae> yup
[18:38:39] <Lambda_Aurigae> ok..gonna head for bed..still not feeling well after 4 days of sickies.
[18:39:00] <Tom_itx> dammit somebody shared that with me as well
[18:39:10] <Jartza> sending full-screen pixel-image with "tricoder" takes ~1.6 seconds
[18:39:28] <Jartza> Lambda_Aurigae: ohh... I'm starting to feel the cold hitting too :P
[18:39:30] <Jartza> maybe even flu
[18:39:39] <Jartza> so "happy holidays" to me too :P
[18:39:48] <Tom_itx> woo hooo!!
[18:40:39] <Jartza> Lambda_Aurigae: not sure how useful that 64x64 pixel graphics is, but whatta heck :)
[18:41:01] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxRDhYenFkdjI5bWs/view
[18:41:07] <Jartza> at least you can draw big text with it!
[18:41:11] <Tom_itx> animate an axe to the head!
[18:41:12] <Jartza> if nothing else
[18:48:12] <Jartza> also that graphics-mode is quite untested, especially the tricoder-part
[18:48:52] <Jartza> it might unleash a demon or cause ruptures in time-space continuum
[18:48:57] <Jartza> be careful :)
[18:49:14] <Jartza> still submitted to git becausr I'm brave
[18:56:26] <cehteh> eeprom reading is 5 cycles right?
[18:56:58] <cehteh> well in practice some more, load addresses etc
[18:57:14] <Jartza> whatever, very slow anyway :)
[18:57:28] <cehteh> but if i get the datasheet right its 1 cycle for the read instruction and 4 cycles halting/waiting
[18:57:35] <Jartza> yep
[18:58:06] <cehteh> too slow for you, but its ok for me
[18:58:13] <Jartza> might blank the screen when storing/restoring the screen
[18:58:33] <cehteh> just wondering if i shall add some print-stuff-from-eeprom to my iolib
[18:58:41] <Jartza> why not
[18:58:54] <cehteh> right from eeprom into tx buffer
[19:00:47] <cehteh> mhm .. special case code, prolly too much overhead
[19:02:27] <cehteh> for anything biggier than 2 byte (int32, int64, floats, strings) doing that from flash→txbuffer will be done, butt eeprom nah not now
[22:58:21] <dgriffi> I must be doing something fundamentally wrong. Using a 328p, set F_CPU to all sorts of values and _delay_ms(500) still takes 13 seconds to run.
[22:58:53] <ThatDamnRanga> pastebin time
[22:59:37] <Casper> dgriffi: have you touched the fuses?
[23:00:00] <Casper> and do you have a crystal?
[23:00:09] <dgriffi> Casper: didn't touch fuses and no crystal
[23:00:10] <dgriffi> http://pastebin.com/qTZF3GFQ
[23:00:17] <cehteh> would still change the time
[23:00:24] <dgriffi> this is building something of my own
[23:00:25] <ThatDamnRanga> you're running at 800khz?
[23:00:40] <dgriffi> yeah.. just to see if I could make a difference somewhere
[23:00:48] <Casper> F_CPU = 1000000UL
[23:01:06] <dgriffi> I need to specify it with UL at the end?
[23:01:06] <ThatDamnRanga> 10?
[23:01:25] <Casper> try with it, most likelly the issue I'ld say
[23:01:44] <dgriffi> some other stuff, just canned code. timing works fine.
[23:02:27] <dgriffi> this is the other stuff:
http://davidegironi.blogspot.it/2013/08/avr-atmega-multiple-8x8-led-matrix.html#.VnI2CteANaM
[23:03:41] <dgriffi> arghh.. lemme throw this up into github
[23:04:56] <cehteh> mhmpf .. i need some integer to string conversion function, which take a base as argument too, and doesnt zero terminate the string, but return the number of characters written instead. no such thing in the stdlib :D
[23:08:40] <Casper> cehteh: actually, if you can live with calling 2 functions...
[23:09:35] <Casper> strlen() and itoa()
[23:10:33] <cehteh> nop, the point is that i dont want to reserve space at the end of the buffer
[23:10:58] <ThatDamnRanga> hang on a tick
[23:11:03] <ThatDamnRanga> an 8-bit int is a char
[23:11:12] <ThatDamnRanga> just byte-stuff a char array
[23:11:40] <Casper> ThatDamnRanga: a 8 bit signed int is a char
[23:11:51] <ThatDamnRanga> well.... kinda
[23:11:55] <cehteh> different types of ints actually, but thats not the problem, the avr-glibc has functions for that
[23:12:22] <ThatDamnRanga> let me guess you want 123456 -> '123456' >_>
[23:12:25] <Casper> and why the f* do they defined a char as a signed? you can have negative chars??? someone should have had his hand cut on that one!
[23:12:45] <cehteh> it is not defined as signed
[23:12:53] <ThatDamnRanga> Casper, I'll admit, I use uint8_t for storing ascii, not char :P
[23:13:02] <ThatDamnRanga> I'm sure someone will gut me for that
[23:13:03] <ThatDamnRanga> but eh
[23:13:04] <cehteh> actually char can be signed or unsigned depending on platform
[23:13:14] <ThatDamnRanga> ~care
[23:13:15] <Casper> I always use uint8_t everywhere...
[23:13:15] <cehteh> ugly C history
[23:13:23] <Casper> cehteh: most is signed
[23:13:34] <cehteh> yes, but still its not defined :)
[23:15:25] <ThatDamnRanga> thankfully not many people try and cast a char to int :P
[23:16:05] * Casper needs to try to figure out why they did that stupidity...
[23:19:08] <Xark> I believe the reason char has undefined sign-ness is that some machines are faster to load unsigned and some signed. E.g., older MIPS needed an extra instruction to zero extend a loaded byte and older ARM required an extra instruction to sign extend a byte.
[23:19:31] <Xark> (most modern ISAs have both signed and unsigned load)
[23:20:28] <Casper> possible
[23:21:19] <Casper> another stupidity of C... why the hell does a char/int change of size based on the architecture?!?
[23:21:32] <Casper> a char, ok... but an integer?!?
[23:21:41] <ThatDamnRanga> actually, char also makes no sense
[23:21:49] <ThatDamnRanga> since 'char' is meant to represent an ascii value
[23:22:00] <ThatDamnRanga> which is, unless you're talking unicode, 8-bit
[23:22:21] <Xark> Casper: Because there was no standard register size when C was developed.
[23:22:23] <Casper> well, could be mean to represent one character, in that sense then unicode can make a char 32 bits
[23:22:41] <Xark> char is not "8 bits" in C either.
[23:22:42] <Casper> so that make sense, in a way...
[23:22:59] <cehteh> in posix it is :D
[23:23:28] <cehteh> mhm maybe even C .. meanwhile, but i dont check that now
[23:23:46] <Casper> char is a character. a character could be a varying length. Right from the start: asiatic characters can'T fit in 8 bits...
[23:23:48] <Xark> ThatDamnRanga: It is not for ASCII. C does not specify the encoding.
[23:23:55] <Casper> but an integer?
[23:24:01] <ThatDamnRanga> Xark, noted
[23:24:24] <ThatDamnRanga> Casper, I can see it being useful if it was static and there was a native_int type
[23:24:32] <ThatDamnRanga> which was the architecture's native integer size
[23:24:39] <ThatDamnRanga> rather than it moving
[23:25:13] <Xark> "int" is supposed to be the native size (as long as >= 16) There are standard definitions in stdint.h
[23:25:33] <cehteh> .. anyway i am just go to write my own itoa .. grr
[23:25:59] * Xark is really glad the C people didn't define C "int" as 16-bits. :)
[23:27:27] <Casper> why?
[23:27:59] <cehteh> they should have defined many more typedefs from the beginning, and typedef should be a real typem not just an alias
[23:28:05] <Xark> Casper: Because that would suck on 32-bit machines (e.g.).
[23:28:49] <Xark> cehteh: What would making them a real type accomplish? Not much (save a #include I suppose).
[23:28:55] <dgriffi> okay, here's my project for which I can't figure out why _delay_ms_(500) takes 13ish seconds.
https://github.com/DavidGriffith/328p
[23:29:07] <cehteh> Xark: more typesaftty for free
[23:29:31] <ThatDamnRanga> ^
[23:30:36] <Xark> cehteh: I am not sure that would change anything. Perhaps disallowing explicit conversion (but be careful what you wish for...cast city).
[23:30:52] <cehteh> imagine error_t errno; or charswritten_t printf(fmtstring_t, ...) (yes ugly names, but you get the idea)
[23:31:22] <Xark> cehteh: That works with typedefs...
[23:31:59] <Casper> dgriffi: first, it need to be 1000000UL not 8... the default fuse is 8MHz internal oscillator with clock divide by 8, for an effective of 1MHz
[23:32:06] <cehteh> good code doesnt need much casts, and if (well not on embedded) i'd rather wrap casts in inline funcs bar_t foo_to_bar(foo_t )
[23:32:39] <cehteh> Xark: typedefs are just aliases they are somewhat fragile and dont help to make things safe
[23:33:30] <Xark> cehteh: C++ allows you to make types like that if you desire.
[23:33:32] <Casper> then, do you have some interrupts going on? they will cause delays on _delays_ms()
[23:33:33] <cehteh> moreover in many places the types are just to generic they allow values which are not valid for the function
[23:33:51] <dgriffi> Casper: that doesn't work
[23:33:57] <dgriffi> error "USB_CFG_CLOCK_KHZ is not one of the supported non-crc-rates!"
[23:33:58] <cehteh> i talk about C and history what could be done better if someone invents a time machine
[23:34:20] <Xark> Fair enough. :)
[23:35:21] <Casper> dgriffi: change the fuse to disable the clkdiv8
[23:35:23] <cehteh> C++ on the other hand became waaaaaaay to bloated
[23:35:29] <Casper> http://www.engbedded.com/fusecalc/
[23:36:06] * Xark is a fan of C++11 :)
[23:36:13] <osteri> why portability is used as an argument when uint8_t is used, because int is much more portable. i think it is more right to say: uint8_t is used because of memory/mod in microcontrollers
[23:37:29] <Casper> portability is a lame excuse
[23:37:48] <Casper> it break code relying on overflow and conversion
[23:38:17] <Xark> Portable code is a trade off typically. On a MCU that may not be acceptable.
[23:39:29] <Xark> osteri: If you don't care at all about portability and want best MCU speed, you may want -mint8. :) Totally breaks C rules, but saves a fair amount of pointless work on AVR (for the upper byte of int, default type). :)
[23:39:35] <Casper> still, one issue is that they should have defined 2 types of variable, the native like they did... and a fixed size, which most should have used
[23:40:21] <Xark> Casper: You say that, but on a (e.g.) 18 bit machine, making a 16-bit int "wrap" properly is very expensive.
[23:40:49] <dgriffi> portability seems to imply bigger code
[23:41:35] <Xark> dgriffi: It can. Sometimes it doesn't hurt (or the optimizer can "bake out" unneeded stuff).
[23:45:02] <Casper> Xark: portability don't go with optimisation, but as little code as possible difference..
[23:48:23] <dgriffi> okay, I think I got things working now
[23:48:43] <dgriffi> does anyone here make regular use of v-usb?
[23:50:52] <dgriffi> I was wondering if anyone here knows of a rewritten version of the hid-data example host code that works with libusb 1.0
[23:52:04] <dgriffi> anyone?
