Search results for:

So that's the GFX HAT done and dusted!

Well, it's working on the bench, let's put it that way. It needs cleaning up and repackaging a bit.
Gordon is already working on a SN3218 module, which worked OK for me.
My PiGlow should also work immediately too, and the Display-o-tron backlight too, I don't see why not, I will have to try....
The other Espruino modules already exist: ST7565 for the LCD display and the CAP1188 for the touch pads and LEDs (it's actually a CAP1166, but it's near enough to see that that everything is configurable, settable and readable). So, at least for the GFX HAT, there's nothing really new here for Espruino.

Couple of points:

After I ordered a Pixl.js (from Pimoroni UK, still waiting), I noticed that the chip pins are 3.3V only, 5V is going to kill them, but that is the same as the Raspberry Pi. Then I noticed that the Arduino is fundamentally 5V, but there are '3.3V only' shields. I'm messing around with a Pico and raspberry HATs most of which have both 5V and 3.3V pins connected when on a Pi. The Pico has 5V tolerant pins. I'm wondering how many Arduino shields and raspberry pi HATs can be fully used with only 3.3V? I've had problems with other boards and level shifters in the past trying to make the sure that the supply voltage and the GPIO pins are correctly shifted at both ends.
Like allObjects mentioned in this thread, I'm not sure about this. I've personally got tons of HATs and pHATs which I'd like to use directly with Espruino, hence my messing around here. But, what was the thinking of going with a Arduino header layout for Pixl.js and then only at 3.3V? Are the GPIO pins on Arduino hardware working at 3.3V or do they need 5V logic to function?
I've seen the description of the shield power jumper on the pixl.js, does setting that to 5V and passing through the USB supply cause any issues with shields and the Pixl itself, or not?

I'm considering buying one of these boards to attach to the Pixl.js, to make adding HATs and pHATs neater without using a black hat hacker board. But I've already noticed that it doesn't have level shifting on all pins, just selected ones.

https://www.abelectronics.co.uk/p/66/arduino-uno-to-raspberry-pi-adapter

I'm no electrical expert, but I'm running the GFX HAT using only 3.3V with the Pico. This means I've connected both the 5V and 3.3V pins on the HAT to 3.3V from the Pico and it's all working as expected.
I suspect all the chips are quite happy electrically at 3.3V and the only reason to have 5V is for the oomph bling-bling RGB LEDs on the backlight. Yes the LEDs are slightly, and I mean only slightly dimmer, at 3.3V, I don't need to be blinded so it doesn't make any difference to me. Are the LEDs the only reason for needing 5V in this case? Or is the SN3218 taking the 3.3V and boosting it itself?

Please shout at mean if I've missed something somewhere in the above!

As a side-effect of not sitting directly over the Pi 3+ processor and using the lower voltage, the GFX HAT is not getting hot or even warm. When it's on the Pi and all the LEDs are on at full whack, it gets extremely hot, which seems to affect the LCD contrast after a couple of hours. I don't like this as I think it might be a design flaw, but I hope not.

Oh I see, you mean the hardware shutdown mode SDB on pin 24?
I didn't notice that in the datasheet before. It must be pulled high on the HAT.

It appears that you can use the software shutdown to make the LEDs flash, without manually setting them all off and then back to their current values or by enabling/disabling the LED outputs individually. The states of all the registers are kept during a 'shutdown', only the outputs are turned off. Just toggle register 0, bit 0, off and on regularly to make everything flash. That could simplify some code.

The interesting things you (unfortunately) find buried in datasheets!

Hi Gordon,

I've got it working... mainly after I realised I needed to connect 5V from the Pico to the GFX HAT to actually get the LEDs to light, doh!

This line seems to be from your project, it's not needed, I removed it, I'm not sure what it's supposed to do:

LED_PWR.set(); // LED on

So now I have the bling-bling RGB backlight on the GFX HAT working with Espruino. 18 LEDs in total, 6 RGB all individually controllable. What a coincidence that Pimoroni used 6 RGB LEDs for the HAT backlight with a SN3218 controller! ;)
I already knew that Pimoroni connected the RGB LEDs in a strange order, so I'll need some functions before calling setLeds to set the correct colour on the correct LED.

