funcctional Block Diagram
Hi,
I do have a MT7620 Board, and want to use RGMII port, on the datasheet comes with board, it shows me a diagram like what I post. the red circle area. shows that somehow the RGMII comes in to the switch port which by my understanding is the LAN port on the board.
my question is how I can enable the RGMII, and connect it with my device(which port on the board I should connect). Is it a auto config or I need to do something for it(eg, DTS).
I am new to this, so please answer more detail. and If I make anything not clear, ask. Thanks
Has been days, but no one come to answer, just post what I found for my question.
I borrow some machine from lab so that I can check the signal on board. I connect the board to internet and my laptop on the other side. and open a video page on browser. so that there will be some data flow between board and my laptop.
I use the machine to check the pins on the board which the circuit map shows belong to RGMII. but there is nothing, no signal comes up. which means the RGMII pins doesn't work by default.
So I assume that I need to edit some DTS to enable the RGMII signal. But I have no idea how to do this now. If anyone knows it. Please write it down. Thanks.
I am not sure of the specific board you are using , but yes the RGMII pins have to configured. If connecting a PHY to a microcontroller, you need to specify the negotiation speed for the TX and RX clock, along with other data pins. Something similar to this -
const IfxGeth_Eth_RgmiiPins Rgmiipins = {
//Set the reference clock
.txClk = &IfxGeth_TXCLK_P11_4_OUT ,
.txd0 = &IfxGeth_TXD0_P11_3_OUT ,
.txd1 = &IfxGeth_TXD1_P11_2_OUT ,
.txd2 = &IfxGeth_TXD2_P11_1_OUT ,
.txd3 = &IfxGeth_TXD3_P11_0_OUT ,
.txCtl = &IfxGeth_TXCTL_P11_6_OUT ,
.rxClk = &IfxGeth_RXCLKA_P11_12_IN ,
.rxd0 = &IfxGeth_RXD0A_P11_10_IN ,
.rxd1 = &IfxGeth_RXD1A_P11_9_IN ,
.rxd2 = &IfxGeth_RXD2A_P11_8_IN ,
.rxd3 = &IfxGeth_RXD3A_P11_7_IN ,
.rxCtl = &IfxGeth_RXCTLA_P11_11_IN ,
.mdc = &IfxGeth_MDC_P12_0_OUT ,
.mdio = &IfxGeth_MDIO_P12_1_INOUT ,
.grefClk = &IfxGeth_GREFCLK_P11_5_IN ,
};
Now you say you are connecting it to a laptop. I did not understand your question completely, but if there is a linux kernel involved somewhere, then yes you need to modify the Device Tree. Here is a link you can start with. Here is an example, taken from the same source-
ethernet#e000b000 {
compatible = "cdns,zynq-gem", "cdns,gem";
reg = <0xe000b000 0x1000>;
status = "okay";
interrupts = <0x0 0x16 0x4>;
clocks = <0x1 0x1e 0x1 0x1e 0x1 0xd>;
clock-names = "pclk", "hclk", "tx_clk";
#address-cells = <0x1>;
#size-cells = <0x0>;
local-mac-address = [00 0a 35 00 00 00];
phy-mode = "rgmii-id";
xlnx,ptp-enet-clock = <0x6750918>;
phy-handle = <0x4>;
mdio {
#address-cells = <0x1>;
#size-cells = <0x0>;
phy#1 {
compatible = "realtek,RTL8211E";
device_type = "ethernet-phy";
reg = <0x1>;
linux,phandle = <0x4>;
phandle = <0x4>;
};
};
};
Hope this will get you started.
Related
I want to control AC Light Dimmer using Micro Python with ESP8266. I am not getting any libraries or examples related to this.Could anyone please help me with this
Thanks in advance!
Actually, it depends on which type of AC dimmer you have. I would expect something like RobotDyn AC dimmer:
Robodyn AC dimmer
In this case the regulation is not so easy like in the case of standard DC PWM (please don't let youself being confused by PWM pin, it is not real PWM). This module is standard triac dimmer which needs controlled dimming process (see this schematics).
The way how regulation works is based on the fact that you know when AC sine goes through zero (twice per period). Therefore there is Z-C input pin. When voltage goes through zero, you open triac for a while and cut off part of sine. Thats about regulation.
Wave regulation image
And this is what your dimmer driver shall do. This is not easy task in micropython as it requires to involve interrupts. You can see following code which I tried on HW and which was "working":
from machine import Timer, Pin
from micropython import alloc_emergency_exception_buf
from math import acos, pi
class Dimmer:
def __init__(self, pwm_pin, zc_pin, fpulse = 4000):
alloc_emergency_exception_buf(100)
self._cnt = 0
self._freq = 0
self._timer = Timer(2)
self._mode = Timer.ONE_SHOT
self._pwm = Pin(pwm_pin, Pin.OUT)
self._fpulse = fpulse
self._ppulse = 100.0 / fpulse + 0.11
self._zc = Pin(zc_pin, Pin.IN)
self._val = 1
self._zc.irq(trigger = Pin.IRQ_RISING | Pin.IRQ_FALLING, handler = self._zeroDetectIsr)
def _zeroDetectIsr(self, pin):
if 0 == self._freq:
self._pwm.on()
return
if 0 > self._freq:
self._pwm.off()
return
self._cnt += 1
if 1 == self._cnt:
self._timer.init(freq = self._freq, mode = self._mode, callback = self._dimmDelayIsr)
def _dimmDelayIsr(self, _timer):
if 1 == self._cnt:
self._pwm.on()
self._timer.init(freq = self._fpulse, mode = self._mode, callback = self._dimmDelayIsr)
else:
self._pwm.off()
self._cnt = 0
#property
def value(self):
return self._val
#value.setter
def value(self, p):
p = min(1, max(0, p))
if not self._val == p:
self._val = p
p = acos(1 - p * 2) / pi
if p < self._ppulse:
f = -1
elif p > 0.99:
f = 0
else:
f = 100 / (1 - p)
self._freq = int(f)
return self._val
Just note that unlike transistor, triac holds opened state till voltage on it drops to 0, so you can even use just short pulse to open it.
Use of driver is then simple:
from dimmer import Dimmer
dimmer = Dimmer(4, 2)
dimmer.value = 0.3
Unfortunately, micropython on ESP32 is locking interrupts quite often, so whole stuff works only when nothing is happening around. Most visible problems was around print function which was sometimes able to block for several AC sine periods, what caused visible bulb blinking. Unfortunately I would expect something similar in the case of WiFi communication.
The conclusion here is that the best solution is to use some cheep AVR based board and write code in C++ which will just care about dimming and nothing else. Such board can be connected to ESP board over I2C bus and ESP only sends command to set dimmer value.
We are using two AKMixer (one for left, one for right channel) and one AKMixer as output with these two mixers as inputs.
If one of the mixers has a volume lower than 0.00001 the output signal is lost. But lower volumes are possible, because if we lower the main system volume on values over 0.00001 the signal on the headphone-jack is going lower.
As a workaround I tried to set the AKMixer.output.volume to 0.5 and the input mixers to 0.00001 and it works too. But in my application I also need max output and than I got weird "clicks" when changing the both volume levels at once.
It would be great if somebody can help. With the workaround or the causing problem.
Thanks.
var rightSine = AKOscillator(waveform: AKTable(.sine))
var rightPanner : AKMixer!
let pan2 = AKPanner(self.rightSine, pan: 1)
pan2.rampDuration = 0
let right1: AKMixer = AKMixer(pan2 /*, .... some more */)
self.rightPanner = right1
let mix = AKMixer(self.rightPanner /* left channel... */)
mix.volume = 1.0
AudioKit.output = mix
do {
try AudioKit.start()
} catch {
}
self.rightPanner.volume = 0.00002
This is the code used to initialise the audio stuff (shortened) and afterwards the nodes are started.
*Edit: I'm testing the precise threshold on which the output is broken..
AudioKit's AKMixer is a simple wrapper around Apple's AVAudioMixerNode and as such, I can't really dig much deeper to help you solve the problem using that node. But, if you're willing to switch to AKBooster, whose job it is to amplify or diminish a signal, I think you will be fine to use small numbers for your gain value.
var rightSine = AKOscillator(waveform: AKTable(.sine))
var rightBooster: AKBooster!
let pan2 = AKPanner(self.rightSine, pan: 1)
pan2.rampDuration = 0
let right1: AKMixer = AKMixer(pan2 /*, .... some more */)
self. rightBooster = AKBooster(right1)
let mix = AKMixer(self. rightBooster /* left channel... */)
mix.volume = 1.0
AudioKit.output = mix
self.rightBooster.gain = 0.00002
Here is what i tried:
[SKRoutingService sharedInstance].navigationDelegate = self;
SKNavigationSettings* navSettings = [SKNavigationSettings navigationSettings];
navSettings.transportMode = SKTransportPedestrian;
navSettings.showStreetNamePopUpsOnRoute = YES;
navSettings.viaPointNotificationDistance = 5;
navSettings.navigationType=SKNavigationTypeReal;
navSettings.distanceFormat=SKDistanceFormatMetric;
[[SKRoutingService sharedInstance]startNavigationWithSettings:navSettings];
I dont find any differences in the behavior when i tried different transportMode. What i believe is Audio advices are only targeted for Car, where advices are alerting user before large distances (take right turn in 30 meters....). But i want it to alert user in short distances (take right turn in 2 meters ...)
What can i do to get advices which are for pedestrians but not for Car/bike riders?
You can change the pre-defined distances for pedestrian advices in SKMaps.bundle > AdvisorConfigs > Pedestrian> advice_places.adv
Where the first column represents distances_outside_city and the second distances_in city.
Here you can find more info and know how on the SDK audio advices.
I have a strange issue when using two RenderTargets in SharpDX, using DX11.
I am rendering a set of objects that can be layered, and am using blend modes to achieve partial transparency. Rendering is done to two render targets in a single pass, with the second render target being used as a colour picker - I simply render the object ID (integer) to this second target and retrieve the object ID from the texture under the mouse after rendering.
The issue I am getting is frustrating, as it does not happen on all computers. In fact, it doesn't happen on any of our development machines but has been reported in the wild - typically on machines with integrated Intel (HD) graphics. On these computers, no output is generated in the second render target. We have been able to reproduce the problem on a laptop here, and if we don't set the blend state, then the issue is resolved. Obviously this isn't a fix, since we need the blending.
The texture descriptions for the main render target (0) and the colour picking target look like this:
var desc = new Texture2DDescription
{
BindFlags = BindFlags.RenderTarget | BindFlags.ShaderResource,
Format = Format.B8G8R8A8_UNorm,
Width = width,
Height = height,
MipLevels = 1,
SampleDescription = sampleDesc,
Usage = ResourceUsage.Default,
OptionFlags = RenderTargetOptionFlags,
CpuAccessFlags = CpuAccessFlags.None,
ArraySize = 1
};
var colourPickerDesc = new Texture2DDescription
{
BindFlags = BindFlags.RenderTarget,
Format = Format.R32_SInt,
Width = width,
Height = height,
MipLevels = 1,
SampleDescription = new SampleDescription(1, 0),
Usage = ResourceUsage.Default,
OptionFlags = ResourceOptionFlags.None,
CpuAccessFlags = CpuAccessFlags.None,
ArraySize = 1,
};
The blend state is set like this:
var blendStateDescription = new BlendStateDescription { AlphaToCoverageEnable = false };
blendStateDescription.RenderTarget[0].IsBlendEnabled = true;
blendStateDescription.RenderTarget[0].SourceBlend = BlendOption.SourceAlpha;
blendStateDescription.RenderTarget[0].DestinationBlend = BlendOption.InverseSourceAlpha;
blendStateDescription.RenderTarget[0].BlendOperation = BlendOperation.Add;
blendStateDescription.RenderTarget[0].SourceAlphaBlend = BlendOption.SourceAlpha;
blendStateDescription.RenderTarget[0].DestinationAlphaBlend = BlendOption.InverseSourceAlpha;
blendStateDescription.RenderTarget[0].AlphaBlendOperation = BlendOperation.Add;
blendStateDescription.RenderTarget[0].RenderTargetWriteMask = ColorWriteMaskFlags.All;
_blendState = new BlendState(_device, blendStateDescription);
and is applied at the start of rendering. I have tried explicitly setting IsBlendEnabled to false for RenderTarget[1] but it makes no difference.
Any help on this would be most welcome - ultimately, we may have to resort to making two render passes but that would be annoying.
I have now resolved this issue, although exactly how or why the "fix" works in not entirely clear. Hat-tip to VTT for pointing me to the IndependentBlendEnable flag in the BlendStateDescription. Setting that flag on its own (to true), along with RenderTarget[1].IsBlendEnabled = false, was not enough. What worked in the end was filling a complete set of values for RenderTarget[1], along with the aforementioned flags. Presumably all other values in the second RenderTarget would be ignored, as blend is disabled, but for some reason they need to be populated. As mentioned before, this problem only appears on certain graphics cards so I have no idea if this is the correct behaviour or just a quirk of those cards.
I am trying to connect Nokia 5110 LCD to BeagleBone Black Rev-C over SPI protocol.
The connections are exactly as shown on the page 6 of:
Nokia5110-BeagleBone Black Connections
I wrote a C equivalent of Arduino's code for Philips PCD8544 (Nokia 3310) driver.
Where I export the required GPIO ports and send commands and data over SPI interface.
I successfully installed and ran Adafruit's python-library:
Adafruit Nokia LCD
My problem is
I have a strange issue, when I run this python code first and then my C code, the code works perfect!
But if I run my C code before the python code, I get no output. Logic says that the python
code must be initializing something that I am missing in my code.
Here's how I initialize the LCD:
fd_spi_dev = open(device, O_RDWR);
//set mode
mode = SPI_MODE_0;
ioctl(fd_spi_dev, SPI_IOC_WR_MODE, &mode);
ioctl(fd_spi_dev, SPI_IOC_RD_MODE, &mode);
//set max bitrate
speed = 4000000;
ioctl(fd_spi_dev, SPI_IOC_RD_MAX_SPEED_HZ, &speed);
ioctl(fd_spi_dev, SPI_IOC_WR_MAX_SPEED_HZ, &speed);
// set an msb first
lsbsetting = 0;
ioctl(fd_spi_dev, SPI_IOC_WR_LSB_FIRST, &lsbsetting);
// set bits per word
bits = 8;
ioctl(fd_spi_dev, SPI_IOC_WR_BITS_PER_WORD, &bits);
ioctl(fd_spi_dev, SPI_IOC_RD_BITS_PER_WORD, &bits);
lcd_write_cmd(0x21); // LCD extended commands
lcd_write_cmd(0xB8); // set LCD Vop (contrast)
lcd_write_cmd(0x04); // set temp coefficient
lcd_write_cmd(0x14); // set biad mode 1:40
lcd_write_cmd(0x20); // LCD basic commands
lcd_write_cmd(0x09); // LCD all segments on
/* I am expecting to see all segments lit here */
sleep(5);
lcd_write_cmd(0x0C); // LCD normal video
void lcd_write_cmd(uint8_t cmd) {
uint8_t *tx = &cmd;
uint8_t rx;
uint32_t len = 1;
struct spi_ioc_transfer tr = {
.tx_buf = (uint32_t)tx,
.rx_buf = (uint32_t)&rx,
.len = len,
.delay_usecs = delay,
.speed_hz = speed,
.bits_per_word = bits,
.cs_change = 1,
};
size = write(fd_dc_val, "0", 1);
size = write(fd_cs_val, "0", 1);
ioctl(fd_spi_dev, SPI_IOC_MESSAGE(1), &tr);
write(fd_cs_val, "1", 1);
}
I am a novice in embedded programming. I would greatly appreciate any help. Thank you.
If you're not missing an initialization step (and I haven't checked you against the 5110 datasheet), it must either be something wrong with your ioctls or a timing issue.
You could try using a library that abstracts away the ioctl calls to rule that out (I'm partial to my own: https://github.com/graycatlabs/serbus ;).
If it still doesn't work with that then I'd say it's probably a timing issue - Python is a lot slower than C when it comes to file I/O, so it might not be giving the LCD driver enough time to update after some of the commands - check the datasheet to see if it needs you to give it some time after any of the commands.