Jump to content

Use GPIO on C2 with Mainline Kernel


nik-ii

Recommended Posts

OK, got K2 to cooperate as well, however apparently defining spidev in DT is frowned upon, there is a dmesg warning gripe about it.  Used SigRock Pulseview to investigate the quality of the sclk timing and... probably ought to stick to 500kHz, even if you might be able to push more.  The clock jitter is noticable.

Link to comment
Share on other sites

@sgjava so the SPI is not defined in the device tree on C1, but is probed later?  I'll perhaps look at that.  

 

No problem on working on this, these boards are supposed to push RPi compatability, so SPI would be an assumed function IMHO.  And maybe I have use for SPI as well, having a thing for ADC's...  :lol:

Link to comment
Share on other sites

@TonyMac32 Correct, check the C1 wiki https://wiki.odroid.com/odroid-c1/application_note/gpio/spi#c1 It might be a easier way to do SPI on the C2 and fall in line with how HardKernel does it.

 

I think between this and the networking being cleaned up it will be easier to use the C2 with Armbian. I'm actually using the C2 as a server and started using NodeMCUs for some device interfacing projects. Sometimes 4 cores and 2G RAM are overkill for simpler projects like my weather station (and NodeMCU is $3.59 delivered):

 

 

IMG_20180824_171841.jpg

Link to comment
Share on other sites

48 minutes ago, TonyMac32 said:

@sgjava I've put spidev with both chip-selects on the C2 and K2 in the expected spi0 position for the dev kernels.  We'll see about images here in a bit.  @Igor gets to make that call.  :thumbup:


https://github.com/armbian/build/commit/9af045538c690bf6256e459f5013b0a15c8228ec In a few hours from now ...

Link to comment
Share on other sites

exciting! i just bumped into this trying to port CircuitPython to odroid C2.

i2c exists and works, and no spidev even when i modprobe..

 

root@odroidc2:/home/pi# uname -a
Linux odroidc2 4.18.8-odroidc2 #244 SMP PREEMPT Tue Sep 18 18:33:22 CEST 2018 aarch64 GNU/Linux


do you know what release i need to look for, when this will be included - like what the release would be called/numbered? cause that would be way faster than bitbanging in python :)

 

also, somewhat relatedly, the onboard uart /dev/ttyS1 isn't working either, device exists but can't open it :/

root@odroidc2:/home/pi# cat uarttest.py
import serial

ser = serial.Serial('/dev/ttyS1')  # open serial port
print(ser.name)         # check which port was really used

ser.write(b'hello')     # write a string
ser.close()             # close port

running it ...

root@odroidc2:/home/pi# python3 uarttest.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/serial/serialposix.py", line 323, in _reconfigure_port
    orig_attr = termios.tcgetattr(self.fd)
termios.error: (5, 'Input/output error')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "uarttest.py", line 3, in <module>
    ser = serial.Serial('/dev/ttyS1')  # open serial port
  File "/usr/local/lib/python3.5/dist-packages/serial/serialutil.py", line 240, in __init__
    self.open()
  File "/usr/local/lib/python3.5/dist-packages/serial/serialposix.py", line 272, in open
    self._reconfigure_port(force_update=True)
  File "/usr/local/lib/python3.5/dist-packages/serial/serialposix.py", line 326, in _reconfigure_port
    raise SerialException("Could not configure port: {}".format(msg))
serial.serialutil.SerialException: Could not configure port: (5, 'Input/output error')

but all the documentation for this board says it should 'just work' with kernels 3.x - not sure if this also broke in 4.x

Edited by adafruit
Link to comment
Share on other sites

Howdy Adafruit,

 

   Kernel 4.18 does not have this implemented, it is a software SPI on these boards so limited speed. if you are working from the serial terminal you can use 4.19 now, the HDMI is a bit buggy at the moment:  https://dl.armbian.com/odroidc2/nightly/

 

On kernel 4.14+ Amlogic devices, the uart is ttyAML0. 

 

 

Link to comment
Share on other sites

hiya, bitbang SPI is just fine, as long as its a device. i think i'll wait till the kernel's in a downloadable image - hopefully soon :)

 

for the uart, there's ttyAML0, but that's attached to the console? its the 4 pin header at the edge called UART right?

pi@odroidc2:~$ dmesg | grep tty
[    0.000275] console [tty0] enabled
[    0.565504] c81004c0.serial: ttyAML0 at MMIO 0xc81004c0 (irq = 13, base_baud = 1500000) is a meson_uart
[    0.565540] console [ttyAML0] enabled

we want to access the uart on the 40 pin connector, e.g. the non-console UART

image.thumb.png.39e0433e104540e3fe815b8feabb6d2f.png

 

this documentation sorta implies its on ttyS1

https://wiki.odroid.com/odroid-c2/application_note/gpio/uart

and no other details :/

Link to comment
Share on other sites

11 minutes ago, adafruit said:

for the uart, there's ttyAML0, but that's attached to the console? its the 4 pin header at the edge called UART right?

Yes.  ttyAML0 is the console.  The Hardkernel documentation covers the really old 3.14 (now 3.16 I guess) kernel, it was different. 

 

Debian GNU/Linux 9 odroidc2 ttyAML0

odroidc2 login:

 

11 minutes ago, adafruit said:

i think i'll wait till the kernel's in a downloadable image

 

