Options for FBSD support with LCD device - new project

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Options for FBSD support with LCD device - new project

Kaya Saman

Hi,


I am looking for a solution capable of running FreeBSD that I will be
able to add an LCD or OLED display to.


The project spec is fairly simple:

- Use an embedded SoC solution

- Fit inside a DIN enclosure eg.
https://eng.italtronic.com/products/embedded_box_en/

- Have an LCD or OLED display with or without keypad eg.
https://www.crystalfontz.com/product/cfa633rdiks-rs232-alphanumeric-lcd-display-16x2#undefined 



Currently I am thinking about an Odroid C1+ with a Crystalfontz display
as they are well supported by Lcdproc.

Already I have gone through:

https://wiki.freebsd.org/FreeBSD/arm/Odroid-C1

https://www.freebsd.org/platforms/arm.html

https://wiki.freebsd.org/FreeBSD/arm


but just wanted to see if anyone has any experience with this type of
setup or could offer some advice?


I guess connection to the LCD would be another question as the most
common two options would be GPIO or USB. In the case of GPIO is there a
way to simulate an serial connection or are there better supported
boards with serial or usb headers on them already?

There are LCD modules made specifically for these boards which do sit on
top of the GPIO however, do these work with Lcdproc?
http://www.lcdproc.org/hardware.php3


Thanks.


Kaya

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Michael Zhilin
Hi,

I'm not sure it's exact you're looking for, but here is link:
https://qiita.com/yamori813/items/ae66330ccbf6fe6bd5ab

Platform is MIPS32/Atheros. It has LCD and keypad.
Details: ask Hiroki Mori please.

Thanks!

On Mon, Mar 18, 2019 at 5:08 PM Kaya Saman <[hidden email]>
wrote:

>
> Hi,
>
>
> I am looking for a solution capable of running FreeBSD that I will be
> able to add an LCD or OLED display to.
>
>
> The project spec is fairly simple:
>
> - Use an embedded SoC solution
>
> - Fit inside a DIN enclosure eg.
> https://eng.italtronic.com/products/embedded_box_en/
>
> - Have an LCD or OLED display with or without keypad eg.
>
> https://www.crystalfontz.com/product/cfa633rdiks-rs232-alphanumeric-lcd-display-16x2#undefined
>
>
>
> Currently I am thinking about an Odroid C1+ with a Crystalfontz display
> as they are well supported by Lcdproc.
>
> Already I have gone through:
>
> https://wiki.freebsd.org/FreeBSD/arm/Odroid-C1
>
> https://www.freebsd.org/platforms/arm.html
>
> https://wiki.freebsd.org/FreeBSD/arm
>
>
> but just wanted to see if anyone has any experience with this type of
> setup or could offer some advice?
>
>
> I guess connection to the LCD would be another question as the most
> common two options would be GPIO or USB. In the case of GPIO is there a
> way to simulate an serial connection or are there better supported
> boards with serial or usb headers on them already?
>
> There are LCD modules made specifically for these boards which do sit on
> top of the GPIO however, do these work with Lcdproc?
> http://www.lcdproc.org/hardware.php3
>
>
> Thanks.
>
>
> Kaya
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Kaya Saman
Many thanks Michael!


I have also found this guide too:
https://www.rototron.info/lcdproc-tutorial-for-raspberry-pi/


It goes through the GPIO connection using a Raspberry Pi and a CF
HD44780 compatible display. This should also work in a similar fashion
with the Odroid.


Regards,


Kaya


On 3/18/19 2:41 PM, Michael Zhilin wrote:

> Hi,
>
> I'm not sure it's exact you're looking for, but here is link:
> https://qiita.com/yamori813/items/ae66330ccbf6fe6bd5ab
>
> Platform is MIPS32/Atheros. It has LCD and keypad.
> Details: ask Hiroki Mori please.
>
> Thanks!
>
> On Mon, Mar 18, 2019 at 5:08 PM Kaya Saman
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     Hi,
>
>
>     I am looking for a solution capable of running FreeBSD that I will be
>     able to add an LCD or OLED display to.
>
>
>     The project spec is fairly simple:
>
>     - Use an embedded SoC solution
>
>     - Fit inside a DIN enclosure eg.
>     https://eng.italtronic.com/products/embedded_box_en/
>
>     - Have an LCD or OLED display with or without keypad eg.
>     https://www.crystalfontz.com/product/cfa633rdiks-rs232-alphanumeric-lcd-display-16x2#undefined
>
>
>
>
>     Currently I am thinking about an Odroid C1+ with a Crystalfontz
>     display
>     as they are well supported by Lcdproc.
>
>     Already I have gone through:
>
>     https://wiki.freebsd.org/FreeBSD/arm/Odroid-C1
>
>     https://www.freebsd.org/platforms/arm.html
>
>     https://wiki.freebsd.org/FreeBSD/arm
>
>
>     but just wanted to see if anyone has any experience with this type of
>     setup or could offer some advice?
>
>
>     I guess connection to the LCD would be another question as the most
>     common two options would be GPIO or USB. In the case of GPIO is
>     there a
>     way to simulate an serial connection or are there better supported
>     boards with serial or usb headers on them already?
>
>     There are LCD modules made specifically for these boards which do
>     sit on
>     top of the GPIO however, do these work with Lcdproc?
>     http://www.lcdproc.org/hardware.php3
>
>
>     Thanks.
>
>
>     Kaya
>
>     _______________________________________________
>     [hidden email] <mailto:[hidden email]> mailing list
>     https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>     To unsubscribe, send any mail to
>     "[hidden email]
>     <mailto:[hidden email]>"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Ian Lepore-3
On Mon, 2019-03-18 at 15:56 +0000, Kaya Saman wrote:

> Many thanks Michael!
>
>
> I have also found this guide too:
> https://www.rototron.info/lcdproc-tutorial-for-raspberry-pi/
>
>
> It goes through the GPIO connection using a Raspberry Pi and a CF
> HD44780 compatible display. This should also work in a similar
> fashion
> with the Odroid.
>

Before you go too far down this path, you should probably be aware that
odroid isn't really supported on freebsd.  There was some initial work
done to support the original C1, but it was basically a drive-by commit
which hasn't been actively supported since then.

