Project: SPI_MSTransfer

im just scrolling thru avr emulation.h and noticed:
Code: 
inline void enable_pins(void) __attribute__((always_inline)) {
		//serial_print("enable_pins\n");
		if ((pinout & 1) == 0) {
			CORE_PIN11_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2); // MOSI0 = 11 (PTC6)
		} else {
			CORE_PIN7_CONFIG = PORT_PCR_MUX(2); // MOSI0 = 7 (PTD2)
		}
		if ((pinout & 2) == 0) {
			CORE_PIN12_CONFIG = PORT_PCR_MUX(2);  // MISO0 = 12 (PTC7)
		} else {
			CORE_PIN8_CONFIG = PORT_PCR_MUX(2);  // MISO0 = 8 (PTD3)
		}
		if ((pinout & 4) == 0) {
			CORE_PIN13_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2); // SCK0 = 13 (PTC5)
		} else {
			CORE_PIN14_CONFIG = PORT_PCR_MUX(2); // SCK0 = 14 (PTD1)
		}

is there a reason why only pins 13 (i could guess because of the led) and pin11 are set to drive strength enable? has anyone played with the slew rate (PORT_PCR_SRE) and drive strength? (PORT_PCR_DSE)

im wondering what impact, if any, will they do when applied on master

seeing as im using spi2 default pin 43 for CS, im wondering why that isnt listed under avr emulation either, perhaps, we might have different pin configs worth testing?


spi2
Code: 
enable_pins(void) __attribute__((always_inline)) {
		//serial_print("enable_pins\n");
		if ((pinout & 1) == 0) {
			CORE_PIN44_CONFIG = PORT_PCR_MUX(2);
		} else {
			CORE_PIN52_CONFIG = PORT_PCR_MUX(2); 
		}
		if ((pinout & 2) == 0) {
			CORE_PIN45_CONFIG = PORT_PCR_MUX(2); 
		} else {
			CORE_PIN51_CONFIG = PORT_PCR_MUX(2); 
		}
		if ((pinout & 4) == 0) {
			CORE_PIN46_CONFIG = PORT_PCR_MUX(2); 
		} else {
			CORE_PIN53_CONFIG = PORT_PCR_MUX(2); 
		}
miso/mosi/sck dont have any set
 
tonton81 said:
great! mikes getting progress :)

tim, pintoggle handled internally? I played with NVIC before, even set it at 113 (just after USBSerial), i did read a post once where paul said theres no priorities used between 1-32 either, and we’re using 0 for highest, i didnt see any differences, i did post a link quite a few posts back which was a post from another thread where the spi clock was not “exactly” within its margin rate for certain cpu speeds, which may explain why some clock rates could mismatch and cause unreliability, sort of simillar to error rates of uarts
Click to expand...

Internal to the library code. The data[2]'s like .pinToggle leave no trace or queue entry. Just wondering if they might ever be useful?

Really need to get back to current version ... been a distracted set of days - 113 would be good if pri could be dropped and work. Might cause a resend - but if something insists on higher priority SPI_MST should cope?

Given the Slave runs off the Master clock - whatever it does - it should work - until it gets too fast to handle? Oddly The Teensy indeed wants to show off and work at higher speeds - where it should not be so reliable if capable.

Wondering if a Circ_buf_arr could be used to dump the time or something useful for each byte received? If no resend then zero that array - if an error then index to next one. Then dump that info during a quiet time - not during a transaction. It might allow seeing what is killing it?
 
Ok, eyes still closed a 7:00am but the T3.5/T3.1 combo with 5ms loops on both is still running. That's about 8 hours and 4.6M+ transfers with 1 error and 0 OT's.

Need coffee then lets see what we can do with the T3.5/T3.5 combo.
 
Ok. Here we go with the good news T3.5M with 30M spi and 5ms loop, T3.5 at 144M clock. Still running after 2 hours up to 1.2M transfers no errors. Also, did quick tests with the SPI bus at 36M and 40M still works :)

Changing the buffer from 32 from 64 seemed to help believe it or not at least for the T3.5s

Cheers
Mike
 
yeah, if the hits are faster than the loop it can wrap around and catch up, which is why we have a deeper circular buffer, although its a bandaid, this gives a reason to give a few ms processing time to complete a few queues
a smart method could be hitting them at 5ms intervals and after a minute auto switch to 20 ms and let that go 2-3 times then auto switch back to 5ms, this should get you the performance gain while allowing slave to "catch up"
 
