Back
[03:21:35] <rue_bed> MarkX, ADC?
[09:04:49] <KongfuPanda> hello :)
[09:04:55] <KongfuPanda> has anyone used the AXON 2?
[10:42:46] <soul-d> :( so far got an seperate avr talking over i2c (same port as adc) and tring to get 4 wire touch screen back so far if i compile with eiher channel fixed and stream it over i2c i get correct values but as soon as i switch while it's running i get single diget nonsense even with delay's
[10:43:14] <soul-d> channel can be read as reading x or y
[10:47:28] <R0b0t1> Hmm, as soon as I enable compare match A on timer 1 on a 644p
[10:47:35] <R0b0t1> but I have an ISR(TIMER1_CMPA_vect)
[10:57:51] <KongfuPanda> hi if I use "switch" statement, can I write case "1" || "2
[10:58:03] <KongfuPanda> "
[10:58:20] <KongfuPanda> or is it only case "1":
[10:58:22] <KongfuPanda> etc
[11:26:16] <RikusW> you can combine many cases that way
[11:26:35] <KongfuPanda> RikusW, thanks
[11:27:52] <MarkX_> ping abcminiuser
[11:27:59] <abcminiuser> Pong
[11:30:03] <MarkX_> i'm trying to use boot_signature_byte_get(x)
[11:31:19] <MarkX_> when i put it in a for loop and output over usb i can get the serial to print out
[11:31:31] <MarkX_> but when i try and output it as a usb string
[11:32:07] <MarkX_> it doesn't show up
[11:32:12] <MarkX_> properly
[11:33:27] <abcminiuser> Are you expanding it to UTF-16?
[11:33:38] <MarkX_> i don't know how to do that
[11:34:01] <abcminiuser> A USB string is 16-bit characters
[11:34:11] <abcminiuser> For ASCII to UTF-16, just make the upper byte zero
[11:34:23] <abcminiuser> Also make sure you're converting to HEX digits, 0-9, A-F
[11:34:33] <abcminiuser> So for example a serial of:
[11:34:39] <abcminiuser> 0x1DC2
[11:35:12] <abcminiuser> Would be encoded as {'\0', '1', '\0', 'D', '\0', 'C', '\0', '2'}
[11:37:13] <KongfuPanda> RikusW, it won't compile :( says "duplicate case value"
[11:37:28] <MarkX_> well what i do is use vsprintf to send the info over usb
[11:38:00] <abcminiuser> Show me the money
[11:38:03] <abcminiuser> I mean, show me the code
[11:38:06] <MarkX_> heheh
[11:45:21] <RikusW> KongfuPanda: you can't have two cases with the same value...
[11:46:08] <KongfuPanda> RikusW, they have different. Anyway, I converted to "IF"
[11:46:13] <KongfuPanda> thanks
[12:06:34] <soul-d> :') ofcourse i just copied adc channel with |= to switch channels :> from init
[12:08:24] <RikusW> KongfuPanda: case "IF": is a pointer, not actual string... doing this will give you some nice bugs :-P
[12:08:42] <KongfuPanda> if
[12:08:44] <KongfuPanda> :P
[12:08:53] <KongfuPanda> it's fine
[12:09:26] <KongfuPanda> I'm sure I will have hundreds of bugs anyway, because I'm an enthusiast :)
[12:09:56] <KongfuPanda> currently I'm struggling to control my 18 servos as an array rather then by name of each servo :(
[12:10:33] <KongfuPanda> by name it works, but need too much code
[12:12:36] <soul-d> mmm din;t know that RikusW ive fallen for that to
[12:13:03] <RikusW> it might work
[12:13:17] <RikusW> if the compiler optimize to one string only
[12:13:27] <RikusW> the pointers would be the same
[12:13:47] <RikusW> but if you parse another string and use that in the switch.....
[12:13:59] <soul-d> mathing a character or byte
[12:14:09] <RikusW> or int or pointer
[12:15:50] <soul-d> switch(ReceivedByte){ case '0': etc... was what i was doing whats the proper way then ? if i wanted to match asci '0'
[12:16:05] <soul-d> or any byte
[12:17:30] <RikusW> bytes are fine
[12:17:44] <RikusW> strings aren't
[12:17:56] <RikusW> (rather string pointers)
[12:18:21] <RikusW> "somestring" produces a pointer in C
[12:19:19] <soul-d> k still easy to oversee and fall for
[12:30:57] <N1njaneer> Woohoo, conversation in here!
[12:31:01] <N1njaneer> Sound the alarm!
[12:31:03] <N1njaneer> Productivity.
[12:33:15] <KongfuPanda> RikusW, do you want to see my robot?
[12:33:23] <RikusW> yes :)
[12:33:36] <KongfuPanda> RikusW,
http://www.youtube.com/watch?v=4FxWpbLiw5g
[12:35:23] <N1njaneer> Very nice!
[12:36:03] <RikusW> nice :)
[12:36:06] <KongfuPanda> thanks :)
[12:36:11] <RikusW> how do you control it ?
[12:36:52] <RikusW> and I guess there is a wireless link ?
[12:36:55] <KongfuPanda> via bluetooth RS-232. And I just send characters from Matlab. I programmed the controller such that depending on the sequence of characters it does different things
[12:37:23] <KongfuPanda> it has two camera batteries under the body , so it's very remote :) but they only last for 30 mins
[12:38:09] <KongfuPanda> to be honest I'm surprised that it's working :D I just sat one day and decide to build it without much design considerations :D mahaha
[12:38:16] <RikusW> heh
[12:38:33] <RikusW> what do you use servos or steppers ?
[12:38:38] <KongfuPanda> servos
[12:38:49] <KongfuPanda> cheap ebay SG9 or something
[12:39:07] <KongfuPanda> was like $5 per servo, but a few dodgy ones, had to throw away
[12:39:41] <KongfuPanda> and the AXON 2 microcontroller
[12:39:57] <KongfuPanda> + bluetooth card (ebay)
[12:40:55] <RikusW> I guess assembly took a while ?
[12:42:52] <KongfuPanda> not really, a couple of days. I posted complete videos how I made , this is probably the most interesting part:
http://www.youtube.com/watch?v=Zqy4GPvATSE
[13:54:44] <masterq> Hello
[13:55:00] <masterq> is somebody able to configure avrdude?
[13:55:29] <theBear> almost anybody is !
[13:55:37] <masterq> i cant finger out how to set offsets correctly...
[13:56:12] <masterq> Nice... theBear, can you help me by finding the offsets for the e5?
[13:56:31] <theBear> what and what and the what ?
[13:58:00] <masterq> if you like to add a new controller to the avrdude.conf you need to define the memory areas where everything is placed...
[13:59:02] <theBear> controller ? you mean device or programmer ?
[13:59:24] <masterq> device of couse
[14:00:40] <masterq> i just can't find any documentation for that...
[14:01:09] <theBear> just compare your chip datasheet to one that is already there and fill in the blanks, i'm way too sleepy and drugged up to care
[14:01:26] <masterq> mayby atmel is not sharing this informations, or im just not able to calculate the offsets correctly
[14:02:19] <theBear> just compare, you can't go wrong
[14:02:55] <masterq> of course i did, but i could not find equal...
[14:03:08] <masterq> of course i did, but i could not find something equal...
[14:03:12] <RikusW> which AVR are you adding ?
[14:03:20] <masterq> e5
[14:03:25] <RikusW> e5 ?
[14:03:27] <masterq> 32e5
[14:03:34] <masterq> atxmega32e5
[14:03:36] <theBear> just say the damned whole name
[14:03:45] <theBear> better, maybe your laziness is why you fail
[14:03:50] <RikusW> not familiar with that one...
[14:04:12] <RikusW> last time I checked pdi wasn't quite up to date
[14:04:41] <bss36504> theBear: ouch...lol
[14:05:24] <masterq> thats not the only one missing xmega d and b is also missing, but easy to add...
[14:05:31] <theBear> bss36504, heh, and hey, i'm not here to baby people
[14:05:54] <bss36504> Oh I feel ya man; it made me laugh
[14:06:17] <masterq> pdi working very well normaly...
[14:06:17] <theBear> much like arduino is trying to fool people, micros aren't about shortcuts, they're about learning and paying attention to everything you do :)
[14:08:53] <bss36504> Arduino *can* be a means to an end, but I generally have a pretty low opinion of it. Plus, most people/examples end up just dumping everything in loop() which is stupid. C isn't that hard....
[14:10:22] <theBear> not to mention wrapping something that should be a simple variable/pointer change is just STUPID and encourages people not to understand anything they are doing
[14:10:35] <theBear> i got a whole list, but i'm tired of repeating it
[14:11:26] <masterq> but if you are labeling something with aduino you can take the twice of its value...
[14:12:55] <theBear> all depends who reads the label, some of us would do anything to avoid something with duino in the name
[14:17:52] <masterq> its a question of balance maybe 20 people of this chat likes to avoid arduino but there are many 1000 out there which loves to buy stupid shit^^
[14:18:23] <theBear> it's not just here, it's most people with a technical bone in their bodies
[14:18:35] <inkjetunito> i like the arduino, even though i don't like the framework
[14:19:45] <inkjetunito> it even has a led on it
[14:19:57] <theBear> many would argue the ide and libs are the majority of what it is, otherwise it's just a bootloader that failed to match what it was supposed to be implementing and an average avr dev board
[14:20:53] <masterq> i see this discution will not make much sens... But is there maybe somebody who likes to help me with this avrdude conf?
[14:23:04] <theBear> i helped you to help yourself
[14:23:13] <theBear> have you even considered doing what i suggested?
[14:24:24] <masterq> yes i did before you suggested it ^^
[14:24:53] <theBear> so check your math, it's a solid method, it works
[14:25:02] <masterq> but it didn't help because these offsets are not part of datasheet
[14:25:16] <theBear> yes they are
[14:26:01] <theBear> and you just said you did do it, so it looks a lot like you're not telling the truth, or at least the whole truth
[14:26:16] <masterq> ...
[14:28:07] <bss36504> Side thread: Has anybody ever seen LUFA stall from a USB point of view? Specifically with the mass storage part, sometimes it just sits there, no activity then suddenly it connects/mounts/writes/reads.
[14:28:21] <masterq> ok i see, the problem is my english...
[14:28:45] <masterq> i often read it but rarely write it
[14:29:53] <masterq> my mention was to say, i read the datasheets
[14:29:59] <bss36504> If I had some xp with avrdude, I'd help you.
[14:30:04] <bss36504> but I cant.
[14:30:23] <masterq> hehe, thanks else^^
[14:34:12] <bss36504> I haven't seen the E series yet. This XCL seems awesome.
[14:35:26] <masterq> yes it's a nice chip, and the VQFN version, is soo sweet^^
[14:36:01] <bss36504> Well...not for soldering (by hand) :P
[14:36:23] <masterq> if you like to try it and if you are using eagle here are some libs
http://www.mikrocontroller.net/topic/305330
[14:36:30] <masterq> i did :-)
[14:36:48] <masterq> it's not very funny but its absolutly possibly
[14:36:51] <bss36504> Oh I'm not saying you cant, just saying a QFP>QFN for hand soldering.
[14:37:35] <R0b0t1> I'm doing software pwm of a pin using timer interrupts (modification to a preexisting board...)
[14:37:48] <bss36504> I assemble custom SMD designs all the time.
[14:37:52] <bss36504> R0b0t1: ok....
[14:38:54] <bss36504> masterq: so this is a shot in the dark, but is the info you need for avrdude in chapter 4 of the Atxmega32E5 datasheet? Specifically page 21+
[14:40:33] <R0b0t1> it seems interrupt overhead is preventing me from getting the higher end of the range, anything I can do?
[14:41:50] <bss36504> R0b0t1: Yeah, use the output compare pins to make a hardware PWM.
[14:42:07] <bss36504> What chip are you using?
[14:44:32] <masterq> bss36504: you are talking about the manual right? Maybe... But, if i can't see it.
[14:45:05] <masterq> bss36504: are you asking me?
[14:47:25] <bss36504> masterq: yes, in the manual for the XmegaE5
[14:48:15] <bss36504> actually, specifically I mean the Xmega E manual, which is the generic E manual. But I think there are device specific ones too (not sure though)
[14:48:42] <bss36504> eiehr way, you should be able to calculate the addresses based on how much memory they have since I think the addressing is continuous
[14:51:41] <masterq> yes there are
[14:52:42] <masterq> http://www.atmel.com/Images/Atmel-8153-8-and-16-bit-AVR-Microcontroller-XMEGA-E-ATxmega8E5-ATxmega16E5-ATxmega32E5_Datasheet.pdf
[14:53:01] <bss36504> yup. just found it. all I needed to do was look down a line on the atmel page :P
[14:53:25] <bss36504> so chapter 8 in this datasheet
[14:53:59] <masterq> page 11?
[14:54:07] <bss36504> yeah
[14:54:10] <bss36504> I think
[14:54:53] <bss36504> application space is: 0:0x37FF, application table is: 0x3800:0x3FFF, boot sector is 0x4000:0x47FF
[14:54:59] <masterq> it's really possible... Thank you! Im not how i could overlook it
[14:55:29] <masterq> i will give it a try...
[14:55:43] <masterq> *im not sure how i could overlock it
[14:56:08] <bss36504> wait what?
[14:56:40] <bss36504> oh sorry, I read that as "overclock" and was a tad confused
[14:56:47] <bss36504> No problem
[14:57:32] <masterq> i see, overlook not overlock^^ sry
[14:57:44] <bss36504> haha not a problem
[15:22:39] <hetii> Hi :)
[15:24:47] <masterq> i do not understand, why the offset for the app table for the x32a4 is 0x807000... we are starting with the application space @0x800000 it's size 32k = 0x8000 bytes, it is followed by the apptable, so should it not be 0x808000 for the apptable, or is the apptable part of the application section?
[15:30:57] <bss36504> Woah there masterq, 0x807000 ≠ 0x008070
[15:31:08] <bss36504> pad to the left
[15:31:15] <masterq> but now i understand what i did wrong by reading the datasheet last time the table addresses are in words, not in bytes^^ So now the avrdude.conf is saying same thing as the datasheet
[15:31:37] <bss36504> ok good. did you read the description of what the app table is?
[15:31:52] <bss36504> cause it's literally the next thing after the memory address table.
[15:36:00] <bss36504> R0b0t1: Did you figure out your PWM?
[15:53:33] <KongfuPanda> can someone please help me with C basics?
[15:53:51] <KongfuPanda> if I have a variable char tempbyte;
[15:54:04] <bss36504> ok
[15:54:04] <KongfuPanda> and I want to compare it with a character 'm'
[15:54:09] <KongfuPanda> what should I do?
[15:54:15] <bss36504> if(charbyte=='m')
[15:54:23] <bss36504> tempbyte*
[15:54:26] <KongfuPanda> hmm
[15:54:30] <KongfuPanda> that doesn't seem to be working
[15:54:34] <KongfuPanda> let me try again
[15:54:55] <bss36504> remember the double =
[15:55:14] <KongfuPanda> yeah, I remembered
[15:56:28] <KongfuPanda> oops
[15:56:34] <bss36504> :)
[15:56:36] <KongfuPanda> I placed { in wrong place :D
[15:56:41] <bss36504> that would do it.
[15:57:02] <R0b0t1> bss36504: No, can't really think of anything to do
[15:57:15] <R0b0t1> bss36504: If I need to I might have to say mfr will need to bridge the wires
[15:57:28] <specing> KongfuPanda:
http://net.pku.edu.cn/%7Ecourse/cs101/2008/resource/The_C_Programming_Language.pdf
[15:57:32] <specing> ^ read that
[15:57:40] <specing> and don't come back until you do so
[15:57:55] <bss36504> easy mistake guys.
[15:58:39] <KongfuPanda> specing, (╯°□°)╯︵ ┻━┻
[15:58:40] <bss36504> R0b0t1: can you elaborate? I understand you have some atmel chip and you're trying to make a software PWM but the interrupt overhead is too much
[15:58:55] <specing> KongfuPanda: keep it ASCII only.
[15:59:11] <R0b0t1> bss36504: that's basically it, heh
[15:59:50] <R0b0t1> high end gets chopped
[15:59:50] <bss36504> specing: simmer.
[16:00:13] <R0b0t1> bss36504: of course
[16:00:14] <R0b0t1> well
[16:00:45] <bss36504> R0b0t1: Ok, so can you use the output compare pins instead? use the Timer overflow register to set the overflow value, and then just leave the timer free running, rollover to zero on compare mode. What chip are you using?
[16:00:45] <specing> bss36504: ?
[16:01:00] <R0b0t1> bss36504:
http://paste.strictfp.com/38873
[16:01:12] <R0b0t1> no I can't
[16:01:12] <R0b0t1> that's the issue
[16:01:15] <bss36504> specing: he's obviously no C pro and new to the chat. seems like you're really harshing his mellow.
[16:01:16] <R0b0t1> otherwise I'd use hardware pwm
[16:01:53] <R0b0t1> Waait
[16:02:03] <R0b0t1> wouldn't overhead cause it to be on too much
[16:02:04] <R0b0t1> ?
[16:02:07] * R0b0t1 chinrubs
[16:02:12] <KongfuPanda> bss36504, it's working !
[16:03:29] <specing> bss36504: I usually tolerate newbies but not knowing how to compare two things tripped me over
[16:03:55] <specing> anyway, that book is only 250 pages and a must read for anyone serious about C
[16:04:16] <bss36504> R0b0t: it might lengthen both sides of the pulse.
[16:04:44] <bss36504> it would depend on how long the timer interrupt interval is compared to the cpu clock speed.
[16:04:55] <bss36504> I think it would sort of jitter over time.
[16:06:01] <bss36504> eitehr way, you have like a few clock cycles (of FCPU) to jump in and out of the vector, plus like 5(?) ish clocks to do the action inside
[16:06:25] <bss36504> not a lot of overhead. what are you observing that indicates a problem?
[16:07:00] <R0b0t1> inability to get full duty
[16:07:37] <R0b0t1> the pump its attached to was meant to run 100%, but it was found to cavitate - I supply what I think is close to 100%, no cavitation
[16:07:48] <R0b0t1> I can't open this thing up atm
[16:07:48] <R0b0t1> or I'd scope it
[16:07:51] <bss36504> what are you driving to drive a pump with a PWM?
[16:08:07] <bss36504> certainly not the MCU pins themselves.
[16:08:32] <R0b0t1> fet
[16:09:48] <bss36504> specing: not denying that a good read is better than pestering, but he did know how an if statement works, he misplaced a curly brace. Without seeing the code, i'd like to give him the benefit of the doubt and say it was just a bit cluttered and he missed it. That being said, no need to be an ass when it took literally one line of response to help him out.
[16:11:47] <bss36504> R0b0t1: Ok, well I suppose that could be ok. I just wonder about external things causing problems. That is to say, your code seems like it should work fine, but it doesn't, so I question the external circuitry,. If you can connect a scope to the pin with no pump circuit attached, that'd be best.
[16:12:30] <R0b0t1> Hm yeah
[16:12:37] <R0b0t1> people who designed this thing were pretty dumb
[16:12:43] <R0b0t1> maybe the fet isn't being driven correctly
[16:12:43] <bss36504> where does that Serial.println come from?
[16:13:06] <R0b0t1> the control code is written utilizing (and within) the ARduino libraries
[16:13:16] <R0b0t1> if I could I'd show you how much of a fucking mess it is
[16:13:25] * R0b0t1 cradles head in hands
[16:13:26] <bss36504> if you need 90% duty, why not just make a voltage divider with some power resistors
[16:13:40] <R0b0t1> It needs to be easilly settable
[16:14:00] <bss36504> oh. yuck. well there might be some code overhead now...Arduinope.
[16:14:08] <R0b0t1> I mean we may not need the high range of the pump anyway but I thought I'd see if there's an easy way to ad it
[16:14:46] <bss36504> here:
http://playground.arduino.cc/Main/MsTimer2
[16:14:59] <specing> bss36504: irelevant, user must read K&R
[16:15:32] <bss36504> specing: alright man, you do you, and I'll do me.
[16:16:16] <bss36504> R0b0t1: That MSTimer2 Lib for arduino works very well, very easy to use.
[16:16:31] <R0b0t1> Gotta use timer2 for something else :p
[16:16:41] <bss36504> R0b0t1: UGGGGHHHHHH
[16:16:42] <R0b0t1> I am doing basically the same thing as I would do with it
[16:16:48] <bss36504> lol
[16:16:50] <bss36504> darn
[16:18:41] <bss36504> R0b0t1:
http://playground.arduino.cc/code/timer1
[16:19:01] <bss36504> theres even a PWM function.
[16:25:27] <masterq> bss36504: i think i managed it, thanks for you help
[16:26:11] <bss36504> masterq: glad to hear it, not a problem
[16:26:16] <masterq> i will share my results as sone i have testet it some more.
[16:26:26] <bss36504> alright
[20:10:04] <avrdood> help with max31855
[20:10:26] <avrdood> i cant get a good read
[20:11:59] <avrdood> first of all, is cs required to be pulled down before every fetch ?
[20:17:02] <N1njaneer> SPI bus?
[20:17:02] <avrdood> yes
[20:17:07] <N1njaneer> Generally yes, CS will be associated for the entre duration of transaction with a particular SPI bus. The datasheet for the MAX31855 will give you a full description of the requirements.
[20:21:18] <avrdood> ok
[20:22:17] <avrdood> DDRB= 0b01000000;
[20:22:17] <avrdood> ony miso wich is PB6 on atmega32 is configured as input
[20:22:37] <avrdood> so to pull cs down i write a 1 and leave miso untouched i guess?
[20:23:23] <N1njaneer> DDRx registers are 1 for output, 0 for input
[20:23:33] <avrdood> eh?!
[20:25:08] <N1njaneer> You need to enable the SPI bus periperal, and set your CS pin as an output, and observe the datasheet for the MAX part. Generally CS is active LOW, however some devices may have it swapped.
[20:25:08] <avrdood> same for PORTB ?
[20:25:08] <avrdood> high 1 low 0 ?
[20:25:09] <avrdood> thats the setup i have : SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0);
[20:25:09] <avrdood> spi enable, master mode, clock / 16
[20:25:09] <N1njaneer> you need to configure DDRB for the direction of the pins, then write to PORTB to set the outputs to 1 or 0
[20:25:35] <N1njaneer> Just setting DDRB only sets the direction of the pins
[20:25:43] <N1njaneer> You need to combination of DDRB and PORTB to use them.
[20:26:02] <avrdood> right input doesnt change anyway it listens
[20:27:03] <avrdood> and it goes from msb ---> lsb
[20:27:03] <avrdood> ?
[20:27:08] <N1njaneer> PORTB pin settings will turn the internal pull-up resistors on and off if the DDRB direction is a zero
[20:27:08] <avrdood> 76543210
[20:27:28] <N1njaneer> Verify the bit-order on the MAX datasheet
[20:28:17] <avrdood> i meant with avr
[20:28:39] <N1njaneer> AVR is switchable for MSB or LSB-first transmissions
[20:28:39] <avrdood> the max chip sends MSB first
[20:29:22] <avrdood> no, i mean if i declare DDRB 0b11111110 the input is pin 0 or 7 ?
[20:29:47] <avrdood> ill find out
[20:29:54] <N1njaneer> Oh for that, 0b11111110 is PB0 as the input
[20:30:20] <N1njaneer> Normal binary notation is always MSB to LSB
[20:30:30] <N1njaneer> I thought you were asking about the SPI bus transmission order
[20:31:45] <avrdood> that is changeable
[20:31:51] <avrdood> by default that chip sends msb first
[20:33:09] <avrdood> my serial port is frozen
[20:38:10] <avrdood> hum
[20:38:24] <avrdood> does a clk pin needs to be driven high with PORTB declaration ?
[20:43:14] <avrdood> it varies now :)
[20:50:02] <jadew> https://www.youtube.com/watch?v=dx596o8t_TY
[20:50:04] <jadew> YouTube: Experiments and Demo of an Agilent DSA-X 96204Q 160GS/s 62GHz Oscilloscope
[20:50:24] <Tom_itx> input = 0 output = 1 in the DDRx reg
[21:13:22] <avrdood> do i have to loop for 8 bits?
[21:13:44] <avrdood> now i just send 8 bits in one shot and wait for result
[21:28:53] <N1njaneer> For SPI, you just send dummy bytes out and read the data-register once it's completed
[21:29:50] <N1njaneer> while(!(SPSR & (1 << SPIF))); will wait for the SPI transaction to be completed, then read SPDR
[21:39:59] <avrdood> yes, heres what i have
[21:40:01] <avrdood> PORTB=0b10100000; /*Start transmission*/ SPDR=0x0; //0x00 will be shifted out from MOSI pin, the data will be shifted // into SPDR register /*wait for complete*/ while (!(SPSR&(1<<SPIF))); data = SPDR ; // save the high 8-bit data data = data << 8; // left * the data PORTB=0b10110000;
[21:40:24] <N1njaneer> Please use pastebin.com or similar - makes it easier to read:)
[21:41:14] <avrdood> http://pastebin.com/3EAaPMye
[21:41:29] <avrdood> this gets all the data from the temperature reading
[21:41:38] <avrdood> however it doesnt show in C
[21:41:40] <avrdood> celcius\
[21:41:51] <avrdood> im not sure i did right
[21:41:52] <avrdood> like
[21:41:56] <avrdood> the sensor sends MSB first
[21:42:30] <avrdood> ive configured the SPI to fill the LSB of the data word
[21:42:47] <avrdood> so that the lower part of the variable gets the MSB byte of the temp reading
[21:42:53] <avrdood> that i think is fine
[21:42:55] <N1njaneer> Note that if you expect new data in SPDR you need to write dummy bytes out
[21:43:04] <avrdood> i did
[21:43:16] <avrdood> thats what SPDR=0x00 does
[21:43:44] <N1njaneer> Okay, I saw you are reading SPDR twice at the bottom there.
[21:43:56] <N1njaneer> in to data with some arithmetic, and data_2
[21:44:30] <N1njaneer> (minor point: I would suggest switching that to only read SPDR once and then use data_2 in your calculation, just for clarity)
[21:44:41] <avrdood> data_2 was just to get the lower bits to see if it made sens
[21:45:17] <N1njaneer> Also, you appears to be deasserting CS on 10 and reasserting on 13?
[21:45:43] <N1njaneer> If all of that SPI transaction is supposed to happen as one block, you'd want to leave CS asserted through the whole thing.
[21:46:40] <N1njaneer> Without looking at the MAX datasheet I can't be sure, but usually you'll send a byte or two through to a device to do a configuration and to initiate a read operation, then immediately clock the dummy bytes across and yank the return results inside of the same CS transaction.
[21:47:18] <N1njaneer> The CS deassert may be resetting the internal state machine of the MAX chip.
[21:47:40] <avrdood> so cs is only to switch between modes read/write
[21:47:43] <avrdood> ..usually?
[21:47:44] <N1njaneer> Again, need to verify the waveforms against the MAX datasheet. Having a logic analyzer here is also useful.
[21:47:55] <N1njaneer> No, CS wraps the entire transaction to the SPI bus of interest.
[21:48:17] <N1njaneer> CS assertion flags the beginning of a transaction to the SPI device
[21:48:25] <avrdood> im low tech tonight, no gear only multimer >.>
[21:48:49] <avrdood> thats right, i thought about it like im starting a read, then stop then read again
[21:49:02] <N1njaneer> Every byte written to the SPI bus results in a byte returning ON the SPI bus from the device of interest, assuming the loop is closed and the device talks back.
[21:49:28] <N1njaneer> If you are deasserting the CS line, chances are you are re-reading the same byte again.
[21:50:11] <N1njaneer> Also, the SPI device may need a READ operation byte sent to it to tell it a read is occuring. In which case you then need the dummy cycle AFTER that instruction to start reading returned data.
[21:50:50] <N1njaneer> Reason for that is the SPI device doesn't usually doesn't know what you want it to do until it has at least one byte of command data clocked, and obviously without a time-machine, that makes it too late to start returning data.
[21:51:24] <avrdood> its a read only device
[21:51:24] <N1njaneer> Unless the device is effectively read-only.
[21:51:31] <N1njaneer> Let me pull up the datasheet
[21:51:35] <avrdood> yes it only sends data
[21:52:44] <N1njaneer> Okay, then that simplifies it, since all you need to do is to clock out bytes
[21:52:58] <N1njaneer> The datasheet seems to indicate this device returns 32 bytes of data
[21:53:01] <avrdood> so my code is right
[21:53:03] <N1njaneer> So you need to assert CS low
[21:53:25] <N1njaneer> The you need to clock a byte out, grab the result, and do this four times. Then release CS.
[21:53:26] <avrdood> spi is 8 bit at a time if i remember right
[21:53:33] <N1njaneer> Yes
[21:54:11] <avrdood> ahhh i know why
[21:54:32] <N1njaneer> Are you only interested in the 14-bit thermocouple data?
[21:54:48] <avrdood> i only fetch the first 16 bits that contains the temperature reading and repeat but with the rest of the bits
[21:54:49] <avrdood> yes
[21:55:01] <avrdood> thats why the right shift by 2
[21:55:02] <N1njaneer> If so then you should be able to terminate it after only the two reads.
[21:55:49] <N1njaneer> Then this looks correct.
[21:57:16] <N1njaneer> ALSO --
[21:57:33] <N1njaneer> VERY subtle nuance with the SPI bus on AVR devices
[21:58:01] <N1njaneer> Make sure you read and thoroughly understand the "SS' Pin Functionality" section.
[21:58:21] <avrdood> it looks ok but its not, the count are too high
[21:58:44] <avrdood> count goes around 1000
[21:58:47] <avrdood> not suppose to
[21:59:03] <avrdood> the SS is for multiple device
[21:59:09] <avrdood> well and single
[21:59:25] <N1njaneer> If you are using the AVR as a Master (as you are) you need to ensure that SS Pin is set specfically as an *output*, even if you are not actively using it. If it is set as an INPUT, unless it is pulled high you can have erratic operation.
[22:00:05] <N1njaneer> "If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin
[22:00:05] <N1njaneer> is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin
[22:00:05] <N1njaneer> defined as an input, the SPI system interprets this as another master selecting the SPI as a
[22:00:05] <N1njaneer> slave and starting to send data to it."
[22:00:49] <N1njaneer> It can cause very erratic operation of the SPI bus where sometimes it will work, and sometimes it won't, if the pin is left floating without an internal or external pull-up on it.
[22:00:50] <MarkX> hi
[22:01:00] <N1njaneer> I have seen this happen on several designs I have troubleshot for people.
[22:01:04] <MarkX> hey N1njaneer hope all is well
[22:01:06] <avrdood> usually you want everything not floating
[22:01:07] <N1njaneer> Hey mark!
[22:01:21] <N1njaneer> What is SS connected to in your circuit?
[22:01:36] <N1njaneer> If nothing, then make sure it is defined as an OUT in the appropriate DDRx register
[22:02:02] <N1njaneer> MarkX: Did you get your thing working? :D
[22:02:20] <avrdood> the chip select of the device
[22:02:28] <MarkX> if i have "const uint8_t *x = (const uint8_t *)&string3;", does that mean the contents of x will equal an 8 bit value which points to memory location of the contents of string3?
[22:02:36] <avrdood> thats the pin i pull down for the read
[22:02:40] <MarkX> N1njaneer: still going, lots and lots to do :P
[22:02:49] <N1njaneer> AVR: Okay, good. That rules that out, then.
[22:03:23] <avrdood> breadboard, the junction looks shaky
[22:03:48] <avrdood> the clock was 4V, ive divided with resistors to get into the range of the device
[22:04:27] <N1njaneer> MarkX: You want to drop the & before "string3" - it is inherently a pointer to the first element of the string.
[22:05:30] <N1njaneer> MarkX: You only need & in the case of something like "=&string3[10];" to get the address of the tenth element
[22:14:50] <avrdood> thats what remains final:
http://pastebin.com/21ShkbZC
[22:15:14] <avrdood> not sure about that but it makes sensdata = data + SPDR;
[22:15:43] <avrdood> where DORD is to fill the LSB of the variable with the MSB of the MAX ic
[22:16:54] <MarkX> N1njaneer: i finally got my code properly uploaded >>
http://copytaste.com/y4264 <<
[22:18:24] <avrdood> is thnat arduino code?
[22:18:50] <MarkX> i don't know what i'm doing wrong here but the message i keep getting here is >> Warning initialization makes integer from pointer without a cast [enabled by default] <<
[22:18:55] <MarkX> avrdood: no thats C
[22:19:04] <N1njaneer> I don't think you want DORD since the MAX datahsheet indicates the MAX transmits it MSB, DS31 down to D0
[22:19:20] <N1njaneer> DORD would set it to receive LSB
[22:19:24] <N1njaneer> +first
[22:19:54] <N1njaneer> Mark: Does it tell you which line that is occuring in?
[22:20:19] <avrdood> When the DORD bit is written to one, the LSB of the data word is transmitted first. When the DORD bit is written to zero, the MSB of the data word is transmitted first.
[22:20:20] <MarkX> yep, in the link i sent, line 15
[22:20:24] <avrdood> so thats fine :)
[22:20:33] <MarkX> the code is massive so i can't paste it all
[22:20:35] <avrdood> waiiiti
[22:20:37] <avrdood> i got it backwards
[22:20:47] <N1njaneer> AVR: You are setting DORD with 1 << DORD
[22:20:52] <N1njaneer> Remove that last OR
[22:21:13] <avrdood> what i understodd here is that its the LSB of the variable is filled with the MSB of the MAX ic
[22:21:30] <avrdood> so that bit switches the register content?!
[22:21:55] <N1njaneer> MarkX: Try removing the {} from around serialNum
[22:22:26] <N1njaneer> avr: It switches the order which the SPI bus is read in to the SPDR register
[22:22:38] <N1njaneer> You want it to match the format of the device you are talking to
[22:23:00] <N1njaneer> If the MAX datasheet indicated that it went D0 to D31 on the waveform transaction example chart, you'd want to set DORD
[22:23:01] <avrdood> yikes
[22:23:43] <avrdood> the count just got up to 15000
[22:24:23] <avrdood> ahhhhh
[22:25:25] <N1njaneer> You are reading MS Byte, then LS Byte. Which means the SPI bus must also going Most Significat BIT in order, else it would be pretty stilly.
[22:26:52] <MarkX> Warning 1 missing braces around initializer [-Wmissing-braces
[22:26:57] <MarkX> Warning 3 initialization makes integer from pointer without a cast [enabled by default]
[22:27:00] <N1njaneer> Your technique is find for the 16-bit conversion. Grab byte to x, shift x left 8, grab new byte and add/OR it in to x, shift right 2 to drop the two LSB's.
[22:27:48] <N1njaneer> MarkX: Oops, sorry, neglected to notice that was a string and not an integet for the serial #
[22:28:32] <avrdood> thats what i did
[22:28:36] <MarkX> http://copytaste.com/a4265
[22:28:46] <avrdood> so, what remains is a hardware issue
[22:28:48] <MarkX> there that is everything related to what i'm trying to do now
[22:29:26] <MarkX> basically USB_get_serialNum should get the unique serialnumber for the chip and populate serialNum[] with it
[22:29:56] <MarkX> if the serial number is "ABCD", serialNum[0] = A, serialNum[1] = B,
[22:29:59] <MarkX> etc
[22:30:03] <N1njaneer> Mark: You've got an interesting mix of PROGMEM and RAM stuff there :)
[22:30:19] <MarkX> i'd like to take credit for it, but none of this is mine
[22:30:30] <MarkX> i'm just hacking and piecing it together as i comment/understand it :P
[22:31:32] <N1njaneer> avr: You can also try reading in the other 16 bits and checking them to see if you are getting what is expected in those as well.
[22:32:59] <N1njaneer> avr: If you don't have 100% confidence in the SPI working properly or something weird in hardware, look at bits 17 for a zero, bit 3 for a zero, and see what the diagnostic bits like 16, 2, 1, and 0 are reading back as.
[22:33:20] <avrdood> you helped alot
[22:33:37] <avrdood> sorry havent seen that line
[22:33:55] <N1njaneer> MAX31855 datasheet, page 10
[22:34:07] <N1njaneer> Table 3 - Memory Map
[22:34:45] <avrdood> there is issue with the clock im pretty sure
[22:35:27] <avrdood> the device takes 3.3V , my micro is running on 5V so the clock is 5volt as well, i had to divide that to around 3V but with resistor a little lower then 1k each
[22:35:44] <N1njaneer> Voltage dividers do not work well for that kind of purpose.
[22:35:50] <N1njaneer> Sorry, meant to comment on that earlier.
[22:36:06] <N1njaneer> You are making a very high-impedence supply to the clock.
[22:36:19] <avrdood> its quite low actually
[22:36:42] <avrdood> like 680 ohms and 470ohm
[22:36:52] <avrdood> ahh no
[22:36:56] <N1njaneer> The better way to do that would be to just put the clock through a 33-120 ohm resistor and tie it to the device
[22:36:59] <avrdood> 20k and 15k
[22:37:14] <N1njaneer> Yeah, don't do that.
[22:37:22] <avrdood> thats all i had
[22:37:39] <avrdood> but i though too low of a resistor would cause too much current sink
[22:38:02] <N1njaneer> Are you dividing the clock, or the power to the clock?
[22:38:30] <avrdood> the clock itself that goes to CLK of the max31855
[22:39:06] <N1njaneer> I would try putting a 120 ohm resistors on the clock like to the MAX31855 if you don't have a level shifter.
[22:39:10] <N1njaneer> line
[22:39:19] <N1njaneer> +resistor
[22:39:34] <MrCurious> I am trying to find an elegant way of driving 10 pins with PWM on a 328 doing it manually. i have timer interrupt working for 1000 ISR calls per second, but want to see how others have done it before committing too much time. any recommendations on search terms other than DIY PWM?
[22:39:35] <avrdood> clk-in--->resistor--->clk of the ic
[22:39:45] <avrdood> and the voltage drop would suffice!
[22:39:46] <avrdood> yes\
[22:40:07] <avrdood> err
[22:40:11] <avrdood> maybe too high current
[22:41:41] <N1njaneer> MrCurious: As long as you don't need super-fine resolution or a high PWM carrier, it can be done like that just fine. I would suggest using inline assembler or similar tricks to make the port bit sets as fast as possible in your ISR, however, so you have time to do other things. Poorly written code in the ISR can result in nearly all of the micro's time being tied up in it.
[22:42:30] <N1njaneer> MarkX: Why is your serialNum[20]; at the top there a uint16_t? For unicode stuff I assume?
[22:42:41] <MarkX> exactly
[22:42:44] <MrCurious> N1njaneer: totally. can you think of any keywords that may point to prior art examples?
[22:43:19] <MrCurious> its for dc motors, and only 5 will ever be active at any given time.
[22:43:34] <N1njaneer> MrCurious: What is the intended application for the fading? Does it need to be smooth, will it be smoothly changing, or do you just need general level sets? How many levels?
[22:43:47] <N1njaneer> Okay that answers the first part :)
[22:44:17] <MrCurious> i need 128 divisions between on and off for doing PID to a dc geat motor. close totally counts. precision is not really neccessary, as the sensor + PID will correct for slop
[22:45:01] <MarkX> MrCurious: are you using PID on the avr?
[22:45:06] <MarkX> is there a library for it?
[22:45:07] <MrCurious> now you mention it... i guess 128 on/offs per second would be equal to 1/2 second on, 1/2 off....
[22:45:17] <MrCurious> there is
[22:45:18] <N1njaneer> MarkX: You may want to do "int16_t *wString;" in your struct usb_string_descriptor_struct declaraction.
[22:45:59] <N1njaneer> You WILL have to handle the reads of that part specifically without using the flash memory library word read commands, since it will be back in RAM and not flash :)
[22:46:33] <MrCurious> ok, this got simple now i realize i dont need to flip the bits constantly within a second, but rather can just do it once at teh right point within each second and with averaging it will be similar effects
[22:46:35] <avrdood> i just build a better circuit tomorrow with the whole register printed on screen
[22:46:36] <N1njaneer> MrCurious: I would probably try down and dirty first to see if it's acceptable, then refine from there.
[22:46:38] <N1njaneer> Something like:
[22:46:42] <N1njaneer> value = 0;
[22:46:48] <MrCurious> yeah. ty :)
[22:47:18] <N1njaneer> if(count > out1) value |= 1<<0;
[22:47:27] <N1njaneer> if(count > out2) value |= 1<<1;
[22:47:35] <N1njaneer> if(count > out3) value |= 1<<2;
[22:47:37] <N1njaneer> etc etc
[22:47:43] <N1njaneer> then PORTx = value
[22:47:50] <N1njaneer> At least blow through it quick :)
[22:48:28] <N1njaneer> Put all of your motor outputs on contiguous bits of the port(s) if possible so you can do some MathTricks(tm) where possible to speed up the evaluations.
[22:51:28] <N1njaneer> There's some other stuff you can do with quasi-PWM (bit angle modulation) which can dramatically reduce CPU overhead when doing ISR's like this but it's usually used more for driving LEDs than DC motors, but would probably work fine. It's basically a spread-spectrum PWM that goes by powers of 2, and only requires one interrupt per bit of resolution per cycle.
[22:52:47] <N1njaneer> So for instance, instead of 1000 ISRs per second for 7-bit level control, it would only need ~55
[22:53:25] <N1njaneer> Note that 1000 ISRs per second for 7-bit level control only yields a PWM carrier of ~7.8Hz. Is that acceptable for your motors?
[22:55:29] <MrCurious> that should work. wont know till i test it... its just a OWI toy arm
[22:55:36] <MrCurious> retrofitted with hall effect sensors
[22:57:01] <N1njaneer> If it doesn't I'd suggest either looking at potentially implementing bit-angle modulation, or using an external piece of hardware to generate PWM faster. AVR's have native PWM generators, but usually only a couple channels.
[22:57:38] <MrCurious> OH ! thats clever
[22:58:00] <N1njaneer> You could also use something like the TLC5951 which is a 10-bit 24-channel LED driver you can talk to over SPI bus. Just set it to low-current output and use the outputs to drive some biased transistors instead of LEDs.
[22:58:22] <N1njaneer> It will clock the PWM for you, and based off a divider for whatever speed clock you inject.
[22:58:39] <MrCurious> that would have been a better design than i did...
[22:58:42] <MrCurious> next time.
[22:59:03] <N1njaneer> Eh, always start simple, because if simple works, then no reason to make it more complex :)
[22:59:53] <MrCurious> all about simple :)
[23:00:18] <N1njaneer> You just always want to maintain alternative options on the back-burner you know you can move in to if you find you are coming up short with simple. :)
[23:00:44] <bsdfox\> MrCurious, use a state machine if you're worried about missing a trigger due to being in an ISR
[23:01:19] <N1njaneer> The nice thing about DC motors is that for your application the horrible jitter that can be introduced via software PWM (that can be exceedingly noticable when driving LEDs) shouldn't be an issue.
[23:01:39] <MrCurious> more so when they are behind 4 reduction gears
[23:01:47] <N1njaneer> Absolutely.
[23:01:51] <bsdfox\> your frequency is way too low if you notice jitter on leds
[23:01:53] <MrCurious> worse i would expect is an odd noise
[23:02:37] <bsdfox\> MrCurious, 20<Hz<20000
[23:02:40] <N1njaneer> bsd: The higher the frequency the more you can notice jitter-based intensity changes. It's kind of a catch-22
[23:02:55] <MrCurious> i think i have enough to run with this one. thanks!
[23:03:10] <MrCurious> now its reading time to learn about this BAM thing that is new and wonderful looking
[23:03:38] <bsdfox\> N1njaneer, not sure I follow that logic
[23:04:20] <N1njaneer> MrC: The biggest drawback for BAM when driving LEDs is getting absolutely smooth-stepping near the middle - the transition from 127 to 128 (when doing 8 bits) is the biggest noticable step if the frequency isn't sufficiently high.
[23:05:46] <N1njaneer> bsd: Higher frequency means shorter duration in the cycle, which means any change in the on:off ratio can affect the brightness significantly more. As the frequency increases, you close the gap between duration of cycle and average window of jitter possibility.
[23:06:51] <bsdfox\> N1njaneer, but it should average out and if the sample size is sufficient your results should be correct
[23:06:58] <N1njaneer> It also depends on the criteria you are using to judge it, but software jitter in PWM will absolutely appear at the low end of the dimming curve if severe enough :)
[23:07:37] <bsdfox\> the only negative for higher frequency is lack of resolution or increased processing time
[23:07:44] <N1njaneer> bsd: Over extended time yes, but if you are using it for a lighting application where the LEDs are viewed directly, isntantaneous jitter can result in very unsightly "pops" in brightness.
[23:08:25] <bsdfox\> N1njaneer, I would guess that we're considering very different frequencies
[23:08:25] <N1njaneer> bsd: Or you can spread the PWM spectrum, which works amazingly well.
[23:08:41] <avrdood> N1njaneer: thanks
[23:09:53] <N1njaneer> bsd: We modulate LEDs at up to 62.5Khz in our professional lighting products using a spread-spectrum PWM technique, done in hardware. Yeilds an effective 16-bit resolution with absolutely zero perceptible flicker and the ability to dim down to <0.01% brightness, to the point where the LED dies are barely glowing when you are in pitch darkness :)
[23:10:21] <N1njaneer> avr: You're welcome! Hope that helped. :)
[23:10:36] <N1njaneer> Man, it's like the help-desk here tonight. "Hello IT! Did you try turning it off and back on again?"
[23:13:16] <N1njaneer> (for those familiar with "The IT Crowd"
[23:13:18] <N1njaneer> )
[23:19:02] * N1njaneer cracks knuckles.