You should consider some well-supported board, something based on an
Allwinner or imx6 SOC would be a good candidate.

Gpio sounds like about the worst way to connect a display.  Something
based on i2c or SPI would be a much better choice.  Usually the so-
called "usb" solutions are really just forms of i2c or SPI being bit-
banged by an FTDI chip.  Not a horrible solution, but probably not
quite as efficient as native i2c or spi.

-- Ian


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Kaya Saman

On 3/18/19 4:07 PM, Ian Lepore wrote:

> On Mon, 2019-03-18 at 15:56 +0000, Kaya Saman wrote:
>> Many thanks Michael!
>>
>>
>> I have also found this guide too:
>> https://www.rototron.info/lcdproc-tutorial-for-raspberry-pi/
>>
>>
>> It goes through the GPIO connection using a Raspberry Pi and a CF
>> HD44780 compatible display. This should also work in a similar
>> fashion
>> with the Odroid.
>>
> Before you go too far down this path, you should probably be aware that
> odroid isn't really supported on freebsd.  There was some initial work
> done to support the original C1, but it was basically a drive-by commit
> which hasn't been actively supported since then.
>
> You should consider some well-supported board, something based on an
> Allwinner or imx6 SOC would be a good candidate.
>
> Gpio sounds like about the worst way to connect a display.  Something
> based on i2c or SPI would be a much better choice.  Usually the so-
> called "usb" solutions are really just forms of i2c or SPI being bit-
> banged by an FTDI chip.  Not a horrible solution, but probably not
> quite as efficient as native i2c or spi.
>
> -- Ian
>
>
That was great advise! Thanks Ian :-)


Looking at the FreeBSD support for these types of boards, it seems the
most common devices are either the Raspberry Pi family and the
Beagleboard Black and Green.


It looks like both Raspberry Pi 2B and the Beaglebone Black have good
support with FreeBSD and both offer SPI headers. I am not sure about the
state of the Pi3 as the information comes up with unknown.


I'm just reading through the wiki page for the BB Black:
https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack right now trying to
get a better understanding of things in general. It might be a good
option as it sounds fairly easy to deploy FBSD on it.


Regards,


Kaya


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Ian Lepore-3
On Mon, 2019-03-18 at 17:34 +0000, Kaya Saman wrote:

> On 3/18/19 4:07 PM, Ian Lepore wrote:
> > On Mon, 2019-03-18 at 15:56 +0000, Kaya Saman wrote:
> > > Many thanks Michael!
> > >
> > >
> > > I have also found this guide too:
> > > https://www.rototron.info/lcdproc-tutorial-for-raspberry-pi/
> > >
> > >
> > > It goes through the GPIO connection using a Raspberry Pi and a CF
> > > HD44780 compatible display. This should also work in a similar
> > > fashion
> > > with the Odroid.
> > >
> >
> > Before you go too far down this path, you should probably be aware
> > that
> > odroid isn't really supported on freebsd.  There was some initial
> > work
> > done to support the original C1, but it was basically a drive-by
> > commit
> > which hasn't been actively supported since then.
> >
> > You should consider some well-supported board, something based on
> > an
> > Allwinner or imx6 SOC would be a good candidate.
> >
> > Gpio sounds like about the worst way to connect a
> > display.  Something
> > based on i2c or SPI would be a much better choice.  Usually the so-
> > called "usb" solutions are really just forms of i2c or SPI being
> > bit-
> > banged by an FTDI chip.  Not a horrible solution, but probably not
> > quite as efficient as native i2c or spi.
> >
> > -- Ian
> >
> >
>
> That was great advise! Thanks Ian :-)
>
>
> Looking at the FreeBSD support for these types of boards, it seems
> the
> most common devices are either the Raspberry Pi family and the
> Beagleboard Black and Green.
>
>
> It looks like both Raspberry Pi 2B and the Beaglebone Black have
> good
> support with FreeBSD and both offer SPI headers. I am not sure about
> the
> state of the Pi3 as the information comes up with unknown.
>
>
> I'm just reading through the wiki page for the BB Black:
> https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack right now trying
> to
> get a better understanding of things in general. It might be a good
> option as it sounds fairly easy to deploy FBSD on it.
>
>
> Regards,
>
>
> Kaya
>

I would never recommend that anybody use any flavor of rpi for any
purpose at all.  The hardware sucks, and the support is minimal,
because all of us developers hate working on it (because it sucks so
much).

The BB isn't too bad, it's just ancient and crippled -- single core at
low clock speeds.

Really, an Allwinnner-based board is your best bet.  I'll let the
various users and supporters of the AW stuff recommend specific models
(I don't have any AW hardware, I have all I can do supporting imx6
these days).

The stuff you'll find on the wiki is mostly ancient news that hasn't
been updated in years.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Jedi Tek'Unum-2
I’ve been lurking here for some time. Long time (commercial) unix expert. Not much FBSD.

I’m running Linux right now on NanoPi NEO (Allwinner H3) and NEO 2 (Allwinner H5). Not because I love Linux (I don’t) but because it works out of the box including I2C. I’d really like to use FBSD on them. I hope that they will reach the same maturity as BB soon.

Perhaps I’m wrong but my impression following this list and searching around is that I2C and SPI are not “out of the box” with FBSD on these platforms.

I’m not all that familiar with FDT. I’d like to learn how to master it. If I understood it better I could probably bring anything I needed to life. BUT, that is back burner to actually completing the projects I’m trying to complete (where I just need I2C access from user land). I really need those things to just work out of the box for now - or have clear instructions on how to enable.

In short I can’t use FBSD yet because it doesn’t appear ready for these kinds of apps on these devices. I greatly appreciate all the effort that has and is going on to get there. If I had the knowledge I’d love to help, but I don’t currently.

Perhaps I’ve just not searched and read enough to find the jewel document that explains all the FDT magic in sufficient detail. By that I mean *current* FDT magic (which is another confusing aspect as things seem to be in flux).

Any advice on these matters greatly appreciated.


