Back
[06:01:26] <hetii> HI :)
[10:54:45] <t4nk349> hi i have a problem with the do{}while loop... when i write do{..}while(PLC!= 'a'); then its working.. but now i want to add a second instruction like: do{..}while(PLC!= ('a' || 'b')); but this doesnt work.. how have i to write that?
[10:55:03] <t4nk349> while(PLC!='a' || PLC!='b').. did also not work
[11:01:19] <x29a> t4nk349: "did not work" as in didnt perform as you intended?
[11:01:30] <x29a> are you sure you want the logical OR?
[11:02:34] <t4nk349> maybe its about the OR statement.. i want that do{ReadingIncoming}while(eitherpress 'a' OR 'b')
[11:04:09] <x29a> you want a OR b to end the loop, right?
[11:04:26] <t4nk349> yes
[11:04:36] <x29a> the statement you write after while is the one to keep it running though
[11:05:10] <t4nk349> in the do{} loop its always reading the input signal.. and this should lasts as long as there is either a 'a' input or a 'b' input
[11:05:18] <x29a> try to formulate the condition in a way where true (boolean 1) would be the opposite of what you have
[11:06:34] <x29a> your last sentence reads to me like "as long as PLC is a OR PLC is B, continue", which is contrary to above
[11:07:15] <x29a> just in case, try other logical operators ;)
[11:09:10] <t4nk349> ok yes i need a && :D
[11:09:21] <t4nk349> but still one mistake.. have to check it out
[11:16:40] <InfiniteE> Hello
[11:17:06] <InfiniteE> I've been away for a few years and feel a bit confused now that i want to start playing with my avr's again
[11:18:41] <InfiniteE> I've got an stk500, but i cant find any asf-example-projects for that board. Are there any major differences between the stk500 and stk600 that makes it impossible to use the same example projects?
[11:19:40] <Lambda_Aurigae> might need to make some minor port changes I would think...so long as you are using the same microcontroller it should be fine.
[11:20:29] <InfiniteE> Ok, thanks :)
[11:20:46] <Lambda_Aurigae> I would look at the board specs and see what is different.
[12:45:02] <malinus> InfiniteE: might I ask why you chose to buy a development bord that is 10 years old?
[12:46:35] <Lambda_Aurigae> I bought one too.
[12:46:36] <LeoNerd> http://pastie.org/9780286 <== can anyone see what might be wrong with this HVSP code? It's an SPI-like clocked transfer. According to a logic probe attached to the IO pins, this is working fine. But the function itself is always returning the number 4, regardless what actual data was read in the SDO pin
[12:46:38] <Lambda_Aurigae> 10 years ago.
[12:46:59] <LeoNerd> (Yes I know I should initialise it to 0, but that's there for me to test "is the return value going through the rest of code code", which I know it now is)
[12:47:44] <LeoNerd> It appears that if(PORTB & _BV(SDO)) is never being true, even though according to logic probe, there's serial data being clocked in there
[12:49:19] <LeoNerd> Righty; if I replace that with if(1) then it does read back as all 0xff
[12:49:43] <LeoNerd> Oh I'm a grade-1 moron. reading PORTB doesn't read input does it? ;) I wanted PINB ;)
[12:50:47] <malinus> Lambda_Aurigae they made us buy one at my school :V
[12:51:14] <LeoNerd> avrdude: Device signature = 0x1e1e0c
[12:51:29] <Lambda_Aurigae> I got one years ago when they had a special of an stk500 and avr-dragon in a bundle cheaper than either of them separately.
[12:51:30] <LeoNerd> Weeeellll.... it's getting better. first and third bytes are correct... second isn't.
[12:52:37] <Tom_itx> dude
[12:52:42] <Tom_itx> git your bits in order!
[12:53:13] <Lambda_Aurigae> bits is bits
[12:53:17] <Lambda_Aurigae> but bits isn't bytes.
[12:53:26] <Lambda_Aurigae> however, bytes is bits.
[12:54:55] <LeoNerd> Also, how annoying that the Saleae Logic software doesn't understand HVSP :(
[12:55:09] <LeoNerd> I have to decode raw logic traces myself
[12:56:19] <Tom_itx> awww
[12:58:15] <LeoNerd> Ah... most curiously odd...
[12:58:29] <LeoNerd> It seems the data out line gets cleared when I raise the clock.
[13:03:56] <InfiniteE> malinus: i got it almost ten years ago, thats why
[13:05:08] <malinus> hahaha damn stk500
[13:05:24] <InfiniteE> ?
[13:15:21] <LeoNerd> OK I really don't understand this... even in the disassembly, there's a single SBI instruction to raise the 'SCI' output pin of PORTB; and in the logic trace that instruction also lowers the 'SDI' pin. :(
[13:22:50] * LeoNerd idles AFK to think and do other things for a moment... :/
[13:38:28] <LeoNerd> http://pastie.org/9780362 <== line 21 in this post
[13:38:34] <LeoNerd> I don't get it :(
[13:39:25] <InfiniteE> the for loop?
[13:39:37] <LeoNerd> Uhm.. 22 :)
[13:39:45] <LeoNerd> The one with the the big shouty comment on it
[13:40:16] <LeoNerd> That line compiles to single instruction: 2dc: 29 9a sbi 0x05, 1 ; 5
[13:40:24] <LeoNerd> It's a single SBI. Why is it clearing another pin?
[13:41:21] <LeoNerd> It doesn't clear it all the time, just in one particular circumstance.. it's 100% repeatable though
[13:41:58] <LeoNerd> The trouble with it is that the other end of this sync-serial protocol is expecting to read the data lines after a rising clock, so those lines have to remain stable around a rising clock
[13:42:21] <InfiniteE> are you 100% sure it is that line that causes the problem?
[13:43:13] <LeoNerd> Well... That's the only line which raises the clock pin. The data pin falls at the exact moment the clock rises, on my logic probe output trace here
[13:43:20] <LeoNerd> So I'm guessing so
[13:44:28] <apo> huh
[13:46:24] <InfiniteE> line 38 & 41 clears sdi & sets sci, sure that is not what is happening?
[13:47:25] <LeoNerd> Indeed not; that's much later.. the "final three" dead clock cycles
[13:49:11] <LeoNerd> Ooh..
[13:49:13] <LeoNerd> <.<
[13:49:13] <LeoNerd> >.>
[13:49:24] <LeoNerd> Ofcourse that's the -final- bit in the data word
[13:49:26] <LeoNerd> DAMNIT!
[13:50:11] * LeoNerd buries head in shame, hides in the corner, etc etc
[13:50:13] <LeoNerd> You're absolutely right :)
[13:51:22] <LeoNerd> Woo! :)
[13:51:23] <LeoNerd> avrdude: Device signature = 0x1e930c
[13:51:27] <LeoNerd> It are the work!
[13:51:39] <InfiniteE> :)
[13:54:58] <LeoNerd> Thanks much for that; I'd have been looking at that all day
[13:55:10] <LeoNerd> I forgot the second-half of that clock cycle spills out after the for loop
[14:01:18] <InfiniteE> your welcome
[14:01:34] <InfiniteE> its the obvious things that you spend forever not considering =d
[15:51:22] <hetii> Hi :)
[15:52:02] <hetii> Did some of you play with openpcd or openpcd2 ?
[15:54:21] <Lambda_Aurigae> never heard of it.
[15:55:29] <Lambda_Aurigae> looks like it is arm based.
[16:03:14] <hetii> Lambda_Aurigae: yes and pic, but the code of handling spi communication is twisted there
[16:03:25] <hetii> and I wonder why its done by this way
[17:01:08] <t4nk349> anyone used with samd20?
[17:08:36] <Lambda_Aurigae> Sam D microcontrollers are ARM.
[17:08:42] <Lambda_Aurigae> Cortex M0+
[17:36:28] <LeoNerd> Hrm.. Where's RikusW lately? I want to talk to him about HVSP and reading/writing the lock bits
[17:36:52] <LeoNerd> There's only 2 bits; reading it seems to give 1s for the other 6 bits
[17:37:18] <Lambda_Aurigae> if they are undefined then they will read as 1.
[17:38:11] <LeoNerd> This seems to upset avrdude
[17:38:42] <LeoNerd> $ avrdude -c stk500hvsp -P /dev/ttyUSB1 -b 57600 -p attiny84 -U lock:w:1:m ==> avrdude: verification error, first mismatch at byte 0x0000 0xfd != 0x01
[17:39:10] <Lambda_Aurigae> so set the bits to 1 in your byte when you write it.
[17:39:18] <LeoNerd> Hrm..
[17:39:23] <Lambda_Aurigae> then it will verify properly.
[17:39:35] <LeoNerd> Hrm..
[17:40:14] <Lambda_Aurigae> happens the same way with standard ISP
[17:40:19] <Lambda_Aurigae> or ICSP
[17:41:07] <LeoNerd> Ah.. OK fair enough
[17:41:18] <Lambda_Aurigae> someone asked about that in here some 6 months ago or so.
[17:41:21] <Lambda_Aurigae> same answer.
[17:42:46] <LeoNerd> In related news: This code seems to be working great. I basically have all the read/write operations via avrdude believing it's talking to an stk500, when in fact it's my HVSP board. :)
[17:43:11] <LeoNerd> And the code weighs in at a little over 2K, so looking great for fitting on to a tiny841
[18:56:12] <LeoNerd> I have just realised -quite- how crazy the tiny841 is; with the SPI "remap" bit and the routing bits of the timer output compare pins
[18:56:26] <LeoNerd> Almost but not as nice as the PIC18 routable IO pin idea. I think I'd prefer that, to be hones
[18:56:26] <LeoNerd> t
[19:33:00] <timemage> LeoNerd, heh. i didn't find that and ended up writing to atmel about the pinout.