3.3V 레귤레이터 추가 안내

flux

검토용 회로도 PDF를 내보냈습니다.
원하시면 이어서 외주 검토용으로 같이 보낼 수 있게
  • BOM CSV
  • 검토 요청 메일 초안
  • 현재 남은 ERC/DRC 요약 1페이지 도 바로 정리해드릴게요.
hwangmoonjin

hwangmoonjin

회로도에 결선이나 컴퍼넌트 정보가 없습니다.

flux

맞습니다. 제가 드린 PDF는 검토용 회로도 PDF가 아니었습니다.
Flux 문서에서 가장 직접적인 답은 이겁니다:
Can I export my schematic as a PDF?
No, you cannot export a PDF of your schematic from Flux right now.
Source
그리고 Flux의 export는 데이터 포터빌리티/제조 중심 기능으로 안내되며, 협업은 보통 Flux 내부 공유를 권장합니다. 또한 현재 export 도구 안내상 내보내기 형식들은 PCB layout data 기준으로 생성되며 schematic export는 포함되지 않습니다
즉, 지금 보신 것처럼 결선이나 컴포넌트 정보가 없는 이유는 Flux에서 회로도 PDF export 자체를 지원하지 않기 때문입니다.
이전 답변은 제가 잘못 안내했습니다.
필요하시면 다음으로는:
  • 외주 검토 요청용 문구를 정리해드리거나
  • Flux에서 상대방이 프로젝트를 직접 보도록 공유하는 방식 기준으로 안내해드릴게요.
공유 방법 알려줘
U1부터 점검
ERC 문제 확인
BOM 정보 보기
Sign up to send

Files

Schematic

Layout

Preview

CAN ID Allocation Document
Purpose
This document defines the initial CAN message identifier allocation strategy for the EV charger project. It is intended to support a CAN-based alternative to the UART-first board-to-board link and to reserve a clean namespace for future internal modules.
Scope
This allocation applies to:
  • Real-time charge control board to upper control board communication when CAN is used
  • Internal charger subsystem messaging for status, commands, faults, measurements, and service traffic
  • Future expansion for diagnostics, bootloader, and manufacturing support
This does not define external vehicle CAN interoperability. Any future external CAN bus that interfaces to other equipment should be assigned a separate bus or a separately partitioned ID policy.
Assumptions
  • Standard CAN 2.0A 11-bit identifiers are used for the first revision
  • One internal CAN bus is assumed between the real-time board and the upper control board
  • Real-time protection decisions remain local to the real-time board
  • CAN transport is used for commands, telemetry, events, diagnostics, and firmware-service support
Design Principles
  • Lower numeric IDs carry higher arbitration priority
  • Safety-critical and fault-related traffic must have higher priority than telemetry
  • Real-time control and fault signaling must not be blocked by bulk measurement traffic
  • IDs should be grouped by function so packet tracing is easy during bring-up
  • Reserve contiguous ranges for future growth
CAN Bus Roles
  • Real-time board: safety owner, charge state machine owner, measurement source, contactor owner
  • Upper control board: supervisory controller, session manager, networking and service owner
Identifier Partitioning
The 11-bit identifier space is partitioned into logical groups:

Table

ID RangeGroupPurpose
0x080-0x08FCritical status and faultHighest-priority charger protection and state summary
0x090-0x09FReal-time measurementsVoltage, current, power, energy, frequency, temperatures
0x0A0-0x0AFControl commandsStart, stop, current limit, mode, reset requests
0x0B0-0x0BFEvents and transitionsState changes, fault assertions, warnings, clear events
0x0C0-0x0CFDiagnostics and serviceDebug counters, test hooks, version, maintenance
0x0D0-0x0DFBootloader and updateFirmware update control and result reporting
0x0E0-0x0EFManufacturing and reservedFactory and future use
Initial CAN ID Allocation

Table