> On Mar 18, 2019, at 12:58 PM, Ian Lepore <[hidden email]> wrote:
> I would never recommend that anybody use any flavor of rpi for any
> purpose at all.  The hardware sucks, and the support is minimal,
> because all of us developers hate working on it (because it sucks so
> much).
>
> The BB isn't too bad, it's just ancient and crippled -- single core at
> low clock speeds.
>
> Really, an Allwinnner-based board is your best bet.  I'll let the
> various users and supporters of the AW stuff recommend specific models
> (I don't have any AW hardware, I have all I can do supporting imx6
> these days).
>
> The stuff you'll find on the wiki is mostly ancient news that hasn't
> been updated in years.
>
> -- Ian
>
> _______________________________________________
> [hidden email] <mailto:[hidden email]> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>
> To unsubscribe, send any mail to "[hidden email] <mailto:[hidden email]>"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Ian Lepore-3
On Mon, 2019-03-18 at 13:59 -0500, Jedi Tek'Unum wrote:

> I’ve been lurking here for some time. Long time (commercial) unix
> expert. Not much FBSD.
>
> I’m running Linux right now on NanoPi NEO (Allwinner H3) and NEO 2
> (Allwinner H5). Not because I love Linux (I don’t) but because it
> works out of the box including I2C. I’d really like to use FBSD on
> them. I hope that they will reach the same maturity as BB soon.
>
> Perhaps I’m wrong but my impression following this list and searching
> around is that I2C and SPI are not “out of the box” with FBSD on
> these platforms.
>
> I’m not all that familiar with FDT. I’d like to learn how to master
> it. If I understood it better I could probably bring anything I
> needed to life. BUT, that is back burner to actually completing the
> projects I’m trying to complete (where I just need I2C access from
> user land). I really need those things to just work out of the box
> for now - or have clear instructions on how to enable.
>
> In short I can’t use FBSD yet because it doesn’t appear ready for
> these kinds of apps on these devices. I greatly appreciate all the
> effort that has and is going on to get there. If I had the knowledge
> I’d love to help, but I don’t currently.
>
> Perhaps I’ve just not searched and read enough to find the jewel
> document that explains all the FDT magic in sufficient detail. By
> that I mean *current* FDT magic (which is another confusing aspect as
> things seem to be in flux).
>
> Any advice on these matters greatly appreciated.
>
>

I'm not sure what would give you that impression about i2c and spi.  I
belive they're well-supported on virtually every arm SOC we have any
support for at all (except maybe amlogic/odroid and exynos, both of
which are rapidly bitrootting from neglect).  We have command-line
tools to read and write data to i2c and spi devices from userland, as
well as programmatic interfaces using ioctl() for higher-performance
needs like a rasterized spi display.

I'm the person who does most of the i2c and spi driver work for all of
freebsd (not just arm), and it's something we use heavily in our
products at $work, so I tend to stay on top of it.

To enable i2c or spi on any given platform, you usually do have to
touch some FDT code along the way.  That's because almost always, the
pins used by i2c or spi can be used for other things as well, so the
default config (which we get by importing fdt source code from linux)
usually isn't set up to enable those devices.

To enable them you typically have to write and compile a small dts
overlay and set a variable in /boot/loader.conf to have that overlay
loaded at boot time.  None of that is hard, but there is quite a bit to
explain, more than I can do right here in this email in the middle of a
$work day.  I guess maybe I should write a wiki page for it.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Jedi Tek'Unum-2
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 Mar 18, 2019, at 2:13 PM, Ian Lepore <[hidden email]> wrote:
>
> On Mon, 2019-03-18 at 13:59 -0500, Jedi Tek'Unum wrote:
>> I’ve been lurking here for some time. Long time (commercial) unix
>> expert. Not much FBSD.
>>
>> I’m running Linux right now on NanoPi NEO (Allwinner H3) and NEO 2
>> (Allwinner H5). Not because I love Linux (I don’t) but because it
>> works out of the box including I2C. I’d really like to use FBSD on
>> them. I hope that they will reach the same maturity as BB soon.
>>
>> Perhaps I’m wrong but my impression following this list and searching
>> around is that I2C and SPI are not “out of the box” with FBSD on
>> these platforms.
>>
>> I’m not all that familiar with FDT. I’d like to learn how to master
>> it. If I understood it better I could probably bring anything I
>> needed to life. BUT, that is back burner to actually completing the
>> projects I’m trying to complete (where I just need I2C access from
>> user land). I really need those things to just work out of the box
>> for now - or have clear instructions on how to enable.
>>
>> In short I can’t use FBSD yet because it doesn’t appear ready for
>> these kinds of apps on these devices. I greatly appreciate all the
>> effort that has and is going on to get there. If I had the knowledge
>> I’d love to help, but I don’t currently.
>>
>> Perhaps I’ve just not searched and read enough to find the jewel
>> document that explains all the FDT magic in sufficient detail. By
>> that I mean *current* FDT magic (which is another confusing aspect as
>> things seem to be in flux).
>>
>> Any advice on these matters greatly appreciated.
>>
>>
>
> I'm not sure what would give you that impression about i2c and spi.  I
> belive they're well-supported on virtually every arm SOC we have any
> support for at all (except maybe amlogic/odroid and exynos, both of
> which are rapidly bitrootting from neglect).  We have command-line
> tools to read and write data to i2c and spi devices from userland, as
> well as programmatic interfaces using ioctl() for higher-performance
> needs like a rasterized spi display.
>
> I'm the person who does most of the i2c and spi driver work for all of
> freebsd (not just arm), and it's something we use heavily in our
> products at $work, so I tend to stay on top of it.
>
> To enable i2c or spi on any given platform, you usually do have to
> touch some FDT code along the way.  That's because almost always, the
> pins used by i2c or spi can be used for other things as well, so the
> default config (which we get by importing fdt source code from linux)
> usually isn't set up to enable those devices.
>
> To enable them you typically have to write and compile a small dts
> overlay and set a variable in /boot/loader.conf to have that overlay
> loaded at boot time.  None of that is hard, but there is quite a bit to
> explain, more than I can do right here in this email in the middle of a
> $work day.  I guess maybe I should write a wiki page for it.
>
> -- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Ian Lepore-3
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?

