Gadgeteer Display N18

@Kevin_Flint:
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.

@Kevin_Flint:
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.
1 Like

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

@Brett:
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)

@Brett:
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

3 Likes

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);
        _controlPin.SetDriveMode(GpioPinDriveMode.Output);
        _resetPin = GpioController.GetDefault().OpenPin(resetPin);
        _resetPin.SetDriveMode(GpioPinDriveMode.Output);
        _backlightPin = GpioController.GetDefault().OpenPin(backlightPin);
        _backlightPin.SetDriveMode(GpioPinDriveMode.Output);
        _backlightPin.Write(GpioPinValue.Low);

        _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 TinyCLR-Drivers/Sitronix/ST7735 at dev Ā· ghi-electronics/TinyCLR-Drivers Ā· GitHub

1 Like

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.

2 Likes

Perfect!
Now it works.
Thank you.