Main Site Documentation

Gadgeteer Display N18


what do you mean?


do i really need to add reasons why code should be as small as possible ?

so what do they learn from the beginning ? may be it would make more sense to learn how it really works instead of using abstract classes

the forum’s are full of “developers” searching for “drivers” and unable to develop their own code


Why not something like Gadgeteer, create a Socket class that includes the SPI channel.


you can be sure that I know what to do.
But I am a fulltime teacher and we have pupils with very! different skills:

  • we do a first time contact with hard and software. We do this with Gadgeteer quite successful and I would like to continue this with TinyCLR and Gageteer hardware.
    They have 2 hours a week for one year - not more - and we want to give them simply an impression what programming of hardware means including the use of a modern programming language like C#. There is also a focus on interfacing. So there is very! few time to do this.That is why choosed Gadgeteer.
  • we do software development for other pupils with ARM - Controllers and C /C**: They have 6 hours a week for 3 years.
  • we do hardware development and board Layout:
  • we do programming for the Internet with HTML. Javascript, ect.
    I myself do computer-programming since 40 years. I did driver-programming for windows and Linux.
    But my time is limited and for the pupils I mentioned above we need something “out of the box” which is really easy to use.


btw. the pupils we teach with Gadgeteer are 16 to 17.
Programming is only a border theme in what they are learning.
the others are grown up fro 20 to 30.


From an abstraction perspective, I think you fundamentally need a constructor that takes the SPI port and the appropriate control pins as parameters. Think of this as the “base” requirement. Then, you can create additional constructors that at the end call that constructor, and this is where you’d define your “board” level view. But to do this, you would need to manage the mapping of boards and ports in your code - the Gadgeteer framework handles this via the board and socket definitions behind the scenes, and connections that you map in the graphical designer. You’d need to “own” the FezBoard enumeration that you show in your pseudo-code, and then call the constructor that passes in the needed SPI port and pins. Does that make a bit more sense for you?

Remember, what you’re trying to do is what Gadgeteer was designed to abstract away, which is why nobody has done this before


Thank you for your answer. It goes along the way I was thinking to be done.
My point is, that this should be done by GHI.
But I fear I have to do it myself or forget it.
To build this for all modules we have means quite a bit.
I’ll think about what I’ll do.


the Gadgeteer abstraction was quite powerful for this reason. The problem you’re now seeing is that it went from a research project with a great idea, that has many areas that benefit from it, to a commercial item that unfortunately didn’t take off in a way that allows vendors to support their commercial ROI.

It’d certainly be possible to do something that was a “framework” or skeleton for each driver you wanted to make universal for a gadgeteer-like experience. But given that there’s only a few community people currently looking at this, you may not get a great deal of assistance. Perhaps we can find someone who is good at architecting C# solutions to help guide a community framework for TinyCLR OS drivers to help abstract some of this? I certainly know I’m not capable of assisting, perhaps I can assist at a driver / integration level (but I suspect like many, I’m time poor for even my own projects)


as GHI stopped offering Gadgeteer boards modules I fear it is “riding a dead horse” to invest a lot of work in making the modules we have working the way we would like to have.
Nevertheless I am not finished thinking about this.


There’s a lot of us in the community who like the boards and modules (like me) and who have an investment in them (like me). Unlike you, most of us are not trying to support a full learning environment where it’d be nice to move to the newest platform, we have one off projects that we can probably handle the code changes for the underlying hardware change easily. Or alternatively, like me since I’m lazy and not that smart, I’d use Gadgeteer and 4.3 :slight_smile:


The problem we have with 4.3 is that there is no VS2017 Support. How to explain my pupils that they should learn Gadgeteer with VS2015 while they use VS2017 in other lessons.
I would have to explain to them that Gadgeteer is obsolete stuff. This would not increase their acceptance, I’m sure.


I am aiming to support Gadgeteer in VS 2017 ASAP


Very good news !


After quite a long time I decided to try TinyClr one more time with our Gadgeteer hardware.
So I updated everything and connected a DisplayN18 to a FEZReaper-Board.
I used Bauland’s libraries. Compiling was fine, download also but nothing happened besides the backlight went on. I tried both Connectors (Socket8 and Socket9)
I wrote to Bauland but as he has no Reaper-Board he could not help me. After looking a bit in his sources and the schematics I think that something with the SPI - Code in TinyCLR does not work properly. Or am I wrong?
Any suggestions?


It is possible. Have you checked what pins you have used for SPI and chip select? G80 is fully supported and it should work.


As I wrote I used Bauland’ library:
My code is:

      DisplayN18 display = new DisplayN18(resetPin: FEZReaper.GpioPin.Socket8.Pin3,
            backlightPin: FEZReaper.GpioPin.Socket8.Pin4,
            controlPin: FEZReaper.GpioPin.Socket8.Pin5,
            spiLine: FEZReaper.SpiBus.Socket8,
            chipSelectPin: FEZReaper.GpioPin.Socket8.Pin6);

This refers to Bauland’s library at:

    /// <param name="resetPin">Pin 3 of S Socket</param>
    /// <param name="backlightPin">Pin 4 of S Socket</param>
    /// <param name="controlPin">Pin 5 of S Socket</param>
    /// <param name="spiLine">Spi line of S Socket</param>
    /// <param name="chipSelectPin">Pin 6 of S Socket</param>
    public DisplayN18(int resetPin, int backlightPin, int controlPin, string spiLine, int chipSelectPin)
        _buffer1 = new byte[1];
        _buffer2 = new byte[2];
        _buffer4 = new byte[4];
        _clearBuffer = new byte[160 * 2 * 16];
        _characterBuffer1 = new byte[80];
        _characterBuffer2 = new byte[320];
        _characterBuffer4 = new byte[1280];

        _controlPin = GpioController.GetDefault().OpenPin(controlPin);
        _resetPin = GpioController.GetDefault().OpenPin(resetPin);
        _backlightPin = GpioController.GetDefault().OpenPin(backlightPin);

        _spi = SpiController.FromName(spiLine).GetDevice(new SpiConnectionSettings() {ChipSelectLine = chipSelectPin, ClockFrequency = 12000000, DataBitLength = 8, Mode = SpiMode.Mode0 });

As “spiLine” is covered in TinyClr where I don’t have the source, I can’t see wether the spi Lines are initialised correctly.


You can also take a look at our N18 driver


Finally, bug has been corrected: it is due to change of spi initialization.
NuGet package is updated to version 1.0.1 (it could take time to validate package).

I test it with Cerberus board, but if someone can test with Reaper (I don’t own one, shame on me :wink: ): bug must be same.


Now it works.
Thank you.