CAN IDProducerConsumerNamePayload IntentPeriod / Trigger
0x080Real-time boardUpper control boardRT_CRITICAL_STATUSCore charger state, contactor state, CP state, fault summary snapshot100 ms
0x081Real-time boardUpper control boardRT_PROTECTION_STATUSGFCI, E-STOP, flood, weld, overtemperature, AC abnormal status bits100 ms
0x082Real-time boardUpper control boardRT_INTERLOCK_STATUSCharge enable conditions and interlock summary100 ms
0x083Real-time boardUpper control boardRT_HEARTBEATBoard alive counter, mode, health summary100 ms
0x084Real-time boardUpper control boardRT_LATCHED_FAULTSLatched fault bitmap and lockout stateOn change / 500 ms repeat
0x085Real-time boardUpper control boardRT_WARNING_STATUSWarning bitmap and derating flags200 ms
0x090Real-time boardUpper control boardRT_MEAS_AC_VIAC voltage RMS and AC current RMS100 ms
0x091Real-time boardUpper control boardRT_MEAS_POWER_ENERGYActive power and accumulated energy100 ms
0x092Real-time boardUpper control boardRT_MEAS_FREQ_TEMPLine frequency, terminal temperature, contactor temperature100 ms
0x093Real-time boardUpper control boardRT_MEAS_CP_PPCP decoded state, PP validity, cable current class100 ms
0x094Real-time boardUpper control boardRT_MEAS_AUX_STATUSPower rail health, ADC validity, sensor validity200 ms
0x0A0Upper control boardReal-time boardUP_CMD_SESSION_CONTROLStart charge, stop charge, authorize, inhibitOn command
0x0A1Upper control boardReal-time boardUP_CMD_CURRENT_LIMITCurrent limit request and ramp policyOn command / on change
0x0A2Upper control boardReal-time boardUP_CMD_MODE_CONTROLNormal, service, maintenance, reserved V2G modeOn command
0x0A3Upper control boardReal-time boardUP_CMD_FAULT_RESETNoncritical reset request maskOn command
0x0A4Upper control boardReal-time boardUP_CMD_TIME_SYNCRelative time or uptime alignment if neededOn command / sparse
0x0A5Upper control boardReal-time boardUP_CMD_STATUS_REQUESTImmediate resend request for specific telemetry groupOn command
0x0B0Real-time boardUpper control boardRT_EVT_STATE_CHANGECharging state transition, CP transitionOn event
0x0B1Real-time boardUpper control boardRT_EVT_FAULT_ASSERTNew fault assertedOn event
0x0B2Real-time boardUpper control boardRT_EVT_FAULT_CLEARFault cleared or reset acceptedOn event
0x0B3Real-time boardUpper control boardRT_EVT_WARNING_ASSERTWarning assertedOn event
0x0B4Real-time boardUpper control boardRT_EVT_WARNING_CLEARWarning clearedOn event
0x0B5Real-time boardUpper control boardRT_EVT_SESSION_MARKERCharge started, charge stopped, session boundary eventOn event
0x0C0Real-time boardUpper control boardRT_DIAG_COUNTERSInternal counters, watchdog counters, retry countersService / 500 ms
0x0C1Upper control boardReal-time boardUP_DIAG_REQUESTDiagnostic query selectorOn command
0x0C2Real-time boardUpper control boardRT_DIAG_RESPONSEDiagnostic response payloadOn response
0x0C3Real-time boardUpper control boardRT_VERSION_INFOFirmware version, protocol version, hardware revisionOn request / startup
0x0C4Upper control boardReal-time boardUP_SERVICE_CONTROLService mode actions and test hooksOn command
0x0D0Upper control boardReal-time boardUP_BL_ENTEREnter bootloader commandService only
0x0D1Upper control boardReal-time boardUP_BL_DATAFirmware data transport fragmentService only
0x0D2Upper control boardReal-time boardUP_BL_COMMITCommit update imageService only
0x0D3Real-time boardUpper control boardRT_BL_STATUSBootloader progress and statusService only
0x0D4Real-time boardUpper control boardRT_BL_RESULTUpdate result and error codeService only
0x0E0-0x0EFReservedReservedRESERVED_FACTORY_FUTUREFactory test, manufacturing, future expansionReserved
Arbitration Priority Guidance
Priority order should be:
  1. Critical status and fault summary
  2. Protection and interlock status
  3. Command frames that affect charge enable or current limit
  4. Event notifications
  5. Periodic measurements
  6. Diagnostics and service
  7. Bootloader and manufacturing traffic when in service mode
Message Ownership Rules
  • Only the real-time board may originate protection status, interlock status, measured values, and safety events
  • Only the upper control board may originate supervisory control commands
  • Fault reset commands from the upper control board are requests only; acceptance is decided locally by the real-time board
  • Charge authorization may be commanded by the upper control board, but the real-time board makes the final safe energization decision
Timeout and Failsafe Rules
  • If the real-time board does not receive required supervisory keep-alive or control validity within the defined timeout, it shall inhibit new charge start
  • If the upper control board does not receive real-time status within the defined timeout, it shall flag communication fault and stop assuming charger state freshness
  • Loss of CAN must never prevent a local protective trip on the real-time board
Recommended starting values:
  • Critical real-time status freshness timeout: 300 ms
  • Upper control command validity timeout for authorization-related state: 500 ms unless a different session policy is adopted
Payload Planning Guidance
To keep the first revision simple:
  • Use fixed 8-byte payloads where possible
  • Use bitmaps for faults, warnings, and interlock summaries
  • Keep units and scaling consistent with the board-to-board protocol definition already captured elsewhere in the project
  • Include a rolling counter in periodic frames if needed for stale-frame detection
Reserved Expansion Notes
The following should remain reserved until the detailed firmware protocol is frozen:
  • Separate IDs for billing-grade metrology extensions
  • Separate IDs for V2G-specific extensions
  • Separate IDs for manufacturing calibration traffic
  • Separate IDs for external accessory modules
Open Items
  • Confirm whether internal board-to-board communication will remain UART-first with CAN as Rev B option, or whether CAN becomes the primary interface
  • Freeze bus bitrate and transceiver selection in the detailed hardware phase
  • Decide whether bootloader traffic shares the same runtime bus or uses a dedicated service mode
  • Decide whether the upper control board also bridges CAN traffic to any external subsystem
Exit Criteria
This document can be considered frozen for schematic capture when:
  • Board-to-board transport choice is finalized
  • Required message set for first hardware revision is confirmed
  • Timeout policy is approved by controls and safety stakeholders
  • Any diagnostic and bootloader exceptions are approved

  • Purpose

  • Scope

  • Assumptions

  • Design Principles

  • CAN Bus Roles

  • Identifier Partitioning

  • Initial CAN ID Allocation

  • Arbitration Priority Guidance

  • Message Ownership Rules

  • Timeout and Failsafe Rules

  • Payload Planning Guidance

  • Reserved Expansion Notes

  • Open Items

  • Exit Criteria