BTW, bottom-posting replies is the norm on freebsd mailing lists.

-- Ian


> > On Mar 18, 2019, at 2:13 PM, Ian Lepore <[hidden email]> wrote:
> >
> > On Mon, 2019-03-18 at 13:59 -0500, Jedi Tek'Unum wrote:
> > > I’ve been lurking here for some time. Long time (commercial) unix
> > > expert. Not much FBSD.
> > >
> > > I’m running Linux right now on NanoPi NEO (Allwinner H3) and NEO
> > > 2
> > > (Allwinner H5). Not because I love Linux (I don’t) but because it
> > > works out of the box including I2C. I’d really like to use FBSD
> > > on
> > > them. I hope that they will reach the same maturity as BB soon.
> > >
> > > Perhaps I’m wrong but my impression following this list and
> > > searching
> > > around is that I2C and SPI are not “out of the box” with FBSD on
> > > these platforms.
> > >
> > > I’m not all that familiar with FDT. I’d like to learn how to
> > > master
> > > it. If I understood it better I could probably bring anything I
> > > needed to life. BUT, that is back burner to actually completing
> > > the
> > > projects I’m trying to complete (where I just need I2C access
> > > from
> > > user land). I really need those things to just work out of the
> > > box
> > > for now - or have clear instructions on how to enable.
> > >
> > > In short I can’t use FBSD yet because it doesn’t appear ready for
> > > these kinds of apps on these devices. I greatly appreciate all
> > > the
> > > effort that has and is going on to get there. If I had the
> > > knowledge
> > > I’d love to help, but I don’t currently.
> > >
> > > Perhaps I’ve just not searched and read enough to find the jewel
> > > document that explains all the FDT magic in sufficient detail. By
> > > that I mean *current* FDT magic (which is another confusing
> > > aspect as
> > > things seem to be in flux).
> > >
> > > Any advice on these matters greatly appreciated.
> > >
> > >
> >
> > I'm not sure what would give you that impression about i2c and
> > spi.  I
> > belive they're well-supported on virtually every arm SOC we have
> > any
> > support for at all (except maybe amlogic/odroid and exynos, both of
> > which are rapidly bitrootting from neglect).  We have command-line
> > tools to read and write data to i2c and spi devices from userland,
> > as
> > well as programmatic interfaces using ioctl() for higher-
> > performance
> > needs like a rasterized spi display.
> >
> > I'm the person who does most of the i2c and spi driver work for all
> > of
> > freebsd (not just arm), and it's something we use heavily in our
> > products at $work, so I tend to stay on top of it.
> >
> > To enable i2c or spi on any given platform, you usually do have to
> > touch some FDT code along the way.  That's because almost always,
> > the
> > pins used by i2c or spi can be used for other things as well, so
> > the
> > default config (which we get by importing fdt source code from
> > linux)
> > usually isn't set up to enable those devices.
> >
> > To enable them you typically have to write and compile a small dts
> > overlay and set a variable in /boot/loader.conf to have that
> > overlay
> > loaded at boot time.  None of that is hard, but there is quite a
> > bit to
> > explain, more than I can do right here in this email in the middle
> > of a
> > $work day.  I guess maybe I should write a wiki page for it.
> >
> > -- Ian
>
>

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Kaya Saman
<snip>

>>> I'm not sure what would give you that impression about i2c and
>>> spi.  I
>>> belive they're well-supported on virtually every arm SOC we have
>>> any
>>> support for at all (except maybe amlogic/odroid and exynos, both of
>>> which are rapidly bitrootting from neglect).  We have command-line
>>> tools to read and write data to i2c and spi devices from userland,
>>> as
>>> well as programmatic interfaces using ioctl() for higher-
>>> performance
>>> needs like a rasterized spi display.
>>>
>>> I'm the person who does most of the i2c and spi driver work for all
>>> of
>>> freebsd (not just arm), and it's something we use heavily in our
>>> products at $work, so I tend to stay on top of it.
>>>
>>> To enable i2c or spi on any given platform, you usually do have to
>>> touch some FDT code along the way.  That's because almost always,
>>> the
>>> pins used by i2c or spi can be used for other things as well, so
>>> the
>>> default config (which we get by importing fdt source code from
>>> linux)
>>> usually isn't set up to enable those devices.
>>>
>>> To enable them you typically have to write and compile a small dts
>>> overlay and set a variable in /boot/loader.conf to have that
>>> overlay
>>> loaded at boot time.  None of that is hard, but there is quite a
>>> bit to
>>> explain, more than I can do right here in this email in the middle
>>> of a
>>> $work day.  I guess maybe I should write a wiki page for it.
>>>
>>> -- Ian
>>
Finding this thread: https://forum.pine64.org/showthread.php?tid=6232

It seems that there is an official image for pine64 platform:
http://ftp.freebsd.org/pub/FreeBSD/releases/arm64/aarch64/ISO-IMAGES/12.0/


Would anyone recommend the Pine64?

Also which model as there are several:
http://wiki.pine64.org/index.php/Main_Page#PINE64_Devices


I could go with A64 or H64, though I wonder if there is a mode basic
model out there? I don't need 4k or even HD graphics, or 'desktop'
related stuff. A serial console would be fine or even vga just as long
as the board is stable and robust and won't crash or hang often.


Regards,


Kaya


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Emmanuel Vadot-7
In reply to this post by Ian Lepore-3
On Mon, 18 Mar 2019 10:07:50 -0600
Ian Lepore <[hidden email]> wrote:

> On Mon, 2019-03-18 at 15:56 +0000, Kaya Saman wrote:
> > Many thanks Michael!
> >
> >
> > I have also found this guide too:
> > https://www.rototron.info/lcdproc-tutorial-for-raspberry-pi/
> >
> >
> > It goes through the GPIO connection using a Raspberry Pi and a CF
> > HD44780 compatible display. This should also work in a similar
> > fashion
> > with the Odroid.
> >
>
> Before you go too far down this path, you should probably be aware that
> odroid isn't really supported on freebsd.  There was some initial work
> done to support the original C1, but it was basically a drive-by commit
> which hasn't been actively supported since then.
>
> You should consider some well-supported board, something based on an
> Allwinner or imx6 SOC would be a good candidate.
>
> Gpio sounds like about the worst way to connect a display.  Something
> based on i2c or SPI would be a much better choice.  Usually the so-
> called "usb" solutions are really just forms of i2c or SPI being bit-
> banged by an FTDI chip.  Not a horrible solution, but probably not
> quite as efficient as native i2c or spi.

 For an hd44780 based display GPIO is easy and ok, also now (and
probably for the last 10-15 years) you can find modules using this
controller with an i2c/spi uC to talk to them more easily.