The slave seems to be quite happy with a 5ms loop. The testing used 5ms sends from the master and the slave used the same (5ms loops). So I am not sure. By the way I missed wrote "changing the buffer from 32 to 64" I meant changing the buffer from 64 to 32. The buffers are at 32,250 in all my testing. :) Sorry. I got too excited and transposed the numbers :(
 
Oh dear, I simply forgot yet another powerful feature...
Why the heck am I reading front() and then pop_front() to clear it when I could do a buffer internal combo? Thats right guys, a new method for circular array to further make things simpler!

remember the F&F had a push_back(buffer,len) single liner?

Code: 
_slave_pointer->SPI_MSTransfer::mtsca.push_back(data, len);

tell me... why the heck didn't i do the same for the deque!?!?:

slave::events() modification:
Old:
Code: 
    if ( mtsca.size() > 0 ) {
      uint16_t checksum = 0, buf_pos = 0, len = mtsca.front()[3], buf[len]; AsyncMST info;
      for ( uint16_t i = 0; i < mtsca.front()[1] - 1; i++ ) checksum ^= mtsca.front()[i];
      ( checksum == mtsca.front()[mtsca.front()[1]-1] ) ? info.error = 0 : info.error = 1;
      info.packetID = mtsca.front()[4];
      len = mtsca.front()[3];
      memmove (&buf[0], &mtsca.front()[5], mtsca.front()[3] * 2 );
      mtsca.pop_front();
      if ( _slave_handler != nullptr ) _slave_handler(buf, len, info);
}

New:
Code: 
    if ( mtsca.size() > 0 ) {
      uint16_t array[mtsca.front()[1]];
      [B][COLOR="#FF0000"]mtsca.pop_front(array,sizeof(array)/2 );[/COLOR][/B]
      uint16_t checksum = 0, buf_pos = 0, buf[array[3]]; AsyncMST info; info.packetID = array[4];
      for ( uint16_t i = 0; i < array[1] - 1; i++ ) checksum ^= array[i];
      ( checksum == array[array[1]-1] ) ? info.error = 0 : info.error = 1;
      memmove (&buf[0], &array[5], array[3] * 2 );
      if ( _slave_handler != nullptr ) _slave_handler(buf, array[3], info);
    }

that alone fills the array buffer with memmove and wipes it out of queue! Bonus addition! :)

haha guys, gotta love the irony here:

Code: 
                      SPI0_PUSHR_SLAVE = _slave_pointer->SPI_MSTransfer::stmca.front()[ ( buf_pos > _slave_pointer->SPI_MSTransfer::stmca.front()[1] ) ? buf_pos = 0 : buf_pos++];
                      if ( SPI0_POPR == 0xD0D0 ) {
                        _slave_pointer->SPI_MSTransfer::stmca.pop_front();

circular array being streamed in circular fashion to the master, everything is going in circles lol
 
Last edited:
On another note, I set the T3.6M to OC240 and the T3.5S to OC168, now I'm getting 49uS transfer rates from master -> slave...
 
Ok. Haven't a clue on to set a T3.5 to 240, but from what I read in an earlier post link, I read it wasn't really a good idea to overclock to 240.

BTW that's about 10uS faster than I am getting with my settings with 5ms transfers.
 
Sorry, I fixed that typo, my master is a T3.6 (keyboard is 10 year old logitech lol) mhs, im doing m->s at 0ms! im gonna wreak havoc, one sec, let me do same for slave
 
Oh dear lord!
https://www.youtube.com/watch?v=9VUYXw-qYpY
0ms both sides, they're going at it with no remorse!
0 error rates, both teensies overclocked, led blinking normal rate

i did correct a bug though, there IS an ISR issue... BUT, due to the small and efficient code, I was able to fix it. It may not be a be-all bug fix, but its a minor fix none the less
 
Just looked at the video - becareful the Teensy's don't start smoking at those speeds. Like you said they are show off :)
 
We all learn from experience, so if I havn't blown up yet, I don't have that experience to not do it that way again :)

just out of curiosity, I reloaded Tim's sketches (same as the tonton examples), just so I can verify no packets are "missed"
His code seems to have an easier sight for sore eyes to see the error count easily while it scrolls

so im using it as a sanity check
 
Interesting, your code I can do 0ms both sides
His code "misses" at 0ms, but works fine at 10ms

This could be an issue with the float processing, the amount of prints, and whatnot
interesting...

i like the way he did it, real easy to see if there were misses
 
I have been using the sketches I sent you previously for 2way communication which is essentially Tim's sketches but the modified slightly. Not sure what else to check right now. So back to that other project for a little bit - think I need to change connections so that all the writes go to serial1 and debugging stuff goes to serial2 or something - again because of the hardwiring of pins 0/1 to the ESP. Also, CH_EN is not exposed so can't connect to that :)
 
can ignore the other pins for now, only ERX0 and ETX1 are important

As far as the code:
https://www.youtube.com/watch?v=8NFOrq3_IQY
I still got 0 misses running 10ms rates both sides with led blinking

