Project: SPI_MSTransfer

tonton81 said:
nope, if you can send a static dma buffer for f&f known at transmission time, dma should be able to handle it
for the other methods, like led toggle, you can PAD the buffer with 0xBEEF to skip right through the ACK area and terminate the connection, this should be enough to trigger that switch statement

but you seen the millis() count in console? its incremental wothout skips, even when printing the slave data :)
Click to expand...

I didn't watch a demo of the transfers to see the millis() print - but that only takes a couple thousand passes through loop to catch that each milli per second. When the system is running in balance and not over loaded the number of loop()'s per second is 500,000 or more even in the current 180 MHz T_3.6 code on the other thread - it can be in the millions unloaded - and one small code error or test can drop it to 30,000 or when stuffed on the other thread it hits 385 loop()'s per second - I know form watching and pushing it.

DMA would be cool where it can be used to reduce Master overhead when messages get longer - and now that they can be put in _QUE the code would never have to stop after doing a _QUE - and the Master DMA just pulling the next from the _QUE would have minimal impact - so that would be great if it could/did go there.
 
tonton81 said:
Teensythreads seems to be helping with the extra boost, I havn't has any crashes yet, Mike still says he had to play with the delays, but the threading i think is helping it as well, especially with the mutex locking to prevent dequeue&queue at same time, while running master loop at 250uS intervals, TT been running here since yesturday, and ever since the speed boost of the queue system before TT added, my javas been running out of memory very quickly in the IDE if i keep those consoles open :)
Click to expand...

Switch to TyCommander - much better SerMon and doesn't use JAVA and has better memory management for SerMon storage - and much better for programming multiple Teensy's in parallel when 'integrated to Arduino'! It was faster than IDE SerMon before SerMon got more usably fast - not sure which is fastest - but TyCommander doesn't let me down.

I wasn't watching the recent 'chat' here much - didn't even notice it was using TeensyThreads. Nice it is a good alternative.
 
I looked through paul's SPI library today and looked into the buffer SPI writing, surprisingly, I think they're 8 bits wide. There doesnt seem to exist a 16-bit version of the transfer tool. Knowing it wont work due to endianess, I tried casting and it didnt work, because of the byte order, the data is not correct, so the slave does nothing with it because it knows its bad... Same goes for the arduino SPI library, no support for direct 16bit buffer writes.
I wanted to see if using that method with the CONT & EOQ flag for SPI would increase performance, but couldnt reach that point... Yup TT is running sweet, code not on github yet though until you guys confirm it's ok to update
The overload for transfer(16) is uint8_t now so 0 == Default ACK, 1 == F&F Direct, 2 == F&F Queue
 
Did you find this in SPI.h?
Code: 
	uint16_t transfer16(uint16_t data) {
		port().C2 = SPI_C2_SPIMODE;
		port().S;
		port().DL = data;
		port().DH = data >> 8;
		while (!(port().S & SPI_S_SPRF)) ; // wait
		uint16_t r = port().DL | (port().DH << 8);
		port().C2 = 0;
		port().S;
		return r;
	}

Also SPI0 has a four byte FIFO - not sure that helps?
 
Thats for a single dword, I was looking for the buffered one for full 16bit transfers
Currently the payloads are transfered like this (with the code you provided in core):

Code: 
      for ( uint16_t i = 0; i < data[1]; i++ ) { spi_port->transfer16(data[i]); }

during this stage we dont even care about the receiving, so blasting them as fast as possible is better
 
Example, adding this to SPI.h's core:

Code: 
     void transfer16(uint16_t *data, int len) {
       for ( uint16_t i = 0; i < len; i++ ) {
         port().SR = SPI_SR_TCF;
         port().PUSHR = data[i] | SPI_PUSHR_CTAS(1);
         while (!(port().SR & SPI_SR_TCF)) ; // wait
       }
     }

This turns SPI_MST's:
Code: 
  for ( uint16_t i = 0; i < data[1]; i++ ) { spi_port->transfer16(data[i]); }

