martinayotte
-
Posts
3892 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by martinayotte
-
-
Oh ! I missed looked the picture in first place : Is it a 12V written on the relay ?
If it is the case, then, 5V is not enough for it ...
(... and I would still use a MOSFET ...)
-
Then, I presume you won't have choice to add MOSFET to drive the IN pin.
-
Maybe I misunderstood something : does a separate LED, without board attached, is flashing or stays always On ?
When board is attached, does it own LED flashing or stays always On ?
-
So, if the LED is flashing/working, then you need to figure out if the relay board is Ok.
Did you tried the board alone by grounding the IN pin ?
if it work, do you have a multimeter to measure how much current it takes ?
if more than 10mA, maybe your need to add a MOSFET between GPIO and the IN pin.
-
I don't see any thing wrong with the setup.
Did you tried connecting an LED directly on PA10 without the relay board attached ?
-
@zador.blood.stained
Due to switch to 4.10 ? Ok ! I will take a look ...
EDIT : Oh ! I'm seeing some error in build process :
[ o.k. ] Checking git sources [ u-boot v2016.11 ] error: Unknown subcommand: get-url ... [ o.k. ] Checking git sources [ linux-sun8i-mainline orange-pi-4.9 ] error: Unknown subcommand: get-url ... [ o.k. ] Checking git sources [ sunxi-tools master ] error: Unknown subcommand: get-url
EDIT2 : Ok ! this was on my other workstation where git was older. No worries ...
EDIT3 : Zador ? I've started new build sunxi-dev/pine64 and don't see errors : ... [[[32ml[[0m][[[32mc[[0m] add_configfs_overlay_for_v4.7.x.patch [[[0;33m succeeded [[0m]
On which target did you faced issues ?
-
Then, to get your feet wet, google a bit about Device Tree, even for other kind of platforms, there is a lot of tutorial.
But, in the mean time, to get you started :
First, do a backup of your current DTB : cp /boot/dtb/board.dtb /boot/dtb/board.dtb-BACKUP
Decompile DTB into DTS :
dtc -I dtb -O dts -o board.dts /boot/dtb/board.dtb
Edit the board.dts to suit your need.
Recompile DTB from modified DTS :
dtc -I dts -O dtb -o /boot/dtb/board.dtb board.dts
Reboot your board.
-
Did you look into the DTS if all UART are enabled, because some are not by default, and still assigned as plain GPIO.
For that, you will need to decompile DTB into DTS, edit by changing their status "disabled" by "okay", and then recompile DTB.
-
-
Right, you don't need my DT overlay shown in the spoiler if you are not using spidev in userspace.
In fact, you just need to replace in the main DT the status "disabled" by "okay".
For accessing the SPI itself in kernel-space, I'm not fluent with that, but you can take a look at other drivers present in the mainline.
-
Good !
On my side, I've ordered yesterday a new one since I still have WiFi problems (flooding in dmesg) with my current one, suspecting hardware issue.
But "slow boat" will bring it only next month, at best in 3 weeks.
-
Right ! That is the lib to use for python, but internals C function can also be copied/pasted to any C program.
-
In Mainline, the devices are defined my Device-Tree loaded by the kernel.
There is plenty of docs/tutorial that you can find on Google about DT.
Some for different platforms, but it doesn't matter if it to read and learn about DT.
For PiZero specific case, the SPIs are already defined in DT, but not visible in userspace until you add an SPIDEV overlay like the following one.
The /dev/spidev0.0 will appear and could be used by python library orangepi_PC_gpio_pyH3.
The /dev/spidev1.0 won't appear unless you disable led_status and uart3 since they are sharing the same pins.
// Enable the spidev interface
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun8i-h3";
fragment@0 {
target-path = "/aliases";
__overlay__ {
/* Path to the SPI controller nodes */
spi0 = "/soc@01c00000/spi@01c68000";
spi1 = "/soc@01c00000/spi@01c69000";
};
};
fragment@1 {
target = <&spi0>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins_a>, <&spi0_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@0 {
compatible = "spidev";
reg = <0x0>;
spi-max-frequency = <1000000>;
};
};
};
fragment@2 {
target = <&spi1>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins_a>, <&spi1_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@0 {
compatible = "spidev";
reg = <0x0>;
spi-max-frequency = <1000000>;
};
};
};
}; -
Interesting ! And even less complex using FIFO than the full complex DMA one !
I will give it a try in my next build ...
-
@Zador,
Oh ! The SPI partioning was one thing I was looking at ealier. Thanks for pointing that to me, it will save time.
Yes, fixing the transfer size into the kernel was another thing I've explored, I was looking at that patch as a possibility :
-
Hi Zador,
Yes, this is exactly the manual method we are all currently using, but I wish to get rid of "flashrom".
First, because, if you remember, in my case, I add to patch flashrom to avoid SPI transaction bigger than 64 bytes.
Second, I wish to avoid flashing the whole 64Mbits (or even 128Mbits) when real SPL is much smaller, this will reduce flash time.
Third, SPIDev are not active by default, I'm using an DT overlay, so, I want to bundle the overlay inside a BASH script and do all the Flashing jobs with a single "flash-spl.sh" command.
-
I still don't get your morbid fascination with 2MB SPI NOR which still does nothing very useful in practise.
Maybe you didn't know yet, but more than a month ago, I've succeeded booting from USB drive by flashing this SPI NOR with a U-Boot-SPL.
Since then, Armbian build is providing such functionalities, only missing thing is a Tutorial+scripts for easy installation.
-
That maybe too late for design change.
Maybe Steven can start new project called "LitePlus"
EDIT : Note this was posted to reply to this post https://forum.armbian.com/index.php/topic/3230-random-sbc-discussion-moved-from-opi-zero-thread/
which has been moved.
-
Presence of SPI NOR gives you possibility to do just that. You must build SPI enabled U-Boot and burn it on SPI chip. Then you can boot from USB, network, etc. But 2 MB is far too litle to boot full OS. AFAIK there is no tutorial how to put U-Boot on chip.
Hi Jernej,
I've uploaded a u-boot into the SPI Flash, and working well with USB-Boot.
Network is another issue, problably because u-boot is unware of xr819, and neither the plain H3 eth0 (I was getting DHCP not responding, if I remember), I didn't investigate further.
SPI-Flash Tutorial ? Well, there are a lot of manual steps, first making sure you have a SPI floash solder properly (my early PiZero didn't have any), then loading my spidev overlay to get /dev/spidev, then get latest flashrom sources, edit the source to make sure it doesn't do any SPI transaction longer than 64 bits, compile it. Create flash.img of the size of the SPI Flash, then "dd" again on the same image to write /usr/lib/linux-u-boot-dev-orangepizero_5.24_armhf/u-boot-sunxi-with-spl.bin into it with "conv=notrunc" and write the resulting image into flash using modified flashrom.
Nothing automated yet ... Maybe scripts can be written here, maybe even avoid using flashrom and use pure Python script which will handle the DT overlay also ...
Lot of jobs in the pipeline.
-
2) No ! The other OPi were using RTL8189.
-
I've OPiPC/OPiPC+/OPiPlus2E/OPiLite/OPiOne/OPiZero/Pine64/OlimexA20Micro, all of them with Mainline (I'm not interested by Legacy).
-
@zador.blood.stained, in my case it was a self made build of Mainline.
With perseverance, I've just made another new build, use another sdcard, and it is now working again, but I'm crossing my fingers :
3 sdcard failed within the same week for this PiZero ? I can't believe it, especially that Kingston/Lexar should be so crappy !
Maybe this board still has something wrong ...
EDIT : %*!@%#^%^%&!! the fourth sdcard start doing the same again after a reboot !!!
-
In my case, after several issue, crappy cable, crappy sdcard, I got it working several times.
But unfortunately, I got back into troubles again, I presume my PiZero has hardware issue.
It is flooding the dmesg with the following lines :
[ 28.399502] xradio_wlan mmc1:0001:1: Failed to read control register. [ 28.443148] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! [ 28.449194] sunxi-mmc 1c10000.mmc: data error, sending stop command [ 28.455622] sunxi-mmc 1c10000.mmc: send stop command failed [ 28.461347] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! [ 28.467458] sunxi-mmc 1c10000.mmc: data error, sending stop command [ 28.473820] sunxi-mmc 1c10000.mmc: send stop command failed
Trying to SSH thru ETH, sometime take minutes to get to the prompt, probably due to flooding taking to much CPU.
So, I will forget about WiFi for now until I get another PiZero.
EDIT: In fact, even if xradio is commented in DT, the flooding still present, to get rid of it, I need to comment the whole mmc@01c10000.
-
PA10 is usually share for SPI1-CS1. I verified in Mainline, it is not define yet, so, therefore free for plain GPIO.
In Legacy, maybe it is not the case, so search for SPI1 stuff and remove it as CS1, it should then work.
Orange pi PC plus - Relay module
in Allwinner sunxi
Posted
I would rather try with a MOSFET, 2N7000 for example, because when IN pin is HIGH at 3V it maybe still enough to keep the opto-coupler conducting.
If you don't have a MOSFET in stock, you can use a NPN transistor (2N3904 or 2N2222 for example) with resistor on its base.
EDIT : Oh ! googling for schematics, I found some boards that has the IN reversed compared to other boards, like this one http://www.elecfreaks.com/store/images/product_images/Breakout/Relay/BK_SRD_03.jpg
(this one is reverse compre to previous : https://forums.unrealengine.com/attachment.php?attachmentid=119903&d=1480742998)
When I've asked you to try IN pin to ground, was it really to GND that works ? because the link I've post here is the reverse, it is required 5V on the IN pin.