參數(shù)資料
型號(hào): PXAC37
廠商: NXP Semiconductors N.V.
英文描述: XA 16-bit microcontroller family 32K/1024 OTP CAN transport layer controller 1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID Filters, transport layer co-proce
中文描述: 的XA 16位微控制器系列32K/1024檢察官可以傳輸層控制器1的UART,1個(gè)SPI端口,CAN 2.0B總線,32可以讀取器,傳輸層合作proce
文件頁數(shù): 51/68頁
文件大?。?/td> 368K
代理商: PXAC37
Philips Semiconductors
Preliminary specification
XA-C3
XA 16-bit microcontroller family
32K/1024 OTP CAN transport layer controller
1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID filters, transport layer co-processor
2000 Jan 25
44
DMA, and then interrupt the CPU that a complete message has
been received.
Since Data Byte 1 of each frame contains the Fragmentation
information, it will never be stored in the CTL message buffer, thus
each frame will have up to seven bytes of data stored. After the
entire message is received, the message buffer will contain all of the
actual informational data bytes received (exclusive of Fragmentation
information bytes) plus the Byte Count at location 00 which will
contain the total number of informational data bytes stored.
Fragmentation Error
By looking at the Fragmentation information, the message handler
can determine the first frame , the middle frames, the end frame of
the message, and each sequence number. In the case of CANopen,
there is no sequence number but rather a one bit field that toggles
each frame. If a Fragmentation error occurs, the message handler
will reset the byte count, address pointer, and generate an interrupt
to the CPU. At this point the CTL message buffer is determined to
be invalid.
Fragmentation checking is disabled for all objects when CAN is the
system protocol (Prtcl[1:0] = 00).
Fragmentation error occurs only one way:
1. When the message handler receives a frame where the
sequence number is NOT one greater than that of the previous
frame. Or in the case of CANopen, the toggle bit has not toggled.
Fragmented Messages in OSEK
There are several important items that must be kept in mind with
regard to hardware assembly of Fragmented OSEK messages. For
a complete discussion, please see the XA-C3 User Manual. These
items are summarized below:
The OSEK FirstFrame cannot be treated as part of the
Fragmented message, but must be handled as a completely
separate, single–frame, non–Fragmented message. However, the
FirstFrame maycontain the first several bytes of User–data.
For the object receiving the forthcoming message Fragments, the
MnFCR register must be initialized by the User to point at an
address otherthan the buffer base location. This can be byte
offset ‘1’ or some other, more strategically chosen location. Since
there will be no FirstFrame received for this object, there will be
no write of 00h to the buffer base location, by DMA, at the
beginning of the message.
The Fragment Count Register (MnFCR) of the object receiving the
message Fragments must be initialized by the User before
enabling the object for receive. The initial value written to MnFCR
must be identical to the SequenceNumber of the first
ConsecutiveFrame that arrives (typically 0h).
There is no “Last Frame” encoding for OSEK. Therefore, there will
be neither an Rx Message Complete Status Flag, nor an interrupt,
nor a Byte Count write associated with Rx Message Complete, at
the conclusion of a Fragmented message. However, by carefully
choosing the initial value for the MnBLR register, the User can
arrange to get an Rx Buffer Full interrupt, and the associated Rx
Buffer Full Byte Count write, instead.
Fragmented Messages in CANopen
In a CANopen system, the software will need to write to the object‘s
Fragment Count Register (MnFCR) to initialize the toggle bit prior to
receiving the first frame of any new message which requires
hardware Fragmentation assembly. This bit will have to be initialized
to the same state that will be received in the 1
st
packet (typically 0).
This bit will need to be initialized each time a new channel is
established, even if none of the other parameters change (e.g.,
Match, Mask, buffer location, buffer size, etc.).
Since the hardware cannot detect a message start, there can be no
semaphore write to the bottom of the buffer space at the start of a
new Fragmented message (for a discussion of the semaphore, see
the section entitled Using the Semaphore Bits, SEM1 and SEM0on
page 46. This location must still be left free for the hardware to write
the byte count into at the end of the message. This means that for
CANopen
Fragmented
messages (only Fragmented)
the software
must initialize the address pointer to location ‘1’ of the
designated receive buffer, not location ‘0’ as it does in
DeviceNet.
It also implies,
of course, that the software loses the
ability to check the semaphore to determine if message
reconstruction is currently in progress.
Essentially, the hardware will treat the first frame of a multi–frame
CANopen message exactly the same as intermediate frames.
Auto–Acknowledge in CANopen
A Fragmented (Segmented) CANopen message may need to be
acknowledged on a frame by frame basis. The XA-C3 provides
hardware support for this process, with no CPU intervention. Of
course the User may elect not to auto–acknowledge, or to
implement the acknowledge function in software.
Suppose Message Object n ( n = 0
31) is enabled for receive, with
the FRAG bit set. If the high level protocol is CANopen, as selected
in the GCTL register, then the following steps must be taken to
ensure that CANopen frames are automatically acknowledged:
Set the AUTO_ACK bit in GCTL.
Set up a transmit object sequential to the CANopen receive
object, i.e., the object number set to be n+1. Set the FRAG bit for
this object.
It is important NOT to set the OBJ_EN bit for the transmit
message.
With the above setup, the XA-C3 will automatically generate a
transmit frame upon successful reception of a CANopen frame. The
User must setup the screener ID for the Tx frame in the M
n+1
MIDH
and M
n+1
MIDL registers, the RTR bit in M
n+1
CNTL[0], and the DLC
in M
n+1
MSKH[3:0]. The User must also store the proper
“Acknowledge Byte”, as defined by the protocol specification, in byte
offset 0 of the Tx object’s message buffer. Bit position [4] is a don’t
care, because the XA-C3 will automatically insert the toggle bit value
from the incoming frame into the toggle bit position of the outgoing
auto–acknowledge frame. The format for storing the Acknowledge
Byte is shown below in Table 24 (subject to change without notice
by the CiA).
相關(guān)PDF資料
PDF描述
PXB16050U NPN microwave power transistor
PY08-02 INDUSTRIERELAIS FASSUNG PCB
PY08-02186697 SOCKET PCB
PY14 INDUSTRIERELAIS CHASSIS MONTAGESOCKEL
PY14-02 INDUSTRIERELAIS LEITERPL MONTAGESOCKEL
相關(guān)代理商/技術(shù)參數(shù)
參數(shù)描述
PXAC37KBA 制造商:PHILIPS 制造商全稱:NXP Semiconductors 功能描述:XA 16-bit microcontroller family 32K/1024 OTP CAN transport layer controller 1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID Filters, transport layer co-proce
PXAC37KBBD 制造商:PHILIPS 制造商全稱:NXP Semiconductors 功能描述:XA 16-bit microcontroller family 32K/1024 OTP CAN transport layer controller 1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID Filters, transport layer co-proce
PXAC37KFA 功能描述:16位微控制器 - MCU OTP32K/1K 32 MHZ CAN EXT PLCC RoHS:否 制造商:Texas Instruments 核心:RISC 處理器系列:MSP430FR572x 數(shù)據(jù)總線寬度:16 bit 最大時(shí)鐘頻率:24 MHz 程序存儲(chǔ)器大小:8 KB 數(shù)據(jù) RAM 大小:1 KB 片上 ADC:Yes 工作電源電壓:2 V to 3.6 V 工作溫度范圍:- 40 C to + 85 C 封裝 / 箱體:VQFN-40 安裝風(fēng)格:SMD/SMT
PXAC37KFA/00,512 功能描述:IC XA MCU 16BIT 32K OTP 44-PLCC RoHS:是 類別:集成電路 (IC) >> 嵌入式 - 微控制器, 系列:XA 標(biāo)準(zhǔn)包裝:250 系列:56F8xxx 核心處理器:56800E 芯體尺寸:16-位 速度:60MHz 連通性:CAN,SCI,SPI 外圍設(shè)備:POR,PWM,溫度傳感器,WDT 輸入/輸出數(shù):21 程序存儲(chǔ)器容量:40KB(20K x 16) 程序存儲(chǔ)器類型:閃存 EEPROM 大小:- RAM 容量:6K x 16 電壓 - 電源 (Vcc/Vdd):2.25 V ~ 3.6 V 數(shù)據(jù)轉(zhuǎn)換器:A/D 6x12b 振蕩器型:內(nèi)部 工作溫度:-40°C ~ 125°C 封裝/外殼:48-LQFP 包裝:托盤 配用:MC56F8323EVME-ND - BOARD EVALUATION MC56F8323
PXAC37KFBD 制造商:PHILIPS 制造商全稱:NXP Semiconductors 功能描述:XA 16-bit microcontroller family 32K/1024 OTP CAN transport layer controller 1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID Filters, transport layer co-proce