Larry Bank

From my brief look at Cron scripts (I've never used them), it looks like it will just fire off events at fixed times. This means you'll need to dynamically adjust the script to follow the changing daylight times. This sounds like a lot more effort than just adding a light sensor. Is the time to develop the software really that much cheaper than adding a $2 sensor to each kiosk?

All of the ones I've been able to find on eBay and Aliexpress have the HD44780 paired with a simple I2C I/O expander. It just acts as a shift register and passes every write straight through to 8 data pins. The LCD can operate in 4-bit mode by sending a command of 2Xh - bit 4 sets the data bus width (see here https://learningmsp430.wordpress.com/2013/11/16/16x2-lcd-interfacing-in-4-bit-mode/). It allows having just the upper 4 data bits connected and the lower 4 bits from the I/O expander are used as control lines.

This may be useful to some of you. I wrote some C code to talk to those common 2x16 LCD displays that are available in various colors from various vendors. My purpose in writing the code was to learn about the device and help document it better for other people to have an easier time using it. In my search for info, I only found poorly documented Python and Arduino code, so I thought I would write a C version and make it easy to read. You can find the code here: https://github.com/bitbank2/LCD1602

How about start here: https://sunrise-sunset.org/api What tools have you tried? What worked/failed?

What kind of analysis are you doing on the images? Hopefully your code is multi-threaded and making use of SIMD

You still haven't shared enough info to help you decide how to proceed. Using composite video is fine, but do you want the user to interact with a mouse and manipulate a windowed GUI or would you prefer simple graphics without much of a UI. If you boot Linux without a desktop on the composite video out, you'll get a framebuffer with no OS support for drawing. This is easy to work with if you don't mind drawing everything explicitly with your own code. If you want a system with overlapping sizable windows and easy to use controls, then you'll probably want to use an X11 based desktop with GTK+.

It appears that the display you chose is supported by my SPI_LCD library. The refresh rate will be slow (at best maybe 9 FPS). I haven't seen any larger SPI LCD displays because the interface isn't fast enough to make them practical. The AllWinner SoCs max out at around 33Mhz as a functional SPI speed. At that speed, you need to divide it by 16 (bits per pixel) and then a bit more due to the command/data overhead of working with these displays. That makes it impractical to use SPI for a display larger than 320x480. As far as installing things, my SPI_LCD library is probably the easiest place to start. you would do the following to get it going: git clone https://github.com/bitbank2/SPI_LCD make make -f make_sample sudo ./lcd Before you build the library, you need to edit spi_lcd.c and uncomment the #USE_GENERIC and the board you're using (#USE_ORANGEPIZERO) and comment out the other choices. This will enable the correct pin->GPIO translation table for your board. Before you build the sample, you need to edit main.c and change the values in the spilcdInit() statement to work for your specific display type and the pins used to connect it. The correct SPI channel for RPI0 should be 1. The pin numbers for the D/C, RST and LED pins are dependent on how you connected the display to the board.

You say that you have the Orange Pi Zero, but it only has composite video out. What type of display will you use? SPI LCD? composite video? Once you specify that, I can help you with choices for how to do it. If you're using a Linux Desktop, you can use GTK+ to do the windowing and graphics. It has "low speed" pixel level access to the display. If you plan to do video/animation then you can make use of SDL2. Here is a simple project I wrote which displays the tags in TIFF files using GTK+: https://github.com/bitbank2/tifftool I've also written a "bare metal" library for drawing on RGB565 framebuffers (e.g. inexpensive LCD display): https://github.com/bitbank2/bbgfx More info once you clarify what you want to do

Not sure where you got that code from, but my ArmbianIO library seems to work correctly. Make sure the pin isn't enabled as a tty or the system will keep you from using the pin as a GPIO.

I just added some command line options for setting the collection period, csv filename and number of samples to collect. I also added timestamps to the samples.

This is a first pass at the project. The reason for recording the values every ten seconds is because I wanted to see the effect of the air conditioner and it only cycles for a couple of minutes (I live in Florida and the air conditioner runs 365 days a year). I will also add a time stamp to the CSV output when I get some time. I wanted to graph the air quality changes due to 3 bodies sleeping in the same room.

I just released the source code to a very simple weather monitoring app. I wrote it to run on my Orange Pi Zero and make use of a few environmental sensors (Bosch BME280 and AMS CCS811), along with a SSD1306 OLED. It records the data every ten seconds into a CSV text file. https://github.com/bitbank2/weather_mon It's just a simple idea that I had to monitor the conditions overnight in my kids' bedroom since our place doesn't heat/cool evenly.

Instead of trying to guess the lighting, why not measure it? Something like the MAX44009 light sensor can do the trick. It's simple to connect on I2C (4 wires total) and they're really cheap. https://www.ebay.com/itm/112194480319

A while back I wrote some simple C code to talk to those inexpensive little 128x64 OLED monochrome displays. I just added options to initialize the display in inverted and/or flipped 180 modes: https://github.com/bitbank2/oled_96

Some legacy kernel builds of Armbian were able to enable the usb OTG port to connect to devices and power the board. I haven't seen that work with a modern kernel. Looks like a hub may be the only solution for that board.

Thanks for letting me know. I'll read the docs and see how easy it is to swap out the sysfs for gpiod calls.

I know there are direct means to access GPIOs, but then I would need to write code unique to each CPU. If Armbian only supported AllWinner H3 devices, it would be an easy decision. For now, I think it's best to keep the code simpler and support all SoCs. I'm not sure where this project is headed. I don't have the time to turn it into a support-everything/do-everything library. I saw a need and I put together a simple solution. It would be great if this was given the "blessing" of Armbian and turned into a real community effort.

I just added support for callback interrupts to the GPIO pins. This is functionality exposed by the kernel GPIO driver. What I can't find is a way to set the pull-up / pull-down resistors of the pins. Does anyone know how to do that on Allwinner boards?

You need to build the library first (just run make). It will copy the .h and .a to the /usr/local directory

This is why I created the ArmbianIO project. As long as you're using a mainline kernel (4.1x), it should recognize your board and work. You can get it here: https://github.com/bitbank2/ArmbianIO

I just open-sourced some code to replace fbtft and fbcp. It uses dirty-tiles to try to minimize the writes to the SPI LCD and improve the framerate. I'm working with some of the guys at sudomod to get it working on Lakka builds too. You can download it here: https://github.com/bitbank2/BB-CP

Thanks for the info. I have no idea how to modify/integrate the driver changes into my setup. I can work around the issue for now (with a performance hit), but it's good to know it will eventually be resolved. Eventually I guess I need to build Armbian from source so that I can experiment with things like this.

Must it be H3? How about H5? For me, the best board for the money is the Orange Pi Zero Plus 2 H5. It's the fastest of the bunch and has on board HDMI and eMMC. If you want to start with the least expensive board and don't need HDMI out, then the Orange Pi Zero is a good choice ($7).

For a project, I need the Linux desktop to be set to 16 bits per pixel. I can't find any documentation about how to do this on the mainline kernel. Anyone?

I first noticed this on my Orange Pi Zero. The latest Armbian releases (4.13.x) have some kind of gap between bytes when transmitting over SPI. I have an SPI performance test built into my SPI_LCD code: https://github.com/bitbank2/SPI_LCD If you run the demo program, it measures how many frames per second it can write to an SPI-connected LCD. On older Armbian builds with kernel version 3.x, it would usually get 27-33FPS on the H2/H3 boards. With the mainline kernel builds and running the same code, I'm seeing 9-17FPS (depending on the board). The H5 doesn't seem to be affected (I'm using an Orange Pi Zero +2 H5 for testing also). Anyone else seeing this? Any simple solution? The people at FriendlyArm are also affected by this. I've been testing the NanoPi Duo using their 4.11 build and I get 3 FPS! The NanoPi Duo nightly build of Armbian gets 9 FPS on the same setup. I'm using SPI LCD displays for gaming and 30FPS gives a good experience, but 10 doesn't. Update: The NanoPi NEO running Armbian kernel 4.13.12 shows 28.5 FPS (which is normal/good). So, why does the OPZ and NanoPi-Duo show such slow throughput when they have the same CPU?