Back
[01:04:38] <LoRez> asteve_: please fix your client
[06:34:29] <antto> peer: u nasty son of a b****
[06:35:04] <Tom_itx> way to start the day off
[06:35:59] <LeoNerd> Soo.. I'm looking at building a little voltage+current monitor onto the front of a development power supply, so as to watch for overcurrent etc... I -was- about to order myself some MAX4172 current-sense amps, and wire the thing up using a few of the ADC ports on an ATtiny, but I have just stumbled upon the INA219, especially the breakout board that Adafruit make for it
[06:36:34] <LeoNerd> That's a single-board solution that talks I2C, managing the voltage and current sense directly for me... Does anyone have any opinions on either of those two solutions?
[06:37:50] <Jartza> one of these days I'm gonna find this peer-guy and reset HIS connection!
[06:37:55] <Lambda_Auriga_> LeoNerd, whatever works best for you.
[06:38:24] <Lambda_Auriga_> LeoNerd, you might also look at the max133...a full DMM on a chip..just needs some caps and resistors.
[06:39:16] <antto> Jartza kick him in teh nuts too!
[06:39:20] <LeoNerd> Well, I don't know if either works, as I haven't tried them out :) The difference mainly is that the Adafruit INA219 board is GBP12, whereas the MAX approach is a lot cheaper but requires more "moving parts" and also I'd have to solder a SOIC8 chip onto a breakout board
[06:39:40] <LeoNerd> I was hoping to hear from someone who's used one or the other, or at least similar
[06:39:45] <Tom_itx> Jartza what did he do?
[06:39:55] <LeoNerd> But I shall now look up the MAX133
[06:40:26] <Lambda_Auriga_> max133 comes in a dip package...bit more expensive than the current sense amp setup but much more functional.
[06:41:29] <Tom_itx> order from newark using voucher code: ND34E and get 15% offf
[06:41:30] <LeoNerd> Huh, that's more for making a DMM directly. Not at all what I want
[06:41:51] <Lambda_Auriga_> it can do measurements of current and voltage though.
[06:42:01] <LeoNerd> I want a box that's monitoring voltage+current on a number of lines at the same time, with a programmed current limit on each.. if it goes over, it'll beep and shut down current
[06:42:02] <Lambda_Auriga_> I'm using it in my android DMM module
[06:42:20] <LeoNerd> Bench PSU => monitor box => circuit under development
[06:44:23] <Jartza> Tom_itx: looking at the irc-log, he's resetting people's connections quite often ;)
[06:44:44] <Tom_itx> how?
[06:44:50] * twnqx doesn't like inline resistor based current sensors
[06:44:55] <Jartza> 14:16 -!- asteve [~textual@unaffiliated/kxsteve] has quit [Read error: Connection reset by peer]
[06:44:58] <Jartza> 14:16 -!- asteve_ [~textual@pool-108-48-28-83.washdc.fios.verizon.net] has joined #avr
[06:45:02] <Jartza> ;)
[06:45:43] <Tom_itx> what's that got to do with peer?
[06:46:05] * twnqx looks into his toybox of unused goodies
[06:46:46] <twnqx> Si8501, ACS714T, ??? 91205
[06:46:55] <twnqx> that's where modern current sensing is at :P
[06:47:03] <Jartza> Tom_itx: "connection reset by peer"
[06:47:13] <Jartza> clearly, this was a joke :(
[06:47:58] <LeoNerd> twnqx: Ah; any particular reason against the shunt res. idea?
[06:48:12] <twnqx> resistive losses
[06:48:27] <LeoNerd> Yeah, but I'm measuring small current.. probably only up to 100mA at most
[06:48:28] <twnqx> also, much more susceptiple to noise
[06:48:36] <twnqx> tibe*
[06:48:38] <twnqx> tible*
[06:49:03] <twnqx> you have a very little voltage drop, so you need a high precision A/D or a differential opamp
[06:49:21] <LeoNerd> Ah, these hall sensors
[06:49:33] <LeoNerd> Yeah; I don't think they'd work anywhere aroudn the tiiiny currents I'm looking at
[06:50:42] * Tom_itx should ban Jartza as a joke
[06:52:02] <Tom_itx> at least he's on a different server now
[08:56:55] <mheld> anybody have any AVR getchar code that's interrupt and/or full message driven?
[08:57:26] <mheld> I really want to just write while(USARTGSM.DATA){ do stuff to usart_getchar(USARTGSM) }
[08:57:29] <mheld> but that ain't gonna roll
[09:01:57] <twnqx> any idea why i can't find
http://lrak.net/secret/data_sheets/app_notes/AVR-I2C-app.pdf on atmel.com? :X
[09:02:11] * twnqx wants the software that seems to belong to it
[09:03:53] <twnqx> well ok, found the .asm
[09:03:56] <twnqx> but still...
[09:04:23] <twnqx> ;* Last updated : 97.07.17 heh
[09:13:31] <specing> mheld: yeah I think I have such; no idea where though
[09:19:03] <mheld> hah
[09:19:05] <mheld> thanks :_P
[09:19:06] <mheld> :-P
[11:14:08] <twnqx> . . .
[11:14:10] <twnqx> just
[11:14:14] <twnqx> how bad is avr-gcc really
[11:14:41] <twnqx> really bad, horrible, or "i'll just write assembly"?
[11:15:32] <twnqx> what the hell is it even doing in this sequence
[11:15:38] <twnqx> 52: 90 e0 ldi r25, 0x00 ; 0
[11:15:41] <twnqx> 56: 90 95 com r25
[11:15:45] <twnqx> 5a: 99 27 eor r25, r25
[11:15:49] <twnqx> 5c: 89 2b or r24, r25
[11:16:35] <twnqx> r25=0; r25 = ~0 = 255; r25 = r25^r25 = 0; r24 |= 0 ????
[11:55:25] <jacekowski> twnqx: that's quite good for avr-gcc
[11:55:41] <twnqx> you are kidding, right
[11:55:54] <twnqx> that's 50% code, 50% nop in my case
[11:57:32] <jacekowski> no
[11:57:38] <jacekowski> avr-gcc is really that bad
[11:58:11] <jacekowski> if you want to look at asm, write in asm, if you do C and use avr-gcc to compile it, don't look at the code it's generating
[11:58:48] <jacekowski> simple byte order change in uint32_t takes about 50 instructions
[11:59:24] <jacekowski> and all i had to do is get data over one usart reverse byte order send it again
[12:02:26] <twnqx> is there any other c compiler that is usable?
[12:02:41] <twnqx> well
[12:02:51] <twnqx> any. this result disqualifies gcc from "usable"
[12:21:43] <Steffanx> What amazing piece of C gets turned into that twnqx?
[12:24:02] <twnqx> http://pastebin.com/wnmEUh6Y
[12:34:39] <twnqx> gah, i haven't written asm in ages
[12:37:56] <specing> heh twnqx just now figured out how crappy gcc is with AVR
[12:38:14] <twnqx> i never really looked into it
[12:38:28] <specing> try simplifing that expression
[12:38:34] <specing> reg = ~reg;
[12:38:35] <twnqx> ... simplifying?
[12:38:51] <specing> auto ison = reg & whatever;
[12:38:54] <specing> while(ison)
[12:39:42] <specing> honestly idk where those coms come from, it should be a matter of andi and brne
[12:39:57] <twnqx> the com comes from the ~
[12:40:35] <twnqx> 50: 80 b3 in r24, 0x10 ; 16
[12:40:36] <twnqx> 52: 80 95 com r24
[12:40:36] <twnqx> 54: 88 71 andi r24, 0x18 ; 24
[12:40:36] <twnqx> 56: e1 f7 brne .-8 ; 0x50 <__SREG__+0x11>
[12:40:36] <LeoNerd> The ~ and ! operators in C annoy me slightly; in that C doesn't allow you to lvalue !=
[12:40:39] <twnqx> in manual asm
[12:41:57] <twnqx> rofl specing
[12:42:00] <twnqx> perfect guess
[12:42:10] <specing> ?
[12:42:13] <twnqx> do {
[12:42:14] <twnqx> reg = ~PINx(I2C_PORT);
[12:42:14] <twnqx> } while (reg & I2C_MASK);
[12:42:17] <twnqx> no more R25 at all
[12:42:28] <specing> ah yes
[12:42:54] <twnqx> does it do some automatic 16bit magic there... hmmmm
[12:45:39] <specing> its just being stupid
[12:45:56] <twnqx> well
[12:46:03] <twnqx> it's clearly expanding reg to 16bit
[12:46:14] <twnqx> for no obvious reason
[12:46:39] <specing> how is I2C_MASK defined?
[12:46:42] <specing> macro?
[12:47:00] <specing> it might be treating it as an int
[12:47:37] <twnqx> currently toying with that
[12:47:44] <twnqx> but even then...
[12:48:20] <twnqx> i think for texting i replaced it with 0x18 (its value)
[12:48:23] <twnqx> testing*
[12:49:00] <twnqx> yeah
[12:49:04] <twnqx> did that
[12:58:53] <specing> try doing (uint8_t)0x18
[12:59:11] <specing> or whatever the reg is
[12:59:45] <specing> implicit conversions are one of the reasons I hate C
[12:59:58] <N1njaneer> Then make the conversions explicit.
[13:00:22] <N1njaneer> Implicit conversions are a matter of convenience, but the compiler is only so smart given the limited information provided.
[13:00:43] <specing> twnqx: try -Wimplicit
[13:01:18] <N1njaneer> Remember, you are not writing actual instructions, you are instead effectively trying to describe to the compiler the work you want it to perform. The more information and hints you can give it, the closer it will get to producing specifically what you want. :)
[13:01:23] <specing> no, this doesen't warn
[13:01:47] * twnqx should use what he does in his more extreme porject
[13:01:57] <specing> N1njaneer: yes, it is a "matter of convenience", but in this case it is buggy
[13:02:07] <specing> s/buggy/not warranted/
[13:02:36] <twnqx> CFLAGS += -Wall -Werror -Wstrict-prototypes -Wextra -Wshadow -Wpedantic -Wimplicit
[13:02:36] <twnqx> :X
[13:02:47] <specing> -WCHorror
[13:03:00] <specing> -WChorror ;)
[13:03:08] <twnqx> hmmmm
[13:03:23] <twnqx> could it be...
[13:03:27] <specing> -fi-made-that-up
[13:03:59] <kastein> git-man-page-generator.lokaltog.net
[13:04:31] <malinus_> N1njaneer: doesn't wall take care of that ?
[13:05:52] <twnqx> specing: while (((uint8_t) ~reg) & 0x18); works too
[13:05:58] <twnqx> the ~ seems to be the expander
[13:12:12] <kastein> ~ is bitwise NOT
[13:13:46] <specing> ~ is teh tidle!
[13:14:17] <twnqx> kastein: true. but:
http://pastebin.com/dVm2Ce8T
[13:15:08] <twnqx> specing: i just learned that the c-spec might actually andate the (int) return type...
[13:15:16] <twnqx> mandate*
[13:15:46] <specing> twnqx: join #cjeopardy and bulge your eyes out over all the things you don't know...
[13:16:19] <twnqx> that makes absolutely no sense...
[13:21:26] <N1njaneer> The difficulty with ~ is that the compiler can't always identify the unit you are trying to swap to. Having an unknown number of leading zeros that need to be flipped to 1's requires casting if you definatively need it in a known size.
[13:22:32] <N1njaneer> Case in point -- ~0 -- does this become 0xFF, 0xFFFF, 0xFFFFFFFF, etc
[13:22:48] <twnqx> i - kind of - agree
[13:22:49] <N1njaneer> Without a cast there needs to be assumption of the lvalue size.
[13:23:30] <N1njaneer> Remember, the compiler does what you tell it to do, not what you want it to do. :D
[13:24:06] <twnqx> in my oppinion
[13:24:16] <twnqx> following it by an and with a constant
[13:24:20] <twnqx> that fits 8bit
[13:24:24] <twnqx> is pretty clear
[13:25:03] <twnqx> (by the way, i know about appending u/ul, but can i specify a smaller-than-int type for a constant?)
[13:25:19] <N1njaneer> twnqx: What optimization level, if any, are you compiling with?
[13:25:27] <twnqx> s, 2, 3
[13:25:42] <twnqx> normally, 2
[13:27:33] <twnqx> but yes, it's spec complying. ~ expands an unsigned char to an int
[13:27:44] <timemage> twnqx, in most situations something smaller than an int types will get promoted to an int type. if you're doing 8bit operations it usually isn't a problem if you're assigning back to 8bit. the optimizer will usually effectively remove the promotions.
[13:27:58] <twnqx> and since the end result of this is a boolean, which is an int...
[13:28:35] <twnqx> gcc misdesign #1
[13:28:40] <twnqx> sizeof(int) != 1
[13:28:45] <twnqx> for this 8bit cpu
[13:28:45] <LeoNerd> That's C, not gcc
[13:28:50] <twnqx> no
[13:29:03] <twnqx> can't you have an int as 8bit, ever?
[13:29:11] <timemage> twnqx, C requires int hold a range of -32767 to +32767. so unless you want to make all your char 16bit then you don't have much choice.
[13:29:12] <LeoNerd> C requires that an 'int' can represent at least -32767 to +..
[13:29:14] <LeoNerd> what he said
[13:29:19] <twnqx> oh.
[13:29:44] <twnqx> so basically, i have to be extra careful around boolean types
[13:30:30] <timemage> twnqx, not as much as you might think.
[13:30:54] <twnqx> if i can accidently end up with stupid 8bit code, yes
[13:31:04] <twnqx> emulating 16bit for absolutely no reason, i mean
[13:31:16] <twnqx> because the result can never, ever use 16bit
[13:31:17] <timemage> twnqx, again, the optimizer trivially removes that.
[13:31:40] <twnqx> escept when it doesn't as in my example and produces 100% overhead
[13:31:54] <twnqx> and even worse, assigns constants over and over
[13:32:14] <Jartza> I specifically usually use uint16_t or uint8_t or int16_t to make sure the variables are of correct size
[13:32:25] <antto> +1
[13:32:35] <twnqx> and how does that help
[13:32:40] <timemage> twnqx, even in the case of somethine like this: unsigned char ul=0xAA; ul &= 0xF0; you have 0xF0 and the old value of ul being promoted to unsigned int. then bitwise-anded then assigned. in practice this isn't a problem though. look at the generated code with any level of optimization turned on.
[13:32:41] <twnqx> in my case?
[13:32:46] <twnqx> i ONLY use u8, u16, etc
[13:33:00] <timemage> twnqx, dunno why i put ul there instead of uc. but anyway.
[13:33:06] <twnqx> well
[13:33:10] <twnqx> look at my pastebin
[13:33:52] <twnqx> so yes, the optimizer fails in boolean context
[13:33:58] <twnqx> period.
[13:35:49] <timemage> twnqx, post a compilable chunk of code.
[13:36:20] <Jartza> I agree
[13:36:39] <twnqx> int main (void) { unsigned char reg; do { reg = PIND; } while (~reg & 0x18);
[13:36:45] <twnqx> }
[13:36:59] <twnqx> since you can't read the two lines of C from my pastebin, it seems...
[13:37:15] <twnqx> oh, i forgot: #include <avr/io.h> before
[13:37:21] <timemage> twnqx, and the types
[13:37:25] <N1njaneer> Good stuff, timemage. (sorry, phonecalles here!)
[13:37:36] <twnqx> unsigned char ?
[13:37:36] <timemage> N1njaneer, erm, what?
[13:37:48] <N1njaneer> timemage: All of your explanations above.
[13:37:58] <timemage> twnqx, you had a macro definition missing before as well.
[13:38:06] <N1njaneer> Had to stop typing when the attorney calls :D
[13:39:04] <twnqx> vs. int main (void) { unsigned char reg; do { reg = PIND; } while ((unsigned char)~reg & 0x18); ]
[13:39:54] <timemage> twnqx, supply -Os to your first one.
[13:40:10] <timemage> twnqx, see if it makes any difference. i'm setting up an env. here.
[13:40:17] <twnqx> it was identical between all three, but give me a moment
[13:40:25] <twnqx> between -Os, -O2 and -O3
[13:40:39] <twnqx> if it humors me
[13:40:41] <twnqx> youÜ*
[13:41:27] <timemage> twnqx, hey, if you don't want me look at it, i'm fine with that as well. sort of learning that way now anyway.
[13:41:48] <twnqx> i am telling you that the result was the same for -Os, -O2 and -O3 for me
[13:41:55] <timemage> twnqx, okay.
[13:41:57] <twnqx> because I tried that _first_
[13:42:26] <twnqx> i did not try -O0 and -O1, because i use those only when i hit real compiler bugs
[13:42:50] <twnqx> only had that on x86_64 so far, though
[13:59:37] <Jartza> twnqx: surely that could be some kind of bug in avr-gcc, that should be reported?
[14:00:14] <twnqx> i asked the same question on the avr-gcc mailing list
[14:01:12] <Jartza> looks like gcc somehow indeed misses that reg is 8bit and you have to cast it to 8bit again
[14:01:31] <Jartza> I got identical code with avr-gcc 4.8.1
[14:03:26] <Jartza> although, I found old avr-gcc from my machine too
[14:03:39] <Jartza> avr-gcc 3.4.6 makes conciderably longer code ;)
[14:04:06] <Jartza> even with the cast
[14:15:58] <Jartza> I'm still fairly happy with avr-gcc 4.8.x
[14:21:21] <twnqx> specing: gcc 4.8. really doesn't seem all that bad
[14:21:41] <twnqx> except i still don't... oh.
[14:21:58] <twnqx> heh.
[14:22:31] <twnqx> actually, it generates almost exactly the assembly of the original asm
[14:23:19] <twnqx> except... it doesn't act on sbic
[14:25:38] <twnqx> fun, it uses sbic in one scenario, but not the other :)
[14:27:58] <N1njaneer> twnqx: sbic and friends can only target certain IO registers in the map due to register number range, so that may be why.
[14:28:11] <twnqx> nah, it's the same :P
[14:29:19] <twnqx> oh wow.
[22:56:35] <Casper> ... dreams are good
[22:56:44] <Casper> ... but sometime they are painfull
[22:56:55] <Casper> I read about the qtouch library of atmel
[22:57:39] <Jartza> :F
[22:57:54] <Jartza> oh, :D even
[22:58:09] <Casper> it make me want to use capacitive touch on a future projects<
[22:58:14] <Casper> in fact, few of 'em
[23:02:26] * Casper pokes rue_house
[23:03:01] <Casper> you used an ide controller as a parallel port right? can you bitbang it? or is it a royal pita to do?
[23:03:29] <Casper> trying to see what I will use on one project... serial or "parallel"
[23:03:57] <Casper> parallel could avoid me the need to use any microcontroller
[23:04:32] <Casper> (unless I decide to use touch)
[23:23:31] <rue_house> Casper, whaaaaa
[23:23:49] <rue_house> Casper, ide IS ISA, so is parallel (almost)
[23:24:05] <rue_house> on the IDE bus, you get:
[23:24:09] <rue_house> 16 bits of data
[23:24:43] <rue_house> /CS (chip select, decoded for the address range of master or slave depending)
[23:24:56] <rue_house> 3 address bits (you have 8 addresses)
[23:25:12] <rue_house> /WR (write)
[23:25:17] <rue_house> /RD (read)
[23:25:47] <rue_house> if you want to get fancy, you have DMA REQ and ACK
[23:26:42] <rue_house> I still stand, that IDE was faster than SCSI back when apple was bloating it to be the best thing since bread slices
[23:26:54] <rue_house> 133Mhz * 16 bits = 266MB/sec
[23:27:00] <rue_house> +-10
[23:27:37] <Casper> yet they somehow fucked up and did only 133 max :D
[23:28:09] <rue_house> media trasfer rate would have been the limit
[23:28:29] <rue_house> I think that seagate had the worst, and everyone loved seagate
[23:28:31] <Casper> do you have simultanious input and output? or they are just bidirectional with few control lines?
[23:28:55] <rue_house> my 5400 fujitsu, without buffer, outpaced a maxtor 7200 with buffer
[23:29:20] <rue_house> Casper, no processor has simotanious input and output, there is a bidirectional data bus
[23:29:38] <Casper> ok... so unusable...
[23:29:46] <Casper> I need a few buttons and many outputs...
[23:30:00] <Casper> so will ends up easier with a µC on serial...
[23:30:03] <rue_house> no, you add io controllers
[23:30:20] <rue_house> you have 128 bits available on the ide bus
[23:30:24] <rue_house> of input and output
[23:31:15] <rue_house> 8 bits of output: 74xx373
[23:31:25] <rue_house> 8 bits of input 72xx244
[23:31:48] <rue_house> if your buying them use the 74xx573 and 74xx544 respectivly
[23:32:04] <rue_house> they are repinned for 8 bit computers
[23:32:20] <mheld> what happens when strcat a string that's larger that its buffer?
[23:32:47] <mheld> char thing[10] = "12345"; strcat(thing, "67890123456");
[23:32:48] <rue_house> it overwrites whatever memory is after the buffer, maybe causing a segfault
[23:33:16] <Casper> or causing no error, but cause bugs
[23:33:36] <rue_house> oh yea, the old 2+2=21564718827772399267618916291666218
[23:33:39] <Casper> or, can be exploited by an hacker to run unauthorised code, like malware
[23:33:59] <rue_house> ah yes, the old nop nop nop nop nop nop pop jump
[23:35:24] <Casper> oh rue_house ! wanna see what I had to fix at work? :D
[23:35:43] <Casper> https://www.dropbox.com/s/9g7weu9cseuwy4a/2014-09-18%2014.13.44.jpg?dl=0
[23:36:00] <Casper> https://www.dropbox.com/s/jrbi7h6iw0xpjp6/2014-09-23%2015.54.39.jpg?dl=0
[23:36:44] <Casper> https://www.dropbox.com/s/sv0k5syaw53vady/2014-09-23%2014.01.46%20HDR.jpg?dl=0 <=== sorry for the french, but you can still understand easilly :D
[23:38:16] <mheld> huh, maybe I use strncpy and do a smaller of strlen(THINGTOCOPY) and remaining size of buffer
[23:39:09] <rue_house> Casper, fancy capture card?
[23:39:40] <Casper> car wheel alignment pc
[23:43:06] <rue_house> ah
[23:44:03] <Casper> made by snap-on (you can see it on the top of the card)
[23:44:08] <Casper> but rebranded machine
[23:44:17] <Casper> which is, of course, cheaper...
[23:45:07] <Casper> they received the pc, they started it up, it show snap-on, the tech install the machine, then remove all reference to snap-on and put their compagny brand :D
[23:46:00] <mheld> a char is a byte, yeah?
[23:46:45] <Casper> mheld: depend on the architecture, on avr 8 bits, yes
[23:46:47] <Casper> but
[23:46:58] <Casper> a char is an unsigned integer 8 bits
[23:47:01] <Casper> err
[23:47:04] <Casper> signed integer
[23:48:07] <Casper> why do they decided a char is signed? probably someone smoked too much...
[23:49:51] <Xark> Casper: Probably PC code compatibility (as this is MS default)? You should always ask for signed or unsigned if you care. :)
[23:49:59] <mheld> huh
[23:50:03] <mheld> that seems like a lot of data
[23:50:12] <mheld> I have 128 bytes
[23:50:18] <mheld> need to encode more than 128 characters in there
[23:50:20] <mheld> :-(
[23:51:42] <Xark> mheld: It is generally tricky to get 2 gallons into a 1 gallon container. :)
[23:52:00] <mheld> I believe in magic
[23:52:13] <Casper> Xark: but still, even on a pc... a CHARACTER can't be negative
[23:52:41] <Casper> it's a stupid thing to have made it signed straight from the start...
[23:52:43] <Xark> Casper: Yes, char is signed on a PC.
[23:52:49] <Xark> Casper: So, it can indeed be negative. :)
[23:53:05] <Casper> it hurt my asperger brain :D
[23:53:32] <Xark> Casper: The C spec doesn't specify (because to do so would penalize one architecture or another - so they let the ABI "choose" - unless you use signed or unsigned).
[23:53:45] <Jartza> ¡
[23:53:49] <Jartza> there's a negative character for you
[23:53:58] <Jartza> ;)
[23:54:05] <Casper> Jartza: that's inverted, not negative
[23:54:17] <Jartza> Casper: I know, it was a joke :)
[23:54:31] <Jartza> what about - then?
[23:54:40] <Jartza> that's surely a bit negative
[23:54:49] <Casper> Xark: yeah... and it's sad that they screwed on the size of the named type...
[23:55:01] <Casper> an int can be 8, 16 or 32 bits...
[23:55:17] <Casper> ... the specs screwed up...
[23:55:19] <Jartza> but yeah, I've always laughed at signed char too
[23:55:40] <Casper> now... what does this linux box say: wlp4s1 no wireless extensions.
[23:55:41] <Casper> grrr
[23:55:45] <Xark> Casper: Well, they had to be flexibile back in the days of 9 bit chars and 36 (or 21 or 24) bit words. :)
[23:56:13] <Xark> Jartza: It is very handy as a "small int". :)
[23:56:16] <Jartza> although, ascii only uses 7 bits, so I guess someone thought that it's convenient data type for either characters or small negative numbers
[23:56:36] <Xark> Jartza: However, poor style to not add signed or use int8_t.
[23:56:52] <Jartza> Xark: sure it is, but why they didn't have datatypes like "char" and "byte" and "unsigned byte" etc? :)
