Sometime back, we announced start of a new project under the “Developed on Hackaday” series – a Badge for the Hackaday community. At its core, this badge is a single node in an Internet of Badges. At every event this badge is deployed at, a Hackaday Sub-Etha mesh network will be created, and each badge will be able to transmit and receive messages from other badge wearers. There are plans for an Sub-Etha to Internet gateway, so even if badge wearers are on the other side of the world, they’re still connected through the HaDge network.
Things have been moving along quickly, so I thought of doing a quick round-up and share progress with the community. First off, it has a name. HaDge, as in HackaDay Badge. Our objectives up until now were to set up a team, name the project, set up repositories and lock down on a working bill of materials. Within a few weeks, we’ve got all of that tied down. The HaDge group chat channel has been super active, and everyone’s been pitching in with ideas and suggestions. A spreadsheet seemed like a good idea – it let everyone add in their suggestions regarding candidate parts, create a feature list and then talk about it on the channel.
We realized early on that building the hardware is going to take some time. So in the interim, we need a dev kit platform to get in to the hands of the software developers so they can start working on the smarts that will power the HaDge. [Michele Perla] had already built JACK (Just another Cortex kit) – a development kit powered by the Atmel SAM D21. It’s pretty bare bone with just the bare minimum of parts to make it work while keeping an eye on reliability. The microcontroller+radio on the HaDge is the Atmel SAM R21 – a close relative of the D21, so it made sense to respin the JACK and create HACK (Hackaday Cortex kit) – a development kit powered by the Atmel SAM R21 that is going to be used as the core of the HaDge. [Michele] has worked hard single-handedly to complete the design and it is now ready to go for PCB fabrication soon. We are just awaiting some feedback and review of the Antenna part of the design. None of us on the hardware team have a strong RF-fu so we don’t want to make an avoidable mistake. If you’d like to review and help vet the HACK design, grab the design files from the github repo and let us know.
Once HACK board layout is cleared for fabrication, we’ll work on building kits that can be sent out to the software folks. We will also be working on porting the HACK design in to KiCad and this is something I have already stared work on. I started by using the neat Eagle2KiCad conversion tool by [LachlanA]. It’s not perfect, but it does reduce the work involved in porting over from Eagle to Kicad. Once that is done, hardware development for the actual HaDge will see some progress – keep a watch on the project page.
The “HACK (Hackaday Cortex kit)” link is broken.
Thanks for spotting. Fixed.
I want one.
+1 totally want one.
I.e a HaDge
There are no good reasons to stick to Atmel Cortex parts other than sponsor ads. They are usually not the cheapest ones nor the most popular ones (vs STM32F). Even if you want Arduino library/platform support, be aware that it has been ported to STM32F and limited Kinetis devices.
I haven’t got anything to do with this project, but speaking generally, I will say that I have quite a bit of brand loyalty to Atmel. That’s partly because of familiarity – AVRs have been my go-to controller since the beginning. I did start with Arduino, yes, but I now mostly develop standalone with CrossPack’s AVR GCC toolchain. Pragmatic familiarity keeps me coming back. If you wish to be less than charitable, you can feel free to call it laziness.
Another reason why I keep going back to Atmel is that they’re a big Open Hardware / Maker community supporter. Or, at the very least, their propaganda along those lines is quite compelling.
Now, AVR isn’t ARM, so maybe the above has nothing to do with any of it. But so far AVR has been the hammer for all of my nails.
For what I know Atmel Cortex are the only one to offer internal HS USB (I mean internal phy too, not some HS interface for an external phy).
A casual google search shows:
LPC1800 >Two High-speed USB 2.0 interfaces – On-chip High-speed PHY”
STM32F439, STM32F756NG, STM32F217VE >device/host/OTG controller with on-chip PHY; USB 2.0 high-speed/full-speed
Kinetis K66: >Integration of a High Speed USB Physical Transceiver
Seriously, do you need beyond full speed on a badge? Are there lots of people who code USB interface beyond serial ones in the hobbyists/”makers” community?
BTW I do code in USB using custom vendor commands…
A casual STM32 page read gives (for the 3 references):
“USB 2.0 high-speed/full-speed device/host/OTG controller with dedicated DMA, on-chip full-speed PHY and ULPI”
So STM32 out.
For what I remember LPC with those integrated phy exist only in “hard” package (0.8mm bga) and are hard to source at retailer.
Anyway I agree no need for HS usb here.
The venerable LPC4337 comes in LQFP 144.
FYI:
Mouser has LPC1837JBD144E (TQFP144), LPC1857JBD208E (LQFP-208) in stock. One High-speed USB 2.0 Host/Device/OTG interface with DMA support and
on-chip high-speed PHY (USB0).
They also have MK66FX1M0VLQ18 (LQFP 144)
USB high-/full-/low-speed On-the-Go with on-chip high speed transceiver
I do program custom USB peripherals and one of my projects would very well benefit from a High Speed interface on a microcontroller. Anyway, for the HaDge we wouldn’t need anything more than Full Speed, that’s true.
So all this has been going on, while the Hackaday.io page for the HaDge has been collecting dust?