Now to attack the CAP1166 with Espruino for the touch pads and the white LEDs indicators.

Lo and behold, after about 5 minutes of wiring to a breadboard and a black hat hacker... the GFX HAT LCD is working!
Wired up as described on pinout.xyz to your example ST7565 Pico setup.
The setContrast seems to be a bit binary at the moment, it's completely off or completely on. That had me worried until I tried setting the contrast myself, and then I could actually see something.
EDIT: Methinks I'm doing something wrong with the setContrast and the resistor divider parameter, but I've got it going from very faint through to completely black which shows that it's working.

Hi Gordon,

Thanks for all the pointers. I'll have a look at the motor board and the Grove modules for more info on how you did it for Arduino shields.
I've got a Pimoroni GFX HAT and, as it's exactly the same display as on the Pixl, I thought I'd give that a try first, by wiring it up to my Pico. Like you wrote it should, in theory, just be a case of changing the relevant pin definitions to match how I wire it up. The fancy RGB backlights and the touch pads/LEDs on the GFX HAT can also be implemented in espruino, but first the LCD itself.

I'm interested in driving raspberry pi HATs , pHATs, and other accessories with Espruino.

The pixl.js has Arduino shield compatible headers (my pixl.js has just been ordered), but I was thinking I could do something similar with my Pico and my large collection of raspberry pi HATs.

pinout.xyz has lots of useful HAT pin and driver info and the hacker breakout boards should make it easy to connect everything properly.

Has anyone done something with directly connecting espruino and HATs? It's probably not exactly rocket science. The trick is obviously just getting all the right pins in all the right places at both ends and setting up module code correctly (and making sure not to put 5V and 3V3 in the wrong places!). I was thinking that I could reuse shared espruino code from other people if they've already connected successfully to particular HATs.

Many of the HATs have pretty standard sensors or chips to drive the relevant HAT hardware, some of these devices have already got espruino modules, so I'm surprised that I can't find anything about interfacing to them when they are built into HATs. Lots of them are just I2C devices which shouldn't be that complicated to get working. Of course the de facto way of interfacing on the Pi is to use python, so some conversion to espruino will be needed.

I've been looking around the Espruino forum and I can't find anyone else trying to do this. I might be looking in the wrong places?!
EDIT: I've now found some, but really not that much, info regarding using espruino with Arduino shields, so perhaps people are just working at the module level and the wiring is an exercise for the student?

Has anyone already done something similar with raspberry HATs? If so, please let me know.

Thanks for that Gordon. I can confirm it now, at least, builds! :))

Now to try that ILI9341 LCD on the F429 Discovery board... But maybe it's hard-wired 'incorrectly' for Espruino. For example, the display reset pin doesn't seem to be available through the F429 pins.

I'm having problems when trying to build Espruino for the STMF429 discovery board with:

STM32F429IDISCOVERY=1 RELEASE=1 make

Other builds, for example, for the Pico, work correctly.

The compilation fails because of #define STM32F429_F439xx not being found in STM32f4xx.h. I've tried forcing the #define STM32F429xx (for the STM32F429ZI) myself but it still won't build, as it still fails when compiling the adc and flash lib code (again probably due to incorrect #defines or a combination of #defines it doesn't like?).

I don't understand why these errors occur now and it apparently worked previously, unless recent builds have changed STM32 headers and something got broken in the process. I suspect various STM32 build headers have not been kept up to date or at least 'in sync' with each other.

I know it's not officially supported and there won't be any 'out of the box' USB or LCD features, but I'd at least like to play around with Espruino on the F429 over a terminal.

Maybe the LCD is too hard-wired on the discovery board, but it might be possible to get it to work (just maybe....) But first I'd need a working Espruino build!

Does anyone know how to fix the problem? Or which Espruino release I can use to get at least a successful build for the F429 (or even where there is a pre-built bin available for download)?

