Back
[03:55:10] <_abc_> Hello. Is there some way to achieve a neat left shift of each byte in an unsigned char [] such that each high bit shifted out of a lower byte shifts into the next byte? Is it cleaner to use a union for this? Any pointers or examples would be welcome.
[04:28:12] <Xark> abc: C is clumsy for this, since you really need a carry bit (which C doesn't expose). If you use a union, C will support up to 4 bytes (as a uint32_t). You can chain these together, but you will have to "manually" get the high bit and OR it into the next uint32_t low bit.
[04:28:46] <_abc_> you mean u_int32_t :)
[04:28:55] <_abc_> yes that is the problem
[04:29:05] <Xark> No, uint32_t is the correct type IIRC. :)
[04:30:03] <Xark> http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html
[04:30:42] <_abc_> my union allusion would have meant making a union over the bytes such that: union { byte[NUM_BYTES]; struct { unsigned char byte2[NUM_BYTES/2]; } even; struct { unsigned char dummy; unsigned char byte2[NUM_BYTES/2]; } odd; } MyData;
[04:31:12] <_abc_> which is ugly beyond words (put unsigned short instead of char above)
[04:31:54] <_abc_> Xark: I wish the avr people would talk to the linux people. In kernel land it is u_int32_t
[04:32:06] <karlp> _abc_: are you sure?
[04:32:09] <karlp> really really sure?
[04:32:19] <karlp> it's not an avr libc thing.
[04:32:58] <Xark> Well uint32_t is totally "official" C and C++ (kernel is kernel-standard). :)
[04:33:29] <karlp> my linux only has this mad u_int32_t in resolv.h
[04:33:30] <karlp> nothing else.
[04:33:46] <Xark> karlp: Well, #include <stdint.h> :)
[04:34:13] <karlp> how about, instead of avr talking to linux, how about linux talks to c standards?
[04:34:26] <_abc_> karlp: I am compiling it for the 20th time, debugging. I am pretty damn sure
[04:34:43] <_abc_> u_int_32t is defined in /usr/include/asm/types.h
[04:34:49] * Xark notes in the kernels defense, that it pre-dates the official stdint (for C especially).
[04:35:12] <Xark> _abc_: Yes, that is some linux kernel only file.
[04:35:29] <_abc_> Xark: and the only one included by default when doing #include <stdio.h>
[04:35:32] <_abc_> which is fine by me
[04:35:45] <_abc_> I used a condtional define to define the missing one :)
[04:35:52] <_abc_> Let's move back to the initial problem...
[04:35:58] <_abc_> So my uinon idea is a bad one?
[04:36:32] <_abc_> Its problem is that it accesses the union as unaligned shorts, which may be a) expensive on 8 bit ones, and b) also expensive on 16 bit cores and 32 bits
[04:36:55] <Xark> Well, it will only "postpone" the problem. :) It will get you to 4 bytes before you have to do a "manual carry" (but that isn't so bad).
[04:37:44] <Xark> _abc_: Well, as soon as you use a union like this (where you assume byte order) you are non portable.
[04:38:02] <Xark> _abc_: Is this super speed critical?
[04:38:40] <_abc_> not really but size and variable use is to be low
[04:45:12] <Xark> _abc_: Perhaps a loop like this
http://pastebin.com/z8SCAbvK (YMMV, serving suggestion only, untested)
[04:48:20] * Xark realizes "byte" may be an unfortunate choice for a local identifier(depending on the namespace pollution present [looking at you Arduino]). :)
[04:51:49] <_abc_> heh
[04:51:55] <_abc_> I won't, I don't use that.
[04:52:51] <Xark> _abc_: That loop make sense? It might even compile... :)
[04:55:39] <Xark> I think this per-byte method is portable also (although the array will always be "little endian" - at least it will work the same everywhere). If the compiler is smart it could even use the carry flag (but I wouldn't really expect avr-gcc to).
[04:57:44] <Other019> test
[05:09:44] <_abc_> Xark: I had no time to look. Just a second
[05:11:50] <_abc_> Okay is there any guarantee that a uint32 packed into a struct in avr-gcc is little endian? i.e. #define N 4; union { unsigned char byte[N]; uint32_t var; } U; U.var = 0x12345678; then U.byte[0] = 0x78; U.byte[1] = 0x56; U.byte[2] = 0x34; U.byte[3] = 0x12; ??
[05:13:02] <_abc_> Also, is there some clever assertion to test same which is portable and available in avr-gcc?
[05:13:12] <_abc_> Preferrably to flag problems at run time?
[05:18:16] <_abc_> gtg
[05:20:37] <Xark> Well you know AVR8 is little endian. There is not really a portable non-run time test. At run-time you can just make a short union, set it to 1 and then look and see which byte changed.
[07:47:58] <BusError> anyone tried olimexino-32u4 with lufa ? I tweaked a couple of examples. flash them, and nothing happend, device doesn't get enumerated on the bus
[07:49:02] <BusError> lufa trunk from git, demo MIDI or VirtualSerial, removed mentions of the joystick...all seems fine..
[09:06:24] <Rickta59> anyone here familiar with the limitations of the avr910 protocol? Can i program an atmega328p with it?
[09:16:24] <Corwin> Rickta59, it depends on protocol version.... and used software
[10:10:41] <GNUtoo-hplaptop> hi, is that code correct:
http://pastie.org/4171860
[10:10:50] <GNUtoo-hplaptop> or should it be more like that:
[10:11:08] <GNUtoo-hplaptop> int freq = ( (F_CPU / (8 * bauds) ) -1) ;
[13:36:21] <Marcel_> hi
[13:36:22] <tobbor> Hello Marcel_
[13:42:03] <Steffanx> Hello other019
[13:42:08] <Steffanx> Totally tell us about your project!!
[13:42:42] <other019> i have only 15 years so it's not sth big.
[13:42:52] <other019> But las time i made 8x8 led matrix
[13:43:33] <other019> Now i'm tring to make termometer (ADC forget name of it) with LCD (/HD44780)
[13:44:09] <other019> what about U?
[13:44:54] <Steffanx> Nothing interesting
[13:45:16] <Steffanx> I actually said that because tobbor, the bot, asks that sometimes
[13:45:23] <Steffanx> */asks/says
[13:46:18] <other019> it doesnt work
[13:47:23] <other019> */asks/says
[13:47:28] <other019> /asks/says
[13:47:30] <other019> /asks
[13:48:19] <GNUtoo-hplaptop> good idea, do you have code yet for the termometer?
[13:48:26] <GNUtoo-hplaptop> I've some lm35
[13:48:31] <other019> nope
[13:48:38] <GNUtoo-hplaptop> ok
[13:49:02] <other019> But to HD44780 i use lib from thiss site
[13:49:06] <GNUtoo-hplaptop> I've also an adapter for lm35<->arduino
[13:49:07] <GNUtoo-hplaptop> ok
[13:49:18] <other019> http://radzio.dxp.pl/hd44780/
[13:49:20] <GNUtoo-hplaptop> (I made the adapter myself)
[13:49:23] <OndraSter> sfspzrt,
[13:49:24] <OndraSter> adapter?
[13:49:53] <GNUtoo-hplaptop> let me fetch it to describe it
[13:49:58] <other019> i want to make it to learn use ADC
[13:50:11] <OndraSter> can't imagine what the adapter can contain
[13:50:17] <other019> so i don't know when it will be workin'\
[13:50:20] <OndraSter> resistor + lm35 + vcc + vss + vsense?
[13:50:34] <GNUtoo-hplaptop> no, way less
[13:50:55] <GNUtoo-hplaptop> just a pcb for connecting it to the right pin + some pins
[13:50:56] <OndraSter> how much less than 1 resistor, 1 lm35 and three holes for wires?
[13:51:18] <GNUtoo-hplaptop> so it plugs directly into the arduino
[13:51:40] <GNUtoo-hplaptop> I've not programmed the ADC yet in avr-libc tough
[13:51:42] <OndraSter> ah
[13:51:50] <OndraSter> shiled for arduino
[13:51:51] <OndraSter> shield*
[13:52:23] <GNUtoo-hplaptop> some very small pcb, some pins that plug into a header and route to some thing that can hold a lm35
[13:53:25] <GNUtoo-hplaptop> what I did so far is a BIOS programmer in avr-libc that targets the arduino uno, but because of issues with 8u2 it ended up working well on the duemilanove only
[13:54:02] <GNUtoo-hplaptop> it supports tons of chips trough flashrom
[13:54:05] <OndraSter> BIOS programmer as in EEPROM writer?
[13:55:21] <GNUtoo-hplaptop> SPI flash reader/writer
[13:59:06] <other019> Im driming about connect termometer with RTC (TWI), and logging temp on SD card
[14:04:18] <OndraSter> other019, if you use already finished SD&FAT libs you are done within an hour :)
[14:07:14] <other019> No i'm crawling i can't make HD44780 to work correctly
[14:36:10] <GuShH_> other019: what's the problem?
[14:36:30] <GuShH_> other019: init, send data. if it's not working and your code is proven, it's a hardware issue and vice versa.
[14:38:53] <other019> LIB just month ago works
[14:39:16] <other019> but i don't remember wchih 4 bit or 8 bit
[14:39:24] <other019> so i try tommorow
[14:40:25] <OndraSter> it is simple to find out whether it is 4 or 8bits :)
[14:40:34] <OndraSter> do you send the data at once or by halves? :P
[14:41:51] <other019> now i try 4 bits and dont work
[14:41:53] <other019> i know it
[14:42:27] <other019> but i think last time i was using 8 bit
[14:42:47] <other019> but both are from this same author
[14:43:04] <other019> so tommorow i try again
[14:55:06] <crazy_imp> heyho
[14:56:32] <crazy_imp> is there something i should keep in mind if i want to use an atmega32u2 without the lufa framework? it keeps reseting after some ms
[14:58:32] <Steffanx> watchdog … ?
[15:00:02] <Steffanx> http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html
[15:01:06] <crazy_imp> Steffanx: hm, lemme check :)
[15:02:52] <Steffanx> include <avr/wdt.h> and wdt_disable () should at least rule out watchdog issues
[15:06:13] <drgreenthumb> dean also has MCUSR &= ~(1 << WDRF); in all the demos too under the "Disable watchdog" comment.
[15:06:46] <crazy_imp> ok, wdt_disable(); doesn't work
[15:06:56] <drgreenthumb> try adding ^^ that line too crazy_imp
[15:07:01] <Steffanx> Perhaps you also have to do what drgreenthumb said
[15:07:25] <crazy_imp> tried that too
[15:07:25] <drgreenthumb> pretty sure I had to do that for atmega32u2
[15:07:32] <drgreenthumb> or both actually
[15:07:45] <drgreenthumb> is it the first thing in your main crazy_imp ?
[15:08:06] <crazy_imp> drgreenthumb: yes
[15:08:14] <drgreenthumb> huh. maybe it's not watchdog then.
[15:08:16] <Steffanx> both lines?
[15:08:20] <crazy_imp> yes
[15:08:31] <crazy_imp> maybe it's my kernel reseting the usbport?
[15:10:15] <crazy_imp> let's see
[15:10:19] <OndraSter> usb port reset != device reset
[15:10:20] * crazy_imp tries the psu
[15:11:57] <crazy_imp> oh
[15:12:02] <crazy_imp> that's interesting
[15:13:24] <crazy_imp> replugging the usbcable fixed it, if i reset the device and use the dfu bootloader, it resets afterwards in a loop - until i replug it
[15:30:46] <other019> Yeah 8bit mode works correctly
[16:51:27] <vectory> good evening mr Rikus
[16:52:06] <vectory> well, that is arkward
[17:10:27] <RikusW> Hi vectory
[17:11:03] * RikusW was busy checking emails...