…I got it!
the line:
var settings = new SpiConnectionSettings(FEZReaper.GpioPin.Socket8.Pin5);
must be:
var settings = new SpiConnectionSettings(FEZReaper.GpioPin.Socket8.Pin6);
now it works!
…next question:
is there a way to pass the used board to the “Display” - Construktor so that I can use the same library for different boards (Reaper, Cerberus, Spider, etc) and different sockets?
…is no one able to answer?
The answer is yes you can. The driver was made for the BrainPad but you can completely change to for your needs.
I hoped to get an answer how.
As far as I found out there is no way to send the board and port to the constructor as parameter.
Or am I wrong??
You can use this if you want:
DisplayN18 is done.
1 Like
Thank you!
And here’s how to fish 
Look at the Using Constructors - C# Programming Guide | Microsoft Learn “Employee” class on this page. It has two constructors defined, one that takes only a salary, one that takes a salary and a number of weeks. You’d want to do the same; add a constructor that takes the needed objects like SPI channel and pins for CS, backlight, control etc.
sorry, it maybe that I am misunderstood. I would like to have a Constructor like this:
Display (FEZBoard board, FEZBoard.Port port)
so that I can make an instance like:
Display display = new Display (FEZReaper,port8)
Until now I found no way to do so. In my implementation and the ones I found here I always have to change the Display class if I want to change board and / or Port.
As with the Module the pins are fixed, there is no need to change the pins.
Why do you need to pass in the Board?
rule #1 code for restricted embedded devices should be as small as possible
We use different boards in different classrooms. At least it would be neccessary to change the Port (which would include the board).
For my pupils - as they are absolute beginners . it is too difficult to change this in the sourcecode of the display - class.
This is also true for endless parameters like:
GpioPin resetPin = GpioController.GetDefault().OpenPin(
GHIElectronics.TinyCLR.Pins.FEZReaper.GpioPin.Socket8.Pin3);
I could make a class for each board we use but not for the port.
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)