Success! At least I know I was on the right trail...
I rebuilt Espruino for my Pico with a socketserver send buffer and chunkSize of 2048 bytes instead of 64. Now my copy of the Espruino Reference HTML file takes about 3 minutes to load from the SD card and appear via the ESP8266 over wifi in the browser. Previously it took around 25 minutes for exactly the same file! ;))
I know I've sacrificed some precious Pico RAM 'just' for a transmit buffer, but the experiment was worth it to learn how to rebuild and very slightly modify Espruino for myself.
I'm just wondering if it's worth adding some optional parameters to the socket functions to point to user-defined buffers (and define their size) so that instead of using the small pre-defined buffer you could, depending on RAM constraints, the hardware modules and the application, define your own buffers.

Don't Panic! It's just an experiment following Gordon's ideas about what can be achieved with Espruino software together with his boards.
One client (me!) is requesting the html page and sensor data over my home wireless network. It was just to see what is possible, not a real solution.
In the real world just sending the sensor values (in JSON format for simplicity) from the Espruino Pico to a data 'hub' would be much, much more practical.
I was just worried about the overall speed, as something seems wrong.
As DrAzzy said, I was also wondering if it is a Espruino/ESP8266 bug or a feature regarding the very slow transfer rate. Which seems to me to be caused by a small Espruino internal buffer.

The default baud rate in this firmware is 115200 and my Pico serial is already set to that value.
I can really see each chunk 'ticking' into the page in the browser, unfortunately it really is that slow.
As I said the at.debug looks like everything is being handled as expected, and it clearly shows only 64 bytes are ever sent in each send by the ESP8266.

I've set up an http file server using code similar to the Internet (HTTP) examples.
I wanted to try serving large files direct from my Pico with a SD card module and an Olimex MOD-WIFI-ESP8266-DEV board attached. The idea was to try using the HTML+SVG code examples to make a nice 'shiny' user interface using only the Pico.
Note that I'm only using the 'normal' AT commands on the ESP8266, no IoT firmware functionality (at least not yet!).
It's all working, using the ESP8266WiFi_0v25 module. It's reading files from the SD card and then using pipe to serve the chunks of the files as an http server, but it's very, very slow. It's painful to watch each line of text appear in the browser (for example, a copy of the Espruino Reference HTML page takes something like 25 minutes or so to serve from the Pico!), but it eventually sends the whole page via the ESP8266 without reporting any errors.
I've had a look at the code and played around with the chunkSize until I noticed that the buffer in the socket code seems to be fixed at a maximum of 64 bytes. Anything more than 64 doesn't have any effect. Of course less than 64 means the sending of the file gets even slower, but at least I can see that changing the chunkSize on the pipe has an effect!
According to all the ESP8266 AT command documentation it should be able to transfer 2048 bytes of data in a single call which would be a much better chunkSize.
I don't think it's any kind of firmware problem, at least everything looks clean with the at.debug switched on. But it's worth a mention that I'm using the latest firmware for the Olimex MOD-WIFI-ESP8266-DEV (which has 2MB of flash memory on the board), I'm NOT using the 512KB firmware that is officially supported. AT+GMR returns "AT version:0.30.0.0(Jul 3 2015 19:35:49)"
Is there any quick way around the Espruino 64 byte 'limit' or, if I want to try getting better performance, do I have to bite the bullet and think about handling all the AT commands myself with my own larger data buffer?
Or, more likely, have I simply misunderstood how to correctly use pipe and the chunkSize option?!

SOLVED! It was mostly a "betwwen-the-ears" problem! ;)

I looked through the code until I found what I needed to know. The call to "wiringPiSetup" confirmed that the normal GPIO numbers should be used (I'm using sudo). I didn't want to risk blowing up any GPIO pins by putting buttons on output pins. However, after reading the code, it looks like the correct pin mode is always set for reads or writes, which probably means it's more difficult to blow up the pins.
Anyway, it works!

Original message is here, so you can still read about the "problem":

I've got Espruino compiled, built and running on the raspberry pi.
WiringPi is (obviously) installed and working too.
Before I go and do anything stupid with the GPIO pins I have a pretty basic question: How do I actually use Espruino and WiringPi together?
I'm looking for some simple example code that will turn raspberry pins on and off, or set pwm values. I've looked at the 433Mhz example and digitalPulse is used there. However, I'm still not sure about the actual pin names/numbers to use with the raspberry pi GPIO pins.
Simple examples would be greatly appreciated!