| // | |
| // Basic instrumentation profiler by Cherno | |
| // Usage: include this header file somewhere in your code (eg. precompiled header), and then use like: | |
| // | |
| // Instrumentor::Get().BeginSession("Session Name"); // Begin session | |
| // { | |
| // InstrumentationTimer timer("Profiled Scope Name"); // Place code like this in scopes you'd like to include in profiling | |
| // // Code | |
| // } |
| #include <ArduinoJson.h> | |
| #include <Key.h> | |
| #include <Keypad.h> | |
| // Allow 5 seconds of lag from the device, to the game, and back to the device. | |
| #define BUTTON_SYNC_TIME 5000 | |
| // Each button press will last about 100ms. | |
| #define BUTTON_HOLD_TIME 100 |
You might want to read this to get an introduction to armel vs armhf.
If the below is too much, you can try Ubuntu-ARMv7-Qemu but note it contains non-free blobs.
First, cross-compile user programs with GCC-ARM toolchain. Then install qemu-arm-static so that you can run ARM executables directly on linux
If there's no qemu-arm-static in the package list, install qemu-user-static instead
| Submodule qtbase 519fcb38a2..705dee9621: | |
| diff --git a/qtbase/mkspecs/common/msvc-desktop.conf b/qtbase/mkspecs/common/msvc-desktop.conf | |
| index b7d2eecc82..755d92149c 100644 | |
| --- a/qtbase/mkspecs/common/msvc-desktop.conf | |
| +++ b/qtbase/mkspecs/common/msvc-desktop.conf | |
| @@ -22,6 +22,10 @@ contains(QMAKE_TARGET.arch, x86_64) { | |
| DEFINES += WIN64 | |
| QMAKE_COMPILER_DEFINES += _WIN64 | |
| } | |
| +contains(QMAKE_TARGET.arch, arm64) { |
| This patch implements numerous changes to make the Qt 5.10.1 build work for the new ARM64 target in | |
| Visual Studio 2017. This change also includes a couple of new batch scripts, in case you want to build | |
| on the target machine itself (very slow) or build on an x86/x86_64 host (much faster). | |
| You can build with something like this: | |
| > configure_src_on_x86_host.bat | |
| > jom -f Makefile Debug Release | |
| diff --git a/configure_src_on_target.bat b/configure_src_on_target.bat | |
| new file mode 100644 |
| Synology NAS - How to make a program run at startup | |
| The other day I created a little node.js project to keep track of some finances. Synology has a node.js package but that just installs the tools - it has no 'container' or any other support to drop files and have it run automagically. Maybe one day. | |
| In the meantime, you can start your project when you SSH into the NAS. My project has a 'www' script which bootstraps my project, so to start I simply type 'node bin/www' from the project directory. But, it only runs while I'm logged in, and if I log out for any reason, the process dies. That's hardly useful when I'm away from home, or on a different PC. So I decided to have a look at starting my project as a Linux service. | |
| After doing a lot of research into how Synology does services, and a few failed attempts at init scripts, I found that Synology DSM (since version 5 perhaps) bundles Upstart, which is a neat little tool to deal with services on Linux. It's most prevalent on Debian and derivatives (notably Ub |
| # Docker の ubuntu:16.04 に AArch64 用のクロスコンパイル環境をビルドする | |
| # 2017/06/29 | |
| # これ以外のファイルは、configure 時の出力ログです。 | |
| # sudo docker run --name cross_compile -it ubuntu:16.04 /bin/bash | |
| # Docker 環境のため、rootで動かしていることに注意してください。 | |
| # 作業環境の整備 | |
| apt update | |
| apt upgrade |
| package cache | |
| import ( | |
| "crypto/sha256" | |
| "encoding/json" | |
| "fmt" | |
| "os" | |
| "sync" | |
| "time" | |
| ) |
| #!/bin/bash | |
| # Where the changelog file will be created | |
| outputFile='%system.teamcity.build.tempDir%/releasenotesfile_%teamcity.build.id%.txt' | |
| # the url of teamcity server | |
| teamcityUrl='%teamcity.serverUrl%' | |
| # username to access Teamcity REST API | |
| username='%system.teamcity.auth.userId%' | |
| # password to access Teamcity REST API | |
| password='%system.teamcity.auth.password%' |
