›

A bit of insight concerning new M1 processor chip

drive1976drive1976
in iOS

Recently I switched over to a Mac Mini with the M1 processor build by Apple..
Since Apple is now manufacturing their own chip (the M1 rather than using the previous Intel processor build) it was very difficult understanding the MbientLab tutorial (no fault of their own) set up guide to implement Swift API’s for application functionality. I researched for two days straight almost a 48 hour run on trying to figure out my new device and how I can implement the Swift API’s in order to start the process of building an application for our project. I noticed flaws while setting up my Mac Mini M1. It did not coincide with the MbientLab site tutorial of Mac OS.
This is because of how new the Mac mini M1 processor is, and as well as how different it is then any other processing chip. To no fault of their own MbientLab just needs to update their tutorial concerning the M1 processor chip. I will suggest the process I am taking to them in order for them to help out others with this problem. I will continue to post in hopes my info helps others having the same problem of functionality that I had.

Some of the fixes were easy and some were difficult. I The first thing I noticed was how hard it was to use the default terminal of the M1. The most important issues I was having is you must set up Homebrew , which is necessary of the process of setting up Rubygems as well as the Cocoapods. Both of which are needed for application functionality. To do so you must either use your default terminal in Rosetta 2, or you can also install it native. Just remember that Rossetta version is stored in /usr/local/bin/brew, and native in /opt/homebrew/bin/brew. Another solution is to install a trusted outside terminal. The default terminal was hard to use for me to use at first, but then I watched this video (which I highly recommend). Previous to watching the video I kept coming up with loading errors and while researching into terminal use, I found it might be a better idea to go to the top left corner of my screen, left click shell and run it native in the homebrew shell. Although when I used the command ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” that was recommended, it did not work on any terminal feasible to the M1. So to remedy this I installed Homebrew straight from the brew.sh website. Using the command arch-x86_64 /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)” natively on the default terminal. From there it installed Homebrew safely into the terminal and now Hombrew and all its functionalities were safely installed and ready to use. Everything else was fairly easy as long as the brew commands were implemented in the process of cocoapods. I’ll add more as I go along. Thought it would be a good idea since I didn’t see much about the M1. It sure is working out great so far. Knock on wood. I would stress however not to use the gem clean up command for now. I don’t now if it was coincidence or something I did by mistake but after I preformed a cleanup I lost most of my gems and had to start the process over. That was when I kept having major gem installation issues.

Comments

  • moccasin655moccasin655

    I'm curious, have you tried running the Metabase app on the M1? I'm thinking about getting an M1 Mac Mini to use with an MMR sensor so I can sync accelerometer data collection with other software, but not sure if it will work. I won't be doing any development, just using Metabase as-is, so hopefully it will be easier than what you're up to! Any insights would be appreciated. Thank you!

  • jjm345jjm345

    @drive1976 were you able to successfully create your app using the SwiftAPI on an M1 Mac? I am debating if I should purchase a refurbished Mac with the Intel chip just to be safe.

  • ryanferrellryanferrell
    edited January 2022

    @drive1976 @jjm345 @moccasin655

    A preview of a new MetaBase app for macOS and iOS is on TestFlight. It uses iCloud sync for devices and sensor recordings. We built it on an M1 Mini. On the App Store is also a new MetaWear app, built using SwiftUI with the Bolts SDK, also on the M1 Mini.

    Bolts isn't as fun as Combine, though. We're now building a Swift SDK using Combine. It's less verbose and you don't need unsafe Swift everywhere.

    We're wrapping up a tutorial series if you'd like to give feedback on the current draft. Reading is a bit smoother in Xcode's doc browser, but the HTML version is fine. To use Xcode, double click a DocC archive here or clone the SDK package and press Control Shift Command D to build the docs.

    We still need to wrap more complicated commands in Combine, but you can still mix in C as needed. For flavor, here’s a snippet logging a variant selection of sensors.

    downloadPipeline = metawear
    .publishWhenConnected()
    .first()
    .optionallyLog(configs.accelerometer)
    .optionallyLog(configs.gyroscope)
    .optionallyLog(configs.quaternion)
    .sink(receiveCompletion: { [weak self] in
        self?.displayError(ifFound: $0)
    }, receiveValue: { [weak self] in
        self?.offerDownloadCallToAction()
    })

metawear.connect()

    Here’s a snippet that flashes the LEDs in purple or blue when pressing or releasing the MetaWear button.

    macroSub = metawear?
    .publishWhenConnected()
    .first()
    .command(.macroStartRecording(runOnStartup: true))
    .recordEvents(for: .buttonUp, { recording in
        recording.command(.ledFlash(.Presets.eight.pattern))
    })
    .recordEvents(for: .buttonDown, { recording in
        recording.command(.ledFlash(.Presets.zero.pattern))
    })
    .command(.macroStopRecordingAndGenerateIdentifier)
    .sink(receiveCompletion: { _ in }, receiveValue: { _ in })

metawear?.connect()
Sign In or Register to comment.