Project: SPI_MSTransfer

yeah but if we fire the callback with the error flag, youll be able to handle it any way you want after, think about it :)

PLUS it can be done in 2-3 lines without rewriting code..

that way you can toss out the bad payload yourself in your callback
 
Okay, whatever works - I was using the PacketID as the error code? It could be one of a few for different error types : -1, -2 ,-3 ( a defined as non-user ID ). I currently reject anything pulled that is not #55.
 
like i said i could add another uint_t debug flag end of callback for error handling, so your packetid can be used for your own purposes :)
 
ill try to finish a 0_0_6 version today with those edits and the callback overload as well, dont have to do much to add the overloard since the generated error will be on slave end and i can still send the array to the callback specifying the error type as well, if any.
basically if the error response is 0, everything is good
and if it’s 1, then it was a CRC error, but it will stil give you the array anyways to handle it how you want
and 2 can be for something else and so on etc..

ill also have to add a callback queue limiter for the arrays from the master to the slave, if a user doesnt enable the callback it will limit the queues so it doesnt fill up the memory endlessly

actually, i might just limit the queues to 16 max as a safety
if a limit is reached, i wont block, ill just pop the front (oldest) queued array and push a new entry into the back. that way you will have a max of 16 newest items
 
if you want a count rate for errors i could add one too
itll be good idea to decide on the future of the callback implementation and what you want on it

in fact, just like i did for the async mqtt library when i made it transparent we could just assign a struct for the callback

example:

callback(uint16_t *buffer, uint16_t length, uint16_t packetID, AsyncMST properties);

this way you have potential to add future upgrades only to the struct itself
So currently the struct can have two item returns (internally) example
uint8_t error
uint32_t count


so in your callback, when it fires, you can just call:
properties.error which will return the error code
and properties.count for the total error count

you could even have the struct return other library details from internal settings as well this way....
 
I just posted my version on the other thread of the SPI_MSTransfer V_0.0.5 working very well. I posted with EXAMPLES MASTER and SLAVE that work together and that SLAVE works with the uNav-AHRS code as posted.

In that posted code I removed FASTLED and renamed assert() to SPI_assert().

I found why there was a '55' printing. I had an ELSE with two statements on one line and no {brackets} so the .printline( PacketID ) was indeed from SLAVE.
 
okay, upload your h/cpp for new reference point for additions, ill use that one, im still out for another half day of work


edit i reread your post ill get it later today and use it for the next feature additions
 
Last edited:
Good work Tony! Those changes using the SPI_MSTransfer passed on and the are working for mjs513 with his pair of T_3.5's!
 
sorry guys... lack of sleep and day/night work shifts while tweaking MST is quite alot :D

ill try to upload 0_0_6 later, it contains an additional struct in the callbacks

calling info.error in callback returns bool if crc error occured or not on the given array supplied by the callback
this leaves you to use packetID for your own needs
suggestion, should we move packetID into the struct as well and out of the overload?
you’d call info.packetID to access it, let me know
now if you’d ever add any struct data in the library the callbacks would be able to access it
makes it very easy to add more “details” to callback later on

tidied up and removed quite alot of for loops, more optimisation for processing
 
Last edited:
That sounds good! The other stuff is coming online for Don with SPI. I measured the 48 byte Transfer of the data for Slave processing to save about 10% from the Master workload. And it should otherwise improve development process as that Slave can then be dedicated to the PC USB port data monitoring.

As you saw - we are looking to try i2c_t3.h to replace Wire.h - when you support Wire is i2c_t3.h Teensy specific version okay?
 
yup ill use i2c t3 when i implement wire

ill remove the packetID in overload and drop it in the struct
makes the callback look cleaner
 
Serial.print("PacketID: "); Serial.println(info.packetID);

:)

so callbacks are now:

Code: 
void myCallback(uint16_t *buffer, uint16_t length, AsyncMST info) {}
 
Will give it a look. You could update to include i2c_t3 as it has more flexibility and can do Wire, Wire1, Wire2. It is Teensy specific - but so is the SPI Slave code - and perhaps other code?
 
