I would start with a 5 $ linode and go until it explodes
I would start with a 5 $ linode and go until it explodes
ZWe dont need autoscaling, it's too ealy
Pwe don't want stuff to explode mid event
ZOh those are the best ones
Pvery bad ux
Zvery big news though
Pemotional damage
Tdifferent kind of explosion
Z
T
T^^Umesh during his next Engineering Hour
Zremember this is just. the IDE and we are the benevolent here, we reserve the right to explode when overloaded
Pfor ~50 concurrent users we'd still need servers with enough CPU and RAM to handle that
specially if we’re running a web-based IDE
it would be around $100–$300/month on AWS
specially if we’re running a web-based IDE
it would be around $100–$300/month on AWS
T100-300 more than current? i mean we could get that on patreon
P- $20–$50/month for load balancing if we want to reduce downtime
Pyes
MMy generation solved that one too - Mainframes 
Zknew it
TActually did you run into any punch card systems at uni?
MI was just after punch cards - but we still had to submit jobs through the control. The jobs would be run at some point later and we could pick up the results the next day.
TSo, what do you think about the live team coding idea? Tried something like that before?
MNever tried it - but would be up for it.
UThat is why we use AWS EC2 Instance to deploy client's IoT dashboards to handle higher traffic generated by iot devices (to save server from crash). They are very scalable. I'm not suggesting the use of EC2 for this case but just saying that the similarity between device-to-server and client-to-server communication!
BHey guys 4 years experienced Embedded Developer here 
Experienced in Hardware + firmware design complete projects.
Any project idea suggestions to get into Embedded AI space ? (Training myself to fetch big bucks 1-2 years down the lane). Please suggest
Experienced in Hardware + firmware design complete projects.
Any project idea suggestions to get into Embedded AI space ? (Training myself to fetch big bucks 1-2 years down the lane). Please suggest
THey Bruce, are you familiar with TinyML?
ZOh wow I have something to teach you then 
EHi tinyML would be a good place to start . Also, if you are looking at speech to text or something related to audio in AI, you can try Picovoice. For the two options, they have specific devices supported. I did a project using Portenta H7 on controlling things via voice commands.
E
Project: Control LED using voice commands(FULLY OFFLINE AND ON EDGE)
Board: Portenta H7
Steps:-
1: A…
BYes have been trying to research about moving into this space online. Overwhelming information available regarding entering the ML / AI space. 
BThank you, will check this out right away.
T@Renuel Roberts any tips for Bruce to get started?
RHello @bruce_wayne are u familiar with python
BYes absolutely. All my career I’ve been scripting using Python and sending commands over Serial or Ethernet to automate testing.
RAhv u worked with any AI related libraries like decision trees, Tensorflow lite and pandas/ numpy or matplotlib for mL
RIf you haven't, start by Data manipulation using pandas and NumPy, understanding algorithms, and working with libraries like Scikit-learn, TensorFlow, and PyTorch.
U can start by creating basic AI chat not till u understand the logic flow to move into complex projects
U can start by creating basic AI chat not till u understand the logic flow to move into complex projects
K@techielew I was just reading the scroll back, this is quite interesting, it also sounds almost identical to a hardware in the loop ci setup with the key differences being we push from users instead of source control (I guess it would be encumbering for users to push git to flash the hardware?) And that users want to poke/shoogle/look at the hardware instead of automated tests.
I'd be interested to discuss further / help with this.
My gut feeling re the aws thing is I'm on the side of the $5 linode - I'm generally of the opinion that if the part talking to hardware needs to scale for users the architecture was built wrong - we usually run these things on something in the raspberry pi territory
P.s. - if you do use a PI, you get the gpios/busses so it's easy to hang off a couple of i2c/spi devices to stimulate various parts of the system, the linode would basically serve some rpc interface which should be very light and the "fancy web stuff" can be done client side - the linode is more there so that you arent exposing a pi in your house to the nasty world
I'd be interested to discuss further / help with this.
My gut feeling re the aws thing is I'm on the side of the $5 linode - I'm generally of the opinion that if the part talking to hardware needs to scale for users the architecture was built wrong - we usually run these things on something in the raspberry pi territory
P.s. - if you do use a PI, you get the gpios/busses so it's easy to hang off a couple of i2c/spi devices to stimulate various parts of the system, the linode would basically serve some rpc interface which should be very light and the "fancy web stuff" can be done client side - the linode is more there so that you arent exposing a pi in your house to the nasty world
Zyou need to teach me so many things please 
Zwow I didnt know v2x was a thing already, this is really amazing.
KIn essence - look at hardware in the loop testing
Consider that a lot of the setup is identical
You could actually drive a system like this from git, people drop a link into some things, when it's their turn the system picks up the code flashes it and runs it.
The difficult part here is if you want people to be able to interact with the target in realtime - now just throwing jobs at it doesnt work, it becomes more like booking an appointment.
We were talking about building something like this on another server for an embedded advent of code, we hashed out some ideas but didnt have the time to commit and make it happen
Consider that a lot of the setup is identical
You could actually drive a system like this from git, people drop a link into some things, when it's their turn the system picks up the code flashes it and runs it.
The difficult part here is if you want people to be able to interact with the target in realtime - now just throwing jobs at it doesnt work, it becomes more like booking an appointment.
We were talking about building something like this on another server for an embedded advent of code, we hashed out some ideas but didnt have the time to commit and make it happen
Zlet me read up a bit, keen for this December maybe on this server let me see what resources I can gather, I'll come back with questions
Rwhen working with Zephyr OS for embedded systems, what do you find most beneficial?
@Dtynin @Boss lady @melta101
I noticed you guys have work on some projects using zephyr can you please share some of your insights
@Dtynin @Boss lady @melta101
I noticed you guys have work on some projects using zephyr can you please share some of your insights
KNot tagged but the HAL and the use of device trees gives more hardware abstraction than other options. The closest thing in terms of completeness is the arduino hal
The general quality of the drivers is also good enough that you don't have to hack it up all the time
The general quality of the drivers is also good enough that you don't have to hack it up all the time
RThat's a great point, Zephyr’s HAL and device tree really do provide that extra level of hardware abstraction, which can simplify development significantly. How would you compare working with Zephyr’s device tree to other approaches you've used in the past? Do you find it as intuitive, or are there challenges you’ve had to overcome to fully leverage its potential?
TYeah looking at it like scheduled HIL testing is a good point. There's a way to do this that could be much less expensive (ie, linode) and not reinventing the wheel if we're willing to do round robin 'appointment' scheduling. It's not what was originally envisioned, but perhaps a necessary next step.
We'd certainly welcome the assist, @ke7c2mi. Thanks for the offer. I have a lot going on this upcoming week but hopefully we'll be able to regroup next weekend.
Also, I'm open to any ideas from anyone that would provide an alternative to the "scheduling/appointment" phenomenon, which would be annoying.
We'd certainly welcome the assist, @ke7c2mi. Thanks for the offer. I have a lot going on this upcoming week but hopefully we'll be able to regroup next weekend.
Also, I'm open to any ideas from anyone that would provide an alternative to the "scheduling/appointment" phenomenon, which would be annoying.
TMaybe it's an extension of the AMA we just did with Ming. You have to submit your question and code ahead of time and then we'll select ones that are of the broadest interest and let that user 'drive' under guidance of the instructor/expert.
KI don't think it's particularly intuitive and I think it's quite a steep learning curve coming from bare metal / reading datasheets and poking memory. It has felt cumbersome for me compared to things like freertos/rtic/baremetal.
Device trees themselves are neat, and I think pretty intuitive. It's just some descriptive templatey IDL. On the other hand they map to your entire system in an abstract way so actually doing things with them can be complicated - the device tree itself isn't the problem there though!
Device trees themselves are neat, and I think pretty intuitive. It's just some descriptive templatey IDL. On the other hand they map to your entire system in an abstract way so actually doing things with them can be complicated - the device tree itself isn't the problem there though!
CHey Guys Cherry here, just joined the group. Excited to be here. Little intro about myself. I am a recent grad with over an year experience as an Embedded Software Developer.
BThanks for the suggestion. @Edison_ngunjiri also suggested a tinyML project that involves hardware and code that runs on a microcontroller. Am I correct to assume that it would be the first thing I need to understand as the step towards AI/ML in Embedded Systems?
Zfelt the same to me it was odd
ZWelcome Cherry, let us know what you are working and any way we can assist.
