Teensyduino 1.54 Beta #11

Status
Not open for further replies.
And ... thought a second INO would clean it up - and it does it the right SOURCE is started - the IDE would of course, given the Folder name matching.
For TSET it takes this having not '~' but the primary Sketch.ino like :: sketchcmd=ALL.ino

If it starts on the wrong one that is when I get:
Code: 
:\arduino-1.8.15\hardware\teensy\avr\cores\teensy4/FS.h:37:0: warning: "FILE_READ" redefined
 #define FILE_READ  0
 ^

Instead of second .CPP file > Twin INO's do compile as one and that eliminates the many other issues.
Will start with that to break them up.
 
defragster said:
So it seems ... but was looking for a way to move 900+ lines form the main.INO so they Setup and Loop would be apparent and the only changing thing needed for the various Media types.

So that was first thought ... seeing it is problematic I can go to a MONO file, But then wondering if any of this would e a problem for larger projects ... I suppose not as they won't have multiple media type randomly selected but rather known ...

Just wanted to know I wasn't missing something easy/generic for a CLASS * that would let this work.
Click to expand...

There is this https://docs.microsoft.com/en-us/cp...2,function m_func1. 4 Example. ... 5 See also but don't think it will be generic enough.

One of the nice things the way its set up now is that you see all the examples for the different storage media.

The other thing you can do is take all the case stuff and make it a function call in a separate file then in the loop and setup it may be cleaner.
 
mjs513 said:
There is this https://docs.microsoft.com/en-us/cp...2,function m_func1. 4 Example. ... 5 See also but don't think it will be generic enough.

One of the nice things the way its set up now is that you see all the examples for the different storage media.

The other thing you can do is take all the case stuff and make it a function call in a separate file then in the loop and setup it may be cleaner.
Click to expand...

If it isn't done soon - there is no way it will get into 1.54 ... so was looking for the clean way to make it more readable without risking breaking stuff trying to clean it up.

Thought for that was make separate INO that held setup() and loop() - though only setup() and constructor and such before that are unique.

Then the 900+ lines of detail would be in separate file, that could be ignored or examined.

With unique 'setup' then the other file would just be the same in all examples. And opening that sketch would be sure to work with no confusing sausage guts to look at or edit.

I seem to be buildable now with twin INO's.

If nothing else that allows unique edit for each Media type - hacking out the #ifdef overhead.

???

<EDIT> these hairy things:
Code: 
//#define TEST_RAM
//#define TEST_SPI
//#define TEST_QSPI
//#define TEST_SPI_NAND
//#define TEST_QSPI_NAND
//#define TEST_PROG
//#define TEST_MRAM
 
PaulStoffregen said:
I've added an example to the SD library, which tries to demonstrate how to access SdFat functions.

https://github.com/PaulStoffregen/SD/blob/Juse_Use_SdFat/examples/SdFat_Usage/SdFat_Usage.ino

We discussed SdFat integration back in November, but as far as I know, no single collection of examples exists to demonstrate how to use it.

Which other special SdFat features should this example demonstrate how to use?
Click to expand...

No ?? :: // Teensy 3.5 & 3.6 & 4.1 on-board: BUILTIN_SDCARD
> const int chipSelect = 10;

Common manipulation?
Maybe a open file "ThisDir.txt" for write {overwrite or delete if exist} and print the DIR data into the file? Open the file and read and show it matches the prior dir?
Could use ? : bool ls(print_t* pr, uint8_t flags = 0) {
 
TeensyWolf said:
There have been some updates to NativeEthernet, will these get rolled into the next beta or release?
Click to expand...

Yes. Pulled in the latest just now... that you mentioned it... ;)

If any other libraries need updates included, please let me know? Will probably package up beta12 tonight or early Wednesday.
 
PaulStoffregen said:
Look carefully at the 5 SD.sdfs.begin() examples. 2 are for SDIO, 3 are for SPI (using chipSelect).
Click to expand...

okay ... Looking 'more' carefully I see:
Code: 
  // Access the built in SD card on Teensy 3.5, 3.6, 4.1 using DMA (maybe faster)
  //ok = SD.sdfs.begin(SdioConfig(DMA_SDIO));
> would have caught my eye / Search with a note that the expected BUILTIN_SDCARD has a new method:
Code: 
  // Access the BUILTIN_SDCARD in SD card on Teensy 3.5, 3.6, 4.1 using DMA (maybe faster)
  //ok = SD.sdfs.begin(SdioConfig(DMA_SDIO));
 
PaulStoffregen said:
I've added an example to the SD library, which tries to demonstrate how to access SdFat functions.