yeah teensy specific better than avr specific :)

the ‘other’ code may work on other mcus (i think) but not tested, and no it wont compile for mega (woohoo) :)
wonder how far we can push the teensy4.0 spi bus registers :D
 
tonton81 - the posted version here should match yours - except updated Master/Slave : uNav-AHRS

It is now giving many errors for mjs513 - when I bumped my T_3.6 to F_CPU==240 and F_BUS==120 and set SPISettings(60000000 - I get mostly errors. I didn't try this before - but it seems the updated V_0.0.6 is making more errors?
 
Last edited:
If it helps - the SLAVE prints data like below when my Master is running at 60 MHz.

Question: Is there a way for the Slave to .print() on the Master?

While this is happening there are no packetID 55 messages coming in to process? Put in a check as follows and it never triggers - maybe I'm using it wrong? :
Code: 
			if ( 0 != info.error ) {
				Serial.print("Slv Rcv Err: "); Serial.println(info.error);
			}

This is seen on Slave USB while Master shows " ************** Packet resent ****************" - this would be from the gpio LED toggle:
34150 4 0 12
34150 4 0 12
34150 4 0 12
34150 4 0 3328
34150 4 0 3328
34150 4 0 3328
34150 4 0 3328
34066 4 34070 44324
34150 4 0 12
34150 4 0 12
34150 4 0 12
34150 4 0 3328
34150 4 0 3328
34150 4 0 3328
34150 4 0 12
34150 4 0 12
34150 4 0 12
34150 4 0 12
34150 4 0 3328
34150 4 0 3328
34150 4 0 3328
34150 4 0 3328
34150 4 0 12
34150 4 0 12
34150 4 0 12
34150 4 0 3328
34150 4 0 3328
34150 4 0 3328
34066 4 0 44324
Click to expand...
 
hmmm, ill look into it, in the mean time can you try this version
it seems the SPI bus transfers for send and receive are more unstable unless a delayMicroseconds(1) is before the transfers

View attachment SPI_MSTransfer 0_0_7.zip

this one seems more stable

1) Serialx.flush() was added
2) transfer uS delays introduced, adjustable by H file
3) fixed vector size entry typos
 
Last edited:
Morning tonton81, Since I was up and online I updated to your 0.0.7 version spin and it is working perfectly at 30Mhz. Thank you.

EDIT: That's with two T3.5's at 120Mhz and fastest compile.
 
great! :) thats good news

yeah for me i do my debug testing at stock speeds
I have it set at 30MHz SPISettings using T3.5 @ 120MHz and T3.6 at 180MHz, both IDEs show "Faster" for compile
 
Last edited:
Working on new constructor addition, what do you think?

Code: 
SPI_MSTransfer teensy_serial = SPI_MSTransfer("Serial", 43, &SPI2, 30000000);
SPI_MSTransfer teensy_serial2 = SPI_MSTransfer("Serial2", 43, &SPI2, 10000000);

you could assign different frequencies to differents ports and slaves

in this case Serial2 would be accessed at 10MHz and SerialUSB would be accessed at 30 MHz (for same slave)
in a multi-slave scenario, you could run the slaves at different clocks, so long range wiring would be possible to lower the frequency and not affect other slaves
as an example, we could set a default of 4MHz until overwritten:

Code: 
SPI_MSTransfer teensy_gpio = SPI_MSTransfer("Serial", 43, &SPI2, 30000000);
SPI_MSTransfer teensy_gpio2 = SPI_MSTransfer("Serial2", 43, &SPI2);

1st would set a specified bus speed, 2nd would default to 4MHz since none defined (we don't know 'other' user uses, so a basic low frequency can help, especially if they have wiring issues)

Also possibly adding debugging method as well:

teensy_gpio.debug(Serial);

Not calling this should suppress slave & master debugging if you run it at either end

well, for slave end it would be slave.debug(Serial)

for master, use any object call to it
 
Last edited:
You must log in or register to reply here.
Back
Top