The 1-Wire protocol is a proprietary protocol (Maxim/Dallas) single-wire interface, half-duplex, bidirectional, low-speed and power, long-distance serial-data communication protocol. It operates over a single data line, without clock signal. But, at least two wires are required for 1-wire bus: Data, GND. An additional wire might be necessary (Vcc), depending on powering mode. The powering modes are: parasitic (no vcc), and conventional (with vcc), as seen on figures below.
This is a step-by-step guide for porting an application from MFC to wxWidgets based on my experience in porting Hippy.
- wxWidgets documentation for detailed class references.
- wxWidgets wiki for general wxWidgets programming guides
- Compiling using MS VC++
| diff --git a/apps/plugins/SOURCES b/apps/plugins/SOURCES | |
| index c512a9e..e9d6f58 100644 | |
| --- a/apps/plugins/SOURCES | |
| +++ b/apps/plugins/SOURCES | |
| @@ -221,7 +221,7 @@ superdom.c | |
| #endif /* LCD_DEPTH > 1 */ | |
| - | |
| +test_disk.c |
Used online repositories for Fedora/RHEL/CentOS linux:
-
The VLSI repository homepage: https://copr.fedorainfracloud.org/coprs/rezso/VLSI
-
The HDL repository homepage: https://copr.fedorainfracloud.org/coprs/rezso/HDL
-
Docker variants of this: https://github.com/cbalint13/copr-packages/tree/main/docker-examples
| # This is Gray Code oscillator that can be used on Lattice ECP5 devices to measure time down to around 500ps of | |
| # precision (with no manual placement!) using only two (!) slices. | |
| # | |
| # In essence how this works is that we create a self-clocking counter that runs as fast as the FPGA fabric will | |
| # allow. If we were to do this with a traditional counter, we would have to worry about propagation delay because | |
| # multiple bits change at a time. If you use gray-codes, however, only one bit is changing at any given time so | |
| # there are no issues with racing signals. | |
| # | |
| # If you drop this in a design and wire out the highest bit of the async_gray_count signal into a spectrum | |
| # analyzer, you will see a dominant frequency of about 125Mhz. In other words, we cycle through all 16 gray codes |
| [tasks] | |
| proof | |
| cover | |
| [options] | |
| proof: mode prove | |
| proof: depth 10 | |
| cover: mode cover | |
| cover: depth 40 |
| # IDA (disassembler) and Hex-Rays (decompiler) plugin for Apple AMX | |
| # | |
| # WIP research. (This was edited to add more info after someone posted it to | |
| # Hacker News. Click "Revisions" to see full changes.) | |
| # | |
| # Copyright (c) 2020 dougallj | |
| # Based on Python port of VMX intrinsics plugin: | |
| # Copyright (c) 2019 w4kfu - Synacktiv |
| # configure.ac | |
| # add an --enable-macos-universal-binary flag that when building for mac | |
| # create a universal x86_64 / arm64 binary | |
| AC_ARG_ENABLE([macos-universal-binary], | |
| [AS_HELP_STRING([--enable-macos-universal-binary], | |
| [Create an universal x86_64+arm64 binary when building for macos)])],, | |
| [enable_macos_universal_binary=no]) | |
| # Determine if we're building for macos/darwin by checking for macos & darwin |
| #!/usr/bin/env python3 | |
| from collections import namedtuple | |
| import socket | |
| import struct | |
| usbip_user_op_common = namedtuple('usbip_user_op_common', 'version code status') | |
| usbip_usb_device = namedtuple('usbip_usb_device', 'path busid busnum devnum speed idVendor idProduct bcdDevice bDeviceClass bDeviceSubClass bDeviceProtocol bConfigurationValue bNumConfigurations bNumInterfaces') | |
| usbip_header_basic = namedtuple('usbip_header_basic', 'command seqnum devid direction ep') |
According to Apple, the only way to remove an unknown firmware password from a MacBook (2011 and later) is to take it to the Apple Store with the original proof-of-purchase. However, I've found that there is another way, which I've been successful with for the unibody MacBook Pro--it's essentially just modifying a couple bytes in the EFI ROM, which should be simple. What's not simple, however, is figuring out how to read and write to the EFI chip. In this post, I'll talk about the process that I figured out and what worked for me.
Apple's method of resetting the firmware password is not reproducible, as Apple generates an SCBO file that unlocks the EFI using their private key. You can read more about this process here. The problem with this system is that, if you are in the unfortunate situation of neither having the firmware unlock pass