to:

Code: 
spi_port->transfer16(&data[0],data[1]);

NOTE, even for the DMA, a 16 byte transfer method would be needed, we cant use the 8 bit wide version as it changes the endianess of the bytes... The DMA, if implemented, should work with that method added in the core, as it doesnt change the endieness of the bytes, it stuffs the 16bits as is in the register

NOTE, that code was inserted at 543->549 of SPI.h of the core, also note we're writing only, not reading, so a retbuf would be nice if anyones interested to do that, SPI_MST doesnt need a retbuf, due to the design of the circular returns, the current poll is more than sufficient
 
Hi tonton81 - back from the dentist - I hate dentists :( Had a break this morning playing with uNav and the ILI9xx display. Right now I am in the process of converting the new version of uNav to my double message version so I can test with the new version. Yes Tim I added in you new code for debugGPS. Then I will be off to the races. :)
 
Ok here we go. No matter what I do with events(__) I will still get doubles as we discussed before. But what I did find was that for que option I need a 450 or so microsecond delay between packets send. For F&F I still need a delay of 200 microseconds between transfers.

With that said, once Don modifies the sketch for faster updates (20hz) things will definitely got more interesting between the two que and F&F transfers. Going to eventually add in a select option for what packet to send from master to slave then you can select instead of sending the two.

As far as I can see the library is working the way its suppose to - when I run the test sketches there is no problem so .. leave it up to you when you want to formally push it to GitHub. :)

Now for some fun with the TeensyThread version. :)


EDIT: Got threaded version up and running - almost can't see the data sent back to the master from the slave - its that fast, things are going to get interesting
 
Last edited:
yes, thats normal, because your queing twice per loop, thats the same as 2 loops, your other option is to double the queue size, this is where power of 16 shines :)
 
Got it - wasn't worried about - just letting you know. The only reason I can see for sending 2 packets is if I want to 1 thing with the 1st packet, like TViewer on Serial and with the second packet send to a second serial or ESP or something else.
 
I was thinking about that but was afraid to ask. But was thinking about the load on the master - interesting thing to put on the todo list....... Think I will wait for the 20hz loop to really try it out with uNav :)
 
Hi tonton81
Have a quick question for you - if I wanted to transfer commands (string or char) from the master to slave I would just use transfer() like it would be done for the ESP?

Mike
 
you mean print/println? MST supports this on master side to print to uart/SerialUSB of slave, didnt understand the question mostly though :)
 
Oh, sorry.

Right not we are using serial.available to real a command from the sermon on the master side to control what the sketch is doing. For instance I send a 5 and the master will transfer message id 55 to the slave, if I hit 6 it turns off message 55 and sends say message 56, but I am doing it from the master side.
Now if I want to do this from the slave to master I would have to transmit a char or a series of chars (i.e., want to adjust sea level pressure so I can get a better altitude from the pressure sensor so I would send p101424 which would me change sl pressure to 1014.24 mb). So was thinking about sending it with transfer() from slave to master. :)

Eventually want to tie it to a radio or esp on the slave so thought that this would be the best way. :)
 
yeah you can have the slave send it as a payload data and handle it from the master callback with print/println, the slave transfer/transfer16’s dont use the overload as they queue only
 
Thanks tonton81. Glad the explanation helped. Just needed a sanity check as my head is beginning to spin.
 
Hi guys, is everything good with the SPI_MST QUEUE version? Is it ready for a github merge?

I also fixed the "resend feature". It wasn't completely finished, only debug output was coded. Now it actually re-asserts and resends on an invalid CRC or each response timeout of 1000uS for a maximum of 3 times.
I've tested it by hotplugging the spi lines and its working pretty well :)

(only non-F&F's use resend feature of course)
 
Hi tonton81. I think its ready to go. Would recommend just a couple of notes on the transfer16 option - 0, 1, 2 along with that its mandatory to events in the master loop as well as a one liner on the parameter that events takes - to be honest didn't check if that's already there.
 
You must log in or register to reply here.
Back
Top