According to What are you using your uConsole for? - #33 by MHam68HC11 this post, apparently this breakout board should be plug and play to µConsole’s mainboard.
There’s however no orientation of FPC marked but no biggie, one site is covered in insulator.
Thing is that plugging it the one way there’s no voltage on 3v3 nor 5v pins, plugging the other way makes my R01 core rise in temperature in mere seconds xD
I’ve:
measured continuity between breakout pin1 and FPC pin1 - OK
same for pin 40
grounds are on pins 6, 9 and 14. They are connected on the board level
FPC is straight-through, meaning that without board connected pins 6,9 and 14 aren’t connecteded, with BB they are
Lemme ask: WTF. i need UART and i need it like yesterday xD
Despite my brutality against device, everything works (i’ve unplugged 18650s once core started to burn my fingertip).
I don’t have (spare) RPI with GPIOs to test if BB actually works, but this device is dead simple and i am positive it is working.
Let’s assume that @MHam68HC11 saw breakout board and assumed it “should work” without actual testing. What are my other options, is there ANY fpc2gpio BB which is positive for working with µConsole? I don’t feel like sketching and ordering custom PCB at JLCPCB just to have three RX,TX and GND broken out, come on xD
I have also been frustrated by this. I bought a similar board and FPC connector from Ali to test the UART, but no dice - I get 5V but not 3V3 on the breakout, and UART doesn’t seem to work either under Linux or by configuring it via baremetal (this is all on the D1-based RISC-V SoC).
I didn’t realise UART1 was routed to the Wifi module, but the schematics do confirm that this is the case, at least on the R1. Still, on baremetal I think I’m configuring the UART correctly so I still feel I should see output on the GPIO Tx/Rx even with the Wifi module at the other end, but I’m not very knowledgeable on the electronic side of things.
I may bite the bullet and roll a custom PCB to break out the extension pins to get access to UART0, but it’s a little frustrating that this is necessary. If it works, I’d be happy to send boards to people (would be from the UK).
I bought one of these as well, and I realized the numbering is reversed on my breakout board. Pin1 of the FPC is actually 40 on by breakout board.
That being said, it still ended up useless. There’s another thread I found here this weekend while working on my project that explains basically every single pin on that fpc already assigned and in use. I’ve tried repeatedly to get i2c to work on that port and no dice there either, I think they reassigned those pins…
I just need to find i2c and SPI inside the uconsole, I don’t much care where anymore…
yeah,i’ve seen your topic but lack of replies and lack of my own experience encouraged me to invest money in this BB.
Anyway, i’ve wrote mail to Alex linking to this topic. Hope he’ll come with some official solution, it’s not the matter of price but compatibility at this point.
If it works, I’d be happy to send boards to people (would be from the UK).
Shut up and take my money xD
I didn’t realise UART1 was routed to the Wifi module, but the schematics do confirm that this is the case, at least on the R1
Sure, some Wifi/bt chip pins are attached to GPIO14/15 (which are indeed labelled as UART0 on RPI) but i highly doubt that actual UART with earlyprinkt would have any sense being sent to communications device.
Keep in mind these are general purpose inputs/outputs, they can be configured as device achitect see it fits.
I am no expert at device trees, but i see some definitions in decompiled DTB taken from µSD’s /boot partition (µConsole R01 device tree source - Pastebin.com)
Serial0 is being referrenced in default (baked into hardware definition) stdout (line 44-46). On top it’s defined as an alias to actual uart device(line 12) and at line 344 you have probably actual hardware serial port 0 definition with pins 0x0e and 0x0f which correspond to 14 and 15. okay, i am lost
If i am not mistaken, according to device tree i’ve posted above (lines 1143-1161) and my mere understanding of it, you’re looking for GPIOs number 33, 34 and 35, there should be located SPI0. These are broken out on 4g connector on pins 24,26,28 respectively.
First I2C port is defined in lines 1206-1222, GPIOs 38 and 39. These also are broken out on expansion connector, pins 38 and 40
Would you mind checking this out?
This might explain discrepancies between your findings and my predictions.
Would you mind sharing somewhere on Pastebin your device tree?
I order to obtain one, go to /boot and look for *dtb file. Then, issue dtc /boot/$name-of-file.dtb -I dtb -O dts -o devicetree.source
we’ll dig your SPI outta there
dtc command is provided by device-tree-compiler package.
syntax differs much from mine, but according to first attached file, all SPI lines are disabled.
they surely can be enabled but i am too wimpy in terms of DTS understanding that writing new rule is way too much for me.
for now at least
I guess at this point you should treat your µConsole more like RPI than distinct device in fancy shell.
this dtcoverlay rings me a bell, and given that in “base DT” all spidevs are disabled makes perfect sense to enable them via overlaying another tree’s branch over “main”.
Go with raspi-config command or directly messing with /boot/config.txt
In the worst case scenario you’ll end up with µSD card that needs to be edited in some external device.