> -- Ian
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Emmanuel Vadot-7
In reply to this post by Kaya Saman
On Mon, 18 Mar 2019 20:57:28 +0000
Kaya Saman <[hidden email]> wrote:

> <snip>
>
> >>> I'm not sure what would give you that impression about i2c and
> >>> spi.  I
> >>> belive they're well-supported on virtually every arm SOC we have
> >>> any
> >>> support for at all (except maybe amlogic/odroid and exynos, both of
> >>> which are rapidly bitrootting from neglect).  We have command-line
> >>> tools to read and write data to i2c and spi devices from userland,
> >>> as
> >>> well as programmatic interfaces using ioctl() for higher-
> >>> performance
> >>> needs like a rasterized spi display.
> >>>
> >>> I'm the person who does most of the i2c and spi driver work for all
> >>> of
> >>> freebsd (not just arm), and it's something we use heavily in our
> >>> products at $work, so I tend to stay on top of it.
> >>>
> >>> To enable i2c or spi on any given platform, you usually do have to
> >>> touch some FDT code along the way.  That's because almost always,
> >>> the
> >>> pins used by i2c or spi can be used for other things as well, so
> >>> the
> >>> default config (which we get by importing fdt source code from
> >>> linux)
> >>> usually isn't set up to enable those devices.
> >>>
> >>> To enable them you typically have to write and compile a small dts
> >>> overlay and set a variable in /boot/loader.conf to have that
> >>> overlay
> >>> loaded at boot time.  None of that is hard, but there is quite a
> >>> bit to
> >>> explain, more than I can do right here in this email in the middle
> >>> of a
> >>> $work day.  I guess maybe I should write a wiki page for it.
> >>>
> >>> -- Ian
> >>
> Finding this thread: https://forum.pine64.org/showthread.php?tid=6232
>
> It seems that there is an official image for pine64 platform:
> http://ftp.freebsd.org/pub/FreeBSD/releases/arm64/aarch64/ISO-IMAGES/12.0/
>
>
> Would anyone recommend the Pine64?
>
> Also which model as there are several:
> http://wiki.pine64.org/index.php/Main_Page#PINE64_Devices
>
>
> I could go with A64 or H64, though I wonder if there is a mode basic
> model out there? I don't need 4k or even HD graphics, or 'desktop'
> related stuff. A serial console would be fine or even vga just as long
> as the board is stable and robust and won't crash or hang often.

 Go for the Pine64-LTS then, H6 (The SoC on Pine H64) isn't supported
right now. It should be easy to add support for it but I have no
hardware and no time for this now.
 

>
> Regards,
>
>
> Kaya
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Bernd Walter-4
In reply to this post by Kaya Saman
On Mon, Mar 18, 2019 at 08:57:28PM +0000, Kaya Saman wrote:

> <snip>
>
> >>>I'm not sure what would give you that impression about i2c and
> >>>spi.  I
> >>>belive they're well-supported on virtually every arm SOC we have
> >>>any
> >>>support for at all (except maybe amlogic/odroid and exynos, both of
> >>>which are rapidly bitrootting from neglect).  We have command-line
> >>>tools to read and write data to i2c and spi devices from userland,
> >>>as
> >>>well as programmatic interfaces using ioctl() for higher-
> >>>performance
> >>>needs like a rasterized spi display.
> >>>
> >>>I'm the person who does most of the i2c and spi driver work for all
> >>>of
> >>>freebsd (not just arm), and it's something we use heavily in our
> >>>products at $work, so I tend to stay on top of it.
> >>>
> >>>To enable i2c or spi on any given platform, you usually do have to
> >>>touch some FDT code along the way.  That's because almost always,
> >>>the
> >>>pins used by i2c or spi can be used for other things as well, so
> >>>the
> >>>default config (which we get by importing fdt source code from
> >>>linux)
> >>>usually isn't set up to enable those devices.
> >>>
> >>>To enable them you typically have to write and compile a small dts
> >>>overlay and set a variable in /boot/loader.conf to have that
> >>>overlay
> >>>loaded at boot time.  None of that is hard, but there is quite a
> >>>bit to
> >>>explain, more than I can do right here in this email in the middle
> >>>of a
> >>>$work day.  I guess maybe I should write a wiki page for it.
> >>>
> >>>-- Ian
> >>
> Finding this thread: https://forum.pine64.org/showthread.php?tid=6232
>
> It seems that there is an official image for pine64 platform:
> http://ftp.freebsd.org/pub/FreeBSD/releases/arm64/aarch64/ISO-IMAGES/12.0/
>
>
> Would anyone recommend the Pine64?
>
> Also which model as there are several:
> http://wiki.pine64.org/index.php/Main_Page#PINE64_Devices

The Pine64 is an excellent board, but so far I've only used it with serial
console.
The Pinebook, which is based on very similar hardware, however works nicely
with it's screen, but not done any X tests yet, only console.

If you want a smallscreen, which just works with FreeBSD then you should
try this one:
https://www.waveshare.com/3.5inch-HDMI-LCD.htm
I've tested it with FreeBSD in text mode.
The touchscreen is based on an XP2046 chip, which (AFAIK) we don't support,
but it shouldn't be difficult to write a driver for it.
It is an HDMI display and should work on other boards as well, but it is
mechanically designed to hook up to an Raspberry with a special HDMI
interconnect PCB.
I also had to define config.txt entries for many of their HDMI displays, which
is raspberry specific.
If you are located in Germany, you can buy it from me, I'm a distributor of
Waveshare.
That said, I can't suggest all of the Waveshare components for use with FreeBSD.
Especially the touchscreen support experience is mixed, some work out of the box
with wmt(4), some don't.

