From a4e45b5ee9ad02acf2e7b1d05e59318cc2ea7b97 Mon Sep 17 00:00:00 2001 From: Amlal El Mahrouss Date: Sat, 29 Nov 2025 17:22:18 -0500 Subject: chore: update kernel and framework specs. Signed-off-by: Amlal El Mahrouss --- docs/STANDARD_FWRK.md | 283 ----------------------------------- docs/drawio/GUI_DESIGN.drawio | 34 ----- docs/md/SPECIFICATION_KERNEL.md | 66 --------- docs/md/SPECIFICATION_MBCI.md | 34 ----- docs/mermaid/.gitkeep | 0 docs/specs/SPECIFICATION_FWRK.md | 296 +++++++++++++++++++++++++++++++++++++ docs/specs/SPECIFICATION_KERNEL.md | 66 +++++++++ docs/specs/SPECIFICATION_MBCI.md | 34 +++++ 8 files changed, 396 insertions(+), 417 deletions(-) delete mode 100644 docs/STANDARD_FWRK.md delete mode 100644 docs/drawio/GUI_DESIGN.drawio delete mode 100644 docs/md/SPECIFICATION_KERNEL.md delete mode 100644 docs/md/SPECIFICATION_MBCI.md delete mode 100644 docs/mermaid/.gitkeep create mode 100644 docs/specs/SPECIFICATION_FWRK.md create mode 100644 docs/specs/SPECIFICATION_KERNEL.md create mode 100644 docs/specs/SPECIFICATION_MBCI.md diff --git a/docs/STANDARD_FWRK.md b/docs/STANDARD_FWRK.md deleted file mode 100644 index 8bc1444c..00000000 --- a/docs/STANDARD_FWRK.md +++ /dev/null @@ -1,283 +0,0 @@ -# STANDARD NEKERNEL FRAMEWORK SPECIFICATION - -## Overview - -The NeKernel framework system (`.fwrk`) provides a standardized structure for creating modular, reusable libraries and components. Frameworks are self-contained packages that include headers, source code, metadata, and configuration for compilation and deployment within the NeKernel ecosystem. - -## Framework Directory Structure - -Each framework follows the standardized directory layout below: - -``` -.fwrk/ -├── .json # Framework manifest and build configuration -├── headers/ # Public API headers -│ ├── *.h # Public header files (C++ headers) -│ └── ... -├── src/ # Implementation source files -│ ├── *.cc # C++ implementation files -│ ├── DylibMain.cc # Dynamic library entry point (optional) -│ └── ... -├── xml/ # Framework metadata and properties -│ └── app.xml # Framework property list -├── dist/ # Build output directory -│ └── lib.fwrk.dylib # Compiled dynamic library -└── .keep # Placeholder file -``` - -## Component Specifications - -### 1. Framework Manifest (`.json`) - -The JSON manifest file defines the build configuration, compilation flags, and metadata for the framework. - -**Required Fields:** - -- **`compiler_path`** (string): Path to the C++ compiler executable - - Example: `"clang++"`, `"x86_64-w64-mingw32-g++"` - -- **`compiler_std`** (string): C++ standard version - - Example: `"c++20"`, `"c++17"` - -- **`headers_path`** (array): Array of header search paths (relative to framework) - - Include paths for finding dependencies and kernel interfaces - - Example: `["./", "../../../src/kernel", "../../../public/frameworks/", "../../../src/"]` - -- **`sources_path`** (array): Array of source file globs to compile - - Example: `["src/*.cc"]` - -- **`output_name`** (string): Path and filename for compiled library output - - Example: `"./dist/libCoreFoundation.fwrk.dylib"` - -**Optional Fields:** - -- **`compiler_flags`** (array): Custom compilation flags - - Example: `["-ffreestanding", "-shared", "-fno-rtti", "-fno-exceptions"]` - -- **`cpp_macros`** (array): C++ preprocessor macro definitions - - Example: `["kCFVersion=0x0100", "__NE_AMD64__", "__CF_64BIT__"]` - -**Example Manifest:** -```json -{ - "compiler_path": "x86_64-w64-mingw32-g++", - "compiler_std": "c++20", - "headers_path": ["../", "./", "../../../dev", "../../../src/kernel"], - "sources_path": ["src/*.cc"], - "output_name": "./dist/libCoreFoundation.fwrk.dylib", - "compiler_flags": [ - "-ffreestanding", - "-shared", - "-fno-rtti", - "-fno-exceptions", - "-Wl,--subsystem=17" - ], - "cpp_macros": [ - "kCFVersion=0x0100", - "kCFVersionHighest=0x0100", - "kCFVersionLowest=0x0100", - "__NE_AMD64__", - "__CF_64BIT__" - ] -} -``` - -### 2. Public Headers Directory (`headers/`) - -Contains all public-facing C++ header files that define the framework's API. - -**Conventions:** -- File extension: `.h` (not `.hpp`) -- Namespace: Typically matches framework name (e.g., `CF::` for CoreFoundation) -- Include guards: Use `#pragma once` for header protection -- Copyright headers: Include NeKernel copyright notice at the top - -**Typical Headers:** -- Main header providing overall framework interface -- Specialized headers for different components -- Type definitions and class declarations -- Exception/error definitions - -### 3. Source Implementation Directory (`src/`) - -Contains C++ implementation files for the framework. - -**Key Files:** - -- **`DylibMain.cc`** (Optional): - - Entry point for dynamic library initialization - - Contains `_DylibAttach(SInt32 argc, Char* argv[])` function - - Returns status code (0 for success, EXIT_FAILURE otherwise) - - **Example:** - ```cpp - #include - - SInt32 _DylibAttach(SInt32 argc, Char* argv[]) { - // Initialization code here - return EXIT_FAILURE; // Change based on initialization result - } - ``` - -- **Implementation Files** (`*.cc`): - - Correspond to public headers - - Contain class definitions and function implementations - - Include necessary system and framework headers - -### 4. Metadata Directory (`xml/`) - -Contains XML-based property list files for framework metadata. - -**`app.xml` Structure:** -- PropertyList format for framework configuration -- Typically includes: - - `LibraryName`: Framework name (string) - - `CacheLibs`: Whether to cache library (boolean) - - Other framework-specific properties - -**Example:** -```xml - - - -``` - -### 5. Build Output Directory (`dist/`) - -Auto-generated directory containing compiled framework binaries. - -- **Output file**: `lib.fwrk.dylib` -- Created during build process via `mk_fwrk.py` -- Not committed to version control - -## Built-in Frameworks - -The NeKernel project includes the following standard frameworks: - -### CoreFoundation.fwrk -**Purpose:** Core data structures and utilities foundation -**Provides:** -- Reference types (CFRef) -- String handling (CFString) -- Collections (Arrays, Dictionaries) -- Geometric types (CFPoint, CFRect, CFColor) -- Object system (CFObject, CFProperty) - -### DiskImage.fwrk -**Purpose:** Disk image management and handling - -### KernelTest.fwrk -**Purpose:** Testing framework for kernel components - -### LaunchHelpers.fwrk -**Purpose:** Helper functions for system launch and initialization - -## Framework Creation - -### Using mk_fwrk.py - -The `mk_fwrk.py` tool automates framework creation: - -```bash -python3 tools/mk_fwrk.py -``` - -This generates: -1. Complete directory structure -2. Template `.json` manifest -3. Skeleton `DylibMain.cc` entry point -4. Template `xml/app.xml` metadata - -**Generated Structure:** -``` -.fwrk/ -├── .json -├── headers/ -│ └── .keep -├── src/ -│ ├── .keep -│ └── DylibMain.cc -├── xml/ -│ └── app.xml -└── .keep -``` - -## Compilation and Linking - -### Build Process - -1. **Configuration Phase**: Read and parse `.json` -2. **Compilation Phase**: Compile source files with specified compiler and flags -3. **Linking Phase**: Link object files into dynamic library -4. **Output Phase**: Place compiled binary in `dist/` directory - -### Dependencies - -- Frameworks can depend on: - - System libraries (via SystemKit) - - Other frameworks (via headers_path) - - Kernel components (via kernel paths in headers_path) - -### Linking Order - -When building applications that use frameworks: -1. Frameworks are linked in dependency order -2. CoreFoundation is typically a base dependency -3. Framework paths and library names must match manifest output names - -## Naming Conventions - -- **Framework directories**: `.fwrk` (PascalCase + .fwrk suffix) -- **JSON manifest**: `.json` (matches framework directory name) -- **Output library**: `lib.fwrk.dylib` -- **Namespaces**: Two-letter abbreviations (e.g., `CF`, `DI`, `KT`, `LH`) -- **Macros**: `k` prefix (e.g., `kCFVersion`) - -## Version Specification - -Frameworks should include version information via preprocessor macros: - -- **`kVersion`**: Current framework version (e.g., `0x0100` for v1.0) -- **`kVersionHighest`**: Highest compatible version -- **`kVersionLowest`**: Lowest compatible version - -**Version Format**: Hexadecimal (e.g., `0x0100` = 1.0, `0x0201` = 2.1) - -## Architecture Support - -Frameworks can be compiled for multiple architectures: - -- **x86_64** (amd64): 64-bit x86/AMD64 architecture -- **ARM64**: 64-bit ARM architecture -- **RISC-V 64**: RISC-V 64-bit architecture -- **PowerPC 64**: PowerPC 64-bit architecture - -Architecture is typically controlled via: -- Compiler selection in manifest -- C++ macros (`__NE_AMD64__`, `__NE_ARM64__`, etc.) - -## Best Practices - -1. **Header Organization**: Keep headers minimal; place implementation in `.cc` files -2. **Namespace Usage**: Encapsulate all public APIs in framework namespace -3. **Dependencies**: Minimize external dependencies; prefer kernel APIs -4. **Configuration**: Use `.json` manifest for all build-time configuration -5. **Documentation**: Include copyright headers and documentation comments in code -6. **Error Handling**: Define framework-specific error codes and status returns -7. **Testing**: Provide test cases using KernelTest.fwrk when applicable - -## Integration with Applications - -Applications that use frameworks: - -1. **Include Headers**: `#include ` -2. **Link Framework**: Add framework library to linker flags -3. **Initialize**: Call framework initialization if provided -4. **Handle Errors**: Check return codes and handle framework exceptions - -## File Permissions - -- Framework files: Standard text (`.h`, `.cc`, `.json`, `.xml`) -- Build artifacts: Auto-generated and read-only during runtime -- Framework package: Should be distributable as single `.fwrk` directory - diff --git a/docs/drawio/GUI_DESIGN.drawio b/docs/drawio/GUI_DESIGN.drawio deleted file mode 100644 index bdf977af..00000000 --- a/docs/drawio/GUI_DESIGN.drawio +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/docs/md/SPECIFICATION_KERNEL.md b/docs/md/SPECIFICATION_KERNEL.md deleted file mode 100644 index 6f1fae03..00000000 --- a/docs/md/SPECIFICATION_KERNEL.md +++ /dev/null @@ -1,66 +0,0 @@ -=================================== - -# 0: General Information - -=================================== - -- ABI and Format: PEF/PE32+. -- Kernel architecture: Portable hybrid Kernel. -- Language: C++/(Assembly (AMD64, X64000, X86S, ARM64, POWER, RISCV)) - -=================================== - -# 1: The Kernel (NeKernel) - -=================================== - -- Drive/Device Abstraction. -- SMP, Preemptive Multi Threading. -- Separation of Files/Devices. -- Networking. -- Hardware Abstraction Layer. -- Native Filesystem support (NeFS, FAT32 and ffs2). -- Program Loaders interfaces. -- TLS (Thread Local Storage) support. -- BinaryMutex, Locks, Timers. -- Canary mechanisms. -- Dynamic Loader. -- Cross Platform. -- Permission Selectors. - -=================================== - -# 2: The Filesystem (NeFS) - -=================================== - -- Catalog object with associated forks. -- Large storage support. -- Long file names. -- UNIX path style. -- Can be formated under 8mb. - -================================== - -# 3: Common naming conventions: - -================================== - -- Kernel -> ke_init_x -- RunTime -> rt_copy_mem -- Hal -> hal_foo_bar -- Class methods -> Class::FooBar - -Internals function shall be formated as such: (hali, rtli, rti...) - -=================================== - -# 4: The Bootloader (BootZ) - -=================================== - -- Capable of booting from a network drive. -- Loads a PE file which is the Kernel. -- Sanity checks, based on the number of sections. -- Handover compliant. -- Does check for a valid partition (useful in the case of recovering) diff --git a/docs/md/SPECIFICATION_MBCI.md b/docs/md/SPECIFICATION_MBCI.md deleted file mode 100644 index 63452a85..00000000 --- a/docs/md/SPECIFICATION_MBCI.md +++ /dev/null @@ -1,34 +0,0 @@ -=================================== - -# 0: General Information - -=================================== - -- High Speed Bus Format. -- Designed for keyboards, mouses, interfaces. -- A open and cheap alternative to other HCIs. - -=================================== - -# 1: Concepts - -=================================== - -- MBCI Host -- MBCI Authentication key (24-bit number) -- MBCI Host Kind and Flags. - -=================================== - -# 2: Pinout - -=================================== - -- VCC (IN) (OUT for MCU) -- CLK (IN) (OUT for MCU) -- ACK (BI) (Contains an Acknowledge Packet Frame) -- D0- (IN) (Starts with the Host Interface Packet Frame) -- D1- (IN) (Starts with the Host Interface Packet Frame) -- D0+ (OUT) (Starts with the Host Interface Packet Frame) -- D1+ (OUT) (Starts with the Host Interface Packet Frame) -- GND (IN) (OUT for MCU) \ No newline at end of file diff --git a/docs/mermaid/.gitkeep b/docs/mermaid/.gitkeep deleted file mode 100644 index e69de29b..00000000 diff --git a/docs/specs/SPECIFICATION_FWRK.md b/docs/specs/SPECIFICATION_FWRK.md new file mode 100644 index 00000000..b506b266 --- /dev/null +++ b/docs/specs/SPECIFICATION_FWRK.md @@ -0,0 +1,296 @@ +=================================== + +# 0: General Information + +=================================== + +- ABI and Format: PEF/PE32+. +- Target: NeKernel. + +=================================== + +# 1: The specification + +=================================== + +## Overview + +The NeKernel framework system (`.fwrk`) provides a standardized structure for creating modular, reusable libraries and components. Frameworks are self-contained packages that include headers, source code, metadata, and configuration for compilation and deployment within the NeKernel ecosystem. + +## Framework Directory Structure + +Each framework follows the standardized directory layout below: + +``` +.fwrk/ +├── .json # Framework manifest and build configuration +├── headers/ # Public API headers +│ ├── *.h # Public header files (C++ headers) +│ └── ... +├── src/ # Implementation source files +│ ├── *.cc # C++ implementation files +│ ├── DylibMain.cc # Dynamic library entry point (optional) +│ └── ... +├── xml/ # Framework metadata and properties +│ └── app.xml # Framework property list +├── dist/ # Build output directory +│ └── lib.fwrk.dylib # Compiled dynamic library +└── .keep # Placeholder file +``` + +## Component Specifications + +### 1. Framework Manifest (`.json`) + +The JSON manifest file defines the build configuration, compilation flags, and metadata for the framework. + +**Required Fields:** + +- **`compiler_path`** (string): Path to the C++ compiler executable + - Example: `"clang++"`, `"x86_64-w64-mingw32-g++"` + +- **`compiler_std`** (string): C++ standard version + - Example: `"c++20"`, `"c++17"` + +- **`headers_path`** (array): Array of header search paths (relative to framework) + - Include paths for finding dependencies and kernel interfaces + - Example: `["./", "../../../src/kernel", "../../../public/frameworks/", "../../../src/"]` + +- **`sources_path`** (array): Array of source file globs to compile + - Example: `["src/*.cc"]` + +- **`output_name`** (string): Path and filename for compiled library output + - Example: `"./dist/libCoreFoundation.fwrk.dylib"` + +**Optional Fields:** + +- **`compiler_flags`** (array): Custom compilation flags + - Example: `["-ffreestanding", "-shared", "-fno-rtti", "-fno-exceptions"]` + +- **`cpp_macros`** (array): C++ preprocessor macro definitions + - Example: `["kCFVersion=0x0100", "__NE_AMD64__", "__CF_64BIT__"]` + +**Example Manifest:** +```json +{ + "compiler_path": "x86_64-w64-mingw32-g++", + "compiler_std": "c++20", + "headers_path": ["../", "./", "../../../dev", "../../../src/kernel"], + "sources_path": ["src/*.cc"], + "output_name": "./dist/libCoreFoundation.fwrk.dylib", + "compiler_flags": [ + "-ffreestanding", + "-shared", + "-fno-rtti", + "-fno-exceptions", + "-Wl,--subsystem=17" + ], + "cpp_macros": [ + "kCFVersion=0x0100", + "kCFVersionHighest=0x0100", + "kCFVersionLowest=0x0100", + "__NE_AMD64__", + "__CF_64BIT__" + ] +} +``` + +### 2. Public Headers Directory (`headers/`) + +Contains all public-facing C++ header files that define the framework's API. + +**Conventions:** +- File extension: `.h` (not `.hpp`) +- Namespace: Typically matches framework name (e.g., `CF::` for CoreFoundation) +- Include guards: Use `#pragma once` for header protection +- Copyright headers: Include NeKernel copyright notice at the top + +**Typical Headers:** +- Main header providing overall framework interface +- Specialized headers for different components +- Type definitions and class declarations +- Exception/error definitions + +### 3. Source Implementation Directory (`src/`) + +Contains C++ implementation files for the framework. + +**Key Files:** + +- **`DylibMain.cc`** (Optional): + - Entry point for dynamic library initialization + - Contains `_DylibAttach(SInt32 argc, Char* argv[])` function + - Returns status code (0 for success, EXIT_FAILURE otherwise) + + **Example:** + ```cpp + #include + + SInt32 _DylibAttach(SInt32 argc, Char* argv[]) { + // Initialization code here + return EXIT_FAILURE; // Change based on initialization result + } + ``` + +- **Implementation Files** (`*.cc`): + - Correspond to public headers + - Contain class definitions and function implementations + - Include necessary system and framework headers + +### 4. Metadata Directory (`xml/`) + +Contains XML-based property list files for framework metadata. + +**`app.xml` Structure:** +- PropertyList format for framework configuration +- Typically includes: + - `LibraryName`: Framework name (string) + - `CacheLibs`: Whether to cache library (boolean) + - Other framework-specific properties + +**Example:** +```xml + + + +``` + +### 5. Build Output Directory (`dist/`) + +Auto-generated directory containing compiled framework binaries. + +- **Output file**: `lib.fwrk.dylib` +- Created during build process via `mk_fwrk.py` +- Not committed to version control + +## Built-in Frameworks + +The NeKernel project includes the following standard frameworks: + +### CoreFoundation.fwrk +**Purpose:** Core data structures and utilities foundation +**Provides:** +- Reference types (CFRef) +- String handling (CFString) +- Collections (Arrays, Dictionaries) +- Geometric types (CFPoint, CFRect, CFColor) +- Object system (CFObject, CFProperty) + +### DiskImage.fwrk +**Purpose:** Disk image management and handling + +### KernelTest.fwrk +**Purpose:** Testing framework for kernel components + +### LaunchHelpers.fwrk +**Purpose:** Helper functions for system launch and initialization + +## Framework Creation + +### Using mk_fwrk.py + +The `mk_fwrk.py` tool automates framework creation: + +```bash +python3 tools/mk_fwrk.py +``` + +This generates: +1. Complete directory structure +2. Template `.json` manifest +3. Skeleton `DylibMain.cc` entry point +4. Template `xml/app.xml` metadata + +**Generated Structure:** +``` +.fwrk/ +├── .json +├── headers/ +│ └── .keep +├── src/ +│ ├── .keep +│ └── DylibMain.cc +├── xml/ +│ └── app.xml +└── .keep +``` + +## Compilation and Linking + +### Build Process + +1. **Configuration Phase**: Read and parse `.json` +2. **Compilation Phase**: Compile source files with specified compiler and flags +3. **Linking Phase**: Link object files into dynamic library +4. **Output Phase**: Place compiled binary in `dist/` directory + +### Dependencies + +- Frameworks can depend on: + - System libraries (via SystemKit) + - Other frameworks (via headers_path) + - Kernel components (via kernel paths in headers_path) + +### Linking Order + +When building applications that use frameworks: +1. Frameworks are linked in dependency order +2. CoreFoundation is typically a base dependency +3. Framework paths and library names must match manifest output names + +## Naming Conventions + +- **Framework directories**: `.fwrk` (PascalCase + .fwrk suffix) +- **JSON manifest**: `.json` (matches framework directory name) +- **Output library**: `lib.fwrk.dylib` +- **Namespaces**: Two-letter abbreviations (e.g., `CF`, `DI`, `KT`, `LH`) +- **Macros**: `k` prefix (e.g., `kCFVersion`) + +## Version Specification + +Frameworks should include version information via preprocessor macros: + +- **`kVersion`**: Current framework version (e.g., `0x0100` for v1.0) +- **`kVersionHighest`**: Highest compatible version +- **`kVersionLowest`**: Lowest compatible version + +**Version Format**: Hexadecimal (e.g., `0x0100` = 1.0, `0x0201` = 2.1) + +## Architecture Support + +Frameworks can be compiled for multiple architectures: + +- **x86_64** (amd64): 64-bit x86/AMD64 architecture +- **ARM64**: 64-bit ARM architecture +- **RISC-V 64**: RISC-V 64-bit architecture +- **PowerPC 64**: PowerPC 64-bit architecture + +Architecture is typically controlled via: +- Compiler selection in manifest +- C++ macros (`__NE_AMD64__`, `__NE_ARM64__`, etc.) + +## Best Practices + +1. **Header Organization**: Keep headers minimal; place implementation in `.cc` files +2. **Namespace Usage**: Encapsulate all public APIs in framework namespace +3. **Dependencies**: Minimize external dependencies; prefer kernel APIs +4. **Configuration**: Use `.json` manifest for all build-time configuration +5. **Documentation**: Include copyright headers and documentation comments in code +6. **Error Handling**: Define framework-specific error codes and status returns +7. **Testing**: Provide test cases using KernelTest.fwrk when applicable + +## Integration with Applications + +Applications that use frameworks: + +1. **Include Headers**: `#include ` +2. **Link Framework**: Add framework library to linker flags +3. **Initialize**: Call framework initialization if provided +4. **Handle Errors**: Check return codes and handle framework exceptions + +## File Permissions + +- Framework files: Standard text (`.h`, `.cc`, `.json`, `.xml`) +- Build artifacts: Auto-generated and read-only during runtime +- Framework package: Should be distributable as single `.fwrk` directory + diff --git a/docs/specs/SPECIFICATION_KERNEL.md b/docs/specs/SPECIFICATION_KERNEL.md new file mode 100644 index 00000000..fe2cb9da --- /dev/null +++ b/docs/specs/SPECIFICATION_KERNEL.md @@ -0,0 +1,66 @@ +=================================== + +# 0: General Information + +=================================== + +- ABI and Format: PEF/PE32+. +- Kernel architecture: Portable hybrid Kernel. +- Used Languages: C++, and Assembly Assembly (AMD64, X64000, X86S, ARM64, POWER, RISCV) + +=================================== + +# 1: The Kernel (NeKernel) + +=================================== + +- Drive/Device Abstraction. +- SMP, Preemptive Multi Threading. +- Separation of Files/Devices. +- Networking. +- Hardware Abstraction Layer. +- Native Filesystem support (NeFS, FAT32 and ffs2). +- Program Loaders interfaces. +- TLS (Thread Local Storage) support. +- BinaryMutex, Locks, Timers. +- Canary mechanisms. +- Dynamic Loader. +- Cross Platform. +- Permission Selectors. + +=================================== + +# 2: The Filesystem (NeFS) + +=================================== + +- Catalog object with associated forks. +- Large storage support. +- Long file names. +- UNIX path style. +- Can be formated under 8mb. + +================================== + +# 3: Common naming conventions: + +================================== + +- Kernel -> ke_init_x +- RunTime -> rt_copy_mem +- Hal -> hal_foo_bar +- Class methods -> Class::FooBar + +Internals function shall be formated as such: (hali, rtli, rti...) + +=================================== + +# 4: The Bootloader (BootZ) + +=================================== + +- Capable of booting from a network drive. +- Loads a PE file which is the Kernel. +- Sanity checks, based on the number of sections. +- Handover compliant. +- Does check for a valid partition (useful in the case of recovering) diff --git a/docs/specs/SPECIFICATION_MBCI.md b/docs/specs/SPECIFICATION_MBCI.md new file mode 100644 index 00000000..63452a85 --- /dev/null +++ b/docs/specs/SPECIFICATION_MBCI.md @@ -0,0 +1,34 @@ +=================================== + +# 0: General Information + +=================================== + +- High Speed Bus Format. +- Designed for keyboards, mouses, interfaces. +- A open and cheap alternative to other HCIs. + +=================================== + +# 1: Concepts + +=================================== + +- MBCI Host +- MBCI Authentication key (24-bit number) +- MBCI Host Kind and Flags. + +=================================== + +# 2: Pinout + +=================================== + +- VCC (IN) (OUT for MCU) +- CLK (IN) (OUT for MCU) +- ACK (BI) (Contains an Acknowledge Packet Frame) +- D0- (IN) (Starts with the Host Interface Packet Frame) +- D1- (IN) (Starts with the Host Interface Packet Frame) +- D0+ (OUT) (Starts with the Host Interface Packet Frame) +- D1+ (OUT) (Starts with the Host Interface Packet Frame) +- GND (IN) (OUT for MCU) \ No newline at end of file -- cgit v1.2.3