Click drivers from MBN

as we see now

mikrobus net was ahead of their time when it was released

and know seem was on of well organised idea and concept

MikroElektronika is the inventor of the MikroBus socket. We only made it available for C# users earlier than others.
“We” including Stephen, Niels and Justin, when he was not a Kiwi.

EDit: Sorry, I forgot Niels :frowning:

3 Likes

Also works great with Java and Android with SPI, I2C and bit banging :wink:

FYI, we have added the GNSS 4 Click and GNSS ZOE Click drivers.

The GPSUtilities assembly has been modified to handle NMEA sentences with empty fields. Indeed, some modules do not fill fields in case of invalid GPS data received, while others put some default values.

6 Likes

A new set of drivers has been added :

  • Altitude2 Click
  • Altitude3 Click
  • Ambient2 Click
  • Barometer Click
  • BMP280
  • BMP085
  • BMP180
  • BMP183
  • ButtonR Click
  • Environment Click
  • Illuminance Click
  • RTC3 Click
  • TempHum Click
  • TempHum2 Click
  • TempHum4 Click
  • TempHum6 Click
  • TempHum7 Click
  • TempHum8 Click
  • TempHum9 Click
  • TempHum10 Click
7 Likes

Minor update to the repo to comply with API changes in rc1 : UART drivers and CAN example have been updated.

4 Likes

Hi Bec_a_Fuel,

You don’t mind if we are going to take your tiny file system example to add to nuget library :))?

2 Likes

No problem. Go ahead !

1 Like

Btw, we’ve updated the repo with 5 new drivers (and sample code, of course) :

4 Likes

@Dat_Tran unique ID click might be the one you were going to test. It was added, thanks @Bec_a_Fuel

8 new drivers added to the repo :

Minor tweaks to the BMP280 driver as well.

5 Likes

Two drivers added :

The 7Seg driver will work with the three versions of this module : small, medium and large sizes of Led display.

5 Likes

This one is not really a “Click driver” but… it is a memory driver for the QSpi memory area of the chips that have one (i.e. SC20260) :wink:

It works either as standalone driver, to store values in the Qspi area, or it can be used with our TinyFileSystem driver to have a fast 16MB drive.

Standalone code :

private static readonly Byte[] Data = new Byte[3];

        public static void TestQspiMemory(Boolean eraseFirstBlock)
        {
            var qspi = new QspiMemory();

            if (eraseFirstBlock)
                qspi.EraseBlock(0, 1);

            Debug.WriteLine("Address 1 before : " + qspi.ReadByte(1));
            qspi.WriteByte(1, 124);
            Debug.WriteLine("Address 1 after : " + qspi.ReadByte(1));

            qspi.WriteData(10, new Byte[] { 110, 111, 112 }, 0, 3);
            qspi.ReadData(10, Data, 0, 3);
            Debug.WriteLine("Read 3 bytes starting @10 (should be 110, 111, 112) : " + Data[0] + ", " + Data[1] + ", " + Data[2]);
        }

Result :

Address 1 before : 0
Address 1 after : 124
Read 3 bytes starting @10 (should be 110, 111, 112) : 110, 111, 112

The same driver used by TinyFileSystem :

private static void TestTFS()
        {
            var _tfs = new TinyFileSystem(new QspiMemory());
            if (_tfs.CheckIfFormatted())
            {
                Debug.WriteLine("Filesystem OK. Mounting...");
                _tfs.Mount();
                Debug.WriteLine("Mounted. Now reading settings.dat file...");
                if (!_tfs.Exists("settings.dat"))
                    return;
                using (Stream fs = _tfs.Open("settings.dat", FileMode.Open))
                using (var rdr = new StreamReader(fs))
                {
                    System.String line;
                    while ((line = rdr.ReadLine()) != null)
                    {
                        Debug.WriteLine(line);
                    }
                }
                TinyFileSystem.DeviceStats stats = _tfs.GetStats();
                Debug.WriteLine($"Stats");
                Debug.WriteLine($"\tBytes free :\t{stats.BytesFree}");
                Debug.WriteLine($"\tBytes orphaned :\t{stats.BytesOrphaned}");
            }
            else
            {
                Debug.WriteLine("Formatting");
                _tfs.Format();
                Debug.WriteLine("Creating file");
                using (Stream fs = _tfs.Create("settings.dat"))
                {
                    using (var wr = new StreamWriter(fs))
                    {
                        wr.WriteLine("<settings>");
                        wr.WriteLine("InitialPosX=200");
                        wr.WriteLine("InitialPosY=150");
                        wr.WriteLine("</settings>");
                        wr.Flush();
                        fs.Flush();
                    }
                }
                Debug.WriteLine("FileCreated");
            }
        }

Result, after a first run that has formatted the file system :

Filesystem OK. Mounting…
Mounted. Now reading settings.dat file…
<settings>
InitialPosX=200
InitialPosY=150
</settings>
Stats
Bytes free : 16773120
Bytes orphaned : 3072

Be aware that formatting the TFS takes some time. I did not measure but that’s roughly around 30 seconds. This is expected.

3 Likes

Can you please send us your cluster, sector config, full project is the best :)). I remember it is longer than 1min when we tested.

Excerpt from our driver :

public override Int32 Capacity => 0x01000000;
public override Int32 PageSize => 0x100;
public override Int32 SectorSize => 0x1000;
public override Int32 BlockSize => 0x10000;

Result :

Formatting
Formatting done, seconds elapsed : 37.7617295
Creating file
FileCreated

By the way, TFS does not work correctly on your SC20260D dev board :open_mouth: TFS thinks it’s not formatted even right after formatting it.
It does however work on our RAM board, which is using SC20260E SOM. Weird…

What’s your email address, so that I can send a test project ?

if erase then write total 100ms a sector, 4096 sector will take 400 seconds. it may faster 100ms but 10ms is very fast, maybe that is why work not correct on yours.

any way, we will check. my config is page and sector size are same 4096. It is slow when format but we tried read write few file just fine.

Oh, when you use whole 16MB then our drive detect all chip and switch to erase chip instead of sector. Maybe that why faster We will check.

Timings to erase one sector and then fill it (4096 bytes) :

SC20260D dev board :

  • One sector erased, 27.6893 milliseconds elapsed
  • One complete sector written, 15.1688 milliseconds elapsed

RAM board (SC20260E SOM) :

  • One sector erased, 22.4835 milliseconds elapsed
  • One complete sector written, 15.2799 milliseconds elapsed

And I repeat : TFS IS working with QSPI on our board but not on yours, not the opposite.

I still don’t have your email address :wink:

dat.tran@gh…

sorry, I just read quickly and wondering why yours is only about 30 second ;)))

Email sent.

And indeed, EraseChip is only 32 ms, so way faster that erasing sectors or blocks one by one.

FYI, regarding the TFS/QSPI not working on SC20260D dev board, I have “rev B” on both PCB and SOM. If it matters.