the upper serial monitor, the last 0 field is the count of misses. If it stays 0, it's all good

the library has been updated as well
 
Thanks. Now I have to go and update my GitHub forks :) Been running at 5/5 with my testing so all is good even with my problematic T3.5M and T3.5/T3.2 slaves. Think you got it fixed. By the way I have been using TD1.42b3 for my testing and no problems with loads. Still can't have 2 t3.5s connected at the same time - it gets confused on which to load to :)
 
mjs513 said:
Thanks. Now I have to go and update my GitHub forks :) Been running at 5/5 with my testing so all is good even with my problematic T3.5M and T3.5/T3.2 slaves. Think you got it fixed. By the way I have been using TD1.42b3 for my testing and no problems with loads. Still can't have 2 t3.5s connected at the same time - it gets confused on which to load to :)
Click to expand...

A button press should tell it which to load to. Are you running TWO instances of the IDE - not two 'File Open' copies of the same?

TyCommander addresses them by Serial # and will work - but the TD1.42b3 is getting closer.


re: Tony "just out of curiosity, I reloaded Tim's sketches (same as the tonton examples), just so I can verify no packets are "missed"
His code seems to have an easier sight for sore eyes to see the error count easily while it scrolls"

and Mike "essentially Tim's sketches but the modified slightly"

Are those the DEBUG HACK versions? Where it watches the indexing - but limits the USB Spew? Hopefully I'll be back soon from voyeur mode and look at the current state.
 
Tim
Are you running TWO instances of the IDE - not two 'File Open' copies of the same?
Click to expand...
Probably two 'File Open'. Guess I need two separate instances. would be nice just to select the comport the teensy is on then it loads to that comport - guess that's essentially where its headed.

Are those the DEBUG HACK versions?
Click to expand...
Shot answer is Yup. :)
 
Starting/Double clicking the EXE two times lets each have unique settings ( device and speeds and TEMP folders to build ) and the independent 'port' selection as well. Problem is the IDE's look identical so tracking COPY1 and COPY2 is needed - especially with 2 copies of the same sketch M & S in each.

DEBUG HACK output was nicer - need to get back and make some improvement I noted some time back to make sure the CORE use is clean and easy to copy/modify from the DEBUG - unique F&F message. Also need to put in a USB_Serial input parser - we could change stuff on the fly. Think I noted the DEBUG HACK drops usb output so much it will work when the FULL 12 value print kills the system at higher rates.
 
I will give it try next time I play with master/slave, but so far it looks like the issues have been resolved with the circular buffer. It was nice to see it working for the T3.5 setup's that I had.

Yep. DEBUG_HACK output was easier to see what was going on.
 
fyi, at 10ms both sides sending using debughack, since my last post, its still running with 0 misses!

10ms must be enough time for debughack to finish its processing :)
 
follow up, still rolling at 10ms two-way with 0 errors (debughack)
12:32PM —> 12:29AM still rolling along nicely (thats 12 hours!) :)
 
Last edited:
tonton81 said:
follow up, still rolling at 10ms two-way with 0 errors (debughack)
12:32PM —> 12:29AM still rolling along nicely (thats 12 hours!) :)
Click to expand...

That sounds Very Good and promising - good work! I really need to update my code and clean up the DEBUGHACK to be a stand alone F&F message type the Master can choose to select.

BTW: Since I have not touched my M:T_3.6 & S:T_3.1 for 5-6(?) days now ... It is still running! Not DEBUGHACK but F&F with REAL Output conversions at 2 ms ( 500/sec! ) with the 10/sec pinToggle!
I think I had 3 OT's at the start from uploading - it is now at 4 :: F&F (OT=4)micros() _time==55

If I get to the NEW IMPROVED code and it breaks - it won't be the Teensy's fault as the old code has completed in 5 days at least 216,000,000 F&F's and also 4,320,000 pinToggle's with perhaps 1 OverTime Event.

Note To self Update Example_Slave update F&F coding ** - in response to these MASTER F&F's:
55 == info.packetID :: Standard IMU_GPS to TViewer < Remove #ifdef DEBUGHACK >
56 == info.packetID :: COPY OF [Standard IMU_GPS to TViewer] - placeholder EXAMPLE for mods for alternate TViewer output
60 == info.packetID :: Current DEBUGHACK
61 == info.packetID :: Standard IMU_GPS to TViewer WITH ADDED __count++ value check and display to allow Slave code to track errors like the DEBUGHACK code does with Debug MASTER's __count++.

** Slave can code to respond to ANY or ALL of them - MASTER can compile to send one or more of them - or at runtime with USER_Serial input could change which is sent.
 
You must log in or register to reply here.
Back
Top