https://github.com/PaulStoffregen/SD/blob/Juse_Use_SdFat/examples/SdFat_Usage/SdFat_Usage.ino

We discussed SdFat integration back in November, but as far as I know, no single collection of examples exists to demonstrate how to use it.

Which other special SdFat features should this example demonstrate how to use?
Click to expand...

Sort of a hard one to answer right now... As I don't remember some of the different things we used with the MTP and MSC integration and which parts have been integrated.

Some of the things I know we have used include things like, check for what type of format does the SD Card have...
Like: if (sdx[user_token].sdfs.fatType() == FAT_TYPE_FAT12) ...
Or:
Serial.println("\n**** dir of sd[0] ****");
sdx[0].sdfs.ls();


There were/are some packaging issues also associated with this, like we created our own sub-library PFsLib which is currently hosted within the the UsbMscFat library code. This code is based on SDFat FSLib, but with extensions, that help it work with Fat file systems hosted on Memory sticks or USB drives, like better partition support. But probably most of this needs to be delayed until hopefully next release.

Edit: Things like extend FS to support Create and Modify dates. SDFS already support this, or forked branches show this in MTP on windows... Also sketches can now query the dates from SDFS File objects...

With Dates/Times, there is then also some call back functions, such that sketches can properly have their files marked with appropriate dates and times.

Code: 
// Call back for file timestamps.  Only called for file create and sync(). needed by SDFat-beta
#include "TimeLib.h"
void dateTime(uint16_t* date, uint16_t* time, uint8_t* ms10)
{ *date = FS_DATE(year(), month(), day());
  *time = FS_TIME(hour(), minute(), second());
  *ms10 = second() & 1 ? 100 : 0;
}
 
defragster said:
If it isn't done soon - there is no way it will get into 1.54 ... so was looking for the clean way to make it more readable without risking breaking stuff trying to clean it up.
.....
<EDIT> these hairy things:
Code: 
//#define TEST_RAM
//#define TEST_SPI
//#define TEST_QSPI
//#define TEST_SPI_NAND
//#define TEST_QSPI_NAND
//#define TEST_PROG
//#define TEST_MRAM
Click to expand...

Kind of figured that but I can't think of anyway around using defines.
 
Since someone brought up MTP, it'd be great if the Teensyduino's experimental MTP support could be switched to a real Serial (per the MTP library's readme) rather than the emulated serial that comes with the earlier versions of Teensyduino.

Chip
 
KurtE said:
But probably most of this needs to be delayed until hopefully next release.
Click to expand...

Yup. At this point the only things to be done before 1.54 release are bug fixes & improving example code.

I'm going to package up 1.54-beta12 within the next 12 hours, and maybe a "final" beta in a couple days if we have more changes.

My goal is a final 1.54 release this weekend.


chipaudette said:
Since someone brought up MTP, it'd be great if the Teensyduino's experimental MTP support could be switched to a real Serial (per the MTP library's readme) rather than the emulated serial that comes with the earlier versions of Teensyduino.
Click to expand...

Absolutely no major changes like editing the USB types are possible at this late hour.

We're in the final few days before a stable release.
 
@Defragster - Please rename LFSintegrity and add comments at the top explaining in a new-user oriented way what it does and how to use it and why they might want to do that. It doesn't need to be on github - here is perfectly fine and I'll take care of those details. The code can remain in its current state for 1.54 release, but the name and comments are required. Now is your time to do this the way you want to see it done. If not, I will change it later this week and there won't be time to discuss.
 
PaulStoffregen said:
@Defragster - Please rename LFSintegrity and add comments at the top explaining in a new-user oriented way what it does and how to use it and why they might want to do that. It doesn't need to be on github - here is perfectly fine and I'll take care of those details. The code can remain in its current state for 1.54 release, but the name and comments are required. Now is your time to do this the way you want to see it done. If not, I will change it later this week and there won't be time to discuss.
Click to expand...

Cool, Started work but wasn't sure there would be another Beta in time. Might have it done by your morning ...

I was breaking it out into individual Media types - so given the wiring/soldering resources as we know to use - when correct it will work.

No Media specific #defines - multiple sketches as noted before. Then some of the details on cryptic prints and go away like printing 'RAM_DISK' on every line.

It was designed to allow a tool to do some of anything that seemed like it could lead to creating detecting breakage - so Jenga added stuff - and so much early verbose disabled over time as baby steps turned to walking then running ....

I was going to fill this out with media specific variation subsketches:
Code: 
T:\arduino-1.8.15\hardware\teensy\avr\libraries\[B][U]LittleFS\examples\Integrity[/U][/B]>dir /b
MRAMSPI
PSRAM
QSPI
RAM
SPI
 
Status
Not open for further replies.
Back
Top