Back
[03:25:01] <Emil> Lambda_Aurigae: hmm : /
[04:02:17] <Emil> What's the alignment like in avr?
[04:02:34] <Emil> Suppose that I have two bytes which I'd like to form into an int.
[04:03:28] <Emil> A trivial way is to do int n = (bh<<8)|bl;
[04:03:46] <Emil> But this consumes at least 9 cycles (probably more)
[04:05:05] <Emil> But I could also do something like this: b[0]=bh; b[1]=bl; int n = *((int *)b);
[04:05:17] <Emil> But it has issues with the strict alignment rules
[04:05:57] <Emil> What's the most efficient way to turn two bytes into an int?
[04:08:29] <jacekowski> try bh*0xff+bl
[04:08:45] <jacekowski> iirc that generated slightly more efficient assembly
[04:12:09] <Emil> Hmm
[04:12:16] <Emil> but if I don't have multiply?
[04:13:25] <jacekowski> thing is avr is 8bit, anything larger than 8bit is emulated by the compiler so it will be slow
[04:13:31] <jacekowski> compiler/libc
[04:13:56] <Emil> jacekowski: eh, 16 bit additions are fast
[04:14:32] <jacekowski> not as fast as 8bit
[04:14:39] <jacekowski> which take 1 cycle
[04:15:14] <jacekowski> 16bit addition is 8bit addition + deal with carry over
[04:15:26] <jacekowski> if you add 8bit to 16 bit
[04:15:48] <jacekowski> and if you do 16+16 then it's 2 8bit additions + carry over
[04:16:06] <Emil> Sure, but still faster than multiplication
[04:16:48] <jacekowski> you could create inline function that does it
[04:16:49] <jacekowski> in asm
[04:21:19] <Emil> But damn, compilers are black boxes
[04:23:08] <cehteh> Emil: gcc will most likely optimize it in the right way when you try it the simplest way
[04:23:29] <Emil> cehteh: at least it ought to do so :D
[04:23:39] <cehteh> the array thing works well, and using a union works too
[04:23:42] <Emil> But damn those shifts are scary
[04:23:50] <cehteh> multiply and shift may get optimized too
[04:23:58] <cehteh> i'd go for union
[04:24:08] <Emil> Hey unions is actually probably the best
[04:24:14] <Emil> That's an excellent point
[04:24:19] <Emil> I always forget that they exist :D
[04:24:56] <cehteh> array in union :D
[04:25:05] <Emil> Yeah :D
[04:36:55] <Emil> Oh derp the error I was getting was about strict aliasing
[09:13:52] <robroavr> Hey, I am trying to get 2 bytes of data using SPI, but i only seem to be getting one. I am using interrupts, I am aware that SPI only sends 1 byte at a time so I will have to let it loop twice to get the full data. But I don't understand how to do it properly
[09:14:08] <robroavr> in my interrupt function i have this data = SPI_SlaveRecieve(ACK);
[09:14:08] <robroavr> data |= (SPI_SlaveRecieve(ACK)<<8);
[09:14:53] <robroavr> using atmega1284p
[09:18:23] <bss36504> Your interrupt should take the bytes and put them somewhere, like in a global array which you then check from your main program logic.
[09:42:17] <Casper> I dunnot for this, but some registers can also only be accessed once, then the data become unreliable
[09:42:48] <bss36504> Yes that is true, once you read the SPDR it's emptied, if I remember correctly.
[09:47:26] <Casper> Also, ADC... not sure if it is the low or high byte...
[13:48:58] <yids> uhm i made some functions to write to uart and read from uart from some examples found on internet, i used it sucesfully with an atmega328p, now i build the same code for an atmega1284, but i get garbage out of my uart, do different atmega`s have different ways of initializing or writing to the uart?
[14:26:18] <yids> hmz im using this uart lib from
http://homepage.hispeed.ch/peterfleury/avr-software.html now, it seems like defenitions are there for atmega1284, but i still get garbaage
[14:26:58] <yids> aah
[14:27:05] <yids> i think i have the frequency all wrong
[14:56:34] <Tom_L> http://wormfood.net/avrbaudcalc.php
[15:19:54] <yids> hmz i take it that memcpy and memset on avr work in the same way as on x86 for example, or is there someting i should keep in to account when using it on avr? (i`m having some unexpcted behaviour and it has something to do with memcpy, could also be that im just doing something wrong)
[16:38:30] <bss36504> yids: what seems to be the problem? they should work the same
[16:43:15] <yids> hm yeah im not really sure, i have for example this "memcpy(rx_kp->secret_key, rx_priv_key, crypto_box_SECRETKEYBYTES);" which seems to make my avr crash
[16:43:18] <yids> but
[16:43:22] <yids> when i put it in a for loop
[16:43:43] <yids> like "for(int i = 0; i < crypto_box_SECRETKEYBYTES; i++){rx_kp->secret_key[i] = rx_priv_key[i];}
[16:43:47] <yids> it seems to work
[16:43:59] <yids> shouldnt that be the same operation?
[16:48:21] <bss36504> yeah theoretically it should work like that
[16:50:26] <bss36504> Just use the for loop version if memcpy isnt working for whatever reason.
[22:43:18] <Eszett_> hi
[22:44:33] <Eszett_> I thought I did something wrong, but after hours of chewing on my fingernails trying to find the bug in my routing, I found this
https://puu.sh/sn6zi/3c689ffb41.png Why in heaven is the pin order swapped between 32u2 and 32u4???
[22:48:37] <Tom_L> U4 has adc, U2 does not
[22:48:52] <Tom_L> dunno
[22:50:21] <Tom_L> U4 has more pins too
[22:50:58] <Tom_L> FWIW, U2 has reset brought out to an IO pin too
[22:51:20] <Tom_L> so if you try to blink PC1 it will reset the chip
[22:58:21] <Eszett_> hi tom
[22:58:44] <Eszett_> but this is odd isnt it i mean: When i connect a usb connector to the 32u4 the pin order matches up. When I connect the usb to the 32u2 the pin order doesnt match up
[23:00:39] <cehteh> wtf pic .. just look at the datasheet, but looks to me that these are not pin compatible in any way
[23:07:10] <Eszett_> I have circuits with both chips, and what i mean is, the 32u4 has the pin order of the 4 USB relevant pads: UVCC D- D+ and GND are in same order of a USB connector. the 32u2 not
[23:10:37] <Eszett_> here is the routing between the pads:
https://puu.sh/sn7NH/af5f5d6005.png
[23:11:08] <Eszett_> which is a PITA.
[23:11:42] <Eszett_> and i dont want to use a reverse mount USB connector, and I dont want to place the USB connector on the opposite side of the PCB
[23:12:00] <Eszett_> coz all this has major downsides too
[23:12:24] <Eszett_> So Atmel seems to be crazy IMHO
[23:13:17] <aandrew> Eszett_: haha yes I *hate* when I run in to that
[23:13:26] <aandrew> if possible can you put one of the components on the other side of the board?
[23:13:53] <aandrew> oh, you already thought of that
[23:14:27] <Eszett_> yea i thought about that.. its possible, However, the downside is it isnt sensible to have automated assembly with the parts on backside, except on single part on frontside. You want to have all parts on one side, this is way cheaper to produce
[23:16:44] <Eszett_> anyway I have another thing which i dont understand:
[23:17:44] <Eszett_> https://puu.sh/sn82s/1f7cd06d0a.png The atmega32u4 has the usb pin order right. here pins 2 3 4 5 are supposed to be the order of the usb connector's VBUS D+ D- GND, right?
[23:18:07] <Eszett_> but why is VBUS pin 7, and not pin 2?
[23:19:32] <Eszett_> of course, I have UVCC connected to the same net as VBUS, so it doesnt matter much. It still riddles me why VBUS is not right beside the D- pin
[23:20:53] <Eszett_> In other words, pin 2 should be "VBUS", no?
[23:21:55] <cehteh> huh
[23:22:54] <cehteh> looking at some usb connectors it should just fit
[23:23:07] <cehteh> is that what you meant with reverse mount?
[23:23:34] <cehteh> micro usb?
[23:24:18] <cehteh> i mean, they surely had some intention to build the chip this way
[23:24:51] <cehteh> maybe in a device installing the PCB with the component layer on the back, then the other side could be used for display, keypad, leds whatever
[23:24:57] <Eszett_> cehteh: then they had a different intention for 32u2 and 32u4, because the order doesnt match
[23:25:17] <Eszett_> cehteh: ye that is a possible explanation
[23:25:43] <Eszett_> but why different approach for 32u2 and 32u4 then? both are similar chips
[23:26:06] <cehteh> not similar enough
[23:26:06] <Eszett_> whatever reason i have, i make it consistent for 32u2 *and* 32u4
[23:27:18] <cehteh> i dont know how atmel designs chips, but i suspect they dont do it on a whim but for some mass orders when someone askes them for 10mio pieces, a chip is designed and then put on normal sale too
[23:27:29] <Eszett_> cehteh: I was angry, because i supposed all the time the pin order of VBUS D- D+ and GND is the same with both chips, and tried for hours to find the bug in my circuit!
[23:27:38] <cehteh> lol
[23:27:51] <cehteh> well thats really your fault, not looking at the datasheet
[23:27:58] <Eszett_> ye, whatever..
[23:28:08] <cehteh> these chips have differnt pin counts too
[23:28:16] <cehteh> they are in no way replaceable with each other
[23:28:37] <Eszett_> well the basic circuit with caps and resistors is pretty much the same
[23:28:37] <cehteh> look at attiny84 and attiny85 .. they are vastly different
[23:28:51] <cehteh> just because the name is similar it doesnt mean the chip is complatible
[23:29:10] <Eszett_> maybe. have another question
[23:29:50] <Eszett_> why is the pin beside D- not VBUS in both chips?
[23:30:29] <cehteh> i looking at the datasheets and both say UVCC
[23:30:36] <Eszett_> It would make sense to have VBUS there since that is name of the VCC pin on the USB connector
[23:31:00] <Eszett_> I dont get it..
[23:31:17] <cehteh> look at the original datasheets!
[23:32:24] <Tom_L> i've made boards with both chips with no problems
[23:32:59] <cehteh> yes but not one board which can take either one
[23:33:14] <Tom_L> that would be silly
[23:33:23] <cehteh> yes
[23:33:26] <Tom_L> not even the same size chip
[23:33:32] <Tom_L> pin count is different
[23:34:02] <cehteh> but might be possible .. one on the backside the other on the frontside with some adapting ,, still silly
[23:34:35] <Tom_L> http://tom-itx.no-ip.biz:81/~webpage/boards/atmega32u4/atmega32u4_1.jpg
[23:34:36] <Eszett_> cehteh: im looking at the original datasheet and it says the same, the pin 2 is UVCC, but why is it not VBUS? Only VBUS would make sense there?
[23:34:37] <Tom_L> http://tom-itx.no-ip.biz:81/~webpage/boards/USB_Breakout/USB_Breakout.jpg
[23:35:22] <Eszett_> nice! @Tom
[23:35:59] <cehteh> isnt vbus the same as uvcc just different name?
[23:36:00] <Tom_L> made a few programmers back when too
[23:36:09] <Eszett_> cehteh: is that so? i dont know
[23:36:15] <Tom_L> basically i think so
[23:36:28] <Tom_L> vbus is 5v from the usb
[23:36:29] <cehteh> U stands vor USB
[23:36:37] <cehteh> and VCC is the positive voltage
[23:37:41] <Tom_L> it's been a while since i visited that but parts of those chips can run at 3.3v or 5v depending how you configure it
[23:38:21] <Eszett_> You can run a atmega32u4 with 3.3v??
[23:38:42] <Tom_L> the IO i believe
[23:38:46] <Tom_L> not the usb side
[23:38:52] <Eszett_> btw. the datasheet say "VBUS" is the "USB VBUS monitor input" so it seems to be something special
[23:39:00] <Eszett_> Tom: thats interesting
[23:39:23] <Tom_L> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_batch.jpg
[23:39:25] <cehteh> thats why they have a dedicated zvcc rails
[23:39:35] <cehteh> but the atmega cores can run at low voltage
[23:39:42] <cehteh> down to 2.7
[23:39:52] <Tom_L> i've programmed them down to 1.5v
[23:40:18] <cehteh> yes some go down that far, at slow speed
[23:40:22] <Tom_L> not saying that you should
[23:40:36] <cehteh> some are speced down to 1.8
[23:40:42] <cehteh> dunno about these
[23:41:13] <cehteh> but you can conviniently run them on a 2032 lithium cell, if carefully programmed
[23:43:16] <Tom_L> Eszett_ are you making a board?
[23:46:22] <Eszett_> ye, im doing pcbs for keyboards, but more or less struggling with the flood of technical details you have to consider
[23:49:34] <Eszett_> so despite of my little knowledge about EE theory i get working pcbs.
[23:50:03] <Tom_L> yo abcminiuser
[23:50:14] <abcminiuser> Ahoyhoy
[23:50:26] <Tom_L> how's things goin?
[23:54:14] <Eszett_> What i dont understand is, the datasheet just states that the VBUS pin is a monitor pin, but in no way explains why and how it functions. The whole explanation is 4 words?
[23:56:21] <abcminiuser> Ok, still working hard at work to get our product done by the deadlines
[23:56:26] <abcminiuser> All work, work, work
