Larry Bank
-
Posts
161 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Larry Bank
-
-
On 11/11/2018 at 10:51 AM, zeekoe said:
Thanks for this wonderful lib!
I attached a TSOP34838 to my Tinker Board, and am using ArmbianIO to decode the IR signals. At first in JAVA. This worked better than I thought. However to get the signal when it's done sending (and not ~87 ms later) I needed to change the C library. Apart from that, I think it's more stable under heavier load.
My initial try is here:
https://github.com/bitbank2/ArmbianIO/compare/master...zeekoe:master
@Larry Bank Is this a direction you'd like to go with the library, or do you like to keep it more light-weight? If it is, I can clean up stuff a bit. An option would be putting the variable timeout mechanism inside the callback, and the decoding mechanism outside.
Note that it currently supports at least one specific remote with 800/1600 microsecond codes and 90 ms wait time. I plan to extend it for another remote I have with 600/1200 microsecond codes. Both seem to be RC5 (-ish).
edit: aha, I knew I read about manual IR decoding for NEC codes somewhere, just didn't remember it was here and written by you
. Well, I took a slightly different approach, making use of the interrupt thingy and it seems to work reasonably reliable. Let me know what you think of it. But if you didn't go that way, perhaps I would need to move on to a hard-polling mechanism too, if I want perfect reception...
I'm glad you found it useful. Your additions look worthwhile. Please do a pull request and I'll merge it into the main branch.
I'm not sure about the bigger direction of ArmbianIO, but if it helps solve problems and more than 1 person finds it useful, then it should be added.
-
If you can't get that going, you can use my project as a starting point. Talking to the ADXL345 over I2C is extremely easy and writing your own code will allow you to have better control of it. Here's my code:
https://github.com/bitbank2/accelerometers
-
50 minutes ago, paul alting said:
I was just reading through Larry's thread on Armbian IO Proposal, and noticed you had some posts there as well.
But, there is no pin definition for any Olimex boards and wonder why not ?
The pin mappings in my ArmbianIO project exist because I own those boards. I just don't happen to own any Olimex boards. You're welcome to make a pin mapping table for your board(s) and do a pull request on Github. I'm happy to add contributions to the project. As Martin says, the AllWinner GPIO pins are numbered in a fixed pattern, so it's easy to create a pin mapping table from the schematic for your board.
-
8 hours ago, TonyMac32 said:
Small physical size + huge memory are not compatible. 512 will probably be tops for a tiny device.
For size I would look at the nanopi duo. It has audio out as well as 2 USB's on pin headers. And it's an Allwinner H2+ (quad core a7), should be able to handle some processing.
Pair it with https://www.adafruit.com/product/2377
by wiring it directly to a UART on the Duo to minimize size, and keeping it to something you'd be comfortable with. Unless: https://make.kosakalab.com/arduino/obaka/project-2/index_en.html
If you are adventurous you can also run a http://www.cypress.com/documentation/development-kitsboards/cy8ckit-043-psoc-4-m-series-prototyping-kit
I use the older one of these and the PSoC 5lp for work all the time, the software works quite well and the configurations are straight forward. I'd have made a hat with one by now if cypress had a linux development suite. ADC's make the Arduino look like trash.
@Larry Bank Any thoughts?
I agree with @TonyMac32. The NanoPi or Orange Pi boards are plenty of CPU power and memory to do what you need. Audio processing normally doesn't require much RAM nor CPU (relative to an ARM board). It's too challenging a task for an AVR or ESP32 although a Cortex-M may be able to do it. There is more audio latency on Linux than a purely embedded solution and it's worse on ARM than on x86 boards. Using the SDL audio system, you'll probably see 100-250ms of latency when generating real time audio and pushing it out of the HDMI or analog out. It's really hard to avoid on Linux. I'm not sure about the jitter. If you don't starve the CPU with your other tasks, the audio driver should be able to reliably output the samples.
If you don't need analog inputs, then you can probably avoid adding an Arduino AVR to the project. Touch buttons and a breath sensor can be implemented as digital devices, not analog.
-
I just released some new code on github to play animated GIF files directly on a Linux framebuffer or SPI LCD (using my SPI_LCD code). It doesn't have any 3rd party dependencies and can easily be made to run on systems with no operating system or file system. This is part of my imaging library that I've been working on for more than 20 years. I'm slowly releasing parts of it as open-source. This code was sliced out of a much larger project which supports a whole bunch of image formats.
https://github.com/bitbank2/gif_play
Comments/feedback welcome.
-
I retested with NanoPi's Linux distro and it has USB OTG and analog audio working by default.
-
Update: Everything working now. These issues are resolved:
1) Constant hangs were due to the cheap wifi adapter. It would hang the ssh session after 5-10 minutes of use. Switched to a better one and it now works reliably
2) GPIO didn't behave the same as other systems. I had to add lseek(handle, 0, SEEK_SET) before each read from a GPIO pin. I should have done it earlier, but other machines seem to work without needing that
3) Now I need to solder a 3.5mm socket onto the analog audio out to hear the output...
Here's a video of it in action:
https://photos.app.goo.gl/zLZS3Pw3iABCXVkK9
-
Today's project is trying to get my game emulator to run on the NanoPi NEO Core board. Lots of exposed I/O, but I'm getting random hangs and some odd behavior with the latest Armbian. In the photo is a ILI9342 (landscape version) 2.3" display and some ugly protoboards I created to allow reliable wiring + sockets for the Core board. I just updated my SPI_LCD project to include support for both the ILI9342 and the Core board's strange header: https://github.com/bitbank2/SPI_LCD
I had to wire the USB-A socket to the header because the OTG port is not properly enabled (in the available Armbian build). If I spent some time messing with it, there's probably a bunch of patches to get it working, but soldering 4 wires seemed like the quicker fix for me.
I'll keep you posted on my progress (if anyone is interested)
-
2 minutes ago, chwe said:
others (e.g. Mediatek) have dedicated IR-drivers..
It might be worth to look through some RK3288 based TV boxes to see how they solved it.. I never spend much attention to IR-stuff. You might look through ArmbianIO, I've in mind that @Larry Bank has done some IR-Stuff for boards witch have a IR receiver populated, so maybe this is also possible for the tinker, no clue cause never tested.
I created a NEC IR code receiver. It's really pretty simple. The IR receiver on These ARM SBCs is just a digital signal connected to a GPIO pin. I shared a demo program on GitHub here:
https://github.com/bitbank2/ir_receiver
-
Thanks for the response. I took the path of least resistance and tested it on a Raspberry Pi Zero. On that platform I can edit the /boot/config.txt to change the I2C speed. It maxes out at 400Khz no matter what value you give it. That's fast enough to do decent animation:
I wrote a blog post and shared the code on github:
http://bitbanksoftware.blogspot.com/2018/05/practical-animation-on-i2c-ssd1306.html
-
12 minutes ago, zador.blood.stained said:
You could try using an overlay to add a "clock-frequency" property to the I2C controller node: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
Sorry for being thick, but exactly what does that entail? Just adding a "param" line to armbianEnv.txt?
-
I'm porting this code and my OLED animation to Armbian. It runs rather slow at 100Khz I2C speed. Has anyone found a way to easily change the I2C speed on Mainline kernel Armbian without doing a custom build?
-
Are you able to use SPI_LCD + BB-CP in place of fbtft+fbcp?
-
I wrote a blog post about speeding up drawing on the SSD1306 display by bit-banging the I2C protocol. The code is for Arduino, but it has useful info about my iterative process of optimizing code that some of you may find interesting:
https://bitbanksoftware.blogspot.com/2018/05/fast-ssd1306-oled-drawing-with-i2c-bit.html
-
Now I'm confused. Are you using SPI_LCD + BB-CP or fbtft + fbcp?
-
I like your idea, but think it might be easier to make a separate document; people tend to just run make and not look any further. It might be better to add a parameter to the make to specify the board name and then it will print a quick message about the pin numbering.
To connect multiple SPI displays is not a problem. What and how do you want to display information on them? My SPI_LCD library allows you to write code which draws directly on the display. Having multiple virtual framebuffers would probably cause some performance issues for the board.
-
Glad you got it working. If you have a suggestion to make the documentation clearer for my library, please let me know.
-
7 minutes ago, TonyMac32 said:
I build small test boxes for my company's products, sometimes for the end customer for field debugging. Visibility in sunlight is important, and the newer devices have complex enough output that graphical representation is handy to have. For the customer/field tech ones I try to keep the cost minimal, as they get destroyed a lot or handed out for free. I usually use Cypress PSoC controllers for the testers, but that's becoming less practical as well, so a move to a NanoPi duo or core may be in the future. (10 years ago the "debugger" only had to be a battery and LED...
Sent from my Pixel using Tapatalk
Thanks for sharing.
-
18 hours ago, TonyMac32 said:
Aliexpress? I have uses for these at that price...
If you don't mind, can you share what you would like do with them? I haven't figured out a specific use yet.
-
Yes, I got them on AliExpress. The vendor took them down after I bought them, but said he is re-organizing his store and will have it ready on May 5th (not sure if that means he'll re-list the product).
I've written a Linux and Arduino library to control it:
https://github.com/bitbank2/hx1230
The challenge with this display is that the PCB/controller is configured only for a 3-wire SPI interface and doesn't work with standard SPI. I wrote code to "bit-bang" the SPI interface for both Linux and Arduino. The nice thing about it is that for pin-limited chips like the ATtiny85, you can control this with 3 pins.
-
Does anyone know how to do this with the "modern" kernel in the armbianEnv.txt file?
-
I just received a couple of these inexpensive LCD displays ($1.82 each shipped). They are very low power and look good. I've got them working on Arduino and will now be converting the code to Linux. If anyone is interested in these, let me know. I'll edit this post to add the github link when it's ready.
-
1 hour ago, @lex said:
pin: 7 for LCD_RESET (that i suppose is your lcd)
pin 11 for LED_EN (that i suppose is your led)
pin 22 for LCD_D/C (that i suppose is your dc)
Taken from the http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2
and here base on the Matrix-2'8_SPI_Key_TFT-1706, but the LCD is without Touch.
Let's chat about this tomorrow; it's going to take too long to resolve like this. You can reach me on direct message through Twitter (@bitbank).
A couple of things to make wiring easier;
1) You don't need to connect the MISO line
2) You can tie the LED line to 3.3V
3) You can tie the CS line to GND
The rest of your wiring looks fine unless there's a conflict with 22 (UART2 enabled)
Did you select the NanoPi NEO GPIO table in spi_lcd.c before you compiled it?
-
How did you wire LED/DC/RESET? The numbers you feed to SPI_LCD are the header pin numbers, not BCM/WiringPI numbers.
Small monochrome displays
in Reviews, Tutorials, Hardware hacks
Posted
Thanks for letting me know. I really dislike that particular display. The frame/contacts are always flaky. For those applications, my preferred screen is the HX1230 (96x68) or the 128x64 LCD under various names.