Personally, I really like svelte. Either use a bundler + js library for redirects OR SvelteKit with static adapter (https://kit.svelte.dev/docs/adapter-static). Fyi I use the latter since it's easier to setup and bit more trouble-free to use overall :D
Tbh, I liked expo, but since you cannot build locally nowdays (you can eject and build, but that won't work 99% of the time, literally didn't work for me on the hello world example), I kinda just threw it in the "cool, but won't use" bucket for time beeing :/, could change in the future, but I don't know how I feel about 3d party service (EAS) building my app and holding my signing certificates (yet)
The Expo Go app needs to connect to a server for two reasons: the server gives you a signing certificate that is used to sign your project manifest, and it also fetches the list of active and recent projects and Snacks. It is certainly not intended to be invasive.
Expo Go is entirely optional and it is recommended to graduate early on in your development cycle to using a development build of your own app instead. Development builds don't sign project manifests (unless you're intentionally using end-to-end signed updates, an advanced feature). They are like regular development builds of a traditional native app.
Also if you'd like to keep using Expo Go, the signing certificate mentioned earlier has an expiry of 30 days or so IIRC, during which time you don't need to connect to a server. You may still want to provide the "--offline" flag to turn off refreshing the certificate.
FYI I've made a patchset that pretty much allows me to actually use the EAS --local builds offline and without an EAS account, so it's in fact possible, even though they, for obvious reasons (e.g. https://github.com/expo/eas-cli/issues/1606), don't encourage it.
Would you mind sharing this? I’ve only used expo for experimental non-production apps so far but it works be great to be able to do this if ever needed. Reading this thread makes me a bit more hesitant about using expo.
My full build process is somewhat more complicated to keep my $HOME clean and remove other impurities, but just these patches should be enough to enable offline building.
EAS CLI is designed for EAS, the hosted services. It is intended to use your EAS account, which I suspect is why the PR wasn't accepted.
Expo CLI is for entirely local builds. Run "npx expo prebuild:{android,ios}" to generate your Android Studio and Xcode projects, and build them with the IDEs or their respective CLI tools directly.
You can build locally without ejecting; just throw the --local flag on the end of your eas build command This does what EAS would do, just on your local machine. If you remove the --local flag, it will send it up to EAS to do the build.
eas build --profile develop --platform ios --local
yes, you are right, however, AFAIK you still need to be logged + have it linked to eas project (because it uses eas credentials) + this method is planned to be deprecated soon [?] (I'm 100% sure I read stuff like this when researching it like half a year ago, but cannot find it for the love-of-god atm :D, but I would like to be proved otherwise, because the build step is the only thing I disliked about expo long-term wise)
... now looking more into it, I probably mistook `npm run export` / `expo build` with `eas build --local`. Is this correct?
I think your commands are kind of muddled. By `npm run export`, I assume you are referring to `expo export`? That is responsible for bundling your app for OTA updates. `expo build` is the deprecated method for building your Expo app with the old ExpoKit native shell app. Only `eas build --local` is the actual command for locally building your app.
Perhaps the issue you're thinking about was what I linked to in my other comment?
By my own thinking, I believe it's quite unlikely that Expo will ever manage to actually totally remove support for local builds, even though they probably will never encourage it; as otherwise, its really quite impossible to debug native builds, and indeed local builds are Expo's recommendation for debugging such issues. With regular React Native native dependencies now possible in Expo, a dizzying new array of hard to diagnose bugs can now be triggered, and its unlikely Expo is ever going to go back on their support for arbitrary native dependencies.
Yeah, afaik, in the old template version `npm run export` activated the `expo export` and THAT got deprecated (recently), however at the time (about half a year ago) I thought that the `--local` flag was getting deprecated. Sorry, that was a huge misunderstanding on my end!
Building Expo apps on your own hardware is definitely supported. Specifically, run "npx expo prebuild:{android,ios}" to generate your project's "android" and "ios" directories. Open them up in Android Studio and Xcode (or use their command-line equivalents), respectively, and build.
The managed services (EAS) are optional for Expo apps. The independence between Expo, the free and open source framework, and EAS, the hosted service offering, is something the Expo team consciously works on.
Building Expo apps locally is not going to be removed. I am one of the cofounders of Expo.
Being able to build your app on your own hardware is a relatively fundamental feature of any application software framework. The Expo framework is free and open source and we consciously keep it decoupled from Expo Application Services (EAS), which is a suite of hosted services we manage.
Two of the ways to build your app are:
- Entirely locally, without EAS: generate your native Android and iOS projects with "npx expo prebuild:{android,ios}" and build your app with Android Studio/Gradle and Xcode/xcodebuild, respectively.
- With EAS: after getting set up with EAS, installing EAS CLI, and configuring eas.json, run "eas build". There is also a "--local" flag that runs the compilation steps locally and uses your signing credentials managed by EAS.
Many developers use a mix. For instance, they'll build locally when working on a feature for a fast feedback loop. And they'll use EAS to build their release candidates and PR previews to share with their team.
Hi, just asking, I'm interested in embedded but as an outsider I fail to understand how would I go about making custom board? I googled a lot, but I still fail to grasp how do you make the board? How do you program the chip? How can you test your board? How can you prototype on an arduino, if you'll use different architecture STM vs Atmega, etc...
I've done some arduino projects using VSCode and Platformio and I want to level up my skill level, however I've been struggling to find a resources that goes throught the process of actually making the product from scratch (starts with nothing and ends with a programmed product on custom board). For example, I have this project of mine where I make smart watches using an arduino and e-ink paper display. I would like to read / watch a resource where I learn to design a board that has custom STM32
I am probably about in the same spot that you are. I've been slowly working my way through this course from Andre LaMothe, I think pieces of it might be applicable for you. It's a Udemy course, so it goes on sale for ~$20ish pretty often, I think it's really well done and I've learned a lot so far.
You could start by doing an io board for one of your stm32 board. You start by doing the schematic in kicad eeschema, debug on the breadboard and then you route the actual pcb in kicad pcbnew. There are a lot of tutorial on YouTube on how to use kicad.
After that you can have it fabricated and assembled in China. It's not a necessity but it is really convenient for surface mounted parts and it is surprisingly inexpensive.
Once your comfortable doing io boards, try to replicate one of your stm32 board.
That will give you an idea about the bare minimum circuit one needs to build a functioning board (crystal, power regulator, boot select buttons, and so on)
First, make a schematic. This covers which things are electrically connected together so it's easier to see what connections there are. There's always "boilerplate" circuitry, so you'll want to start with an existing schematic. Eg https://stm32-base.org/assets/pdf/boards/original-schematic-...
Then you design the board. You take the schematic, and then actually draw the actual wires (traces) on a board, and tell it which parts go where. The output from this step is a series of Gerber files. They look something like https://info.ewmfg.com/hubfs/Gerber-file-East-West-MFG.png
Finally, you send the board files off to a fab for them to make the board, and optionally solder all the parts on. You used to be able to make it yourself but these days, a pcb house, or manufacturing facility is the way to go.
KiCad is the preferred hobbyist software package these days.
/r/PrintedCircuitBoard/ has some good resources for this process.
> How do you program the chip?
These days, via USB. Circuitry is so cheap these days that the easiest thing to do is have a USB port, and a 'program' button, so when you hold the button down, and power up the device, it boots into a special mode where it can be programmed. There are other techniques but they're mostly harder.
Back in the day, you would have a chip programming device where you would burn the code into a chip, and then have to physically put that chip into your circuit. In order to erase it, you would need to uncover a hole in the top of the chip, and then shine UV light on it.
> How can you test your board?
Depending on the level of debugging you need, a multimeter, a oscilloscope or a digital logic analyzer, in addition to printf debugging and using a debugger, possibly via JTAG.
A multimeter is good enough for simple low/high testing. Like why is this single LED not on, it should be one.
An oscilloscope is useful for graphing simple signals that a multimeter can't catch. If you're turning the LED on and off 50 times a second, it'll be dimmer than if it's just on the whole time (PWM), and an oscope is good for looking at those 50 times.
Finally, a digital logic analyzer. If you're using a bus, like I²C or SPI, and are sending bytes and bytes of data, you can read those off an oscilloscope; low, high, low low is a 4, but that gets old real quick. A digital logic analyzer will interpret the signals on the wire and just tell you the bytes.
Most chips will have a serial port so you can do printf/console.log-grade debugging. You may need additional circuitry to talk to this port, or it may happen over USB.
Finally some microcontrollers support in-circuit emulation (ICE) debugging methods. The two big ones are JTAG and SWE. These let you connect your computer to the microcontroller, and then step through your code, line by line, using a debugger.
> How can you prototype on an arduino, if you'll use different architecture STM vs Atmega, etc...
To be clear, that's not recommended. You're writing in C, not assembly so the code you write is largely portable, so it's just a matter of copying your code to a different configuration, updating the code that interacts with the chip's hardware, and then recompiling.
Updating the code may or may not be trivial though. And personally it's not especially fun. I'd just use the same chip for prototyping as I'd want in my production run. If you have your heart set on using an STM32, just use a dev kits for that to prototype with eg https://www.digikey.com/en/products/detail/stmicroelectronic... instead of an Arudino.
And of course, these days, and on the linked article, you can program in MicroPython instead of C, which is easier.
This was a great answer but the mashup of wildly varying abstraction levels made me chuckle a little. “Debugging? You’ll need printf()… and an oscilloscope.”
chip on it, e-ink display sawthered on and etc, just get me from my prototype to a full on product. Basically, I want to advance my skills to the next level, but I struggle to find how :/ .... you seem to have experience in this kind of stuff, could you please answear some of these questions?
Ps: accidentally posted before I finished the comment and using mobile client without ability to edit comments :d
Ps2: these comments are kinda out of context, but it's something that's bothering me for more than a month now.
In theory you can play with KiCad and draw something up. There's lots of tutorials on KiCad. There's always ESP32 layouts online you can start from too. You can probably figure out how to connect the memory bus to your peripherals correctly but there's always mistakes to be made. That's why it's slightly harder than a minor hobby imho since you really want a full electronics bench including logic analyzer. So it's a big expensive hobby.
If you really want a custom board I'd honestly prototype with a dev kit board like the above and then contract out what you really want to a board design company, showing them your hacked up prototype. Expect $30k for an ESP32 layout that precisely does what you want with no fluff and minimal expense. You then send that off to a PCB maker for the first run and test when it gets back. If all is well you send it off again for a larger more cost effective run.
Hey, recentlly wrote a little site that could be relevant here (ip-atlas.tomasdiblik.cz), basically, I download ip2asn list and list how many IPs (4s and 6es) are not routed yet and how many are owned by which entity (and what ranges). Idk it was an interesting weekend project :D (Although, I was kinda suprised that percentage-wise, number of IPv6 and IP4 is nearly identical, makes you wonder wether companies should own HUNDREDS OF MILIONS of IPv6es)
PS: The site can get laggy on low end devices, because of the number of records (sorry :(, but I didn't want to spend too much time on this project)
And then being pointed at as a source of all problems. I'm pretty sure I've heard about something similar that was happening in Slovanian countries not so long ago :D /s
