Project: SPI_MSTransfer

Ah, wouldn't do anything until I can see if I can break it :) Why add latency, may cause other issues.
 
You don't know how much I appreciate that one. :) Running the update now with 20ms on the master and 40 on slave, might as well. Wonder if the fix will also help with post #451? Will have to give that a try at some point. :)
 
indeed, my coding is done for tonight, another 3 hours before i get ready for work so ill be chatting via phone here :)
haha

15 days thread lifetime

Replies: 629
Views: 6,897

3 active chatters :)
 
Have fun:) By the way I did break it:
Master:
Code: 
PacketID: 55
Length: 48
0 0 5180 40EA 0 0 51A0 40EA 0 0 51C0 40EA 0 0 51E0 40EA 0 0 5200 40EA 0 0 5220 40EA 0 0 5240 40EA 0 0 5260 40EA 0 0 5280 40EA 0 0 52A0 40EA 0 0 52C0 40EA 0 0 52E0 40EA 
F&F (OT=0)micros() _time==73
F&F (OT=0)micros() _time==99986
]
Slave:
Code: 
23388.00, #, #, #, #, #, #, #, #, #, #, #,18334,0
23400.00, #, #, #, #, #, #, #, #, #, #, #,18335,0

Going to slow down the slave transfers as a sanity check. This is a problem for another day.

Mike
 
FASTRUN can use only a tiny portion of RAM on T_3.6 - Paul noted but not recorded - maybe 8K? At most it is the same size on T_3.5.

That area is also where most recently used code is maintained - putting too much there by force ( if it fits ) will prevent MRU from holding over? The spi0_isr() at 5+ kb is a lot of code.

Indeed Teensy needs active USB stack to catch the 'bootloader' speed change request. If higher PRI code is busy/hung it will be missed.

If CS had a PULLUP on Slave and Master end were pulled it would rise. If just pulled - it will float.


If the 'fancy' CPP code is still used - versus manual 'C' queue that may drag in other code and hitting malloc related stuff is ugly.

If the Slave wants to make request - they will be known in nature at compile time and could be accounted for with static allocations. There was a static buffer for incoming SPI - that could be expanded to a set as needed. T_3.5/3.6 have more than enough RAM to dedicate some to expected buffers until they can be re-used.
 
your suggesting we drop the STL containers in favor of multiple storage arrays? theyre no longer shared between isr&loop
 
tonton81 said:
your suggesting we drop the STL containers in favor of multiple storage arrays? theyre no longer shared between isr&loop
Click to expand...

Yeah, Just seems like using a big unknown external code path in a time critical area. Might be of 'under'kill or a bit Technophobic ... but more deterministic for a couple simple sets of bytes.
 
things are working fine here for several hours, if you want C type queues ill have to figure out how to make one thats similar to FIFO, not to mention try to redesign the library around in order to use them, and then theres no guarentees thatll fix anything either, so another long shot test :)
 
Right now been running for about 20 minutes with 20/120 ms and no errors or hangups. If it keeps going I will remove FASTRUN from the callbacks and see how it goes. Maybe just a little more spacing is needed between master/slave transfers? <EDIT> At least for fire & forget.
 
May not relate to the problem. If the SPI transfer are handled right it should run forever. I haven't been following closely - not sure of the nature of any trouble - just seems like a potential problem.

If the ISR just managed headers with data links, it could manage its own data blobs for use and re-use through events, and user calls to transfer to Master could provide memory pointer for the data and then just need to know when it could be re-used.
 
mjs513, maybe onto something here, the callbacks call upon usbserial which does printing, which spi0 has more priority, perhaps this is hinting something
 
yeah we could setup like 16x 1K buffers and just tell the master/slave theres a payload of 128 (thereby ignoring the rest)

but im not familiar with building a queue system from scratch so its something i gotta learn
 
USB processing does show in function - that is part of why the TViewer output was moved to Slave - that and the overhead of formatting made the SerMon jumpy
 
Ok. Spoke too soon again. Just hung. Have an idea though:
Master:
Code: 
F&F (OT=0)micros() _time==73
F&F (OT=0)micros() _time==99975
Slave:
Code: 
41968.00, #, #, #, #, #, #, #, #, #, #, #,63573,0
41980.00, #, #, #, #, #, #, #, #, #, #, #,63574,0
Beginning to think that the code is not recovering properly from - not sure if there is a trap or something that can be used that says just ignore, clear buffer and start over - guess a reset..... may loose some packets but...

Mike
 
I don't know - problems seem to be attracted to me :( I think its something with the T3.5/T3.5 configuration to be honest. Is there anything unique in the library that would be different for the T3.5 vs the 3.6? I didn't see anything T3.5/T3.6 ifdefs are together.
 
tonton81 said:
mike, why only you :p mines scrolling like a madman OT=0
Click to expand...

'Something' happens - even on normal F&F it seems. As noted my T_3.1 slave stopped after 26+ hours - noticed no LED blink. Master was just stuck in RESEND and Slave was silent . . .

Paul has a FIFO for Serial you might follow tracking a Packet Struct instead of a byte: \hardware\teensy\avr\cores\teensy3\serial1.c

Follow key words here:
Code: 
int serial_available(void)
{
	uint32_t head, tail;

	head = rx_buffer_head;
	tail = rx_buffer_tail;
	if (head >= tail) return head - tail;
	return SERIAL1_RX_BUFFER_SIZE + head - tail;
}

This adds chars read from FIFO: uart0_status_isr()
This pulls out chars: serial_getchar()
 
I do have a T3.6 I could solder up and give it try. If it works then, its something with the T3.5s. Maybe running the slave at a slower speed like 144 or 120 with the master at 168 oc'ed?

Right now I think its slave getting stuck. If I reset the slave it starts right up again.
 
mjs513 said:
I do have a T3.6 I could solder up and give it try. If it works then, its something with the T3.5s. Maybe running the slave at a slower speed like 144 or 120 with the master at 168 oc'ed?

Right now I think its slave getting stuck. If I reset the slave it starts right up again.
Click to expand...

As noted - that is what fixed mine too - tapped added reset button on T_3.1 and Master went back to work fine and Slave came up running.
 
This is too too strange for words. It should work for me but it doesn't.... for the sake of seeing if I can break things further I am playing around with buffer size and the delay in the .h file. Changing delay to 1 didn't do much, still hung and looks like making the buffer size larger made it hang faster.. maybe making it smaller :)
 
You must log in or register to reply here.
Back
Top