The SPI based displays work by running HDMI as dummy output in a specific
resolution and then regularily grab the fbdev data and push it the the SPI
display.
It should be possible to write software for that, maybe even in userland, but
getting the display initialisation right requires some research.
On the display module they use shift registers to the parallel data input of
the panel.
They also have XP2046 base touch chips.

> I could go with A64 or H64, though I wonder if there is a mode basic
> model out there? I don't need 4k or even HD graphics, or 'desktop'
> related stuff. A serial console would be fine or even vga just as long
> as the board is stable and robust and won't crash or hang often.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Mori Hiroki
In reply to this post by Kaya Saman


Hi

----- Original Message -----

>From: Kaya Saman <[hidden email]>
>To: Michael Zhilin <[hidden email]>; "[hidden email]" <[hidden email]>; Mori Hiroki <[hidden email]>
>Date: 2019/3/19, Tue 00:56
>Subject: Re: Options for FBSD support with LCD device - new project
>
>
>Many thanks Michael!
>
>
>I have also found this guide too: https://www.rototron.info/lcdproc-tutorial-for-raspberry-pi/
>
>
>It goes through the GPIO connection using a Raspberry Pi and a CF HD44780 compatible display. This should also work in a similar fashion with the Odroid.
>
>


My other solution for LCD is use FTDI USB module and HD44780.

Sorry only Japanese.


https://qiita.com/yamori813/items/bc2bebdf06517023e721

This is mruby and cairo library and libftdi.


I try only on mips.


Hiroki Mori


>
>Regards,
>
>
>Kaya
>
>
>On 3/18/19 2:41 PM, Michael Zhilin wrote:
>
>Hi,
>>
>>
>>I'm not sure it's exact you're looking for, but here is link:
>>https://qiita.com/yamori813/items/ae66330ccbf6fe6bd5ab
>>
>>
>>Platform is MIPS32/Atheros. It has LCD and keypad.
>>
>>Details: ask Hiroki Mori please.
>>
>>
>>Thanks!
>>
>>
>>On Mon, Mar 18, 2019 at 5:08 PM Kaya Saman <[hidden email]> wrote:
>>
>>
>>>Hi,
>>>
>>>
>>>I am looking for a solution capable of running FreeBSD that I
          will be

>>>able to add an LCD or OLED display to.
>>>
>>>
>>>The project spec is fairly simple:
>>>
>>>- Use an embedded SoC solution
>>>
>>>- Fit inside a DIN enclosure eg.
>>>https://eng.italtronic.com/products/embedded_box_en/
>>>
>>>- Have an LCD or OLED display with or without keypad eg.
>>>https://www.crystalfontz.com/product/cfa633rdiks-rs232-alphanumeric-lcd-display-16x2#undefined
>>>
>>>
>>>
>>>Currently I am thinking about an Odroid C1+ with a
          Crystalfontz display

>>>as they are well supported by Lcdproc.
>>>
>>>Already I have gone through:
>>>
>>>https://wiki.freebsd.org/FreeBSD/arm/Odroid-C1
>>>
>>>https://www.freebsd.org/platforms/arm.html
>>>
>>>https://wiki.freebsd.org/FreeBSD/arm
>>>
>>>
>>>but just wanted to see if anyone has any experience with this
          type of
>>>setup or could offer some advice?
>>>
>>>
>>>I guess connection to the LCD would be another question as the
          most
>>>common two options would be GPIO or USB. In the case of GPIO
          is there a
>>>way to simulate an serial connection or are there better
          supported
>>>boards with serial or usb headers on them already?
>>>
>>>There are LCD modules made specifically for these boards which
          do sit on

>>>top of the GPIO however, do these work with Lcdproc?
>>>http://www.lcdproc.org/hardware.php3
>>>
>>>
>>>Thanks.
>>>
>>>
>>>Kaya
>>>
>>>_______________________________________________
>>>[hidden email] mailing list
>>>https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>To unsubscribe, send any mail to "[hidden email]"
>>>
>
>

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Kaya Saman
In reply to this post by Bernd Walter-4

On 3/18/19 11:25 PM, Bernd Walter wrote:

> On Mon, Mar 18, 2019 at 08:57:28PM +0000, Kaya Saman wrote:
>> <snip>
>>
>>>>> I'm not sure what would give you that impression about i2c and
>>>>> spi.  I
>>>>> belive they're well-supported on virtually every arm SOC we have
>>>>> any
>>>>> support for at all (except maybe amlogic/odroid and exynos, both of
>>>>> which are rapidly bitrootting from neglect).  We have command-line
>>>>> tools to read and write data to i2c and spi devices from userland,
>>>>> as
>>>>> well as programmatic interfaces using ioctl() for higher-
>>>>> performance
>>>>> needs like a rasterized spi display.
>>>>>
>>>>> I'm the person who does most of the i2c and spi driver work for all
>>>>> of
>>>>> freebsd (not just arm), and it's something we use heavily in our
>>>>> products at $work, so I tend to stay on top of it.
>>>>>
>>>>> To enable i2c or spi on any given platform, you usually do have to
>>>>> touch some FDT code along the way.  That's because almost always,
>>>>> the
>>>>> pins used by i2c or spi can be used for other things as well, so
>>>>> the
>>>>> default config (which we get by importing fdt source code from
>>>>> linux)
>>>>> usually isn't set up to enable those devices.
>>>>>
>>>>> To enable them you typically have to write and compile a small dts
>>>>> overlay and set a variable in /boot/loader.conf to have that
>>>>> overlay
>>>>> loaded at boot time.  None of that is hard, but there is quite a
>>>>> bit to
>>>>> explain, more than I can do right here in this email in the middle
>>>>> of a
>>>>> $work day.  I guess maybe I should write a wiki page for it.
>>>>>
>>>>> -- Ian
>> Finding this thread: https://forum.pine64.org/showthread.php?tid=6232
>>
>> It seems that there is an official image for pine64 platform:
>> http://ftp.freebsd.org/pub/FreeBSD/releases/arm64/aarch64/ISO-IMAGES/12.0/
>>
>>
>> Would anyone recommend the Pine64?
>>
>> Also which model as there are several:
>> http://wiki.pine64.org/index.php/Main_Page#PINE64_Devices
> The Pine64 is an excellent board, but so far I've only used it with serial
> console.
> The Pinebook, which is based on very similar hardware, however works nicely
> with it's screen, but not done any X tests yet, only console.
>
> If you want a smallscreen, which just works with FreeBSD then you should
> try this one:
> https://www.waveshare.com/3.5inch-HDMI-LCD.htm
> I've tested it with FreeBSD in text mode.
> The touchscreen is based on an XP2046 chip, which (AFAIK) we don't support,
> but it shouldn't be difficult to write a driver for it.
> It is an HDMI display and should work on other boards as well, but it is
> mechanically designed to hook up to an Raspberry with a special HDMI
> interconnect PCB.
> I also had to define config.txt entries for many of their HDMI displays, which
> is raspberry specific.
> If you are located in Germany, you can buy it from me, I'm a distributor of
> Waveshare.
> That said, I can't suggest all of the Waveshare components for use with FreeBSD.
> Especially the touchscreen support experience is mixed, some work out of the box
> with wmt(4), some don't.
>
> The SPI based displays work by running HDMI as dummy output in a specific
> resolution and then regularily grab the fbdev data and push it the the SPI
> display.
> It should be possible to write software for that, maybe even in userland, but
> getting the display initialisation right requires some research.
> On the display module they use shift registers to the parallel data input of
> the panel.
> They also have XP2046 base touch chips.
>