The downloads I linked are CLI images with buggy HDMI.  The spidev is a new feature for this and the NanoPi K2 (same SoC) with Armbian, I have not done much testing so far.  Using the uart that won't be an issue though.

 

Let me look at the gpio uart, it can be enabled of course, it's most likely just gpio at the moment.

 

 

Link to comment
Share on other sites

ooh ok didnt realize the image was a full image, thought you meant a kernel image

 

yeah i can't run the `gpio readall` program that would normally give me the MUX data so no idea what anything is set up as. serial might not be muxed right. all very mysteirous

 

Quote

pi@odroidc2:~$ sudo gpio readall
 +------+-----+----------+------+ Model  ODROID-N1 +------+----------+-----+------+
 | GPIO | wPi |   Name   | Mode | V | Physical | V | Mode |   Name   | wPi | GPIO |
 +------+-----+----------+------+---+----++----+---+------+----------+-----+------+
 |      |     |     3.0V |      |   |  1 || 2  |   |      | 5V       |     |      |
Bus error

 

Link to comment
Share on other sites

Hmm, The odroid-N1 is an RK3399 board, maybe that's what's killing the gpio library.  Or the header may be irrelevant, I honestly don't know.  :unsure:

 

The GPIO on the Amlogic devices is quite a bit different.  I don't vary from the stock device tree most of the time, so other than the spidev I added it will reflect (assuming I read the schematic correctly, and it in turn was correct)

 

image.thumb.png.b4be858eb0516ed79a05d37d816845f0.png

 

I've been meaning to do it for some time, but I'm just starting working on documenting some of the GPIO's and their various functions.  So, in the device tree if you enable UART A, you'd have the port you want.  Unfortunately my wizardry does not include device tree overlays yet, however this may be something that's ok out of the box if the vendor image has it configured.  (clarification:  I can make a static change to the device tree, however for these sorts of things dynamic changes via overlays is better)

 

It's also good to see @adafruit doesn't sleep either.  However, I will be going, back to paid work in 6 hours. :D

Link to comment
Share on other sites

I am willing to put in time on the overlays/etc, my lack of knowledge is how we specifically use the bootloader scripts to apply them. I am reading through the Allwinner example, but...

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

14 minutes ago, TonyMac32 said:

I am willing to put in time on the overlays/etc

I've just added the CONFIGFS patch for RunTime/UserSpace overlay loading, since "meson64-dev" is using Mainline, it was simply question of doing a copy of the patch ...

Building image currently, I will test in maybe 15 mins... Then, maybe write a little overlay for UART1 ...

 

Link to comment
Share on other sites

thanks folks - if y'all can help with getting the uart/spi emabled (sounds like its possible), we will do all the documentation so people can use the odroid c2 w/armbian with a wide variety of gpio/spi/uart/i2c devices including parts like DHT sensors, gps, servos, IR, etc. good for home automation, IoT, etc!

that will relieve ya'll from trying to do that kind of support.

Link to comment
Share on other sites

@adafruit I haven't tested it yet, but the odroid C2 client images have spidev set up for both chipselects in the RPi locations.

I got caught up in a lot last night and didn't get as far as I hoped, working on libre computer Tritium H3 first since it had an SD in it already (ok, lazy).

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

Hi guys,

 

just wanted to ask if the latest changes are in the build system already.

I will need no PWM this time when we go subsea, but SPI instead, and for different issues I worked so far with a C1+ and SPI (as I had to complete setup already using this).

So, it would be great to know if just a "compile your image" will work for SPI, and if not, how to get the necessary steps done.

 

Any help is appreciated.

 

@TonyMac32: if it helps, you can have one of my C2 as test setup. :)

 

So far, Michael

Link to comment
Share on other sites

Haha it is the two chipselects as found on RPi. To add another channel you could make an overlay for another set of GPIO, but all of them being software I don't know if that would be very helpful...

We could try compiling in the rt-preempt scheduler and see if you can boost the max frequency a bit, the jitter is noticeable even at 500 kHz... (Simple loopback)

Can you share what fpga you are using? I've been lazy, and my Ice40 is still sitting on my desk, not used...



Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

Hi Tony,

 

I use only Lattice FPGA nowadays, mainly XO2 series. Best price for a load of features, and no external EEPROM stuff to handle.

Don't use I2C for configuring, it is screwed up, and can brick the FPGA (had to manually fix all boards for our first subsea stuff to get SPI flashing working).

If you use SPI for configuring, forget about Lattice software, it is "just" writing some Flash rows (easy to handle even from an 8bit uC).

 

See picture, it features a XO2-1200 reading out an Hamamatsu C12880MA spectrometer by 14bit ADC and SPI (quite big PCB due to power supply with LDO and stepup converter, and level converter for 5V spectrometer signals). XO2-7000 is prefered if you need more BRAMs, the 1200 is available in a nice handsolderable small package (limited I/O, indeed).

For doing both user communication and flashing, you "just" have to wire SPI SCK, MOSI and MISO to dedicated sysConfig pins, and to normal I/Os in parallel (I always use my own VHDL SPI slave, not the macro one). Next, use CSN for flashing, and normal I/O for /CS in user mode. And don't forget the feature row, to enable SPI config. I use JTAG pins in dual use, so don't forget about JTAGEN.

spec.jpg

(Black box is a commercial spectrometer, as size comparison, it has unfortunately bad dark current values, so it is not suitable for long time exposure as we need it subsea - but silly enough it uses a XO3 FPGA :))

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines