그러니까.. 이제 cpu에 ram이 달린게 아닌 ram에 cpu가 달린 녀석이 나오면 되는건가..(!!)
Q : 그럼 무엇을 해야 하나? A : “인터페이스(물리적 구조)를 바꿔야 한다. HBM의 핵심 목적은 속도를 늦추고, 복잡도를 낮추며, 전력 소모를 줄이는 거였다. 그런데 계속 속도를 높이면서 전력 소비와 비용이 커지고 있다. ‘약간 빨라진 차세대 D램’은 흥미롭지 않다. 진정한 변화가 필요하다.”
32-bit MCU & 2.4 GHz Wi-Fi & Bluetooth 5 (LE) Xtensa® 32-bit LX7 dual-core processor that operates at up to 240 MHz 512 KB of SRAM and 384 KB of ROM on the chip, and SPI, Dual SPI, Quad SPI, Octal SPI, QPI, and OPI interfaces that allow connection to flash and external RAM Additional support for vector instructions in the MCU, which provides acceleration for neural network computing and signal processing workloads Peripherals include 45 programmable GPIOs, SPI, I2S, I2C, PWM, RMT, ADC, DAC and UART, SD/MMC host and TWAI™ Reliable security features ensured by RSA-based secure boot, AES-XTS-based flash encryption, the innovative digital signature and the HMAC peripheral, “World Controller” Fully certified with integrated antenna and software stacks
esp32
32-bit MCU & 2.4 GHz Wi-Fi & Bluetooth/Bluetooth LE ESP32 embedded, two or one Xtensa® 32-bit LX6 microprocessor(s) with adjustable clock frequency, ranging from 80 MHz to 240 MHz +19.5 dBm output power ensures a good physical range Classic Bluetooth for legacy connections, also supporting L2CAP, SDP, GAP, SMP, AVDTP, AVCTP, A2DP (SNK) and AVRCP (CT) Support for Bluetooth Low Energy (Bluetooth LE) profiles including L2CAP, GAP, GATT, SMP, and GATT-based profiles like BluFi, SPP-like, etc Bluetooth Low Energy (Bluetooth LE) connects to smart phones, broadcasting low-energy beacons for easy detection Sleep current is less than 5 μA, making it suitable for battery-powered and wearable-electronics applications Peripherals include capacitive touch sensors, Hall sensor, SD card interface, Ethernet, high-speed SPI, UART, I2S and I2C Fully certified with integrated antenna and software stacks
golang에서는 비트 구조체 안되던것 같은데 러스트에서는 된다고 하니 관심이 증가중 ㅋㅋ
머 리눅스 커널에서도 쓰려고 하는데 설마 없겠어? 싶기도 하네
use bit_struct::*;
enums! {
// 2 bits, i.e., 0b00, 0b01, 0b10
pub HouseKind { Urban, Suburban, Rural}
}
bit_struct! {
// u8 is the base storage type. This can be any multiple of 8
pub struct HouseConfig(u8) {
// 2 bits
kind: HouseKind,
// two's compliment 3-bit signed number
lowest_floor: i3,
// 2 bit unsigned number
highest_floor: u2,
}
}
// We can create a new `HouseConfig` like such:
// where all numbers are statically checked to be in bounds.
let config = HouseConfig::new(HouseKind::Suburban, i3!(-2), u2!(1));
// We can get the raw `u8` which represents `config`:
let raw: u8 = config.raw();
assert_eq!(114_u8, raw);
// or we can get a `HouseConfig` from a `u8` like:
let mut config: HouseConfig = HouseConfig::try_from(114_u8).unwrap();
assert_eq!(config, HouseConfig::new(HouseKind::Suburban, i3!(-2), u2!(1)));
// We need to unwrap because `HouseConfig` is not valid for all numbers. For instance, if the
// most significant bits are `0b11`, it encodes an invalid `HouseKind`. However,
// if all elements of a struct are always valid (suppose we removed the `kind` field), the struct will
// auto implement a trait which allows calling the non-panicking:
// let config: HouseConfig = HouseConfig::exact_from(123_u8);
// We can access values of `config` like so:
let kind: HouseKind = config.kind().get();
// And we can set values like so:
config.lowest_floor().set(i3!(0));
// We can also convert the new numeric types for alternate bit-widths into the
// numeric types provided by the standard library:
let lowest_floor: i3 = config.lowest_floor().get();
let lowest_floor_std: i8 = lowest_floor.value();
assert_eq!(lowest_floor_std, 0_i8);