That's fantastic! I will probably need the serial console more then the
HDMI display though I do want to add a character based LCD such the
Crystalfontz I referenced earlier in this thread as an example. Though
it looks like there are some alternatives on the site you mentioned too:
https://www.waveshare.com/product/modules/oleds-lcds.htm


So I think that your reply and Emmanuel's response have clarified things
a lot for me and the Pine64-LTS is the one to choose.


Looking through the RPi header documentation or the Pine64:
http://synfare.com/599N105E/hwdocs/pine64/index.html I should even be
able to add a DB9 connector for UART serial rs232c access for terminal
emulators like minicom,tip etc.


Now I just need to find a DIN NS35 enclosure for it (or make one) and
then I can begin my project :-) :-)


I'm getting excited now as this is going to be a lot of fun!


Thanks everyone for all the responses.


Kaya


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Kaya Saman
In reply to this post by Mori Hiroki

On 3/18/19 11:58 PM, Mori Hiroki wrote:

>
> Hi
>
> ----- Original Message -----
>> From: Kaya Saman <[hidden email]>
>> To: Michael Zhilin <[hidden email]>; "[hidden email]" <[hidden email]>; Mori Hiroki <[hidden email]>
>> Date: 2019/3/19, Tue 00:56
>> Subject: Re: Options for FBSD support with LCD device - new project
>>
>>
>> Many thanks Michael!
>>
>>
>> I have also found this guide too: https://www.rototron.info/lcdproc-tutorial-for-raspberry-pi/
>>
>>
>> It goes through the GPIO connection using a Raspberry Pi and a CF HD44780 compatible display. This should also work in a similar fashion with the Odroid.
>>
>>
>
> My other solution for LCD is use FTDI USB module and HD44780.
>
> Sorry only Japanese.
>
>
> https://qiita.com/yamori813/items/bc2bebdf06517023e721
>
> This is mruby and cairo library and libftdi.
>
>
> I try only on mips.
>
>
> Hiroki Mori
>
>
Thanks Hiroki-san!


There are many ways to connect an LCD display. Since now I know what
board I will go for; the Pine64-LTS, I will look at using the SPI
interface on the GPIO RPi header.


I have used quite a few displays on x86 hardware connected to USB or
Serial headers so it should be fine.


Best Regards,


Kaya

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Bernd Walter-4
In reply to this post by Kaya Saman
On Tue, Mar 19, 2019 at 12:01:22AM +0000, Kaya Saman wrote:

>
> On 3/18/19 11:25 PM, Bernd Walter wrote:
> >On Mon, Mar 18, 2019 at 08:57:28PM +0000, Kaya Saman wrote:
> >><snip>
> >>
> >>>>>I'm not sure what would give you that impression about i2c and
> >>>>>spi.  I
> >>>>>belive they're well-supported on virtually every arm SOC we have
> >>>>>any
> >>>>>support for at all (except maybe amlogic/odroid and exynos, both of
> >>>>>which are rapidly bitrootting from neglect).  We have command-line
> >>>>>tools to read and write data to i2c and spi devices from userland,
> >>>>>as
> >>>>>well as programmatic interfaces using ioctl() for higher-
> >>>>>performance
> >>>>>needs like a rasterized spi display.
> >>>>>
> >>>>>I'm the person who does most of the i2c and spi driver work for all
> >>>>>of
> >>>>>freebsd (not just arm), and it's something we use heavily in our
> >>>>>products at $work, so I tend to stay on top of it.
> >>>>>
> >>>>>To enable i2c or spi on any given platform, you usually do have to
> >>>>>touch some FDT code along the way.  That's because almost always,
> >>>>>the
> >>>>>pins used by i2c or spi can be used for other things as well, so
> >>>>>the
> >>>>>default config (which we get by importing fdt source code from
> >>>>>linux)
> >>>>>usually isn't set up to enable those devices.
> >>>>>
> >>>>>To enable them you typically have to write and compile a small dts
> >>>>>overlay and set a variable in /boot/loader.conf to have that
> >>>>>overlay
> >>>>>loaded at boot time.  None of that is hard, but there is quite a
> >>>>>bit to
> >>>>>explain, more than I can do right here in this email in the middle
> >>>>>of a
> >>>>>$work day.  I guess maybe I should write a wiki page for it.
> >>>>>
> >>>>>-- Ian
> >>Finding this thread: https://forum.pine64.org/showthread.php?tid=6232
> >>
> >>It seems that there is an official image for pine64 platform:
> >>http://ftp.freebsd.org/pub/FreeBSD/releases/arm64/aarch64/ISO-IMAGES/12.0/
> >>
> >>
> >>Would anyone recommend the Pine64?
> >>
> >>Also which model as there are several:
> >>http://wiki.pine64.org/index.php/Main_Page#PINE64_Devices
> >The Pine64 is an excellent board, but so far I've only used it with serial
> >console.
> >The Pinebook, which is based on very similar hardware, however works nicely
> >with it's screen, but not done any X tests yet, only console.
> >
> >If you want a smallscreen, which just works with FreeBSD then you should
> >try this one:
> >https://www.waveshare.com/3.5inch-HDMI-LCD.htm
> >I've tested it with FreeBSD in text mode.
> >The touchscreen is based on an XP2046 chip, which (AFAIK) we don't support,
> >but it shouldn't be difficult to write a driver for it.
> >It is an HDMI display and should work on other boards as well, but it is
> >mechanically designed to hook up to an Raspberry with a special HDMI
> >interconnect PCB.
> >I also had to define config.txt entries for many of their HDMI displays,
> >which
> >is raspberry specific.
> >If you are located in Germany, you can buy it from me, I'm a distributor of
> >Waveshare.
> >That said, I can't suggest all of the Waveshare components for use with
> >FreeBSD.
> >Especially the touchscreen support experience is mixed, some work out of
> >the box
> >with wmt(4), some don't.
> >
> >The SPI based displays work by running HDMI as dummy output in a specific
> >resolution and then regularily grab the fbdev data and push it the the SPI
> >display.
> >It should be possible to write software for that, maybe even in userland,
> >but
> >getting the display initialisation right requires some research.
> >On the display module they use shift registers to the parallel data input
> >of
> >the panel.
> >They also have XP2046 base touch chips.
> >
>
> That's fantastic! I will probably need the serial console more then the
> HDMI display though I do want to add a character based LCD such the
> Crystalfontz I referenced earlier in this thread as an example. Though
> it looks like there are some alternatives on the site you mentioned too:
> https://www.waveshare.com/product/modules/oleds-lcds.htm
>
>
> So I think that your reply and Emmanuel's response have clarified things
> a lot for me and the Pine64-LTS is the one to choose.
>
>
> Looking through the RPi header documentation or the Pine64:
> http://synfare.com/599N105E/hwdocs/pine64/index.html I should even be
> able to add a DB9 connector for UART serial rs232c access for terminal
> emulators like minicom,tip etc.

If you go for DB9, then don't forget that you need propper RS232 transceiver
to get the +- signals.
The console is 3.3V TTL only.
Also for the PINE64-LTS, the console is on the EXP connector, no idea if
the RPi compatible header has the same signals or not.

> Now I just need to find a DIN NS35 enclosure for it (or make one) and
> then I can begin my project :-) :-)
>
>
> I'm getting excited now as this is going to be a lot of fun!
>

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Daniel Braniss-2
In reply to this post by Ian Lepore-3


> On 18 Mar 2019, at 21:13, Ian Lepore <[hidden email]> wrote:
>
> On Mon, 2019-03-18 at 13:59 -0500, Jedi Tek'Unum wrote:
>> I’ve been lurking here for some time. Long time (commercial) unix
>> expert. Not much FBSD.
>>
>> I’m running Linux right now on NanoPi NEO (Allwinner H3) and NEO 2
>> (Allwinner H5). Not because I love Linux (I don’t) but because it
>> works out of the box including I2C. I’d really like to use FBSD on
>> them. I hope that they will reach the same maturity as BB soon.
>>
>> Perhaps I’m wrong but my impression following this list and searching
>> around is that I2C and SPI are not “out of the box” with FBSD on
>> these platforms.
>>
>> I’m not all that familiar with FDT. I’d like to learn how to master
>> it. If I understood it better I could probably bring anything I
>> needed to life. BUT, that is back burner to actually completing the
>> projects I’m trying to complete (where I just need I2C access from
>> user land). I really need those things to just work out of the box
>> for now - or have clear instructions on how to enable.
>>
>> In short I can’t use FBSD yet because it doesn’t appear ready for
>> these kinds of apps on these devices. I greatly appreciate all the
>> effort that has and is going on to get there. If I had the knowledge
>> I’d love to help, but I don’t currently.
>>
>> Perhaps I’ve just not searched and read enough to find the jewel
>> document that explains all the FDT magic in sufficient detail. By
>> that I mean *current* FDT magic (which is another confusing aspect as
>> things seem to be in flux).
>>
>> Any advice on these matters greatly appreciated.
>>
>>
>
> I'm not sure what would give you that impression about i2c and spi.  I
> belive they're well-supported on virtually every arm SOC we have any
> support for at all (except maybe amlogic/odroid and exynos, both of
> which are rapidly bitrootting from neglect).  We have command-line
> tools to read and write data to i2c and spi devices from userland, as
> well as programmatic interfaces using ioctl() for higher-performance
> needs like a rasterized spi display.
>
> I'm the person who does most of the i2c and spi driver work for all of
> freebsd (not just arm), and it's something we use heavily in our
> products at $work, so I tend to stay on top of it.

I have several allwinner SoC, mainly from FriendlyArm, and neither i2c or SPI work.
I have a hacked i2c that mostly works, but hangs sometimes :-), mainly
timing issues of which I have no idea how to fix.
I’m willing to help here but my knowledge of the twsi tends to zero.
hint hint …

cheers,
        danny

>
> To enable i2c or spi on any given platform, you usually do have to
> touch some FDT code along the way.  That's because almost always, the
> pins used by i2c or spi can be used for other things as well, so the
> default config (which we get by importing fdt source code from linux)
> usually isn't set up to enable those devices.
>
> To enable them you typically have to write and compile a small dts
> overlay and set a variable in /boot/loader.conf to have that overlay
> loaded at boot time.  None of that is hard, but there is quite a bit to
> explain, more than I can do right here in this email in the middle of a
> $work day.  I guess maybe I should write a wiki page for it.
>
> -- Ian
>
> _______________________________________________
> [hidden email] <mailto:[hidden email]> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>
> To unsubscribe, send any mail to "[hidden email] <mailto:[hidden email]>"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Jedi Tek'Unum-2
In reply to this post by Ian Lepore-3
On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> 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.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
1234