Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
Flutter 在 IMX93 上的运行 你好 我有一个 IMX93 主板,我想在上面运行一个 Flutter 程序。我在 CPU 使用率方面遇到了很大问题(显示一个每秒刷新一次的时钟的静态画面时,CPU 使用率约为 20%% ;而滚动包含图片的整页内容时,CPU 使用率则超过 90%% )。这主要取决于栅格(在静态屏幕上,每秒约180毫秒)。我正在尝试启用 PxP,但要么是我无法启用,要么是 Flutter 无法使用它进行栅格化。 我看到 Flutter 使用的 API 包括 OpenGL ES、Vulkan 和 Metal,因此我不确定是否可以使用 PXP 来辅助 CPU。  谢谢!
View full article
SPI Underrun Hello: I am using the SPI of S32K312 as a slave to communicate with external devices, in the actual test I found that it works fine when the SPI bus is 5MHZ, but because of the demand I need the SPI to communicate at 10MHZ rate, the test found that the trigger event of SPI is LPSPI_IP_EVENT_FAULT and the SPI is configured for DMA, I have set the DMA in the void Lpspi_Ip_IrqTxDmaHandler(uint8 Instance). void Lpspi_Ip_IrqRxDmaHandler(uint8 Instance);Interrupt point observation to SR register for observation. Found out that triggering RX first at this point SR = 6914, after that it will return to the callback function I registered, then triggering TX at this point SR = 3; By checking the datasheet I found out that an SPI underflow and FIFO overflow problem occurs when triggering the RX. I have run the slave's asynchronous transceiver program Lpspi_Ip_AsyncTransmit before the host initiates the communication, I would like to know why and how this problem occurs, and how I can optimize it hope to get some suggestions. Attached is my SPI configuration. Re: SPI Underrun Hello @siyuanzhengwei, What do you mean by this statement: "Without monitoring the slave device's SPI interrupt trigger events, the master device can receive the correct data sent by the slave device." TX underrun (SR[TEF]) is set only when the master starts the transfer while the slave TX FIFO does not contain valid data, i.e. the driver or DMA did not write the next data word in time. There is no other condition under which this flag is set. Therefore, this error cannot be explained by SPI signal quality; it indicates that the slave transmit path was not serviced early enough before or during the transfer. BR, Daniel Re: SPI Underrun Hello: I roughly say the workflow, MCU slave will start the first reception after power on, the external master device sends about 15ms to initiate a communication, after that the slave will be based on the information received to parse and send the corresponding data, in the not pay attention to the slave SPI interrupt triggering event, the host is able to receive the correct data sent by the slave. There is about 10ms from the first time the slave calls Lpspi_Ip_AsyncTransmit to the time the host initiates the communication, and the SPI error occurs not after a period of time, but the first time the communication is faulty. I call the slave's Lpspi_Ip_AsyncTransmit every 2ms through a timer, 10ms should be enough time to prepare the data, but every SPI trigger event is FAULT, I have used a logic analyzer to check the waveform of the data, and I can observe the correct send/receive data, but through the oscilloscope to observe the quality of the signal is not good and not a smooth square wave. The signal quality is not very good and not a smooth square wave, is it possible that this is also related to the signal quality? Re: SPI Underrun Hi @siyuanzhengwei, The return status of Lpspi_Ip_AsyncTransmit is LPSPI_IP_STATUS_SUCCESS because this is an asynchronous transfer (it only indicates that the transfer was started, not completed). The key issue is the TX underrun (SR[TEF]). This means the slave did not have data available in the TX FIFO when the master started clocking. In SPI slave mode, the TX FIFO must be populated before the master asserts CS and starts the transfer.  The RTD drivers introduce some overhead, and starting the transfer on the slave side takes time. As a result, Lpspi_Ip_AsyncTransmit is called too late and the first data words are not ready in time. Do you monitor the TX line with an oscilloscope? What do you measure there? Regards, Daniel Re: SPI Underrun One more piece of information to add; although the SPI trigger event is LPSPI_IP_EVENT_FAULT, the return status of Lpspi_Ip_AsyncTransmit is LPSPI_IP_STATUS_SUCCESS, the LpspiHwStatus is LPSPI_IP_BUSY, and the received data again is correct.
View full article
How do I convert the voltage of digital signals? (Japanese blog) 0. Table of Contents 0. Table of Contents 1. What is a voltage level translator? 2. Digital signals 2.1 Various Digital Signals 2.2 CMOS and TTL: Logic level signals using simple voltage HIGH and LOW 2.3 Input/Output Voltage Specification: VOH/VOL and VIH/VIL 2.3.1 Output voltage specifications: VOH and VOL 2.3.2 Input voltage specifications: VIH and VIL 2.3.3 The relationship between VOH/VOL and VIH/VIL 3. Basic voltage level conversion method: One-way signal conversion 3.1 Examples where conversion is not necessary even if the chip's power supply voltage is different. Column: How are the TTL values VIH(min) = 2.0V and VIL(max) = 0.8V determined? 3.2 Examples requiring conversion 3.2.1 Conversion using open-drain output 3.2.2 Conversion using standard logic (general-purpose logic) chips 4. Conversion of bidirectional signals requiring automatic direction switching. 4.1 Bidirectional conversion using a single MOS transistor 4.2 Bidirectional conversion using dedicated equipment 4.2.1 I²C signal voltage conversion chip 4.2.2 High-speed bidirectional open-drain signal-to-voltage conversion chip 4.2.3 Bidirectional push-pull signal-to-voltage converter chip 4.2.4 I3C signal voltage converter chip 4.2.5 Buffer-based conversion 5. Summary 5.1 Comparison of methods/part numbers introduced in the blog 6. Reference materials 1. What is a voltage level translator? When connecting digital circuits, you can simply connect the signal lines directly... That's not the case; if the " logic level voltage " doesn't match, it may not work, become unstable, or in the worst case, damage the chip. That's where a voltage level translator (also called a voltage level shifter) comes in handy. A voltage level translator is a circuit that allows signals to be exchanged between digital circuits with different power supply voltages. For example, it is needed in the following cases: 3.3V microcontroller ↔︎ 5V sensor connection Connecting a 1.8V FPGA to 3.3V peripheral devices スクリーンショット 2025-08-21 12.39.23.png Figure 1: Differences in signal voltage   This blog explains the differences in voltage levels between various types of logic circuits used in digital circuits (*TTL, *LVTTL, *CMOS), and the important meanings of VOH / VOL / VIH / VIL for determining them. Furthermore, it explains which voltage level translator to choose from among various conversion methods. Furthermore, this blog will look at specific examples of voltage level translators that automatically detect and convert the direction of a signal . NXP also offers voltage level translators for SD cards/SIM cards and application-specific translators such as GTL↔︎TTL level conversion, but this blog will focus on products targeted at general-purpose or serial bus applications. *TTL (Transistor-Transistor Logic) *LVTTL (Low Voltage Transistor-Transistor Logic) *CMOS (Complementary Metal-Oxide-Semiconductor) *GTL (Gunning Transceiver Logic) 2. Digital signals   2.1 Various Digital Signals So-called "digital signals" are electrical representations of logic levels 1 and 0. Historically, there have been various circuit design methods for handling these logic levels 1 and 0. These include methods that represent logic levels with simple voltage HIGH and LOW, and methods that use voltage differences to represent HIGH/LOW. TTL simply represents HIGH/LOW as 5V/0V. Further reducing the voltage of TTL to 3.3V/0V, such as LVTTL , are systems where the voltage level is determined based on a bipolar transistor circuit. Similarly, ECL (Electronic Classification) uses bipolar transistors but employs a negative power supply to implement low-amplitude, differential operation logic levels, resulting in higher speeds. GTL (Global Transistor Lapping) uses a reference voltage to transmit HIGH/LOW signals with low-amplitude single-ended signals, etc. Furthermore, even with a simple HIGH/LOW representation, the 4000 series of CMOS general-purpose logic, developed with the aim of reducing power consumption, allowed the use of 3V to 18V as the HIGH level. https://en.wikipedia.org/wiki/Logic_family This blog will explain how to handle voltage levels in TTL (LVTTL) and CMOS, which represent logic using simple HIGH and LOW voltages , among the various logic levels mentioned above. Other signal conversions utilize dedicated chips and are therefore not covered here. In addition, in recent years, semiconductor technology has become smaller, faster, and more power-efficient, and the voltage used for power supplies has been decreasing. For this reason, voltage level translators, which bridge the signal voltage difference, have become particularly important. スクリーンショット 2025-08-21 12.42.23.png Figure 2: Signal waveform - Voltage levels (HIGH/LOW) represent logic levels.   2.2 CMOS and TTL: Logic level signals using simple voltage HIGH and LOW In digital circuits, simple voltage-based logic level signals using HIGH and LOW typically use the power supply voltage for HIGH and 0V for LOW. As long as the HIGH/LOW voltage levels are the same, the signals can be transmitted even if the power supply voltages are different. For example, TTL (LVTTL) interprets an input signal as HIGH if it is 2.0V or higher, and LOW if it is 0.8V or lower. Because of this convention, the HIGH/LOW voltage levels of TTL signals do not change even if the power supply voltages are different. On the other hand, CMOS defines HIGH/LOW based on half the power supply voltage. Therefore, the HIGH/LOW voltage levels of CMOS change when the power supply voltage is different. スクリーンショット 2025-08-21 12.52.04.png Figure 3: Input signal voltage specification   2.3 Input/Output Voltage Specification: V OH / V OL and V IH / V IL In digital circuits, the voltages output as HIGH and LOW , and the voltage used to determine whether an input signal is HIGH or LOW, are specified. These are defined in the specifications of each chip used, so you need to check the datasheet. V OH : High-level output voltage VOL : Low-level output voltage V IH : High-level input voltage V IL : Low-level input voltage 2.3.1 Output voltage specifications: V OH and V OL When considering the output, you must take into account the current required when outputting HIGH/LOW signals. The current will increase or decrease depending on the load. The voltage that can be guaranteed at the maximum outflow current with HIGH output is called VOH (min) , and the voltage that can be guaranteed at the maximum inflow current with LOW output is called VOL (max) . V OH (min) is the voltage output when the upper transistor in the circuit's output stage is turned ON. This transistor has a resistance called "ON resistance". When a large current flows out of a transistor, a voltage is generated equal to "the transistor's resistance x the current flowing through it". This causes the output voltage to drop below the power supply voltage by that amount, resulting in a low VOH . Therefore, VOH (min) is the minimum voltage that can be guaranteed when the maximum expected outflow current is reached. スクリーンショット 2025-08-21 12.53.04.png Figure 4: Digital signal output circuit (push-pull)   スクリーンショット 2025-08-21 12.53.18.png Figure 5: HIGH output voltage varies depending on the load.   VOL is the opposite. When the lower transistor in the output stage of the circuit is turned ON, if the incoming current is large, the output will rise above 0V due to the voltage generated by the ON resistance of the transistor, as described above. Taking this into consideration, VOL (max) is the maximum voltage that can be guaranteed when the maximum incoming current is anticipated. スクリーンショット 2025-08-21 12.53.31.png Figure 6: LOW output voltage also changes depending on the load.   2.3.2 Input voltage specifications: V IH and V IL The input has voltage levels to determine HIGH and LOW : V IH (min) and V IL (max) . If the voltage is above V IH (min), it is judged as HIGH; if it is below V IL (max), it is judged as LOW. In CMOS inputs, half the power supply voltage serves as the reference for HIGH and LOW, but this is not directly used as V IH (min) and V IL (max). This is because the threshold can fluctuate due to variations between chips. Also, to mitigate glitches caused by noise on slow-rising signals appearing in the output, it is common practice to incorporate hysteresis into the input. For these reasons, V IH (min) and V IL (max) are defined with a certain voltage difference. 2.3.3 The relationship between VOH / VOL and VIH / VIL For normal signal exchange to occur, the relationship between the output and input must satisfy the following equation. HIGH level: V OH (min) > V IH (min) LOW level: VOL (max) < VIIL (max) If this relationship is maintained, the output circuit can correctly transmit HIGH/LOW signals to the next input circuit. Furthermore, the voltage difference between them, "V OH (min) - V IH (min)" and "V IL (max) - V OL (max)," becomes the " noise margin " and serves as a guideline for maintaining high noise immunity. スクリーンショット 2025-08-21 12.55.13.png Figure 7: V OH (min) / V OL (max) and V IH (min) / V IL (max) 3. Basic voltage level conversion method: One-way signal conversion   3.1 Examples where conversion is not necessary even if the chip's power supply voltage is different. Voltage level conversion is generally not necessary when the relationships "V OH (min) > V IH (min)" and "V OL (max) < V IL (max)" hold true. For example, although TTL and LVTTL use different power supply voltages for their respective chips, the input and output voltage specifications are the same . In both TTL (5V) and LVTTL (3.3V), V OH (min) is 2.4V and V OL (max) is 0.4V. Since V IH (min)/V IL (max) are also 2.0V/0.8V in both cases, they can be connected to each other without any problems. However, caution is required if the output voltage is higher than the power supply voltage of the input chip. If the output chip uses a 5V power supply and the input uses a 3.3V power supply, the input must support " 5V tolerant input ". A 5V tolerant input is an input that can operate without problems even when a 5V HIGH signal is connected to the input of a chip that operates on a 3.3V power supply voltage. While typical chip inputs have ESD protection circuits to protect against static electricity, if this ESD protection circuit is configured as shown in the following diagram, a 5V input can cause current to flow back from the input to the 3.3V power supply, potentially damaging the chip. A 5V tolerant input is designed to prevent such problems. Tolerant inputs do not lack ESD protection; they incorporate an ESD protection circuit that is structured to handle signals higher than the power supply voltage without causing problems. ESD protection diodes like the one shown in Figure 7 can also cause problems when the power to the input chip is turned off. In systems where the power to each chip is controlled individually, the output signal may feed back into the power supply even when the input chip is off, causing the input chip to operate. スクリーンショット 2025-08-21 12.57.16.png Figure 7: ESD protection diode - non-tolerant input Column: How are the V IH (min) = 2.0V and V IL (max) = 0.8V determined for TTL? While the input threshold of CMOS is based on the midpoint of the power supply voltage (VCC/2), the V IH (min)/V IL (max) of TTL is 2.0V/0.8V, which is not a particularly neat ratio with respect to the power supply voltage (5V). This is related to the fact that the input stage of TTL is composed of bipolar transistors. スクリーンショット 2026-06-20 6.45.38.png Example of the internal circuit of a standard TTL logic IC: SN7400 (2-input NAND). This information was included in the "Latest General-Purpose Logic Device Specifications Table 1988" (CQ Publishing). A typical TTL gate's input stage consists of a multiple emitter input transistor and a subsequent phase splitter transistor, both connected in series. The "switching threshold," at which the gate actually begins to react, is determined by the forward voltage of the PN junctions in these two stages. Since the forward voltage of a single silicon PN junction is approximately 0.6 to 0.7V, the combined forward voltage of the two stages is approximately 1.3 to 1.5V, which is the effective switching threshold for a TTL gate. However, this value of approximately 1.4V is merely a "typical value," and it will fluctuate from lot to lot and from condition to condition due to individual differences and variations in temperature. Therefore, the specified values V IH (min) and V IL (max) on the datasheet are defined as guaranteed values, with sufficient margins above and below this typical value of approximately 1.4V, meaning that "if it drops to this level, it can be reliably determined to be LOW (V IL (max) = 0.8V)" and "if it rises to this level, it can be reliably determined to be HIGH (V IH (min) = 2.0V)." Furthermore, this value is not determined in isolation, but is designed taking into account the relationship between VOH and VOL , as explained in Section 2.3.3. In standard TTL, due to the output stage configuration, the HIGH output is not the power supply voltage, but a slightly lower voltage (lower by the voltage generated by the 130Ω resistor, transistor, and diode in the circuit example above) (VOH(min)=2.4V). When this is combined with VOL(max)=0.4V, HIGH noise margin: V OH (min) − V IH (min) = 2.4 − 2.0 = 0.4V Low-side noise margin: V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V As shown, it is designed to ensure a noise margin of 0.4V symmetrically above and below. In other words, the 2.0V/0.8V figures for TTL, which may seem "odd" relative to the power supply voltage, are actually reasonable values derived from two requirements: the physical reality of the bipolar transistor junction voltage and the noise margin design. スクリーンショット 2026-06-20 8.20.24.png This image shows an SN7420 (4-input NAND) with three input pins set to HIGH and one pin receiving a 100kHz triangular wave (ch1). The output under no load (ch2) is less than 4V when HIGH (Vcc=5V). The circuit introduced in this column is an example of a standard TTL without a designation (such as 74 LS 00 or 74 HC 00, without LS/HC prefixes; sometimes called "vanilla TTL" in English), but the reason why the V IH /V IL specifications are the same (bipolar junction characteristics of the input stage) is common to other TTL families such as the 74LS.   3.2 Examples requiring conversion   While TTL and LVTTL connections are possible because the voltage levels are aligned, mismatches in logic levels often occur when connecting CMOS chips with different power supply voltages, or when connecting a CMOS chip to a TTL chip. This occurs when the aforementioned relationship "V OH (min) > V IH (min)" and "V OL (max) < V IL (max)" does not hold true, or when the difference becomes too small, resulting in insufficient noise margin. A voltage level translator solves this problem. スクリーンショット 2025-08-21 12.56.11.png Figure 9: Example of mismatched logic levels (1): Insufficient HIGH voltage input   スクリーンショット 2025-08-21 12.56.20.png Figure 10: Example of mismatched logic levels (2): Insufficient LOW voltage is input.     3.2.1 Conversion using open-drain output There are ways to easily adjust voltage levels without using a voltage level conversion chip. If the signal direction is fixed from the output chip to the input chip and does not switch, then this method involves making the HIGH output an open-drain output to match the input voltage. An open-drain output is a configuration in which the upper transistor of the output stage of a digital circuit is absent, and the HIGH voltage is obtained by a pull-up resistor connected to the power supply voltage of the input chip . スクリーンショット 2025-08-21 12.58.18.png Figure 11: Digital signal output circuit (open drain)   Open drains are a simple and inexpensive method, but there are a few things to keep in mind . First, the output side must be capable of open-drain output. Many microcontrollers' GPIO pins can provide this type of output through configuration. First, the output side must be capable of open-drain output. Many microcontrollers' GPIO pins can provide this output through configuration. If the output is fixed to push-pull output and cannot be configured for open-drain output, an external transistor or similar device will be needed to convert it to open-drain output. Furthermore, the selection of pull-up resistors is also important. A pull-up resistor is necessary to obtain a HIGH voltage, but if the resistance value is too small, the current flowing when the output is LOW will be large (similar to a heavy load), which will increase power consumption and lead to an increase in VOL . Conversely, if the value is too large, it will be affected by the capacitance of the wiring and pins, causing the rise time from LOW to HIGH to be slow, resulting in a decrease in communication speed. 3.2.2 Conversion using standard logic (general-purpose logic) chips For simple voltage level conversion, you can also use standard logic. For example, Nexperia's 74AVCH4T245 is a general-purpose CMOS logic chip that can perform 4-bit bidirectional level conversion. This chip can convert signals from 0.8V to 3.6V, and the signal direction can be switched using the DIR pin. The signal speed depends on the voltage being converted, but it can support speeds of approximately 100M to 380Mbps. スクリーンショット 2025-08-22 3.29.11.png Figure 12: Example of standard logic - 74AVCH4T245 This chip enables high-speed bidirectional voltage conversion of signals, but the direction must be controlled by an external signal. While such control is possible with signals like READ/WRITE on a parallel bus, it is difficult to apply to communications like serial buses where the communication direction switches depending on the protocol. スクリーンショット 2025-08-22 3.29.26.png Figure 13: Example of standard logic. The signal direction must be specified externally. 4. Conversion of bidirectional signals requiring automatic direction switching. The "open-drain output" and "voltage conversion methods using standard logic chips" introduced so far mainly perform conversion in only one direction, or require switching of direction by an external signal. Communication methods like I²C and I3C , where the direction of the signal changes dynamically, require " bidirectional voltage level conversion " that automatically detects and switches the direction. Controlling the direction of such signals externally is difficult, and it is challenging to implement this with the buffer chips mentioned above. Furthermore, since I²C is an open-drain signal, it is not possible to connect standard open-drain logic buffers in opposite directions. Figure 14 shows an example of this, where open-drain buffers are connected in opposite directions. There is no problem when both sides of the buffer are HIGH, but once one of them goes LOW, the buffers will keep pulling the other input LOW and will not be able to return to HIGH. スクリーンショット 2025-08-22 3.29.39.png Figure 14: A typical open-drain buffer cannot automatically switch between bidirectional communication.   4.1 Bidirectional conversion using a single MOS transistor   Until now, simple circuits have sometimes been used for I²C signal-to-voltage conversion. We will present the simplest method, using a MOS transistor, as an example. VLT_by_MOS.png Figure 15: Example of conversion using a MOS transistor   Figure 15 is taken from the I²C specification version 2.1 (2000) and shows an example where two MOS transistors (TR1, TR2) are used to convert 3.3V and 5V signals, respectively. Although such a simple conversion example using only transistors has been removed from the current I²C specification due to the problems described later, it is included here to understand the principle . The I²C signal lines, called SDA and SCL, are both open-drain bidirectional signals. Pull-up resistors are connected to the 3.3V and 5V sides, respectively. In this circuit, when the 3.3V and 5V signals are HIGH, the gate (g) and source (s) of this transistor are at the same potential, so the source (s) and drain (d) are OFF, and the connection between them is broken. When 3.3V changes to LOW in this state, the 3.3V side transistor (between s and d) turns ON , and the 5V side signal also goes LOW . When the 3.3V side changes to HIGH and the 5V side changes to LOW , the parasitic diode (body diode) connecting the 3.3V side to the 5V side first turns ON . When the diode turns ON, the source(s) voltage drops . As a result, the transistor turns ON , and the signal on the 3.3V side also becomes LOW . While this very simple mechanism using a transistor as a switch allows for voltage level conversion, there are problems. Transistor variations affect the threshold voltage for signal conversion. Furthermore, with the increasing need to handle lower signal voltages, for example, at signal voltages of around 1V, such a circuit cannot operate because it cannot obtain a sufficient gate-to-source voltage (Vgs). Addendum: The same circuit as in Figure 15 is still publicly available as application note AN10441 "Level shifting techniques in I²C-bus design" from Nexperia , a company formed when the semiconductor discrete/logic products business was spun off from NXP. The application note was first published in 2007 (Rev.01) separately from the I²C specification, and was revised under the Nexperia brand in 2020 (Rev.2). 4.2 Bidirectional conversion using dedicated equipment   By using a dedicated voltage level translator IC , voltage level conversion for bidirectional communication buses such as I²C and I3C can be easily performed. 4.2.1 I²C signal voltage conversion chip The PCA9306 and NVT20xx series ( NVT2001/02 , NVT2003/06 , NVT2008/10 ) are voltage level translators specifically designed for bidirectional signal conversion. These chips can handle multiple signal lines (multi-bit signal lines) simultaneously. While they are designated as I²C signal voltage conversion chips, they can also be used for other purposes (such as SPI and other push-pull signals) if the signal specifications match . The PCA9306 and NVT20xx series share the same internal structure, and the pull-up resistor only needs to be connected to the higher voltage side if the voltage difference to be converted is 1V or more . Figure 16 shows its internal structure and connection to external chips (excerpted from Fig. 2 of Application Note AN11127 : "Bidirectional voltage level translators NVT20xx and PCA9306" ). This chip contains the number of signal lines (bits) + 1 MOS transistors. Each transistor has a structure in which the source and drain are interchangeable. The transistors in the signal transmission path are called pass transistors , and the remaining one is called a reference transistor . スクリーンショット 2025-08-22 15.56.50.png Figure 16: NVT20xx (PCA9306) - Diagram illustrating chip operation.   Looking at the circuit, the gate and drain of the reference transistor are shorted and connected to the higher voltage power supply via a 200kΩ resistor. The remaining terminal of the reference transistor, the source, is connected to the lower voltage power supply. With this connection, the reference transistor acts as a single diode , and its gate voltage is one diode higher than the lower voltage power supply . The remaining pass transistor has its drain connected to the high-voltage signal line and a 1kΩ pull-up resistor, its source connected to the low-voltage signal line, and its gate connected to the gate of the reference transistor. When both the high and low signals of the pass transistor are HIGH, the high-voltage side becomes the voltage pulled up by the 1kΩ resistor . A pass transistor forms a circuit known as a "source follower." The terminal on the lower voltage side (source terminal) has a voltage that is lower than the voltage applied to the gate by the amount of Vgs required to turn the transistor ON . In other words, it has the same voltage as the low-voltage power supply. The transistor is in a semi-ON state (operating in the linear region), neither ON nor OFF. In this state, when either the high or low signal becomes LOW , the voltage difference between the gate and the signal terminal causes the transistor to turn ON (operating in the saturation region where it is fully ON), and the other terminal also becomes LOW . The signal speed that this series can handle is affected by the pull-up resistor and the capacitance of the signal line. The datasheet states that the PCA9306 can handle up to 2MHz. The NVT20xx series can handle signal speeds up to 33MHz with a 192Ω pull-up resistor and a capacitance of 50pF. For signals around 1MHz, it will work without problems even if you don't worry too much about the pull-up resistor and capacitance (assuming it's within the range typically used for I²C). However, when using this chip to handle higher-speed signals in a push-pull configuration, a thorough understanding of its characteristics and careful component selection are necessary. Details of the operation of this type of voltage level translator are described in the article " The Internals and Operation of the PCA9306 ". 4.2.2 High-speed bidirectional open-drain signal-to-voltage conversion chip We introduce the NTS030x series ( NTS0302JK , NTS0304E ) as high-speed bidirectional open-drain signal conversion chips. This chip can perform 2-bit or 4-bit bidirectional signal conversion and can handle signals up to 2Mbps (1MHz) for open-drain signals and 20Mbps (10MHz) for push-pull signals.   スクリーンショット 2025-08-22 15.59.57.png Figure 17: NTS030x - Internal Chip Block Diagram   Figure 17 shows the internal structure of one signal bit in the NTS030x. In the diagram, transistor T3 is a pass-through transistor , and a gate terminal bias voltage is applied to it, so it turns ON when either the signal labeled A or B goes LOW. When both A and B are HIGH, T3 turns OFF, and since A and B are connected to their respective power supplies with relatively large pull-up resistors (10kΩ), they will have their respective voltages. This chip has T3, as well as T1 and T2 . These T1 and T2 are used for a function called " edge rate accelerator ." We will focus on one of them, T1, and explain its operation. T1 is placed on the A side, with its source terminal connected to the A signal and its drain terminal connected to the A side power supply. The gate terminal is connected to the block labeled "ONE-SHOT AND SLEW RATE CONTROL" that controls it. The "ONE-SHOT AND SLEW RATE CONTROL" block is connected to the B signal on the opposite side and detects the change from LOW to HIGH in the B signal . When this is detected, T1 is temporarily turned ON, bypassing the 10kΩ pull-up resistor and allowing current to flow, thereby accelerating the change from LOW to HIGH in the A signal . By speeding up the rise time of the signal in this way, it becomes possible to handle faster signals. Incidentally, the slew rate when T1 is turned ON is controlled, taking into consideration the suppression of ringing caused by a sudden increase in current. The other T2 uses the same mechanism but in the reverse direction, and is applied to the B-side signal as well. The NTS series has another user-friendly feature . In the case of the MOS transistors and PCA9306/NVT20xx described so far, there was a problem in that if one power supply was turned off, the signal of the other would be set to LOW. To solve this problem, the NTS030x operates so that when both power supplies are not ON, the signal pins are set to a high impedance state to prevent them from affecting each other . By using this function, it becomes possible to partially control the ON/OFF state of the system's power supply . The NTS010x series ( NTS0102 , NTS0104 ) is equivalent to the NTS030x series, but lacks slew rate control functionality to handle higher-speed signals. An evaluation board, NTS0304EUK-ARD, is available for the NTS0304E to allow for quick and simple operational verification. For an overview of the NTS0304EUK-ARD board and how to operate it, please refer to this video , "How to operate the NTS0304EUK-ARD" . 4.2.3 Bidirectional push-pull signal-to-voltage converter chip Furthermore, for use with push-pull signals only, there is the NTB010x series ( NTB0102 , NTB0104 ), which offers a faster option. When stable in a HIGH or LOW state, the signal is driven through a 4kΩ resistor. Similar to the NTS030x series, it has a one-shot function on both the HIGH and LOW sides, and has a mechanism that uses this to change the signal on the opposite side when there is a change in the signal at either terminal. This mechanism enables signal-to-voltage conversion at speeds of 70-80 Mbps while also having an automatic signal direction detection function.   スクリーンショット 2025-08-22 16.04.45.png Figure 17: NTB010x - Internal Chip Block Diagram 4.2.4 I3C signal voltage converter chip I3C has a specification that switches between open-drain and push-pull communication modes . In open-drain mode, it is compatible with I²C and operates at frequencies up to 4MHz . In push-pull mode, a 12.5MHz clock is used. Since the signal voltage is usually in the range of 1V to 3.3V, a voltage level translator that operates according to the signal specifications is required when there is a voltage difference. Figure 18 shows the internal block diagram of one bit of the P3A1604 . As shown in the figure, this chip incorporates a mechanism to accelerate not only the LOW→HIGH change but also the HIGH→LOW change, as well as a pull-up resistor that can be switched ON/OFF.   スクリーンショット 2025-08-22 16.28.46.png Figure 18: P3A1604 - Chip internal block diagram The P3A1604 is a 4-bit I3C voltage level translator. A 2-bit version, the P3A9606 , is also available.   4.2.5 Buffer-based conversion Another method for converting bidirectional signals is to use a dedicated buffer. The primary purpose of a buffer is to enhance driving capability and separate the capacitance of connected signal lines, but there are also products that support voltage conversion. As explained in this blog, simple buffers cannot mutually buffer bidirectional open-drain signals. Therefore, various buffer products with special features for bidirectional open-drain signals are available. I will explain more about buffers on a later occasion. 5. Summary Voltage level translators are essential components for safely and reliably exchanging signals between digital circuits with different power supply voltages. Understanding the definitions of logic levels such as TTL, LVTTL, and CMOS, as well as the relationships between VOH/VOL/VIH/VIL, allows you to select the appropriate connection and conversion method. For unidirectional conversion, open-drain outputs or standard logic ICs can be used, while for bidirectional conversion, MOS transistors or dedicated ICs (such as the PCA9306/NVT/NTS/NTB/P3A series) can be used. Voltage level translators with automatic signal direction detection capabilities are particularly useful for buses requiring bidirectional communication, such as I²C and I3C. Furthermore, recent advancements in semiconductor technology have led to lower voltages and higher speeds, requiring more precise voltage level control. While there are many methods and options for voltage level conversion, it is important to select the optimal method and components according to the application, taking into account signal specifications, speed, and system power management. 5.1 Comparison of methods/part numbers introduced in the blog Method/Part Number Purpose Number of bits Direction change Open wiring compatible Low voltage side [V] High voltage side [V] Bitrate [bps] Conversion with open-drain output General purpose 1 unidirectional - - - - Standard logic (e.g., 74AVCH4T245) General purpose (parallel bus, etc.) 4 + 4 External control Not supported 0.8 ~ 3.6 0.8 ~ 3.6 100M ~ 380M Bidirectional conversion using a single MOS transistor I²C, General Purpose 1 automatic correspondence Depending on the transistor specifications ~ 1M PCA9306 I²C, General Purpose 2 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz, depending on conditions) NVT2001 I²C, General Purpose 1 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2002 I²C, General Purpose 2 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2003 I²C, General Purpose 3 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2006 I²C, General Purpose 6 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2008 I²C, General Purpose 8 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2010 I²C, General Purpose 10 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NTS0302JK I²C, SPI, General Purpose 2 automatic correspondence 0.95 ~ 3.6 1.65 ~ 5.5 2M @ Open Drain, 20M @ Push Pull NTS0304E I²C, SPI, General Purpose 4 automatic correspondence 0.95 ~ 3.6 1.65 ~ 5.5 2M @ Open Drain, 20M @ Push Pull NTS0102 I²C, SPI, General Purpose 2 automatic correspondence 1.65 ~ 3.6 2.3 ~ 5.5 50M @ Push-Pull NTS0104 I²C, SPI, General Purpose 4 automatic correspondence 1.65 ~ 3.6 2.3 ~ 5.5 50M @ Push-Pull NTB0102 SPI, General Purpose 2 automatic Not supported 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M NTB0104 SPI, General Purpose 4 automatic Not supported 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M P3A9606 I3C, I²C, SPI, General Purpose 2 automatic correspondence 0.72 ~ 1.98 0.72 ~ 1.98 (12.5MHz) P3A1604 I3C, I²C, SPI, General Purpose 4 automatic correspondence 0.72 ~ 1.98 1.62 ~ 3.63 6.8M @ Open Drain, 40M @ Push Pull Table 1: Comparison of methods/part numbers introduced in the blog   6. Reference materials Product introduction page: Voltage Level Converter NXP System Management I2C, I3C, SPI Selector Guide I2C Bus Specifications and User Manual (Rev5.0) (Japanese version) I2C Bus Specifications and User Manual (Rev7.0) English version) NXP Community Blog: I3C Bus Overview – The Next Serial Bus Japanese Webinar Video: "The Basics of the Next-Generation Interface 'I3C' That You Need to Know Now" Qiita @teddokano: PCA9306's internals and operation Change history: 2025-08-28: First Edition 2025-08-28: Added information about NTS0304EUK-ARD and a link to the blog with the video. 2026-04-10: Correction of low voltage side [V] and high voltage side [V] in Table 1. 2026-06-20: Section 3.1 "Column: VIH (min) of TTL" Added "How are VIL(max) = 2.0V and VIL(max) = 0.8V determined?". Added internal circuit example of standard TTL logic IC: SN7400 (2-input NAND) and output waveform of SN7420. 2026-07-10: Added to Section 4.1 that the circuit in Figure 15 is also published as Nexperia application note AN10441. ========================= We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) This blog explains the differences in voltage levels between various types of logic circuits used in digital circuits (*TTL, *LVTTL, *CMOS), and the important meanings of VOH , VOL , VIH , and VIL for identifying them. Furthermore, we will explain which voltage level translator to choose from among the various conversion methods. We will take a closer look at the conversion of bidirectional open-drain signals , which requires special handling. スクリーンショット 2025-08-21 12.52.04.png Interface Introduction Japanese Blog
View full article
IMX8mp gstreamer vpuenc_h264 プロファイルとレベルを設定 当社では、カスタムボード上にIMX8mpを搭載し、NXP Yocto Hardknottをベースプラットフォームとして使用しています。 ハードウェアH264エンコーダーであるvpuenc_h264プラグインを使用して、カメラストリームをH264/MP4に圧縮/エンコードしています。 基本的な例としては、次のようなものがあります。 gst-launch-1.0-v videotestsrc num-buffers=100 !video/x-raw、幅=720、高さ=576、フレームレート=25/1 !vpuenc_h264 !video/x-h264,profile=main !h264parse !mp4mux fragment-duration=10 !filesink location=/tmp/Video1.mp4 しかし、vpuenc_h264 は profile= および level= ストリームパラメータを無視するようです。imx-gst1.0-plugin を見てみるとコードには、H264プロファイルを設定する機能がないようです。 GStreamerのパラメータを使用してH264ハードウェアエンコーダのプロファイルを設定する機能はありますか? インターネットで、この設定をVPUのハードウェアレジスタにハードコーディングする必要があることを示唆する情報を見かけたのですが、実際はどうなのでしょうか? 代替案(コミュニティ?)があることに気付いた。gstreamer1.0-plugins-imxこのプラグインはプロファイルとレベルをサポートしているようです。これは、NXP fsl-nxp-bsp-hardknott Yoctoビルドのソフトウェアモジュール/カーネルでは使用できないということでしょうか? Re: IMX8mp gstreamer vpuenc_h264 set profile and level 裏付けとなるご意見をありがとうございます。 私も同様に、v4l2-ctl -d /dev/video1 --all がこれらのエンコーダーパラメータに関して誤解を招くような表示をしており、変更可能であるかのように誤って示唆し、「high」がデフォルトのプロファイルであるかのように見せかけているのを目にしました。 Re: IMX8mp gstreamer vpuenc_h264 set profile and level はい、ご指摘ありがとうございます。 NXPの公式ドキュメントは通常入手困難なため、インターネット検索やコードの確認を通して私が収集した情報を他のユーザー向けに以下にまとめました。 H264エンコーディングプロファイルは、vpu_wrapper内でBaselineにハードコーディングされています。例えばこれをMainlineに変更すると(vpu_wrapperを再構築する)、H264ストリームがMainlineとしてマークされます。実際の圧縮率が異なるかどうかは分かりません。 レベルは、ビデオの解像度に基づいてvpu_wrapperによって設定されます。このレベルをH264ストリームにタグ付けする以外に、何か影響があるかどうかは分かりません。どうやら、vpu_wrapperの古いバージョンには、このレベルを誤って設定するバグがあったようです。 ビットレートを指定しない場合、少なくともgstreamerのvpuenc_h264レベルでは、結果として得られるストリームのビットレートは非常に低くなり、したがって非常に低品質になります(少なくとも私たちのビデオストリーム(通常は静止画で、時折動きがある)の場合)。ビットレートを設定しない場合、H264エンコーダーは私が知らない何らかの可変ビットレートアルゴリズムを使用することになります。 NXPへのフィードバック: H264エンコーダーのプロファイル、レベル、ビットレートに関するドキュメントが必要であり、おそらく「i.MX Linuxリファレンスマニュアル」または他の場所に記載されているでしょう。 NXPのgstreamer vpuenc_h264コードは、gst-inspect-1.0でモジュールに関する情報を一覧表示する際に、この点について言及すべきです。なぜなら、多くのエンドユーザーがこのレベルで作業を行うからです。 Re: IMX8mp gstreamer vpuenc_h264 set profile and level こんにちは、 @TerryBarnaby1 さん。 お元気でお過ごしでしょうか。   関連情報については、下記のスレッドをご覧ください。 https://community.nxp.com/t5/ i-MX-プロセッサ/Encoding-H-264-amp-H-265-using-vpu-wrapper-h/mp/1347610   この情報がお役に立てば幸いです。   ありがとう、よろしく。 ドゥルヴィット・ヴァサヴァダ Re: IMX8mp gstreamer vpuenc_h264 set profile and level 同様に、デバイスはforce_key_frame ( V4L2_BUF_FLAG_KEYFRAME )が使用可能であると誤って宣伝しているようですが、実際には、私がそれを送信してもVPUによって完全に無視されているようです。
View full article
如何通过 UART 接收不同长度的数据? 嘿 ! 我使用的是 s32k144 评估板,我使用 UART_PAL 库使用 MODBUS 协议通过 UART 接收数据。我在 while 循环中使用了 thenon 阻塞 uart_receivedata() API,并使用回调检查接收事件和接收数据。 在我确定要接收的数据长度之前,一切都很正常,但当要接收的数据长度不固定,而且每次都不一样时,我该怎么办呢? 我看到了许多相同的主题,但没有一个主题提供了绝对的解决方案,我请求您指导我一个正确的解决方案,如果可能的话,请提供相同的代码/屏幕截图。 我附上了一张截图,在开关语句中,不同情况下接收数据的长度是不确定的。 Adarshnanda_0-1683700959540.png 请@Robin_Shen为我们提供解决方案。 此致, 阿达尔什 Re: How to receive data of varying length over UART? 你好,我想问一下你们是否解决了在 485 上接收变长数据的问题。我目前也遇到了同样的问题,但一直无法解决。 Re: How to receive data of varying length over UART? 本指南中还缺少一样东西,但@Robin_Shen发送的链接中却有。我也会把它写在这里。 6.在 LPUART_DRV_StartReceiveDataUsingInt() 函数中,启用 CTRL[IDLE]。 harivignesh_1-1746257780938.png 非常感谢@Adarshnanda制作这份指南! Re: How to receive data of varying length over UART? HI 我正在尝试通过 LPC804 的 UART 接收数据,并使用 mcuxpresso ide,请问谁能提供代码并告诉我接收数据的步骤。 Re: How to receive data of varying length over UART? 嘿,@Robin_Shen、 我查看了该主题,它对我很有效。唯一令人困惑的是,该主题中有些答案与通过 DMA 接收数据有关,有些则与通过中断接收数据有关。 如果想使用 INTERRUPTS 实现 UART_IDLE_LINE_RECEIVE,让我总结一下需要遵循的步骤。 请注意,我们需要添加 LPUART 驱动程序。 1.在 LPUART_DRV_INIT 函数中,必须配置外设寄存器,以启用 IDLE LINE INTERRUPT& 设置 IDLE 标志设置前接收的空闲字符数。你应该看看参考手册。我已将其配置为 8 个空闲字符& ,在此附上截图。 Adarshnanda_0-1684475336590.png 2.在 LPUART_DRV_IRQHandler 中,必须检查 IDLE_LINE_DETECT 标志是否设置& ,如果设置了,则调用 LPUART_DRV_RxIdleCallback 函数(默认情况下没有,用户需要定义)。请注意 - 需要在启动 IRQ_Handler 时调用此函数。 Adarshnanda_1-1684475537665.png 3.在文件 - (callbacks.h) 的枚举 - uart_event_t 中,定义一个事件 UART_EVENT_IDLE_DETECT。 Adarshnanda_2-1684475649321.png 4.定义 LPUART_DRV_RxIdleCallback& 并提供其函数原型。 Adarshnanda_3-1684475819016.png 5.之后,您就可以在应用程序中使用它了。 Adarshnanda_4-1684475984634.png 谢谢@Robin_Shen & 我希望这对其他人有所帮助。 此致, 阿达尔什 Re: How to receive data of varying length over UART? 你好,阿达什、 很抱歉,最近的 S32K1 SDK/RTD 驱动程序没有实现空闲检测功能。您是否参考过S32K144 LPUART IDLE 线路中断配置中的讨论? 您需要更改 SDK 驱动程序,才能获得 LPUART 空闲线中断。 祝好, Robin ------------------------------------------------------------------------------- 注: - 如果本帖回答了您的问题,请点击"Mark Correct" 按钮。谢谢! - 我们会在最后一次发帖后的 7 周内跟踪主题,之后的回复将被忽略 如果您以后有相关问题,请另开新主题,并参考已关闭的主题。 ------------------------------------------------------------------------------- Re: How to receive data of varying length over UART? 7。调用 LPUART_DRV_GetReceiveStatus 函数来计算接收的长度,调用 LPUART_DRV_AbortReceivingData 函数以在处理第一帧后重新开始接收数据,这样接收缓冲区从 0 开始。 企业微信截图_17737263769503.png 这是我添加的内容。现在调试成功了。感谢专家们分享之前的内容。谢谢大家。
View full article
i.MX 91 - LPDDR4 内存兼容性指南 本文档的目的是为选择 i.MX 91 系列处理器支持的兼容 LPDDR4 内存设备提供扩展指导。在所有情况下,强烈建议遵循恩智浦硬件开发者指南中针对特定 SoC 概述的动态随机存取存储器(DRAM)布局指南。 二进制密度(例如 1 GB、2 GB、4 GB)的内存设备是首选,因为它们通过与系统寻址方案保持一致并降低软件复杂性来简化内存管理。 LPDDR4 - 最大支持密度 SoC 最大数据总线宽度 最大密度 假定内存组织 说明 i.MX 91 (i.MX 91xx) 16 位 16GB / (2GB) 具有 17 行地址的单列单通道设备(R0-R16) 1, 2, 3 LPDDR4 - 经过验证的存储器列表 验证过程是一项持续性工作--预计将定期更新表格。 SoC 密度 内存供应商 经过验证的内存部件编号 说明 i.MX 91 16GB / (2GB) 美光 MT53E1G16D1FW-046 AAT:A MT53E1G16D1ZW-046 AAT:C 5 2 Gb/(256 MB) Winbond W66BP6NBHAHJ 4 8GB / (1GB) 南亚 NT6AN512M16AV-J1I   4 Gb/(512 MB) 南亚 NT6AN256M16AV-J1I 4 8GB / (1GB) ISSI IS43LQ16512B-046BLI 4 12GB / (1.5GB) 美光 MT53E768M16D1ZW-046 4 16GB / (2GB) 智能存储器 IMAG16L4KBBG 4 2 Gb/(256 MB) 南亚 NT6AN128M16AV-J1 4 4 Gb/(512 MB) 联合信息中心 SCB11N4G160BF-04ZI 4 4 Gb/(512 MB) ISSI IS43LQ16256B-053BLI 4 4 Gb/(512 MB) Winbond W66CP6RBHAHJ 4 Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences. 注意:某些内存供应商的 LPDDR4 设备可能不支持低速运行,此外,DQ ODT 可能未处于活动状态,这可能会影响这些速度下的信号完整性。如果在用例中计划低速运行,请向内存供应商咨询内存设备的配置方面和可能的自定义,以确保功能正确。 注 1: 这些数字完全基于DDR控制器和DDR PHY的IP文档、为将其集成到SoC而选择的实现参数设置、SoC参考手册以及JEDEC标准 JESD209-4B(LPDDR4)。因此,除非另有说明,否则它们没有经过验证,也不能保证存储器供应商提供的 SoC 具有特定的密度和/或所需的内部结构。如果客户选择使用最大密度,并将其用于预期用途,则风险自负。 注 2: 不支持任何密度的字节模式 LPDDR4 设备(在两个芯片之间内部分配 x16 通道,每个 x8),因此,这些数字仅适用于内部组织 x16 的设备(在 JEDEC 规范中称为 " 标准 ")。 注 3: SoC 还支持双列单通道设备,因此,使用具有 16 行地址(R0-R15)的双列单通道设备也可以实现 16GB/2GB 的密度。 注 4: 该内存部件号没有经过 JEDEC 的全面验证,但通过了所有功能测试项目。 注 5: 该内存部件号不推荐用于新设计,已被新部件号取代
View full article
S32DS v3.5 - 在创建项目时不可见 SDK& OpenSDA 调试问题 (S32K144) MCU:S32K144 板:S32K144 EVB(板载 OpenSDA) 集成开发环境:S32 Design Studio v3.5 SDK:S32K1xx SDK v4.0.1 操作系统:Windows 11 问题 1:创建项目时看不到 SDK 已成功安装 S32K1xx SDK v4.x,可在下面看到:   首选项→ S32 Design Studio → SDK 管理   但是,在创建新的 S32DS 应用程序项目时,"选择要附加的 SDK "列表是空的,没有 SDK 出现。 发生在S32DS v3.5中 SDK 在首选项中可见,但在创建项目时无法选择 问: S32DS v3.5和S32K1xx SDK v4.x 之间是否存在已知的兼容性问题? 建议 v3.5 使用哪个 SDK 版本? 问题 2:使用板上 OpenSDA (peMicro) 调试失败 在板载 O penSDA 上使用 GDB peMicro 接口调试时,我经常会遇到以下错误: "启动 GDB 服务器任务遇到问题" "执行 MI 命令失败:-exec-run" "不知道怎么跑。试试'帮助目标'" 说明: 板被检测为 OpenSDA USB 设备 即使是基本的hello_world也会出现问题 重新刷新 OpenSDA 固件后有时能正常工作 在S32DS v3.5中发生得更频繁 问题: v3.5 中 是否完全支持板载 OpenSDA,还是推荐使用外部调试器? 申请它 请告知: 针对 S32K144 推荐的S32DS + SDK版本组合 SDK 附件和 OpenSDA 调试的已知问题或变通方法 谢谢! Re: S32DS v3.5 – SDK not visible during project creation & OpenSDA debug issues (S32K144) 你好@mahesh7、 一般来说,SDK 不再得到支持和维护。 最后一个版本 - S32 SDK for S32K1xx RTM 4.0.2 - 用于 S32DS 3.4。 请使用 S32K1 的实时驱动程序而不是 SDK: S32K1_S32M24X 实时驱动程序 AUTOSAR 4.4 & R21-11 版本 2.0.0 适用于 S32DS 3.5 S32K1_S32M24X 实时驱动程序 AUTOSAR R21-11 版本 3.0.0 适用于 S32DS 3.6 可以从页面访问实时驱动程序 (RTD) https://www.nxp.com/products/S32K1软件部分。 顺祝商祺! 帕维尔 Re: S32DS v3.5 – SDK not visible during project creation & OpenSDA debug issues (S32K144) 你好@PavelL、 感谢您对 SDK 的弃用以及对 S32K1 使用实时驱动程序 (RTD) 的建议的澄清。 根据建议,我已将S32 Design Studio 3.5移至RTD。不过,我目前在RTD 的安装和使用方面也遇到了问题,尤其是在创建项目和调试时。 我面临的问题是 RTD 软件包似乎已安装,但是在创建新应用程序项目期间,RTD 并非总是可以选择或正确识别的 即使创建了项目,我在调试过程中也会遇到问题,例如调试器无法启动,或者目标程序无法在 main() 处停止。 如果您能提供或指点我一个分步骤的程序,包括S32DS 3.5 和 RTD 的完整工作流程,将对我非常有帮助: S32DS 3.5 和热电阻的正确安装顺序 如何验证S32DS 内部的RTD 安装情况 创建基于 RTD 的新项目的正确步骤 所需项目设置(编译器、SDK/RTD 路径等) 推荐的调试探针和调试配置 在 S32DS 3.5 中使用热电阻进行调试时的任何已知限制或常见陷阱 这些详细的指导将大大有助于建立稳定的开发和调试环境。 感谢您的支持。 致以最诚挚的问候, @mahesh7 Re: S32DS v3.5 – SDK not visible during project creation & OpenSDA debug issues (S32K144) 你好@mahesh7、 请查看以下相关链接: 安装 -https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-offline-install-S32K1-RTD-2-0-0-in-S32DS-v3-5/ta-p/1927845 创建新项目 -https://community.nxp.com/t5/S32-Design-Studio/Install-SDK-RTD-into-S32-Design-Studio/m-p/1779464 上述主题的解决方案中有几个相关链接。 具体到 S32K1,要查看可用的 SDK/RTD,可能需要选择工具链的上一版本。 推荐的调试探针取决于您的要求,例如: 多链路调试探器:适用于许多 ARM 和 8-/16/32 位设备的调试探器 世纪佳缘 J-Link 调试探头 劳特巴赫 TRACE32 调试和跟踪解决方案 顺祝商祺! 帕维尔 Re: S32DS v3.5 – SDK not visible during project creation & OpenSDA debug issues (S32K144) 你好@PavelL、 谢谢你的参考。我使用 S32K1 SDK RTM 4.0.3 安装了 S32DS v3.4,并开始使用建议的设置创建项目。在运行 SDK 示例项目(FTM、ADC、UART、GPIO)时,我仍然会遇到版本和集成问题,希望获得有关同时使用 ConfigTools、生成的代码和 SDK 驱动程序的推荐工作流程的指导。您能否还阐明可靠地导入和构建 SDK 示例的正确方法?此外,查看运行日志的推荐工具是什么?S32DS 是否提供串行终端,还是应该通过 OpenSDA 虚拟 COM 端口使用 PuTTY?如果能就所需的驱动程序和调试工具提出建议,将非常有帮助。 Re: S32DS v3.5 – SDK not visible during project creation & OpenSDA debug issues (S32K144) 你好@mahesh7、 示例流程可能是这样的 根据示例创建项目 打开配置工具 修复所有错误(如果有 检查外围设备的引脚、时钟和设置(如果所有设置都符合板要求) 更新源代码 返回代码 - S32DS C/C++ 构建 闪存 调试时可使用 printf() -已解决:如何在 S32DS.3.5 中使用 printf 函数?- 恩智浦社区 你可以使用 S32设计工作室知识库——恩智浦社区作为参考点。 顺祝商祺! 帕维尔
View full article
IMX8QX DDR RPA_tool 構成、レジスタ情報が欠落しています こんにちは、 IMX8QX 上の DDR3L 用の RPA_tool の構成に記載されているいくつかのレジスタに関する情報が必要です。次のようなレジスタ アドレスが記述されています。 0x41C80044 0x41C80208 0x41C80204 0x41C82C00 0x41C83800 しかし、それらはドキュメントのどこにも記載されていません。 それぞれの機能と設定フィールドを教えていただけますか。 よろしくお願い申し上げます。 Re: IMX8QX DDR RPA_tool configuration, missing register information こんにちは、 @CPE さん。 この設定ファイルは、サードパーティのIPベンダーによって提供されています。ポイント付きレジスタはNDAドキュメントには表示されていません。i.MX8X実装の場合、提供された値以外に選択肢はないとご理解ください。 よろしくお願いいたします。
View full article
RT1170 上的 LPUART1 BREAK 检测问题 亲爱的恩智浦支持团队 我目前正在 RT1170 上使用 SDK 和 LPUART1 进行 UART 通信。我在发送 BREAK 检测时遇到了一个问题,希望得到您的指导。 问题描述: 当我启用LIN 中断检测 (LBKDE)和LBKDIE 时: MCU 成功检测到来自 PC 的发送 BREAK 信号(LBKDIF 标志置位)。 但是,正常的 UART 数据通信不起作用。 在正常 UART 模式下,RX 和 TX 正常工作。 示波器测量结果显示,在发送中断期间,PC 的 TX 线路在预期的持续时间(约 2100 毫秒)内保持低电平。 问题 RT1170 LPUART 是否会出现这种行为? 有没有既能检测 PC 发送 BREAK,又能进行正常 UART 通信的推荐方法? 如果您能指导我如何在保持 RT1170 正常 UART 数据接收的同时可靠地检测到来自 PC 的发送中断(Send BREAK),我将不胜感激。 感谢您的帮助。 顺祝商祺! Re: Issue with LPUART1 BREAK Detection on RT1170 亲爱的恩智浦支持团队 感谢您之前的解释和对 RT1170 参考手册的参考。 根据 RM 的描述,我们可以理解当LBKDE = 1 时,LIN 中断检测电路被启用,接收到的数据不会写入 RX FIFO,因此正常的 UART 接收会被有意禁用。我们承认这种行为是意料之中的。 不过,我们想就可能的替代方案或建议的解决方案提出一个后续问题。 我们的要求 检测来自 PC 的发送 BREAK条件(通过 USB-UART)。 同时,继续正常的 UART 数据收发。 不需要 LIN 协议栈;这是一般的 UART 通信,BREAK 用作同步或控制信号。 我们观察到的情况 LBKDE = 1时 LIN BREAK 检测正确(LBKDIF 已设置)。 正常 UART RX 数据被阻断,如 RM 所述。 LBKDE = 0时 正常 UART RX 正常工作。 我们的问题 RT1170 是否支持或推荐在不启用 LBKDE 的情况下,在保持正常 UART RX 激活的同时检测发送中断(Send BREAK)的方法? 是否认为使用成帧错误 (FE) + RX FIFO 清除是非 LIN UART BREAK 检测的预期解决方法? 在使用 LBKDE 与普通 UART 通信时,是否存在任何勘误、未注明的设置或硬件限制? 如果不支持这种使用情况,能否请您确认RT1170 LPUART 在设计上不支持同时进行 LIN BREAK 检测和正常 UART 接收? 如果您能确认或推荐任何最佳做法,我们将不胜感激。 非常感谢你们一如既往的支持。 顺祝商祺! Re: Issue with LPUART1 BREAK Detection on RT1170 你好@dskim2、 感谢您关注恩智浦 MIMXRT 系列! 您所描述的现象是意料之中的。请参阅 RM 的以下解释: Gavin_Jia_0-1768802115983.png 此外,我们的一位同事也实现了类似的功能,或许对您有所帮助: 1.https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/RT1170-LIN-driver-development-and-stack-porting/ta-p/1356144 2.https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Use-RT1060-STAT-LBKDE-to-detect-Lin-quot-break-quot-but-cannot/m-p/1458242 致以最诚挚的问候, Gavin
View full article
i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Hello, I am currently evaluating the H265 decode → encode pipeline on i.MX95 and I am observing significantly worse latency and stability compared to i.MX8MP, using similar workloads and configurations. Context On i.MX8MP, using: imxvpudec_h265 vpuenc_hevc I am able to achieve: Very low end-to-end latency (≈ 10 ms) Stable operation with multiple streams No visible freezes or artifacts On i.MX95, using: v4l2h265dec v4l2h265enc I observe: ~90 ms latency for a single decode → encode pipeline Freezes and visual artifacts when running 4 simultaneous camera streams Test pipeline To reproduce the issue, I used IP cameras (H265 over RTSP) with the following pipeline: test-launch "( rtspsrc location=rtsp://10.42.0.85 drop-on-latency=true latency=0 buffer-mode=4 ! rtph265depay ! h265parse config-interval=1 ! v4l2h265dec ! v4l2h265enc ! rtph265pay name=pay0 pt=96 )" This pipeline works correctly with a single camera, but when scaling to 4 cameras, freezes and artifacts start to appear. Questions Why is the H265 VPU pipeline on i.MX95 significantly more latent than on i.MX8MP? Is DMABUF zero-copy fully supported between v4l2h265dec and v4l2h265enc on i.MX95? If not, is there an implicit memory copy that could explain the additional latency and bandwidth pressure? Are there known limitations in the current i.MX95 VPU driver regarding: Low-latency operation Multi-stream decode + encode Internal buffering depth Are there recommended V4L2 controls or io-modes (capture/output-io-mode) to minimize latency on i.MX95? Is the i.MX95 VPU driver expected to reach performance parity with i.MX8MP in future BSP releases, or is the higher latency an inherent design tradeoff? Goal My objective is real-time, low-latency video processing (decode → process → encode), similar to what is achievable on i.MX8MP. Thank you for your support. Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Hello, Which BSP version are you using on i.MX8MP and i.MX95 to recreate this issue? Are you using the same GST pipeline (other than the decoder/encoder elements) on both 8MP and 95? AFAIK, there is no known limitation that results in high latency on i.MX95. On i.MX95, encoder support mmap and dmabuf, which can make a pipeline to transfer dma-buf without copy b/w decoder and encoder. Does the IP camera encode without B frames? Then we can disable decode frame reorder, which will reduce the latency. Please check this. You can disable frame reorder using below v4l2 control " v4l2h264dec extra-controls="decode,display_delay_enable=1,display_delay=0" " You can list all v4l2 controls using below command: v4l2-ctl -l -d Regards Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) The kernel versions: imx95: 6.6.101-0 imx8mp: 6.6.84-0 Yes it is the same gstreamer pipeline. The IP camera encode without B frames. I tired your command and it doesn't solve the issue. There are still artifacts on the screen and the latency is high. However qualitatively speaking, it seems to remove the freezes. ``` v4l2-ctl -l -d /dev/v4l/by-path/platform-4c480000.vpu-video-index0 User Controls min_number_of_capture_buffers 0x00980927 (int) : min=1 max=32 step=1 default=1 value=1 flags=read-only thumbnail_mode 0x00981901 (bool) : default=0 value=0 flags=write-only Codec Controls h264_profile 0x00990a6b (menu) : min=0 max=4 default=0 value=0 (Baseline) hevc_profile 0x00990b67 (menu) : min=0 max=0 default=0 value=0 (Main) display_delay 0x00990b8d (int) : min=0 max=0 step=1 default=0 value=0 display_delay_enable 0x00990b8e (bool) : default=0 value=0 ``` ``` v4l2-ctl -l -d /dev/v4l/by-path/platform-4c480000.vpu-video-index1 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 rotate 0x00980922 (int) : min=0 max=270 step=90 default=0 value=0 flags=modify-layout min_number_of_output_buffers 0x00980928 (int) : min=1 max=32 step=1 default=1 value=1 flags=read-only Codec Controls video_gop_size 0x009909cb (int) : min=0 max=2047 step=1 default=30 value=30 video_bitrate_mode 0x009909ce (menu) : min=0 max=1 default=1 value=1 (Constant Bitrate) flags=update video_bitrate 0x009909cf (int) : min=1 max=1500000000 step=1 default=2097152 value=2097152 frame_level_rate_control_enable 0x009909d7 (bool) : default=1 value=1 h264_mb_level_rate_control 0x009909da (bool) : default=1 value=1 number_of_mbs_in_a_slice 0x009909dc (int) : min=0 max=262143 step=1 default=1 value=1 slice_partitioning_method 0x009909dd (menu) : min=0 max=1 default=0 value=0 (Single) force_key_frame 0x009909e5 (button) : value=0 flags=write-only, execute-on-write intra_refresh_period 0x009909ec (int) : min=0 max=2160 step=1 default=0 value=0 intra_refresh_period_type 0x009909ed (menu) : min=0 max=1 default=1 value=1 (Cyclic) h264_i_frame_qp_value 0x00990a5e (int) : min=0 max=51 step=1 default=30 value=30 h264_p_frame_qp_value 0x00990a5f (int) : min=0 max=51 step=1 default=30 value=30 h264_b_frame_qp_value 0x00990a60 (int) : min=0 max=51 step=1 default=30 value=30 h264_minimum_qp_value 0x00990a61 (int) : min=0 max=51 step=1 default=8 value=8 h264_maximum_qp_value 0x00990a62 (int) : min=0 max=51 step=1 default=51 value=51 h264_8x8_transform_enable 0x00990a63 (bool) : default=1 value=1 h264_cpb_buffer_size 0x00990a64 (int) : min=0 max=18750000 step=1 default=0 value=0 h264_entropy_mode 0x00990a65 (menu) : min=0 max=1 default=1 value=1 (CABAC) h264_i_frame_period 0x00990a66 (int) : min=0 max=2047 step=1 default=0 value=0 h264_level 0x00990a67 (menu) : min=0 max=16 default=14 value=14 (5) h264_loop_filter_alpha_offset 0x00990a68 (int) : min=-6 max=6 step=1 default=0 value=0 h264_loop_filter_beta_offset 0x00990a69 (int) : min=-6 max=6 step=1 default=0 value=0 h264_loop_filter_mode 0x00990a6a (menu) : min=0 max=2 default=0 value=0 (Enabled) h264_profile 0x00990a6b (menu) : min=0 max=4 default=4 value=4 (High) vertical_size_of_sar 0x00990a6c (int) : min=0 max=65535 step=1 default=0 value=0 horizontal_size_of_sar 0x00990a6d (int) : min=0 max=65535 step=1 default=0 value=0 aspect_ratio_vui_enable 0x00990a6e (bool) : default=0 value=0 vui_aspect_ratio_idc 0x00990a6f (menu) : min=0 max=17 default=0 value=0 (Unspecified) h264_constrained_intra_pred 0x00990a7f (int) : min=0 max=1 step=1 default=0 value=0 h264_chroma_qp_index_offset 0x00990a80 (int) : min=-12 max=12 step=1 default=0 value=0 hevc_minimum_qp_value 0x00990b58 (int) : min=0 max=51 step=1 default=8 value=8 hevc_maximum_qp_value 0x00990b59 (int) : min=0 max=51 step=1 default=51 value=51 hevc_i_frame_qp_value 0x00990b5a (int) : min=0 max=51 step=1 default=30 value=30 hevc_p_frame_qp_value 0x00990b5b (int) : min=0 max=51 step=1 default=30 value=30 hevc_b_frame_qp_value 0x00990b5c (int) : min=0 max=51 step=1 default=30 value=30 hevc_profile 0x00990b67 (menu) : min=0 max=0 default=0 value=0 (Main) hevc_level 0x00990b68 (menu) : min=0 max=8 default=7 value=7 (5) hevc_loop_filter 0x00990b6c (menu) : min=0 max=2 default=1 value=1 (Enabled) hevc_loop_filter_beta_offset 0x00990b6d (int) : min=-6 max=6 step=1 default=0 value=0 hevc_loop_filter_tc_offset 0x00990b6e (int) : min=-6 max=6 step=1 default=0 value=0 hevc_refresh_type 0x00990b6f (menu) : min=0 max=2 default=2 value=2 (IDR) hevc_num_of_i_frame_b_w_2_idr 0x00990b70 (int) : min=0 max=2047 step=1 default=0 value=0 hevc_constant_intra_prediction 0x00990b72 (int) : min=0 max=1 step=1 default=0 value=0 hevc_strong_intra_smoothing 0x00990b76 (int) : min=0 max=1 step=1 default=1 value=1 hevc_tmv_prediction 0x00990b79 (int) : min=0 max=1 step=1 default=1 value=1 prepend_sps_and_pps_to_idr 0x00990b84 (int) : min=0 max=1 step=1 default=1 value=1 frame_skip_mode 0x00990b86 (menu) : min=0 max=2 default=0 value=0 (Disabled) average_qp_value 0x00990b91 (int) : min=0 max=51 step=1 default=0 value=0 flags=read-only ``` Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) The BSP versions are : imx8mp: lf-6.6.52-2.2.0 imx95: lf-6.6.52-2.2.1 Thank you Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Yes the IP camera encode without B frames. I tried your command and it doesn't solve the issue. There are still artifacts on the screen and the latency is high. However qualitatively speaking, it seems to remove the freezes. Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) ok Also please confirm the B frame question I mentioned above. Regards Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Hello, To confirm: the IP cameras encode without B frames (I-P only). I have applied display_delay_enable=1, display_delay=0 on the decoder. This helped remove freezes, but the latency remains at ~90 ms. To isolate the bottleneck, I used the GStreamer element-latency tracer on this pipeline: ``` rtspsrc location=rtsp://... drop-on-latency=true latency=0 buffer-mode=4 !  rtph265depay ! h265parse config-interval=1 !  v4l2h265dec extra-controls="decode,display_delay_enable=1,display_delay=0" capture-io-mode=4 output-io-mode=4 !  v4l2h265enc extra-controls="encode,video_bitrate_mode=1,video_bitrate=2097152,frame_level_rate_control_enable=0,video_gop_size=30" capture-io-mode=4 output-io-mode=4 !  h265parse config-interval=1 ! rtph265pay name=pay0 pt=96 ``` Per-element latency results (640x480 @ 30fps, single stream): v4l2h265enc: ~67 ms v4l2h265dec ~2 ms all other elements < 1 ms The encoder alone accounts for ~67 ms (~2 frame periods). This is consistent across runs. The decoder is fine at ~2 ms. I have tried: frame_level_rate_control_enable=0 capture-io-mode=4 and output-io-mode=4 (DMABUF) on both encoder and decoder Minimal queue buffering between elements (max-size-buffers=1) None of these significantly reduce the encoder latency. My questions, focused on the encoder: Is the Wave6 encoder expected to hold 2 frames internally before producing output? Is there a way to reduce this internal buffering (similar to display_delay=0 on the decoder side)? Does output-io-mode=5 (DMABUF_IMPORT) work on the encoder to achieve zero-copy from upstream? Would this help latency? Is there a V4L2 control or driver parameter to enable a low-latency / zero-delay encoding mode on the Wave6? On i.MX8MP, vpuenc_hevc achieves ~10 ms for the same workload. Is this latency gap with v4l2h265enc on i.MX95 expected to improve in future BSP releases? Thank you for your help.
View full article
介绍 eRPC 本教程介绍eRPC(嵌入式远程过程调用)开源项目。 eRPC(嵌入式远程过程调用)是由恩智浦创建的远程过程调用(RPC)系统。RPC是一种机制,用于通过简易本地函数调用远程系统上的调用软件例程。远程系统可以是通过通信信道连接的任何CPU:例如,网络中的服务器、多核系统中的另一个CPU内核,等等。对客户端而言,这就像在应用中调用某个库中的函数一样。唯一的区别在于通信信道引入的任何延迟或不可靠性。 重要链接: 所有与 eRPC 开发相关的内容都位于:GitHub - eRPC base eRPC开发数据位于GitHub - eRPC development。 eRPC 发布版本位于:GitHub - eRPC Releases eRPC文档位于Github - eRPC wiki eRPC已作为Python软件包发布至pypi eRPC支持多核和多处理器类型的应用。 在哪里可以找到 eRPC 示例 在 NXP MCUXpressoSDK 软件包中可以找到大量 eRPC 多核和多处理器示例。访问 https://mcuxpresso.nxp.com 可配置、构建并下载这些软件包。 要获取支持多核(包含 eRPC)的开发板列表,请基于 “中间件 (Middleware)” 进行筛选,并搜索 “multicore” 关键词。下载包含多核中间件的选定软件包后,可参考以下路径: /boards/ /multicore_examples :eRPC 多核示例(使用 RPMsg_Lite 或消息单元传输)或者 /boards/ /multiprocessor_examples :eRPC 多处理器示例(使用 UART 或 SPI 传输)。 eRPC 示例均以 “erpc_” 为名称前缀。 获取 NXP MCUXpressoSDK 的 eRPC 多核和多处理器示例的另一种方法是使用 mcux-sdk 的 GitHub 代码库。请按照 README 概述部分中关于如何使用 West 工具克隆和更新 mcuxsdk 代码库的说明操作。完成后,armgcc 版本的 eRPC 示例可以在以下文件夹中找到: mcuxsdk/examples/ /multicore_examples or in mcuxsdk/examples/ /multiprocessor_examples folders. 例如,你可以使用 evkmimxrt1170 作为 board_name。与 MCUXpressoSDK 软件包类似,这些 eRPC 示例都使用 “erpc_” 作为名称前缀。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kunal,您好!您的问题似乎已在此得到解答:需要帮助——在iMx6sx中实现eRPC的分步过程?· 问题#5 · EmbeddedRPC/erpc-imx-demos · GitHub Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> HI [email protected]‌, 我不知道 eRPC 在 MPC5748G 上的官方使用方式。只是提醒一下:eRPC 取决于编程语言、操作系统和传输层。它没有特定于电路板的文件。所以,如果使用的是 FreeRTOS 和 C 语言,那几乎就成功了,你只需要移植你想用的传输层(如果还没有移植的话)。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan,       eRPC是否已移植到恩智浦MPC5748G?有没有可供参考的示例代码? 顺祝商祺! Alex Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi [email protected], 我在这方面没有太多经验。最近,当从多个任务中调用多个 eRPC 调用时,我们不得不添加一些互斥锁。不过我喜欢你的想法。 我快速浏览了一下源代码。你需要说明你的用例。但我认为是 i.MX Linux 与使用 RPMsg 的 M 核之间的通信。在这种情况下,我认为你可以像我们那样添加互斥锁(这将使 eRPC 调用序列化。你需要在 performRequest 函数的某个地方添加它们)。为每个线程创建端点在我看来是个好主意,但我发现有更多问题需要解决。一个更简单的解决方案可能是:传输初始化函数将初始化更多端点(基于任务数量),客户端的 eRPC rpmsg 发送 / 接收函数改为使用未使用的端点进行发送,并使用相同的端点接收消息,服务器上的 eRPC rpmsg 接收函数需要等待所有端点上的消息。 我不知道这对你来说是简单的任务还是更复杂的任务。但恐怕如果不修改代码,你将无法进行多线程调用。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, 我目前在Cubic与Chandini共事。我只是想了解一下从多个线程调用eRPC的额外信息。当前我们采用单一端点进行即止型调用,每次调用完成后才发起下一次调用。现在我们希望通过多个线程发起多次调用,因此想了解实现该功能的最佳方案。 其实由于我对这方面了解不足,我们尝试过并发进行其他调用,不过直到出现问题,我们才意识到正在这么做。 我们已观测到eRPC返回的通信故障错误代码。 是否可以使用单一端点来实现这一点,也就是说客户端这边是否应该是线程安全的? 如果不建议执行此操作,是否应该为每个线程配置独立的端点, 或者我们应该做别的事情吗? 此致 李 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi [email protected]‌, 感谢您告知我们。真有趣,我今天因为另一项目刚刚研读过相关方案:smileygrin: Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, 感谢您的快速回复。 通过在客户端和服务器端的套接字连接中禁用Nagle算法,并使用以下API调用,我可以在TCP中实现更好的性能(响应时间以微秒为单位)。 int result = setsockopt(sock, /* 受影响的套接字 */                         IPPROTO_TCP,     /* 在TCP级别设置选项 */ TCP_NODELAY, /* 选项名称 */ (char *) &flag, /* 类型转换是历史遗留问题 */ sizeof(int)); /* 选项值的长度 */ 参考资料:TCP_NODELAY:2018 年 TCP 优化最佳实践 | ExtraHop 谢谢! 萨西达兰。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi [email protected]‌, 或许您可以询问GitHub的相关用户(在同一主题下,或创建新主题)。至少有两名用户正在执行与TCP相关的任务: github: GitHub - EmbeddedRPC/erpc: Embedded RPC 线程1:使用具备TCP传输功能的多连接处理服务器 · 问题#32 · EmbeddedRPC/erpc · GitHub 讨论帖 2:TCP Example client /server code・Issue #39・EmbeddedRPC/erpc・GitHub 就个人而言我建议这个方案,但不确定是否适用于您的情况:linux - Ubuntu上的低延迟TCP设置 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, 我想要将eRPC移植到TCP套接字上。 我在虚拟串口(Linux 系统内)上运行了你的示例测试代码 (test_arrays),串口的响应时间不到 1 毫秒。 当我通过TCP运行同一示例代码时,TCP的响应时间约为90毫秒。 有没有办法像优化串口那样,降低 TCP 的延迟并提升其性能呢? 谢谢! 萨西达兰。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi, Dusan. 这很有帮助。顺便说一下,示例的头文件中提到了这一点。 来自A9的函数调用运行良好,M4则可返回数据。 但当前问题出现在M4调用函数时。A9中显示如下错误:“MU传输缓冲等待清空超时!imx_mu_rpmsg_send()失败,错误码:-5”。 在出现此错误之后,数据函数调用也无法在另一端正常运行:“rpmsg_multiept rpmsg0: virtqueue_add_outbuf失败,错误码:-5” 我应该检查什么? 感谢您的帮助。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vadim, 通常情况下,您需要执行两项任务。一项针对客户端,另一项则针对服务器。问题还在于erpc_arbitrated_client_init的输出结果应作为参数传递给初始化服务器。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,Dusan、Marek、社区。 我已经使用eRPC创建多个应用,M4(客户端)-A9(服务器)或M4(服务器)-A9(客户端)均能正常运行,但我希望在各端使用客户端/服务器应用。不过它现在无法正常工作或运行,只要从一端执行一次,应用就会挂起。 我想检查一下代码的整体结构。 我哪里做错了呢? 是不是应该在 M4 上为客户端和服务器分别使用两个独立的 FreeRTOS 任务? M4 . . erpc_transport_t transport = erpc_transport_rpmsg_lite_rtos_remote_init(.....); erpc_mbf_t message_buffer_factory = erpc_mbf_rpmsg_init(transport); erpc_server_init(transport, message_buffer_factory); erpc_add_service_to_server(create_TEST_service()); erpc_arbitrated_client_init(transport, message_buffer_factory); while (true) { erpc_server_poll(); function1(....); } A9 . . erpc_transport_t transport = erpc_transport_rpmsg_linux_init(......); erpc_mbf_t message_buffer_factory = erpc_mbf_dynamic_init(); erpc_server_init(transport, message_buffer_factory); erpc_add_service_to_server(create_TEST_service()); erpc_arbitrated_client_init(transport, message_buffer_factory); while (true) { erpc_server_poll(); function2(....); } Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> vadimfilippenko,您好!如果您仍然对使用Python版本的话题感兴趣,可以查看此线程:将MPU补丁添加到内核中 - 我无法查看新模块 · 问题#2 · EmbeddedRPC/erpc-imx-demos · GitHub。来自mhanuel26 的最后两条消息值得您关注,因其已成功使用python应用。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Dusan, Marek, 我终于成功启动了修改后的 eRPC 示例。不过在 Linux 端我用的是 C 语言,且在 M4 端使用的是 eRPC 1.5.0 版本,其中 rpmsg 初始化函数带 6 个参数(这是杜尚在 GitHub 上提到的关于第 6 个参数的提示)。感谢你们的帮助。准备好迎接新的问题吧) Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您需要在运行python应用之前运行M4应用。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vadim, 请在这里贴出:ls /sys/class/rpmsg 的结果 看起来 M4 没有发送命名服务(M4 是否运行了正确的固件?)。正因为如此,没有创建来自 M4 的动态宣告通道的文件夹,因此 Python 无法创建 rpmsg 传输... 请检查你的 M4 内核打印输出。 此致, Marek Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vadim,  正如你在其他评论中看到的,我一直努力尽快回复。但这周(可能还有下周)我比较忙。 不过,从你遇到的错误来看,你应该对比一下 transport.py 中 RpmsgTransport 类里的初始化函数, 以及erpc-imx-demos/sysfs.py at master · EmbeddedRPC/erpc-imx-demos · GitHub   - class RpmsgEndpoint 请确保 GitHub - EmbeddedRPC/erpc-imx-demos: eRPC demos for i.MX devices 是最新版本,且子仓库已根据与 erpc-imx-demos 匹配的提交进行了检出 也许mareknovak能更准确地指出问题所在。 看起来 如果self.id == -1: raise Exception() 返回 -1 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 有人能帮我解决以下问题吗? 我正在 iMX6COM 开发板上使用 erpc-imx-demos 中的 eRPC 演示示例。 在M4侧启动演示应用程序: "硬件已初始化 eRPC已初始化 MatrixMultiply服务已添加" 在 Linux 中添加驱动: "root@imx6sxea-com:~# modprobe -v rpmsg_multiept insmod /lib/modules/4.1.15-2.0.3+geb0b90b/kernel/drivers/rpmsg/rpmsg_multiept.ko" (系统并未反馈关于rpmsg通道已创建的信息,并且sys/class/rpmsg目录下的rpmsg文件夹为空) 在 Linux 上启动 appl 演示: 回溯(最近一次调用在最后): 文件"example.py",第111行,在 transport = erpc.transport.RpmsgTransport() 文件"build/bdist.linux-armv7l/egg/erpc/transport.py",第 199 行,在 __init__ 文件 "build/bdist.linux-armv7l/egg/rpmsg/sysfs.py" 中,第 116 行,在__init__ 异常 异常类型错误:'需要整数' 在 <绑定方法 RpmsgEndpoint.__del__ of > 被忽略 附言: 我已构建M4 eRPC演示应用,所用平台为cmake和eclipse。 M4 rpmsg演示应用运行良好。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vakul, 抱歉,我错过了您的评论。目前我们不支持任何加密传输。但由于eRPC是模块化的,我认为您可以轻松地将此功能添加到您的eRPC项目中。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi eRPC 通信能否通过某种加密传输方式(例如 TLS)来保障安全? 此致 Vakul Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,Evgeny,目前我们对此还没有预估。但我认为你可以通过编写自己的 erpc_malloc/erpc_free 函数实现来编写/使用自己的分配器。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, 是否计划在其他部分(例如erpcMatrixMultiply_shim 的生成等效实现)中增加更多静态内存分配?每个输入参数是否都需要动态分配内存(从编解码器填充数据后,在函数调用结束时释放)? 比如将预先分配的内存(由用户应用静态分配)传递给框架? 谢谢! Evgeny Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,Evgeny,这看起来像是 MCUExpresso 项目文件/ IDE 的问题。顶层文件夹名称应该是虚拟目录,未来这些目录将不会存在。你磁盘上的软件包中,eRPC 的目录结构应该与 GitHub 上的类似。GitHub 的目录结构更为推荐。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, 我注意到ERPC在运行时使用了大量动态内存分配。是否有计划使其更适合嵌入式系统,并添加静态内存分配方案? 编辑: 很抱歉我刚才的问题,我确实在代码仓库中看到了 erpc_setup_mbf_static.cpp 文件。问题在于,我的代码是基于 MCUXpresso SDK 中提供的示例 ——frdmk66f_multiprocessor_examples_erpc_server_matrix_multiply_spi 和 frdmk66f_multiprocessor_examples_erpc_client_matrix_multiply_spi。这些示例的目录结构与代码仓库中的代码大不相同。 所以我的问题再问一次,应该使用 SDK 示例的目录结构还是代码仓库中的呢?它们为什么会有这么大的差异? 谢谢! Evgeny  Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Evgeny, 首先:您是否正在使用 develop 分支中的 smac.erpc(并且应用程序是从该分支构建的)?对我来说,这个版本是可以正常工作的。 目前erpcgen应用版本和其余eRPC代码已连接。这意味着如需使用您从github构建的新版erpcgen应用,则必须将github上的github erpc_c/*文件复制至您的示例中。然后,您可以使用新版erpcgen应用重新生成代码,更新应用(erpc初始化 + 传输)功能,其他部分即可正常运行。否则,如果您不更新erpc_c文件,则必须使用提供的erpcgen应用。 查看这个页面的底部内容:入门指南・EmbeddedRPC/erpc Wiki・GitHub,对于较新的 erpcgen 版本来说,该内容应该是相当新的。 我不确定最新提交是否已修改spi,建议您暂时使用旧版实现。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hey Dusan, 当我使用自己编译的 erpcgen.exe 时,我在 smac.erpc 示例中遇到了相同的错误: error: file smac.erpc:135:5: syntax error, unexpected identifier, expecting '}' 我之前提到的目录结构是存储库中的erpc_c目录,并且: 来自SDK示例。哪个目录结构是“正确”的?结合使用我生成的文件与SDK示例代码是否安全? 谢谢! Evgeny Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hey dusancervenka-b51352, 感谢您的快速回复!我克隆了开发分支。我注意到erpc_c目录结构与Kinetis SDK提供的示例有很大不同。哪一个更合适? 谢谢! Evgeny Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi evgenyerlihman‌, 实际上,我们正在进行更频繁地更新。您需要切换到开发分支。GitHub - EmbeddedRPC/erpc at develop。最后一次代码更新是昨天。但您需要在该此构建erpcgen应用。有了smac IDL,就能正常运行。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi dusancervenka-b51352, 我正在考虑将 eRPC 框架用于我正在开发的一款新产品,该产品使用多个 NXP 的 Kinetis 器件。我注意到 eRPC 的 GitHub 仓库最后一次更新是在 6 个月前。我的问题是,这个框架目前还在维护、修复和开发吗?我尝试了 GitHub 上的示例: erpcgen.exe smac.erpc 并且它未能生成 cpp 源代码,出现了错误。 erpcgen可执行文件来自MCUXpresso SDK。 谢谢! Evgeny Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,Chandini, 没关系。我也刚休完长假,希望您度过了一段美好时光。 我已通过社区消息系统(私信)给你发了邮件。 我们可以通过邮件详细讨论。大致流程是,你需要在 GitHub 上创建分支,切换到开发分支,应用你的修改,创建提交记录,再发起拉取请求。我们会审核你的修改,提出修改建议,之后将其合并到开发分支。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan , 非常抱歉回复迟了,我刚结束长假回来。已与团队成员进行内部沟通,请提供您的电子邮箱地址以便我们转发资料。根据公司政策,我们无法直接将任何内容直接上传至您的github。 谢谢 Chandini Re: Introducing eRPC 嗨,杜桑 、 当然,我会与我的前辈讨论并创建拉取请求。目前我正在度假,抱歉迟复。 谢谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,Chandini。很高兴你成功了。我有一个特别的提议,你能否在 eRPC 的 GitHub 开发分支上,就你新创建的传输层提交一个拉取请求(基于开发分支)?或许还需要做些工作才能让它与更新版本的 eRPC 兼容。但如果你不想更新的话,我可以来做:)通过在 GitHub 上提交拉取请求,你将成为有价值的贡献者,并且会永远出现在贡献者历史记录中。 希望 eRPC 能成为你的理想解决方案。我们会一直在这儿(或 GitHub 上)为你提供帮助:) Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi dusancervenka-b51352 , b50844 , novakma7   终于恢复正常运行,演示程序现可在Linux上配合我的c++代码运行。 非常感谢各位回答了我所有的问题。:) 特别感谢Dusan:smileyhappy 谢谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> HI Dusan , 由于我昨天忙于其他任务,所以未能进行任何尝试。今天我会进行尝试,并及时通知您。 我觉得我得稍微修改一下我的函数,再进行尝试。因为到目前为止,我在发送和接收函数中只传递了 char * 类型的数据。 很快会回来找您。 谢谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Chandini,您好!是的,没错。我当时不在公司,所以无法获知具体功能的名称。此功能是否能正常运行? Re: Introducing eRPC 你好,杜桑 感谢您的答复: write(fd、 >getBuffer(), >getUsed()😞 我可以看到getused函数(位于erpc/message_buffer.h at 9e18d069aeae19a6e80a5e8783903bc63bd9b567 · EmbeddedRPC/erpc · GitHub中),但找不到getbuffer函数。 我想我必须用下面这个函数来获取我的缓冲区,对吗? /*! * @brief This function returns pointer to buffer to read/write. * * @return Pointer to buffer to read/write. */ uint8_t *get() { return m_buf; } 因此函数为如下形式: send :erpc_status_t send(MessageBuffer *message) { write(fd, message->get, message->getUsed())};  谢谢 chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,chanidi,您需要以不同的方式来做:您必须使用 transport.h。如果您不使用它,它将无法正常工作。 也许您可以使用我上面提到的 ioctl 命令: erpc_status_t receive(MessageBuffer *message) {int fd = open("/dev/rpmsg_ept1024.1", O_RDWR);} 发送:erpc_status_t send(MessageBuffer *message) { write(fd, message->getBuffer(), message->getUsed())}; 读取:erpc_status_t receive(MessageBuffer *message){size_t size = read(fd, message->getBuffer(), 500); message->setUsed(size)}; novakma7您能否确认操作步骤? Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Dusan , Marek 是的,我也参考了那些文件,但是 我正在使用trasport.h创建传输层。但面临参数不匹配的问题 transport.h中的发送和接收函数以消息缓冲区作为参数,          virtual erpc_status_t receive(MessageBuffer *message) = 0;          virtual erpc_status_t send(MessageBuffer *message) = 0; 根据 example.py 我已经创建了我的 RpmsgEndpoint 类,该类需要以下参数       RpmsgEndpoint::receive(int maxlen) RpmsgEndpoint::send(char *buffer,int dst) 根据我的理解,我们只需要从 Linux 中读取和写入 /dev/rpmsg_ept1024.1 设备即可。   所以我在想,与其使用 transport.h,或许我需要创建自己的 transport.h 版本? 感谢大家 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 不客气。您可以从/erpc-imx-demos/middleware/erpc/transport/文件夹汲取灵感。有多种传输方式。 Re: Introducing eRPC 非常感谢 Dusan 的快速回复 ,我将继续沿着这条路走下去,不久后再来找你。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,Chandini。您是对的。这些步骤是正确的。您需要创建继承自transport.h的类 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Marek 我还有一个问题。 目前我的工作状态: 我已在c++中实现RpmsgEndpoint类 我正在研究如何让我的客户端应用程序现在正常运行。 erpc-imx-demos/MPU/example_erpc at master · EmbeddedRPC/erpc-imx-demos · GitHub中的 Python example.py调用继承自Transport类的 RpmsgTransport。 我的问题是,我是否应该使用transport.h(位于/erpc-imx-demos/middleware/erpc/erpc_c/infra)来确保应用正常运行。 以便我创建RpmsgTransport类,并在客户端应用中调用它。 我这样想对吗? 先感谢您 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 是的,你说得对。 Python 所做的一切都只是对文件的 IO 操作(读/写)。这在任何语言中都可以实现,包括 C/C++。 选择 Python 来演示是因为它在 Linux 用户空间中很受欢迎,但你完全可以将其移植到 C 语言中。 我想我们现在的理解是一致的了。 祝您好运! 祝好, Marek Re: Introducing eRPC 你好,马雷克 感谢您的答复,它消除了我的一些疑惑。 我们不打算在两边都使用 FreeRTOS。 我们的计划是   M4 核 - 运行 FreeRTOS—— 这一点在你们的演示中已经实现了 A7 核 - 运行 Linux—— 你们的演示中有 Python 代码,用于利用内核的 RPMSG 实现   我们只需要用C或C++来代替Python。 我认为我们可以轻松地将 Python 代码移植到 C 或 C++,对吗? 谢谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,Chandini Indavara Basavaraju, RPMSg-Lite是RPMsg协议的实现,仅适用于运行 FreeRTOS或裸机的M4端。 在Linux/A7端,您可以放心使用内核中的RPMsg实现。(例如:GitHub - EmbeddedRPC/erpc-imx-demos:i.MX设备的eRPC演示) 或者你是打算在 M4 和 A7 两个内核上都运行 FreeRTOS?这种情况下它是可以工作的,但这并非标准用例。这需要你为 A 内核创建一个移植层,并让 FreeRTOS 在那里运行。 希望这能给你一些方向, Marek Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Marek 不知怎的,我漏掉了你的消息,对此我很抱歉 非常感谢 。我会尽快尝试您的最新版本。 您能否回答我关于RPMSG传输层的最后一个问题? 谢谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,我理解您。 您需要新建一个(此外还可根据需求,通过github上的拉取请求将其添加到我们的存储库)。 在 Linux 端,您可以使用 /dev/ttyRPMSG(如果系统中存在)。   例如,在此处创建新的传输erpc_c/transports with: 初始化可以像这样: int fd = open("/dev/ttyRPMSG", O_RDWR); 发送:write(fd, buffer, buffer_size); read:size_t size = read(fd, buffer, expected size); 如果没有这样命名的设备,你可以从 Python 代码中获取灵感。RPMSG 不是我的专长。我不知道在 Linux 上应该如何使用它。我会把你的问题转发给 Marek。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan , Marek 我计划的是: 在 M4(freertos)和 A7(Linux)上使用rpmsg-lite 我需要: RPMSG C 包装器(在 erpc_c/setup 下),可在 M4 和 A7 侧使用 RPMSG 传输层(在 erpc_c/transports 下),可在 M4 和 A7 侧使用 我有以下问题: 请问,您是否有适用于该场景的传输层? 或 我们是否需要参考 rpmsg-python 并写出类似的内容? 任何建议都会非常有帮助 感谢大家 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,我不确定是否有您需要的信息(Linux端的c传输)。但新建一个也很简单。您可以从/dev/ttyRPMSG(如果系统中存在)读取和写入。 例如: 初始化操作如下: int fd = open("/dev/ttyRPMSG", O_RDWR); 发送:write(fd, buffer, buffer_size); 读取:size_t size = read(fd, buffer, expected size); mareknovak或许能就该问题分享更多专业见解。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan , 感谢您告知我此次更新。 我想现在我对ERPC有了初步的了解。一旦我让RPMSG客户端应用程序正常运行,我就可以更新ERPC版本。 我开始研究rpmsg-lite,其中包含M4平台文件。 我想知道是否有适用于A7平台的方案?任何相关信息都将大有帮助。我的主要目标是使用C语言获取客户端应用,并使用RPMSg作为传输层 谢谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我很高兴您能够独立解决问题(对我们而言,这意味着该问题对开发人员来说并不复杂)。此外,正如mareknovak在上述评论中提到的那样, 他已经在存储库中更新其imx演示应用。您在进行下一步操作可以使用该版本,因其已采用新的rpc功能 Re: Introducing eRPC 感谢您的回复 这正是我想要的信息,我已经为 TCP 创建了 C 语言包装器,在对 eRPC 做了几处修复后,它运行得很顺利。 我的下一步是将TCP层替换为rpmsg。 再次感谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,Chandini Indavara Basavaraju, 我刚刚更新了 GitHub 上的 erpc-imx-demos 仓库(链接:GitHub - EmbeddedRPC/erpc-imx-demos: eRPC demos for i.MX devices),使其适配 eRPC 1.4.0 和 RPMSg-Lite 1.1.0。 你可以下载预编译的 erpcgen 应用程序,它用于代码生成,下载地址是:Release v1.4・EmbeddedRPC/erpc・GitHub,在下载部分选择适合你的架构即可。 然后你可以这样调用它:./erpcgen -gpy 接口定义语言文件名.erpc,这会为你生成 Python 的序列化和反序列化垫片代码。如果你省略 - gpy 参数或指定 - gc,将会得到 C 语言的垫片代码。 erpc-imx-demos 仓库的最新提交中也更新了序列化 / 反序列化垫片代码,你可以放心使用。 欢迎以拉取请求的形式提交你的修改, 感谢你使用 eRPC 和 RPMsg-Lite! Marek Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,目前我们在 GitHub 仓库中没有示例。但是我们在那里有 C(c++) 测试。如果您熟悉 Linux 或 Mac,您可以以此为例。其他选项如上所述: 1. 下载支持的开发板的 SDK -> 多核/多处理器 C/Python 示例。 2. 阅读这篇文章:入门指南・EmbeddedRPC/erpc Wiki・GitHub Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan 请问你们有 C 语言的客户端应用示例吗?不是 Python 的那种。或者你们有计划编写一个吗?如果已经有的话,那会非常有用,能帮上大忙。 先感谢您 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 终于成功了,非常感谢你的帮助:)Dusan 抱歉未找到附件选项以上传补丁,故将内容粘贴如下: 来自 7a5b152524a3c82b5bced4a72ed396f21860b666 2001年9月17日星期一00:00:00 日期:2017年5月8日星期一11:33:05 +0100 主题:[补丁]修复问题以运行eRPC_demo演示 --- erpc_c/infra/transport.h | 4 +- erpc_c/setup/erpc_server_setup.cpp | 36 ++++- erpc_c/setup/erpc_server_setup.h | 2 +- erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp | 54 +++++++ erpc_c/setup/erpc_transport_setup.h | 18 ++- erpc_c/transports/rpmsg_lite_rtos_transport.cpp | 158 ++++++++++++++++++ erpc_c/transports/rpmsg_lite_rtos_transport.h | 177 +++++++++++++++++++++ erpc_c/transports/rpmsg_rtos_transport.h | 147 +++++++++++++++++ erpc_python/erpc/transport.py | 21 +++ 9 files changed, 602 insertions(+), 15 deletions(-) create mode 100644 erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp create mode 100644 erpc_c/transports/rpmsg_lite_rtos_transport.cpp create mode 100644 erpc_c/transports/rpmsg_lite_rtos_transport.h create mode 100644 erpc_c/transports/rpmsg_rtos_transport.h diff --git a/erpc_c/infra/transport.h b/erpc_c/infra/transport.h index eb7ec71..fd4862a 100644 --- a/erpc_c/infra/transport.h +++ b/erpc_c/infra/transport.h @@ -48,7 +48,7 @@ //////////////////////////////////////////////////////////////////////////////// namespace erpc { - +class MessageBuffer; /*! * @brief 传输层的抽象接口。 * @@ -89,7 +89,7 @@ public: * * @return基于发送实现。 */ - virtual erpc_status_t send(MessageBuffer *message) = 0; + virtual erpc_status_t send(const MessageBuffer *message) = 0; /*! * @brief 轮询传入消息。 diff --git a/erpc_c/setup/erpc_server_setup.cpp b/erpc_c/setup/erpc_server_setup.cpp index 51fa799..5cd4346 100644 --- a/erpc_c/setup/erpc_server_setup.cpp +++ b/erpc_c/setup/erpc_server_setup.cpp @@ -33,8 +33,10 @@ #include "basic_codec.h" #include "manually_constructed.h" #include "simple_server.h" -#include +#include "message_buffer.h" +#include "erpc_config_internal.h" #include +#include #if !(__embedded_cplusplus) using namespace std; @@ -43,6 +45,29 @@ using namespace std; using namespace erpc; //////////////////////////////////////////////////////////////////////////////// +// 类 +//////////////////////////////////////////////////////////////////////////////// + +class BasicMessageBufferFactory : public MessageBufferFactory +{ +public: + virtual MessageBuffer create() + { + uint8_t *buf = new (nothrow) uint8_t[ERPC_DEFAULT_BUFFER_SIZE]; + return MessageBuffer(buf, ERPC_DEFAULT_BUFFER_SIZE); + } + + virtual void dispose(MessageBuffer *buf) + { + assert(buf); + if (*buf) + { + delete[] buf->get(); + } + } +}; + +//////////////////////////////////////////////////////////////////////////////// // 变量 //////////////////////////////////////////////////////////////////////////////// @@ -50,29 +75,32 @@ using namespace erpc; static ManuallyConstructed s_server; SimpleServer *g_server; +static ManuallyConstructed s_msgFactory; static ManuallyConstructed s_codecFactory; //////////////////////////////////////////////////////////////////////////////// // 代码 //////////////////////////////////////////////////////////////////////////////// -void erpc_server_init(erpc_transport_t transport, erpc_mbf_t message_buffer_factory) +void erpc_server_init(erpc_transport_t transport) { // 初始化工厂。 + s_msgFactory.construct(); s_codecFactory.construct(); // 使用提供的传输初始化服务器。 s_server.construct();s_server->setTransport(reinterpret_cast (transport)); + s_server->setMessageBufferFactory(s_msgFactory); s_server->setCodecFactory(s_codecFactory); - s_server->setMessageBufferFactory(reinterpret_cast (message_buffer_factory)); g_server = s_server; } - void erpc_server_deinit() { + s_msgFactory.destroy(); s_codecFactory.destroy(); s_server.destroy(); + } void erpc_add_service_to_server(void *service) diff --git a/erpc_c/setup/erpc_server_setup.h b/erpc_c/setup/erpc_server_setup.h index 8e6a6ef..e4e9eaa 100644 --- a/erpc_c/setup/erpc_server_setup.h +++ b/erpc_c/setup/erpc_server_setup.h @@ -60,7 +60,7 @@ extern "C" { * * 此函数用于初始化服务器,且包含运行服务器所需的所有组件。 */ -void erpc_server_init(erpc_transport_t transport, erpc_mbf_t message_buffer_factory); +void erpc_server_init(erpc_transport_t transport); /*! * @brief 此函数用于取消初始化服务器。 diff --git a/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp b/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp new file mode 100644 index 0000000..b480d42 --- /dev/null +++ b/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp @@ -0,0 +1,54 @@ + /* + * Copyright (c) 2014-2016, Freescale Semiconductor, Inc. + * + * 允许以源代码或二进制形式重新分发和使用,无论是否修改, + * 只要满足以下条件: + * + * o 重新分发的源代码必须保留上述版权声明、本 + * of 条件列表以及以下免责声明。 + * + * o 以二进制形式重新分发时,必须在随分发提供的 + * 提供的文档和/或 + * 其他材料中复制上述版权声明、此条件列表和以下免责声明。 + * + * o 未经事先书面许可,不得使用Freescale Semiconductor, Inc.的名称或其 + * 贡献者的姓名来认可或推广由此 + * 软件衍生的产品。 + * + * 本软件由版权所有者和贡献者“按原样”提供,并且 + * 不提供任何明示或暗示的担保,包括但不限于 + * 对适销性和针对特定用途的适用性的暗示担保 + * 免责声明。在任何情况下,版权所有者或贡献者均不对 + * 任何直接、间接、偶然、特殊、惩戒性或后果性的损害 + *(包括但不限于采购替代商品或服务; + * 使用、数据或利润损失;或业务中断)负责,无论其由 + * 何种原因引起,也无论其基于何种责任理论,无论是在合同、严格责任还是侵权行为 + *(包括疏忽或其他行为)中,以任何方式因使用本 + *软件而引起,即使已被告知可能发生此类损害。 + */ + +#include "manually_constructed.h" +#include "rpmsg_lite_rtos_transport.h" +#include "erpc_transport_setup.h" + +using namespace erpc; + +//////////////////////////////////////////////////////////////////////////////// +// 变量 +//////////////////////////////////////////////////////////////////////////////// + +static ManuallyConstructed s_transport; + +//////////////////////////////////////////////////////////////////////////////// +// 代码 +//////////////////////////////////////////////////////////////////////////////// + +erpc_transport_t erpc_transport_rpmsg_lite_rtos_remote_init( + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice) +{ + s_transport.construct(); + s_transport->init(src_addr, dst_addr, start_address, rpmsg_link_id, ready_cb, send_nameservice); + return reinterpret_cast (s_transport.get()); +} + + diff --git a/erpc_c/setup/erpc_transport_setup.h b/erpc_c/setup/erpc_transport_setup.h index 798d92f..6c3959e 100644 --- a/erpc_c/setup/erpc_transport_setup.h +++ b/erpc_c/setup/erpc_transport_setup.h @@ -34,6 +34,7 @@ #include "erpc_version.h" #include +#include /*! * @addtogroup transport_setup @@ -48,7 +49,7 @@ //! @brief 不透明传输对象类型。 typedef struct ErpcTransport *erpc_transport_t; //! @brief RPMsg-Lite传输就绪回调对象类型。-typedef void (*rpmsg_ready_cb)(void); +//typedef void (*rpmsg_ready_cb)(void); //////////////////////////////////////////////////////////////////////////////// // API @@ -106,21 +107,21 @@ erpc_transport_t erpc_transport_rpmsg_lite_master_init(unsigned long src_addr, /*! * @brief 创建RPMsg-Lite零拷贝传输。 */ -erpc_transport_t erpc_transport_rpmsg_lite_zc_master_init(unsigned long src_addr, - unsigned long dst_addr, - int rpmsg_link_id); +//erpc_transport_t erpc_transport_rpmsg_lite_zc_master_init(unsigned long src_addr, +// unsigned long dst_addr, +// int rpmsg_link_id); /*! * @brief 创建RPMsg-Lite传输。 */ erpc_transport_t erpc_transport_rpmsg_lite_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); /*! * @brief 创建RPMsg-Lite零拷贝传输。 */ -erpc_transport_t erpc_transport_rpmsg_lite_zc_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); +//erpc_transport_t erpc_transport_rpmsg_lite_zc_remote_init( +// unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); /*! * @brief 创建RPMsg-Lite RTOS传输。 @@ -133,7 +134,8 @@ erpc_transport_t erpc_transport_rpmsg_lite_rtos_master_init(unsigned long src_ad * @brief 创建RPMsg-Lite RTOS传输。 */ erpc_transport_t erpc_transport_rpmsg_lite_rtos_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); + //@} diff --git a/erpc_c/transports/rpmsg_lite_rtos_transport.cpp b/erpc_c/transports/rpmsg_lite_rtos_transport.cpp new file mode 100644 index 0000000..e04ae91 --- /dev/null +++ b/erpc_c/transports/rpmsg_lite_rtos_transport.cpp @@ -0,0 +1,158 @@ +/* + * Copyright (c) 2015, Freescale Semiconductor, Inc. + * + * 允许以源代码或二进制形式重新分发和使用,无论是否修改, + * 只要满足以下条件: + * + * o 重新分发的源代码必须保留上述版权声明、本 + *条件列表以及以下免责声明。 + * + * o 以二进制形式重新分发时,必须在随分发提供的 + * 提供的文档和/或 + * 其他材料中复制上述版权声明、此条件列表和以下免责声明。 + * + * o 未经事先书面许可,不得使用 + * Freescale Semiconductor, Inc.的名称或其贡献者的姓名来认可或推广由此 + * 软件衍生的产品。 + * + * 本软件由版权所有者和贡献者“按原样”提供,并且 + * 不提供任何明示或暗示的担保,包括但不限于 + * 对适销性和针对特定用途的适用性的暗示担保 + * 免责声明。在任何情况下,版权所有者或贡献者均不对 + * 任何直接、间接、偶然、特殊、惩戒性或后果性的损害 + *(包括但不限于采购替代商品或服务; + * 使用、数据或利润损失;或业务中断)负责,无论其由 + * 何种原因引起,也无论其基于何种责任理论,无论是在合同、严格责任还是侵权行为 + *(包括疏忽或其他行为)中,以任何方式因使用本 + *软件而引起,即使已被告知可能发生此类损害。 + */ + +#include "rpmsg_lite_rtos_transport.h" +#include + +#if !(__embedded_cplusplus) +using namespace std; +#endif + +using namespace erpc; + +//////////////////////////////////////////////////////////////////////////////// +// 变量 +//////////////////////////////////////////////////////////////////////////////// +uint8_t RPMsgRTOSTransport::s_initialized = 0; +struct rpmsg_lite_instance *RPMsgRTOSTransport::s_rpmsg; + +//////////////////////////////////////////////////////////////////////////////// +// 代码 +//////////////////////////////////////////////////////////////////////////////// + +RPMsgRTOSTransport::RPMsgRTOSTransport() +: Transport() +, m_dst_addr(0) +{ +} + +RPMsgRTOSTransport::~RPMsgRTOSTransport() +{ + rpmsg_lite_deinit(s_rpmsg); + s_initialized = 0; +} + +erpc_status_t RPMsgRTOSTransport::init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, unsigned long length, int rpmsg_link_id) +{ + if (!s_initialized) + { + s_rpmsg = rpmsg_lite_master_init(base_address, length, rpmsg_link_id, RL_NO_FLAGS); + s_initialized = 1; + } + + m_rpmsg_queue = rpmsg_queue_create(s_rpmsg); + m_rpmsg_ept = rpmsg_lite_create_ept(s_rpmsg, src_addr, rpmsg_queue_rx_cb, m_rpmsg_queue); + + m_dst_addr = dst_addr; + return m_rpmsg_ept == RL_NULL ? kErpcStatus_InitFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice) +{ + if (!s_initialized) + { + s_rpmsg = rpmsg_lite_remote_init(base_address, rpmsg_link_id, RL_NO_FLAGS); + + /* Signal the other core we are ready */ + if (ready_cb != NULL) + { + ready_cb(); + } + + while (!rpmsg_lite_is_link_up(s_rpmsg)) + { + } + + s_initialized = 1; + } + + m_rpmsg_queue = rpmsg_queue_create(s_rpmsg); + m_rpmsg_ept = rpmsg_lite_create_ept(s_rpmsg, src_addr, rpmsg_queue_rx_cb, m_rpmsg_queue); + + if(send_nameservice) + { + rpmsg_ns_announce(s_rpmsg, m_rpmsg_ept, + "rpmsg-openamp-demo-channel", + 0); + } + + m_dst_addr = dst_addr; + return m_rpmsg_ept == RL_NULL ? kErpcStatus_InitFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::receive(MessageBuffer *message) +{ + int ret_val = rpmsg_queue_recv(s_rpmsg, m_rpmsg_queue, &m_dst_addr, (char *)message->get(), kRpmsgMessageBufferSize, + NULL, RL_BLOCK); + return ret_val != RL_SUCCESS ? kErpcStatus_ReceiveFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::send(const MessageBuffer *message) +{ + int ret_val = + rpmsg_lite_send(s_rpmsg, m_rpmsg_ept, m_dst_addr, (char *)message->get(), message->getUsed(), RL_BLOCK); + return ret_val != RL_SUCCESS ? kErpcStatus_SendFailed : kErpcStatus_Success; +} + +MessageBuffer RPMsgMessageBufferFactory::create() +{ + uint8_t idx = 0; + while (((m_freeBufferBitmap & idx) == 0) && (idx < kInitCountMessageBuffers)) + { + idx++; + } + + assert(idx < kInitCountMessageBuffers); + + m_freeBufferBitmap &= ~(1 << idx); + + uint8_t *buf; + buf = m_buffers[idx]; + + assert(NULL != buf); + return MessageBuffer(buf, kRpmsgMessageBufferSize); +} + +void RPMsgMessageBufferFactory::dispose(MessageBuffer *buf) +{ + assert(buf); + uint8_t *tmp = buf->get(); + + if (tmp) + { + uint8_t idx = 0; + while ((tmp != m_buffers[idx]) && (idx < kInitCountMessageBuffers)) + { + ++idx; + } + m_freeBufferBitmap |= 1 << idx; + } +} diff --git a/erpc_c/transports/rpmsg_lite_rtos_transport.h b/erpc_c/transports/rpmsg_lite_rtos_transport.h new file mode 100644 index 0000000..f1aec8a --- /dev/null +++ b/erpc_c/transports/rpmsg_lite_rtos_transport.h @@ -0,0 +1,177 @@ +/* + * Copyright (c) 2015-2016, Freescale Semiconductor, Inc. + * + * 允许以源代码或二进制形式重新分发和使用,无论是否修改, + * 只要满足以下条件: + * + * o 重新分发的源代码必须保留上述版权声明、本 + *条件列表以及以下免责声明。 + * + * o 以二进制形式重新分发时,必须在随分发提供的 + * 提供的文档和/或 + * 其他材料中复制上述版权声明、此条件列表和以下免责声明。 + * + * o 未经事先书面许可,不得使用 + * Freescale Semiconductor, Inc.的名称或其贡献者的姓名来认可或推广由此 + * 软件衍生的产品。 + * + * 本软件由版权所有者和贡献者“按原样”提供,并且 + * 不提供任何明示或暗示的担保,包括但不限于 + * 对适销性和针对特定用途的适用性的暗示担保 + * 免责声明。在任何情况下,版权所有者或贡献者均不对 + * 任何直接、间接、偶然、特殊、惩戒性或后果性的损害 + *(包括但不限于采购替代商品或服务; + * 使用、数据或利润损失;或业务中断)负责,无论其由 + * 何种原因引起,也无论其基于何种责任理论,无论是在合同、严格责任还是侵权行为 + *(包括疏忽或其他行为)中,以任何方式因使用本 + *软件而引起,即使已被告知可能发生此类损害。 + */ + +#ifndef _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_ +#define _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_ + +#include "transport.h" +#include "message_buffer.h" +#include "rpmsg_lite.h" +#include "rpmsg_queue.h" +#include "rpmsg_ns.h" + +/*! + * @addtogroup rpmsg_lite_rtos_transport + * @{ + * @file + */ + +//////////////////////////////////////////////////////////////////////////////// +// 定义 +//////////////////////////////////////////////////////////////////////////////// + +enum +{ + kRpmsgMessageBufferSize = RPMSG_BUFFER_SIZE, + kInitCountMessageBuffers = 2, +}; + +//////////////////////////////////////////////////////////////////////////////// +// 类 +//////////////////////////////////////////////////////////////////////////////// + +namespace erpc +{ +/*! + * @brief 使用RPMsg RTOS API进行进程间消息传递的传输。 + * + * @ingroup rpmsg_lite_rtos_transport + */ +class RPMsgRTOSTransport : public Transport +{ +public: + /*! + * @brief 构造函数。 + * + * 此函数用于初始化对象属性。 + */ + RPMsgRTOSTransport(); + + /*! + * @brief RPMsgRTOSTransport析构函数 + */ + virtual ~RPMsgRTOSTransport(); + + /*! + * @brief 此函数调用RPMsg rtos初始化函数 - 作为RPMsg主服务器 + * + * @Param[in] src_addr 源地址。 + * @Param[in] dst_addr 目标地址。 + * @Param[in] base_address 共享内存中的RPMsg基地址。 + * @Param[in] length RPMsg共享内存区域长度。 + * @Param[in] rpmsg_link_id 选择通信将在哪些内核之间进行。 + * + * @retval kErpcStatus_Success 当rpmsg初始化函数成功执行时。 + * @retval kErpcStatus_InitFailed 当rpmsg初始化函数未成功执行时。 + */ + virtual erpc_status_t init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, unsigned long length, int rpmsg_link_id); + + /*! + * @brief 此函数调用RPMsg rtos初始化函数 - 作为RPMsg远程 + * + * @Param[in] src_addr 源地址。 + * @Param[in] dst_addr 目标地址。 + * @Param[in] base_address 共享内存中的RPMsg基地址。 + * @Param[in] rpmsg_link_id 选择通信将在哪些内核之间进行。 + * @Param[in] ready_cb 在RPMsg初始化完成且内核就绪后调用的回调函数。 + * @Param [in] send_nameservice 如果为true,RPMsg主服务器会收到域名服务通知。 + * + * @retval kErpcStatus_Success 当rpmsg初始化函数成功执行时。 + * @retval kErpcStatus_InitFailed 当rpmsg初始化函数未成功执行时。 + */ + virtual erpc_status_t init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); + + /*! + * @brief 将传入消息存储于消息缓冲区。 + * + * 在无消息传入时进行循环。 + * + * @Param[in] message 消息缓冲区,用于存储传入的消息。 + * + * @retval kErpcStatus_ReceiveFailed 无法接收消息缓冲区。 + * @retval kErpcStatus_Success 成功接收所有数据。 + */ + virtual erpc_status_t receive(MessageBuffer *message); + + /*! + * @brief 函数用于发送就绪消息。 + * + * @Param[in] message 传递要发送的消息缓冲区。 + * + * @retval kErpcStatus_SendFailed 无法发送消息缓冲区。 + * @retval kErpcStatus_Success 成功发送所有数据。 + */ + virtual erpc_status_t send(const MessageBuffer *message); + +protected: + /* 远程设备 */ + struct remote_device *m_rdev; /*!< 代表第二个内核的设备。*/ + struct rpmsg_channel *m_app_rp_chnl; /*!< 代表两台设备(两个内核)间的连接。*/ + unsigned long m_dst_addr; /*!< rpmsg使用的目标地址。*/ + rpmsg_queue_handle m_rpmsg_queue; /*!< 处理RPMsg队列。*/ + struct rpmsg_lite_endpoint *m_rpmsg_ept; /*!< 指向RPMsg Lite端点结构的指针。*/ + + static struct rpmsg_lite_instance *s_rpmsg; /*!< 指向RPMSG lite实例的指针。*/ + static uint8_t s_initialized; /*!< 表示rpmsg-lite是否已初始化的信息。*/ +}; + +class RPMsgMessageBufferFactory : public MessageBufferFactory +{ + uint8_t m_freeBufferBitmap; + uint8_t m_buffers[kInitCountMessageBuffers][kRpmsgMessageBufferSize]; + +public: + /*! + * @brief 构造函数。 + */ + RPMsgMessageBufferFactory() + : m_freeBufferBitmap(0xFF) + { + } + /*! + * @brief RPMsgMessageBufferFactory destructor + */ + virtual ~RPMsgMessageBufferFactory() {} + /*! + * @brief 此函数可创建用于设备间通信的消息缓冲区。 + */ + virtual MessageBuffer create(); + /*! + * @brief 此函数可处理用于设备间通信的消息缓冲区。 + */ + virtual void dispose(MessageBuffer *buf); +}; + +} // 命名空间erpc + +/*! @} */ + +#endif // _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_ diff --git a/erpc_c/transports/rpmsg_rtos_transport.h b/erpc_c/transports/rpmsg_rtos_transport.h new file mode 100644 index 0000000..ad1d229 --- /dev/null +++ b/erpc_c/transports/rpmsg_rtos_transport.h @@ -0,0 +1,147 @@ +/* + * Copyright (c) 2015, Freescale Semiconductor, Inc. + * + * 允许以源代码或二进制形式重新分发和使用,无论是否修改, + * 只要满足以下条件: + * + * o 重新分发的源代码必须保留上述版权声明、本 + *条件列表以及以下免责声明。 + * + * o 以二进制形式重新分发时,必须在随分发提供的 + * 提供的文档和/或 + * 其他材料中复制上述版权声明、此条件列表和以下免责声明。 + * + * o 未经事先书面许可,不得使用Freescale Semiconductor, Inc.的名称或其 + * 贡献者的姓名来认可或推广由此 + * 软件衍生的产品。 + * + * 本软件由版权所有者和贡献者“按原样”提供,并且 + * 不提供任何明示或暗示的担保,包括但不限于 + * 对适销性和针对特定用途的适用性的暗示担保 + * 免责声明。在任何情况下,版权所有者或贡献者均不对 + * 任何直接、间接、偶然、特殊、惩戒性或后果性的损害 + *(包括但不限于采购替代商品或服务; + * 使用、数据或利润损失;或业务中断)负责,无论其由 + * 何种原因引起,也无论其基于何种责任理论,无论是在合同、严格责任还是侵权行为 + *(包括疏忽或其他行为)中,以任何方式因使用本 + *软件而引起,即使已被告知可能发生此类损害。 + */ + +#ifndef _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ +#define _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ + +#include "transport.h" +#include "message_buffer.h" + +extern "C" { +#include "rpmsg.h" +#include "rpmsg_rtos.h" +#include "rpmsg.h" +} + +/*! + * @addtogroup rpmsg_rtos_transport + * @{ + * @file + */ + +//////////////////////////////////////////////////////////////////////////////// +// 定义 +//////////////////////////////////////////////////////////////////////////////// + +enum +{ + kRpmsgMessageBufferSize = RPMSG_BUFFER_SIZE, +}; + +//////////////////////////////////////////////////////////////////////////////// +// 类 +//////////////////////////////////////////////////////////////////////////////// + +namespace erpc +{ +/*! + * @brief 使用RPMsg RTOS API进行进程间消息传递的传输。 + * + * @ingroup rpmsg_rtos_transport + */ +class RPMsgRTOSTransport : public Transport +{ +public: + /*! + * @brief 构造函数。 + * + * 此函数用于初始化对象属性。 + */ + RPMsgRTOSTransport(); + + /*! + * @brief RPMsgRTOSTransport析构函数 + */ + virtual ~RPMsgRTOSTransport(); + + /*! + * @brief 此函数用于调用rpmsg rtos初始化函数。 + * + * @Param[in] dev_id 设备ID号。 + * @Param[in] role 设备角色编号。 + * + * @retval kErpcStatus_Success 当rpmsg初始化函数成功执行时。 + * @retval kErpcStatus_InitFailed 当rpmsg初始化函数未成功执行时。 + */ + virtual erpc_status_t init(int dev_id, int role); + + /*! + * @brief 将传入消息存储于消息缓冲区。 + * + * 在无消息传入时进行循环。 + * + * @Param[in] message 消息缓冲区,用于存储传入的消息。 + * + * @retval kErpcStatus_ReceiveFailed 无法接收消息缓冲区。 + * @retval kErpcStatus_Success 成功接收了所有数据。 + */ + virtual erpc_status_t receive(MessageBuffer *message); + + /*! + * @brief 用于发送就绪消息的函数。 + * + * @Param[in] message 传递要发送的消息缓冲区。 + * + * @retval kErpcStatus_SendFailed 无法发送消息缓冲区。 + * @retval kErpcStatus_Success 成功发送所有数据。 + */ + virtual erpc_status_t send(const MessageBuffer *message); + +protected: + /* 远程设备 */ + static struct remote_device *m_rdev; /*!< 代表第二个内核的设备。*/ + static struct rpmsg_channel *m_app_rp_chnl; /*!< 代表两台设备(两个内核)之间的连接。*/ +}; + +class RPMsgMessageBufferFactory : public MessageBufferFactory +{ +public: + /*! + * @brief 构造函数。 + */ + RPMsgMessageBufferFactory() {} + /*! + * @brief RPMsgMessageBufferFactory destructor + */ + virtual ~RPMsgMessageBufferFactory() {} + /*! + * @brief 此函数可创建用于设备间通信的消息缓冲区。 + */ + virtual MessageBuffer create(); + /*! + * @brief 此函数可处理用于设备间通信的消息缓冲区。 + */ + virtual void dispose(MessageBuffer *buf); +}; + +} // 命名空间erpc + +/*! @} */ + +#endif // _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ diff --git a/erpc_python/erpc/transport.py b/erpc_python/erpc/transport.py index 0765e9f..c335943 100644 --- a/erpc_python/erpc/transport.py +++ b/erpc_python/erpc/transport.py @@ -31,6 +31,8 @@ import struct import serial +from rpmsg.sysfs import RpmsgEndpoint +import time import socket import threading from .crc16 import crc16 @@ -107,6 +109,25 @@ class SerialTransport(FramedTransport): class ConnectionClosed(Exception): pass +class RpmsgTransport(Transport): + def __init__(self): + self.ept = RpmsgEndpoint( + RpmsgEndpoint.rpmsg_openamp_channel, + RpmsgEndpoint.LOCAL_DEFAULT_ADDRESS, + RpmsgEndpoint.Types.DATAGRAM) + + def send(self, message): + self.ept.send(message, RpmsgEndpoint.REMOTE_DEFAULT_ADDRESS) + + def receive(self): + while True: + ret = self.ept.recv(2048) + if len(ret[1]) != 0: + return ret[1] + else: + time.sleep(0.001) + return ret[1] + class TCPTransport(FramedTransport): def __init__(self, host, port, isServer): super(TCPTransport, self).__init__() -- 2.7.4 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Dusan,谢谢 。一旦演示程序正常运行,我将创建拉取请求。 再次感谢你的回复,我已经拿到了 Python 文件。我会运行演示,很快再跟你说。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,做得真棒:)如果你愿意的话,可以为 i.MX 演示代码库创建一个拉取请求来修复这个问题。mareknovak 可以审核并将其合并到代码库中。 要生成python代码:与其他应用一样,您可以在命令行中输入"erpcgen --help"(-h也应有效)。 python -gpy idl_file -> gpy 表示生成 python。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 太好了,在更新之前我可以继续使用这个稳定版本。 经过几次修复,我的 MCU 演示现在可以正常构建和运行。感谢您的信息。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan 我已修复此问题,现在MCU演示程序恢复正常运行......感谢您推荐的稳定版本...... 你能告诉我如何使用 erpcgen 工具生成 Python 代码吗? 谢谢 Chandini Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,最早也要到明天。但我不能保证一定是明天。我的同事 mareknovak 今天没来上班。不过应该很快就会处理。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 请问您能告诉我,您什么时候会更新? Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,感谢您的关注。erpc似乎使用不同的erpcgen生成文件,且与Marek提交时的版本不一致(这是我们的失误)。最佳解决方案是将该演示程序更新为erpc和erpcgen的最新稳定版本。您可以从主分支GitHub - EmbeddedRPC/erpc: Embedded RPC(且已部署预构建erpcgen 1.4.0)尝试此操作。但我不知道您需要完成多少变更。或者您可以等待我们进行更新。 mareknovak Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan 我正在使用您推荐的同一个eRPC库 我遵循的步骤如下: 克隆 erpc-imx-demos(包含子模块,该子模块会克隆 eRPC 库,对应链接为 GitHub - MarekNovakNXP/erpc at 232afb209f0a0cfceb25a1be11879f7d1934e065) 1. git clone --recursive https://github.com/EmbeddedRPC/erpc-imx-demos.git 2. 进入 erpc-imx-demos/middleware/erpc 文件夹,然后像这样构建 erpcgen: 安装所需的 flex、bison 和 boost 包 make eprc 生成eprcgen sudo make install 成功获取 erpcgen 3. 尝试使用相同的 erpc_matrix_multiply.erpc 文件创建我自己的输出文件,命令如下: erpcgen -I erpc-imx-demos/MCU/example_erpc/service -o test/erpc-imx-demos/MCU/example_erpc/service erpc_matrix_multiply.erpc 成功获取以下文件: erpc_matrix_multiply.h erpc_matrix_multiply_server.cpp erpc_matrix_multiply_server.h erpc_matrix_multiply_client.cpp 4. 尝试构建 MCU/example_erpc/build/armgcc/imx7d_sdb_m4/build_all.sh。 失败并出现错误: /home/basavarajuc/test/erpc-imx-demos/MCU/example_erpc/service/erpc_matrix_multiply_server.cpp:在函数 'void* create_MatrixMultiplyService_service()' 中: /home/basavarajuc/test/erpc-imx-demos/MCU/example_erpc/service/erpc_matrix_multiply_server.cpp:168:56:错误:抽象类类型“MatrixMultiplyService_service”的 new-expression 无效 返回 new(nothrow) MatrixMultiplyService_service(); 很抱歉再次询问,只是为了澄清我的理解。 如果我使用的是 GitHub - MarekNovakNXP/erpc at 232afb209f0a0cfceb25a1be11879f7d1934e065 这个 eRPC 库,那我是否需要更新演示程序才能成功运行演示? 2. 您能否告知我erpc-imx-demos/MCU/example_erpc/service at master · EmbeddedRPC/erpc-imx-demos · GitHub中的输出文件是由哪个erpcgen版本生成的? 这样我就能暂时使用旧版本的 erpcgen 来创建我自己的文件了。 非常感谢。很抱歉打扰您 Chandini   Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,感谢您的评论。 您提到的示例版本早于当前erpcgen构建版本。mareknovak也因当时官方eRPC版本未包含某些细微改动,而创建了官方eRPC存储库的分支版本。如果您点击中间件文件夹下erpc-imx-demos存储库中的eRPC引用,将重定向到其eRPC存储库。您需要借助该版本构建erpcgen。我们计划在未来更新演示。 希望我的回答对你有帮助。如果你有任何疑问,欢迎随时向我们咨询。 Re: 介绍 eRPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi 抱歉,如果我问的是基本问题。 我正在尝试理解如何使用恩智浦的erpcgen工具。 参考 https://github.com/EmbeddedRPC/erpc-imx-demos,我成功运行了示例演示。 我的下一步计划是构建 erpcgen,然后使用相同的 erpc_matrix_multiply.erpc 文件创建自己的输出文件,再次运行相同的演示,以便熟悉 erpcgen 工具的使用方法。 我得到了输出文件,但即使我使用了相同的erpc_matrix_multiply.erpc文件,我的文件与示例文件不同。 变更如下: 示例演示中的输出文件显示(erpc_matrix_multiply_server.h): erpc_status_t erpcMatrixMultiply_shim(erpc::Codec * in, erpc::Codec * out, uint32_t sequence); 我的文件 (erpc_matrix_multiply_server.h): erpc_status_t erpcMatrixMultiply_shim(erpc::Codec * codec, uint32_t sequence); 为什么文件会不同呢?我是不是漏掉了什么配置? 我是否需要手动编辑 erpc_matrix_multiply_server.h 和 erpc_matrix_multiply_server.cpp 文件? 先感谢您 Chandini
View full article
LX2160A 最多支持多少个 DPDMUX 实例 Hi, LX2160A 中可以创建的最大 DPDMUX 实例是多少? 我尝试创建 8 个 dpdmux 对象,但只有 6 个成功。 我创建 dpdmux 的参数是 #--default-if=1 --num-ifs=2 --method DPDMUX_METHOD_CUSTOM --options=DPDMUX_OPT_CLS_MASK_SUPPORT,DPDMUX_OPT_AUTO_MAX_FRAME_LEN 尝试第 7 次时出现以下错误: MC 错误:无可用内存(状态 0x9) 回复:LX2160A 支持的最大 DPDMUX 实例是多少 这是有关调整 DPAA2 资源使用情况的一些有用信息。但仍然需要进一步微调,以将所有对象(8x DPDMUX + DPMACs/DPNIs)塞入 DPAA2 使用的内存缓冲区。 - DPNI:如果流量仅用于管理目的,则降低流量控制规则,参数“--fs-entries” - DPDMUX:如果分割不复杂,则降低自定义规则的使用,参数“--max-dmat-entries”。并且在创建 dpdmux 时降低内存(PEB 缓冲区)的使用率,参数“--mem-size” 进一步的调整正在进行中。希望这对社区有所帮助。 回复:LX2160A 支持的最大 DPDMUX 实例是多少 @dunk  太感谢了, 祝您有美好的一天。 BR, 赫克托尔 回复:LX2160A 支持的最大 DPDMUX 实例是多少 你好,赫克托, 是的,感谢恩智浦的支持。我会继续和你们的团队成员讨论。并尝试与社区分享我最近获得的一些有用的信息。 回复:LX2160A 支持的最大 DPDMUX 实例是多少 Hello @dunk  希望这篇文章对你有帮助, 我们注意到我们的一名团队成员已经为您提供有关此主题的支持。 为了避免任何混淆,并尽可能保持沟通清晰, 请与我们的团队成员保持沟通。 祝您有美好的一天。 BR, 赫克托尔 回复:LX2160A 支持的最大 DPDMUX 实例是多少 你好@Hector_Villarruel , 对于我对 DPAA2 内存设置的反馈有什么评论吗? 我仍然无法在我的设置中创建 8 个 DPDMUX。 回复:LX2160A 支持的最大 DPDMUX 实例是多少 谢谢, @Hector_Villarruel 。 这是我的 MC 固件的配置和内存分配。 -u-boot:mcmemsize=0x70000000 -dpc:total_bman_buffers = <0x9EB100> 我在我的 DPC 文件中找不到 total_num_buffers,所以我推测它的默认设置是 640000。 对于如上的配置和设置,我相信内存应该足够了。我还遗漏了什么吗? 回复:LX2160A 支持的最大 DPDMUX 实例是多少 Hello @dunk  希望您收到这封邮件后一切安好, 当您超过有关 MC 内存限制的最大缓冲区数量时,可能会遇到此错误( MC 错误:无可用内存(状态 0x9)) ,请参阅 DPAA2UM、Rev 53、08/2023 中的 3.5 最低内存要求。 请注意,LX2160 具有 256MB 内存,但有以下限制: 所有队列中可同时存在的缓冲区总数限制为 640000。如果 dpc 文件中的 total_num_buffers 大于 640000 MC 将无法启动。 如果 dpc 文件中缺少 total_num_buffers,MC 将使用默认值 640000。 祝您有美好的一天。 BR, 赫克托·维拉鲁埃尔
View full article
JavaとAndroidのオフラインキー JavaアプリケーションとAndroid APK(taplinx)にオフラインキーを使用している場合 このオフライン キーは両方とも更新可能でしょうか、それとも NXP から新たに要求する必要がありますか? または、このキーには有効期限/時刻がありますか????? #た オフライン認証
View full article
Wi-Fi Easy Connect (DPP) Between Two MediaTek Genio-510 Boards Hi NXP Community, Problem Statement I am trying to connect two MediaTek Genio-510 EVK boards using Wi-Fi Easy Connect (DPP). Board A → AP + DPP Configurator (hostapd) Board B → STA + DPP Enrollee (wpa_supplicant) DPP authentication succeeds, but configuration fails with the error: DPP-FAIL Configurator rejected configuration DPP-CONF-FAILED I would like to understand what is causing the configurator to reject the configuration, even though DPP authentication completes successfully. Board Configuration Details 🔹 Board A (AP + DPP Configurator) hostapd version: v2.10 Interface: wlp1s0 Mode: AP Security: DPP only /etc/hostapd_nxp3.conf ctrl_interface=/var/run/hostapd interface=wlp1s0 driver=nl80211 ssid=DPP_AP111 hw_mode=g channel=1 country_code=IN ieee80211n=1 ieee80211w=2 wmm_enabled=1 auth_algs=1 # ---- DPP CONFIG ---- wpa=2 wpa_key_mgmt=DPP rsn_pairwise=CCMP dpp_connector=1 Start command: hostapd /etc/hostapd_nxp3.conf -B AP verification: iw dev # Interface wlp1s0 # type AP # ssid DPP_AP111 # channel 1 (2412 MHz) 🔹 Board B (STA + DPP Enrollee) wpa_supplicant version: v2.10 Mode: Managed (STA) /etc/wpa_supplicant_nxp.conf ctrl_interface=/var/run/wpa_supplicant update_config=1 pmf=2 dpp_config_processing=2 Start command: wpa_supplicant -i wlp1s0 -D nl80211 -c /etc/wpa_supplicant_nxp.conf -B DPP Procedure Followed On Board A (Configurator) hostapd_cli Commands executed: dpp_configurator_add dpp_bootstrap_gen type=qrcode chan=81/1 mac=a8:41:f4:89:a2:5d dpp_bootstrap_set 1 conf=sta-dpp ssid=DPP_AP111 configurator=1 dpp_bootstrap_get_uri 1 dpp_listen 2412 Result: DPP Authentication → SUCCESS DPP Configuration Sent → ✅ Relevant logs: DPP-AUTH-SUCCESS init=0 DPP-CONF-REQ-RX DPP-CONF-SENT On Board B (Enrollee) wpa_cli Commands executed: DPP_QR_CODE dpp_auth_init peer=1 role=enrollee Logs observed: DPP-AUTH-SUCCESS init=1 GAS-QUERY-DONE result=SUCCESS DPP-FAIL Configurator rejected configuration DPP-CONF-FAILED Questions Why does the configurator reject the configuration even though authentication succeeds? Should the configurator send PSK/SAE credentials instead of sta-dpp? Is this a driver or firmware limitation on MediaTek Genio-510 for full DPP support? Any guidance or working reference configuration for Genio-510 DPP AP ↔ STA would be very helpful.
View full article
S32K3 上の FlexCAN DMA – 割り込みと TCD NXPチームの皆様、こんにちは。 私たちはS32K3 上で FlexCAN Rx DMAを評価しており、私たちの観察結果が予想通りであるか、または推奨されるアプローチがあるかどうかを確認したいと思います。 アプローチ1:割り込みベースのDMA完了イベント情報 DMA は 1 つの CAN フレームを Rx FIFO から RAM 一時バッファにコピーし、割り込みを生成します。 データをアプリケーションの循環バッファにプッシュする前に、一時バッファが必要です。 観察/質問: eDMA は循環キューや車載再Arm機能をサポートしていないため、一時ストレージが必要なようです。 負荷がかかると RX メッセージが失われ、場合によっては TX が停止することがわかりました。 レガシー Rx FIFOおよびER-FIFOに対して DMA を使用してロスのない循環 Rx バッファリングを実装するための推奨方法はありますか、それともこれは既知の制限ですか? アプローチ2: TCDベースのDMA DMA は、生の FlexCAN レジスタ ワード(CS/DLC/フラグ、ID、データ) を RxFIFO 出力場所 (ソース) から RAM バッファ (宛先) にコピーします。 受信データは正規化された CAN メッセージ形式ではありません。 観察/質問: CPU は、メッセージ ID (STD/EXT)、ペイロード長 (DLC から派生)、正しい順序のペイロード バイト、FD/BRS フラグ、およびタイムスタンプを解析する必要があります。 FlexCAN DMA は生の転送のみを実行し、メッセージの正規化は常にソフトウェアで実行する必要があると考えられますか? DMA 受信フレームの RTD ドライバ解析ロジックを再利用するための推奨方法はありますか? もう 1 つの問題は、宛先モジュロが CAN FD フレームの循環キュー操作を処理できないことです。つまり、TCD 方法には宛先アドレスを特定のバイト数後にラップするのに役立つ宛先モジュロの概念が 1 つあります。SO、CAN FD フレーム バイト数 (フレームあたり 72 バイト) は、モジュロ値と適切に一致しません。 そして、宛先最終アドレスレジスタの調整に別のオプションを試しました。単一フレームでは機能しますが、20 フレームのキューのようなフレーム数に対して宛先アドレスが適切にラップされないなどの問題があります。 追加の質問 通常の Rx FIFO 割り込みと比較して、 CAN DMA 割り込みを使用する利点は何ですか。 上記のすべての観察が S32K3 上の FlexCAN Rx DMA の予想される動作であるかどうかを確認してください。 ありがとう... Re: FlexCAN DMA on S32K3 –Interrupt vs TCD こんにちは@kapidlitap 同様のトピックの質問。 https://community.nxp.com/t5/S32K/S32K358-レガシー-RX-Fifo-DMA 付き vs-強化された RX-Fifo-DMA/td-p/2266494 当社の RTD ドライバはユーザー向けの DMA 構成をすでに完了しているため、ユーザーは自分のニーズに合わせて DMA を再構成する必要はありません。 割り込み方法と DMA 方法のパフォーマンス比較データは提供していません。ユーザーは実際の使用ケースに応じて構成およびテストを行い、最適な方法を選択する必要があります。 拡張FIFO+DMAデモ https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-FlexCAN-Ip-TX-RX-EnhanceRXFIFO-DMA-test-S32DS3-5/ta-p/2015832
View full article
S32K3xx、FLS 阵列完整性检查 队员们好 是否有示例或验证测试项目可演示在旧 RTD 版本(如 3.0.0)的 FLS 驱动程序中使用 ArrayIntegrityCheck、我可以与客户分享吗? 我注意到较新 RTD 版本(例如 6.0.0)的用户手册包括此类示例,但我找不到旧版 FLS 的类似内容。 谢谢! BR,丹尼尔 RTD Re: S32K3xx, FLS ArrayIntegrityCheck 你好,我是@danielmartynek、 我附上了基于 RTD 3.0.0 的 C40_Ip_ArrayIntegrityCheck 示例P07 版本。 顺祝商祺! 丹 Re: S32K3xx, FLS ArrayIntegrityCheck 你好,@DanNguyenDuy、 谢谢你的举例。 由于目前不在办公室,我还没能进行测试。 但是,客户报告遇到了指令总线故障异常。 澄清一下:我的理解是,阵列完整性检查中涉及的 C40_Ip API 必须从 SRAM 中执行,因为闪存阵列在测试期间不可用。 这样做对吗? 能否确认在测试/验证驱动程序期间,从 SRAM 运行了哪些特定的驱动程序 API? 谢谢! BR,丹尼尔 Re: S32K3xx, FLS ArrayIntegrityCheck 你好,我是@danielmartynek、 1.这样做对吗? => 是的,这是正确的。 2.能否确认在测试/验证驱动程序期间,从 SRAM 运行了哪些特定的驱动程序 API? => 到目前为止,还没有特定的驱动程序支持在 SRAM 上运行 C40_Ip_ArrayIntegrityCheck。 顺祝商祺! 丹 Re: S32K3xx, FLS ArrayIntegrityCheck 你好,@DanNguyenDuy、 感谢您的回复。 我知道我们需要将C40_Ip_ArrayIntegrityCheck()和C40_Ip_CheckUserTestStatus()放在 SRAM 中。 是否有其他功能也需要放在 SRAM 中? C40_Ip 驱动程序的功能肯定已经测试过了,对吗? 那么,您能否提供有关测试设置的详细信息?如果驱动程序所有者能就验证是如何进行的发表评论,将会很有帮助。 BR,丹尼尔 Re: S32K3xx, FLS ArrayIntegrityCheck 你好,我是@danielmartynek、 RTD 团队使用 linker_ram 代替 linker_flash 测试了该功能。 在示例中,用户可以修改 makefile 中的一个变量:LOAD_TO=ram 以使用 linker_ram 顺祝商祺! 丹
View full article
MWCT2016S 无法更改 UART 波特率 嗨,恩智浦社区、 我有一个关于 MCAL 中 UART 模块配置的问题。我无法更改波特率。SBR 和 OSR 寄存器符合预期,但实际测量的波特率为 72254。请帮助解决这个问题。 感谢您的帮助! Johnson97_0-1765938756521.png Johnson97_1-1765938839658.png Re: MWCT2016S can't change UART baud rate 请参阅[RTD400 MCAL 3] K312 MCU 时钟系统配置 的 2.2 EB 配置 部分配置 Mcu 。 Re: MWCT2016S can't change UART baud rate 是的,我已经调用了 Mcu_DistributePllClock() 函数。 如有必要,附加文件包含基于参考例程的源代码。 Johnson97_0-1766022864617.png Re: MWCT2016S can't change UART baud rate 您是否在主函数中调用了Mcu_DistributePllClock()?请参考以下代码: /* Initialize the clock driver */ Mcu_Init(NULL_PTR); /* Initialize the clock tree and apply PLL as system clock */ Mcu_InitClock(McuClockSettingConfig_0); #if (MCU_NO_PLL == STD_OFF) while ( MCU_PLL_LOCKED != Mcu_GetPllStatus() ) { /* Busy wait until the System PLL is locked */ } Mcu_DistributePllClock(); #endif Re: MWCT2016S can't change UART baud rate HI 一开始,我使用了 aips 慢时钟,但问题依然存在。波特率为 142857。在我将时钟更改为 aips plat 之后,波特率发生了变化,甚至变得更低,达到了 72254,但仍然不是预期的波特率。 我和 UART 例程的区别似乎只在于核心时钟。我使用 PLL 作为核心时钟源。会是这个原因吗?使用 PLL 时有什么特别的注意事项吗? 如有必要,附件中包含我的 EB 项目。 Re: MWCT2016S can't change UART baud rate HI 请根据表 130配置UartClockRef 。S32K3XXRM Rev12 的LPUARTn 实例时钟。 对于 S32K312,LPUART [1:7] 由AIPS_SLOW_CLK 提供时钟。 祝好, Robin ------------------------------------------------------------------------------- 注: - 如果本帖回答了您的问题,请点击"ACCEPT AS SOLUTION" 按钮。谢谢! - 我们会在最后一次发帖后的 7 周内跟踪主题,之后的回复将被忽略 如果您以后有相关问题,请另开新主题,并参考已关闭的主题。 ------------------------------------------------------------------------------- Re: MWCT2016S can't change UART baud rate 问题已经解决。 非常感谢!
View full article
TWR-KV58 ハードフォールト おはよう TWR ボードに顕著なエラーがあります。以前、このボードを同じ状態で使用し、正常に動作していましたが、しばらくそのまま放置していたところ、突然、ハードフォールトが発生し、起動しなくなりました。 JTAG ケーブルをコネクテッド状態で Multilink を使用しています。以前もそうしました。ハードフォルトで直接スタートします。 これがスクリーンショットです pietrodicastri_0-1765878099381.png ジャンパー J19 と J20 は JTAG を使用するために開いています。それで十分なはずです。 何か提案してください。壊れているとしか思えません。 皆様ありがとうございました ピエトロ Re: TWR-KV58 Hard Fault おはよう ただサポートしてください。バックアップソリューションとしてすでに新しいものを注文しましたが、続行するには支援が必要です。 ありがとう Re: TWR-KV58 Hard Fault こんにちは@pietrodicastri 、 ご投稿ありがとうございます。これがソフトウェアの問題であるかどうかを判断するために、「Hello World」デモなど、SDK に含まれているデモを実行したときに HardFault が引き続き発生するかどうかを確認してください。 SDKリンク:ボードを選択 | MCUXpresso SDKビルダー 詳細については、 https://www.keil.com/appnotes/files/apnt209.pdfを参照してください。 Celeste_Liu_0-1766030502918.png BR セレステ Re: TWR-KV58 Hard Fault こんにちは ボードが動作するようになりました…サポートに感謝します。 今度は別のものを投稿します。 ありがとう ピエトロ
View full article
iMX6ULL 控制台 UART 与其他使用 RS-485 的 UART 相互干扰 iMX6ULL 系统,内核为 lf-6.6.52-2.2.1。控制台设置为 ttymxc3 上的 RS-485 串行端口 ttymxc0。收发器"驱动使能" 连接到 SNVS_TAMPER7,我们有一个 DTS: &iomuxc_snvs { pinctrl_rs485_snvs: rs485grp_snvs { fsl,pins = < MX6ULL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b1 /* RS485.DE as RTS */ >; }; }; &uart4 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_rs485>, <&pinctrl_rs485_snvs>; fsl,dte-mode; rts-gpios = <&gpio5 7 GPIO_ACTIVE_HIGH>; linux,rs485-enabled-at-boot-time; status = "okay"; label = "rs485"; }; 我注意到,如果向控制台打印数据,会干扰 RS-485 串行端口:RTS/DE 信号有时会延迟 5-10 毫秒。该值在 9600 bps 时超过 3.5 个字符,这意味着由于主机仍在驱动总线,因此来自设备的响应将出现乱码。可以用以下方法复制: while true;do echo xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >/dev/kmsg;done 这是一个已知的问题吗? i.MX6UL 疑似软件缺陷 Yocto Project Re: iMX6ULL console UART interferes with other UART using RS-485 你好@astrand 这似乎是 Linux 内核中的一个常见问题。以下是 LWN.NET 中的讨论。 printk/console 是一个速度慢的设备。当遇到大量日志时,内核必须同步向控制台写入信息。在这一过程中,它持有相关锁并消耗 CPU 时间,从而延迟其他任务调度和中断处理。即使您的控制台不同于 RS-485 串行端口,系统的整体调度/软中断/任务队列仍然会被拖慢。这将延迟 UART 传输完成事件到达驱动器并随后拉低 DE 位所需的时间。更多详情,请参阅该讨论。 https://lwn.net/Articles/909980/ 您可以尝试在运行时设置较低的控制台日志级别,或定义 rs485-rts-delayin dts. echo "4 4 1 7" > /proc/sys/kernel/printk 致敬, Zhiming
View full article
MPC5748G 将 uart 与 tcpip 结合使用 我想把以太网传输和串行端口打印功能结合起来。在代码 A 中,我试图在串行端口打印的基础上添加以太网传输功能 (tcpip),但失败了。我想在代码 B 的 LWIP 例程中添加串行端口显示功能,但按下 SW2 按钮后串行端口显示屏上看不到发送的信息。我不知道这两个地方设置得不对。 我是一名学生,这个问题已经困扰了我一个星期。如能解决,我将不胜感激 Re: MPC5748G combine uart with tcpip 我承认我用 AI 编写的代码是电子垃圾,但我不明白为什么在修改了两个例程的文件中使用相同的代码段只能实现一半的功能(UART 或 tcpip) 谁能帮帮我? QING_QUE_0-1765711747775.png
View full article