Options for FBSD support with LCD device - new project

[Jedi Tek'Unum]

On Mar 18, 2019, at 2:57 PM, Ian Lepore <ian at freebsd.org> wrote:
> 
> On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
>> My impression wasn’t that support wasn’t there - but “out of the box”
>> configuration wasn’t there. In comparison, I didn’t have to do
>> anything to get I2C enabled in the binary distribution of Linux that
>> comes through the manufacturer.
>> 
>> Its the enabling part that isn’t obvious to most people IMO.
>> 
>> Documentation/wiki is great. But even better would be all the
>> enabling overlays already in place and the entries in loader.conf
>> already there and commented out. It would be so much easier to go to
>> a “common place” (loader.conf), skim through the notes, find the
>> thing that one wants, and then just uncomment the referenced line!
>> (Or any other similarly easy method.)
>> 
>> 
>> For FBSD to get a better foothold in this space it needs to be better
>> documented. For example, the wiki for NEO2 <
>> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2> is a step-by-
>> step guide for how to acquire and configure Linux for it.
>> 
>> 
> 
> On one of my imx6 boards I have 5 SPI devices.  Each device can use 3
> or 4 different sets of pins for clock, data-in, and data-out.  Plus,
> each can use literally any number of whatever gpio pins they want as
> chip selects.  Even limiting the chipsels to a handfull, there would
> literally be thousands of possible combinations of devices and pin
> configurations, each one needing to be a separate overlay.
> 
> Maybe you have experience primarily with rpi or some similarly crippled
> devices that only offer one or two choices?

If memory serves correctly, there are only 2 I2C devices on the H3/H5 and the NanoPi NEO/2 implementations only externalize 1. There is only 1 SPI AFAIK.

I wouldn’t call that crippled. I chose this platform exactly because of its characteristics - small, fast, cheap. It fits the project I’m using it for perfectly. In fact, I can see uses for even smaller (see Giant Board <https://groboards.com/giant-board/>). I understand other projects may have different requirements and would drive one towards different solutions - and require more of the various interfaces. But they aren’t going to be typical of hobbyist projects.

Maybe I should pose the question in another way. What is the philosophy for choosing GPIO as default for all the pins? These boards have a very limited number of pins and my preference would be that the broadest range of interface types would be the default. There are 2 UARTs exposed so I would have picked 1 to be enabled by default. After that, with I2C and SPI enabled, there are still 6 GPIO available. For a tiny board like this that seems to be reasonable. If people have a need for slightly more GPIO then I would expect they would be the ones configuring overlays.

Apparently the developers of the Linux packages for these boards have chosen the diverse approach (“FriendlyCore” based on UbuntuCore Xenial).

IMHO, most “hobbyists” would prefer the diversity approach. I’m completely capable of becoming an expert in FBSD and this sort of configuration stuff yet it isn’t a priority for me - I just want to use it like any other hobbyist. The way things are now pushes this type of user away from FBSD.

If there is some philosophical perspective against the diversity approach then the next best thing is to have documentation that clearly and simply tells people how to enable the other functionality.

Finally, I think there is an opportunity to grow FBSD in the hobbyist world of these small products. We are past the point where people can have a real operating system running on systems at Arduino size and cost. Linux has been aggressively deployed there but I can say from experience that it ain’t pretty - I won’t say more as everyone reading this has a clear understanding of why that is.