search

AllYarnsAreBeautiful / ayab-hardware

Contains the schematics and layouts for the AYAB Arduino shield
Creative Commons Attribution Share Alike 4.0 International
33 stars 15 forks source link

ESP32 hardware #21

Closed VIPQualityPost closed 1 year ago

VIPQualityPost commented 1 year ago

we should bring this into upstream so that others can start contributing on the new hardware

dl1com commented 1 year ago

Hmm... I wonder if we could use this for the project? But it seems it might require a separate repo? https://github.com/neilenns/KiBot-CICD-Template

//edit: OK, it only requires a separe repo in case we want to use the GH template. But we can just cherry pick the files and config we want to have in our CI

VIPQualityPost commented 1 year ago

You're right, I didn't notice, my wildcards were too aggressive. I moved the KiCad gitignore template into the ayab-esp32 directory to limit the scope. I also added a top-level gitignore which at least will keep out my macOS .DS_Store junk.

I've added a readme to both the main repo and the new KiCad design.

I agree it would be nice to only include symbols and footprints not from the default library, but it doesn't appear that KiCad can do this (export is all symbols and fp), so it would need to be manual. I don't think it's worth the effort and if nothing else, it guarantees the project will always open even if KiCad changes things upstream for the default symbols/footprints (although I doubt that is likely to ever happen). I think we can just keep the exported libraries that include the default symbols/fp.

I'm not sure the best practices, I always keep global libraries so I don't have a lot of experience with trying to produce a 'complete package' KiCad project. There is the temp / cache file like you mention, but that seems a little bit like a hack to rely on that for carrying the data instead of a standalone library, unless I misunderstand how it works.

t0mpr1c3 commented 1 year ago

IMO it doesn't really hurt to export all the symbols.

dl1com commented 1 year ago

How do we want to proceed from here? Shall we merge it, so we have a common starting point and do further work in form of PRs?

VIPQualityPost commented 1 year ago

I think @jpcornil-git seems happy with most of the decisions... thanks to much of their input! I would like us to confirm how we are feeling about the user UART, SPI bus and protection on the user buses. Otherwise, I'm happy to merge this and start on digging into component values, choosing parts, footprints, etc.

VIPQualityPost commented 1 year ago

OK, I think we are good to merge this and start on design finalization/ component selection!