Happy 10th Anniversary year, me!

On 12th January, 2014, I registered the domain – theembeddedkitchen.net. February 6th (2014) was when I published the first article on this website and opened the gates of The Embedded Kitchen to the whole world. I imagined myself as a chef baking circuit boards in a reflow oven and serving it fresh to the world, although tbh I would not be able to serve as I would have ideally wanted to serve :), but, a good thing is that I have also learnt over the years is to also cook food for humans too in a real kitchen, not just electronics in my embedded kitchen.

3 years have gone by since I published my last post and had changed companies and fields (I went on to work for Google, and have now completed 3 years in my role, learnt a lot but didn’t have time, nor the authorization to share specifics). I felt an update was overdue on the website, and how it will evolve in the years to come. So here we go.

A supplementary website – kumarabhishek.me

Rather than expanding The Embedded Kitchen to add other aspects of my personal life, I will be dedicating this site exclusively to my engineering, and especially electronics pursuits leaving the other bits at my personal website – which I would like to introduce readers to today – please say hi to kumarabhishek.me!

Although technology is what defines me professionally, if you want to know the person behind all this and see beyond the tech side of yours truly, you are more than welcome to visit, browse along the articles and also consider subscribing via email to receive new posts as they are published (I run it on a Ghost instance).

Viewership

My website has seen modest viewership, and has not had too much attention so far. While everyone has the hope that their website or articles will go viral one day – the best I’ve gotten is some traffic from Hackaday when my articles on BeagleLogic got featured. In hindsight, having a small niche corner of the internet is good for less noise [and good Signal-to-Noise ratio], but I suppose – maybe the signal itself from this website isn’t too strong either but it’s okay so far as I don’t have to deal with things that distract me from official or personal work. Should this change in the future, I will revisit this.

Redesign / rehosting

“If it ain’t broken, don’t fix it.”

It’s interesting that the website has used only one theme since it was inaugurated. And I still like the theme today and do not want to mess with it. While WordPress itself updates, and so does this theme’s visual effects from time to time – the vibe has remained the same regardless. And I do not want it to change unless there is a very strong force to do so.

The website was hosted on shared hosting for a while, then shifted to RedHat OpenShift Platform-as-a-service when it had a very generous free quota (so I paid for the domain registration only, not the servers that ran the site). It came to an end some years later and I chose the least resistance path of moving this site as-is to a LAMP (PHP/MySQL) shared hosting solution. This is still cheaper than a monthly VPS today, so it’s fine for the traffic I receive as the goal is to just keep the lights on in here. Whether I have to crank up the lights up to floodlights in the future is something to be seen.

I did consider moving this to a static site somewhere in between but decided against it primarily due to the inertia / friction / link-breakage and unable to find a suitable replacement theme. If in the future the need comes to do so, I will consider it but for now I will just keep it as-is, not to break what’s already working.

What happened to BeagleLogic?

I feel this is a question that needs to be addressed as a lot of people [O(100s)] have filled up the interest form but I never got back to them over the past 6 years. I feel bad about it, about what BeagleLogic could have become had I nurtured and given it much more attention than I did. On my software engineering job today, I have learnt how important it is to have SLOs defined for issue responses, documentation, unit/integration testing and design patterns but I suppose I would have learnt these things anyway had I given enough attention to BeagleLogic and given it the proper hardware and software product engineering treatment, over time. You should not need to join a company to learn these things (yes, it does help to learn to label the phenomena and the terms of the profession) but it would have come as a natural part of the process. Part of it was also my unfortunate sadness that BeagleLogic if manufactured in low volumes would be too expensive for the raw performance it has (in getting the data out of the PRUs via USB/Ethernet – it would never achieve Gigabit throughput even if it got that 1Gbps PHY) that I wouldn’t buy it myself ($100) – but I’d have wanted to reach the $50 price point [today I know better and also that AliExpress prices are unsustainable unless you actually flood the market with generic stuff under different sellers], but I never gave my potential customers the chance to prove their need for BeagleLogic (and give me the confidence to take things forward) with their money by letting them back a group order – I apologize to have let you down. BeagleLogic also hasn’t had a proper community built around the codebase that would have made it self-sustaining, maybe these things will improve over time.

Last November, I gave a talk at the Hackaday Superconference on my attempt to recreate a BeagleLogic-like experience on a Raspberry Pi platform which, as of today, the Pi 4 can easily hit 1Gbps and saturate a USB3.0 SSD. I had thought that adding a Raspberry Pi Pico can replicate the PRU experience on the Pi, but it turned out to be pretty convoluted. I hope it works out.

I do have ideas for a spiritual successor to BeagleLogic. It’s called Meghaduta, literally meaning “messenger of the clouds” in Sanskrit. It is named after Kālidāsa’s lyric poem Meghadūta, and is intended to be a vendor-agnostic specification for accessing instrumentation data over RPCs as an online-first protocol, not compromising on performance. You will hear more on it in the days to come. BeagleLogic will become one of the boards that runs on the Meghaduta stack.

Also, the BeagleBoard.org community is going to be blessed with more boards, and I will be looking forward to get BeagleLogic to work with them and bring more discipline to the BeagleLogic project by establishing CI pipelines, Debian packages and all the good things.

More articles?

Content is the craze today. Everyone wants to be/is a content creator today. I’ve personally been more of a content consumer than a creator myself over the years, scrolling through X/Twitter, watching YouTube and other social media feeds. Maybe you’ll find yourself here after scrolling through a similar feed – and if you made it this far, thank you!

This year, I hope that I can give back more quality content than I consume. Either by reducing my content consumption, or creating more content, or both, or increasing both in some ratio, but still creating more content than content consumed.

My home country India is seeing more and more interest growing in the hardware sector, from manufacturing to semiconductor design. Yet we have a whole generation of engineers who may be (now over-[?])exposed to mass-scale DSA content, how to of product-based companies, coding, interview processes, web and app development using JavaScript and other frameworks but may not be aware of the variety, options and depth available to them in hardware. Be it analog/digital/mixed-signal chip design, antenna/RF design, circuit boards, protocol engineering – there is so much available to learn and think about and I believe simply opening one’s eyes to the possibilities are going to ignite the collective imagination a lot of young minds and make India a quality hardware hub. This is the direction I personally want to take The Embedded Kitchen now – an apprenticeship where you can come and learn to create electronics.

Summary

Thank you for sticking around and reading this! Do check out my alter ego site – kumarabhishek.me and consider subscribing there if you find something interesting. I hope that this corner of the internet continues to offer little and useful things. I feel lighter after having finally given a public reply of why I held back on BeagleLogic and I hope, that this hope is not like the previous hopes where I started working but gave up soon after. And finally, I feel like I am in a position to give back by encouraging a generation of future hardware engineers, and hopefully The Embedded Kitchen gets a role to play in this.

State of the Embedded Kitchen in 2020

I started this website, “The Embedded Kitchen” back in 2014 as a platform to share what I make with the world. The thought behind naming the website so was comparing my process of building hardware with that of cooking food because of course boards are baked as a part of the manufacturing process and it appeared no different to me than baking bread, for example. And thinking of myself as a chef bringing my creations to life in my mini-laboratory of hardware equipment, it sounded like a really good idea to register the domain name and start writing. A lot has happened in the 6 years since, and this post is a reflection on how things have been.

Firstly, this website has allowed me and my work to be discovered over the years, nothing viral as such but serving a niche who happen to stumble upon my work when looking for something very specific on the internet, as Google’s Search console tells me when I go and review what leads users to my website, and at the time of writing this post it’s mostly always BeagleLogic (if you’re wondering how it is currently, I could write a full blog post on how I missed so many opportunities for it to gain traction). Of course I have worked on many personal projects here and there since then, but I feel nothing so far has came close to the scale of the creative work I did for BeagleLogic in 2014, and then a second wave in 2017 for its standalone version. All the work done in few focused 100m-dashes with no long-term horizon, and yet it’s what probably brings you here. Wow.

I graduated and moved to a full time job in 2017 and since then it has been almost radio silence over the years on “The Embedded Kitchen”, with an occasional post, and a 100-day experiment which I couldn’t complete as planned. That didn’t stop me from flourishing at my day job; I was still building and debugging boards, I was still writing code but it was all for the company I worked with. I suppose it’s the cost of having your day job overlap with the things you once loved and performed as a hobby.

I wasn’t working at my Embedded Kitchen as I was busy cooking in another kitchen and at the end of the day I wanted to have a wholesome meal for myself and 8 hours of sleep.

Fast forward to 2020, while this hasn’t been the best year so far for the world, staying indoors for several months has helped me gain personal perspective, reprioritize and reorganize. If you look at my LinkedIn today, you will see that I now have a new day job as a Software Engineer at Google – as exciting this new position is, it also entails a whole new set of responsibilities which means that I will have a lot less time to spend here. It’s interesting to note that the recruiter who reached out to me about the opportunity found me through my body of work on this website, which makes me all the more grateful.

I also now have a personal website, a new web property called kumarabhishek.me which will be the home to new content that has a more personal touch, which is not just about hardware creation but what I choose to show to the world about myself.

Going forward, The Embedded Kitchen is going to be my sacred space, a space for me to look up to and look back on as an archive of the place I begun my journey, as a collection of my previous writings to come back to so that I am reminded of humble beginnings. Please know that while I no longer cook in this kitchen on a daily basis, I make sure it’s maintained and whenever I choose to cook here, know that I’ll be cooking with the utmost reverence and serving you my finest.

Thank you so much for stopping by The Embedded Kitchen. Should you choose to follow me along on kumarabhishek.me, I’ll see you there.

Announcing: BeagleLogic Standalone

Today, I’m delighted to announce something that I’ve been working on the past four months, which is now alive and doing exactly what it was meant for. A Standalone, turnkey logic analyzer based on the work I did for BeagleLogic. And is aptly titled – BeagleLogic Standalone.beaglelogic-standalone-top

BeagleLogic Standalone is a specialized version of the BeagleBone which is intended to be used a logic analyzer based on BeagleLogic.

Describing it as an equation, (BeagleLogic Standalone) > (BeagleBone) + (BeagleLogic). The greater than comes from the fact that the BeagleBone + BeagleLogic has up to 14 logic inputs, BeagleLogic Standalone has 16. It has 1000Mbps Ethernet, while the BeagleBone has just 100Mbps.

This logic analyzer has networking capabilities (10/100/1000Mbps Ethernet); it can be used to used to debug circuits remotely. And as it is a full-featured Linux computer, you can run the sigrok set of tools directly on the BeagleLogic Standalone board (they come preinstalled in the BeagleLogic system image), or on your host PC. It has 16 channels and can sample up to 1.5 seconds of data at the maximum sample rate, which is 100MSamples/sec (3 seconds of data if using only the first 8 channels).

If you are interested in purchasing one of these boards, please fill up this form, and I’ll keep you informed.

The rest of this post is dedicated to describing the story behind the creation of BeagleLogic Standalone.

Read more

The Printed Circuit Name Card

The events described in this article take place in July, when I spent some of the best days of my life so far as a summer intern based at Mountain View, CA.

My internship was coming to a close. I wanted to have a namecard to give out to the new connections I made while I was there – and with a little more than two weeks to go then before winding up, I had to make it fast. Having seen a lot of interesting projects that make business/name cards out of printed circuit boards, I decided to do my take on the concept and create a printed circuit namecard for myself. This article describes the thoughts behind the design and what I learned in the process. It was fun nonetheless. Before continuing over to the rest of the article, here’s what the finished card looks like:

namecard1

The dream phase

“My card would have a small multi-colored LED that would glow whenever someone would hold it in their hands. It would contain my contact information as a QR code and on the back would be whitespace where I can leave someone a handwritten note”.

Which color would it be? The soldermask colors of choice were – OSHPark purple, blue, black and white. Had recently seen a board with a matte black soldermask and liked the feel of it so I was interested in trying it out too.

The card designs I had seen placed all the text on the silkscreen, but maybe putting some part of the text as exposed copper would add more contrast? The effect would look more dramatic when the board gets gold plated (ENIG) vs the usual solder finish (HASL), also the boards would cost more as a result.

The Mock-up

Business card size is 3.5″x2″ ( 89x51mm ). Mine’s 89x50mm to fit a 10cmx5cm bounding box for standard fabrication size.

Mock-up of the card was done in Inkscape. I generated a QR code for myself as a SVG file from here

The QR code is in vCard format, so scanning it reveals my contact details which can be straightaway saved on your phone. Also it was at this point that the fonts and font sizes were frozen. Once it looked good to me, I exported different sections of the file in PNG format, which I would later convert to footprint using KiCAD’s handy utility and position in the board layout as any other component.

The Electronics

For choosing the right microcontroller, there were four requirements – low power, 3 PWM channels, touch sensing and low price. Wanted to use the AVRs initially for ease of use, familiarity (the Arduino framework) but they were roughly around a dollar or more on DigiKey/Mouser. The PICs seemed to fit the bill though in just about half a dollar – selected the PIC12LF1572 microcontroller – that sounded good enough. Also, my first time using a PIC microcontroller – a new platform to learn!

The battery? CR2032s are pretty standard, and also have the highest possible mAh. The next smaller one with a comparable mAh was the CR1632. I decided to go with the CR1632, though next time I might consider a CR1220.

I needed a PIC programmer, found a project on Hackaday.io which meant I could repurpose one of my Arduino boards to do the programming – this project actually gave me faith that I could somehow program the PICs while still being on a tight deadline (thanks to hackaday.io user jaromir.sukuba for maintaining this!) and I decided to give it a shot.

namecard-sch

Submitted a Mouser order for all the parts and it all arrived in 3-4 days. The BOM cost was ~$60 for enough to build 40 of these.

The Board Layout

As this was a relatively low complexity design, it was completed in a few hours on an extended night shift.

The key detail here was my name – unlike the other text I put it on the copper layer so that it would get gold plated . To ensure that the soldermask opened up around it, I added a 0.2mm “stroke” around the vector graphic corresponding to my name in Inkscape and put it on the F.Mask layer so that the text is exposed through the mask and would eventually get gold plated. Here you can see what I mean [red = top copper, magenta = top soldermask, green = bottom copper]:

vcard-soldermask-opening

Here’s a shot of the completed layout:

pcbsnapshot

Board Fab

I used Elecrow for this order – they offered matte black soldermask option without a custom quote. I had used them once before and have been satisfied with the quality. One more good thing about them is that they don’t add production codes on the silkscreen of your boards [which can be so annoying on a board design like this] and also send you a picture of the finished board before they dispatch your order [which makes you even more excited to receive the boards once you’ve seen them made as you wanted them to be]. The quality was excellent. From silkscreen to plating and all the vias were properly covered.

I had selected DHL Shenzhen as the shipping method which is supposed to be faster than DHL Hong Kong, the price difference being roughly $5. For a total of 40 boards with matte black soldermask and ENIG finish, paid $100 total. Order was submitted on a Wednesday and the boards were delivered next Wednesday. The boards looked beautiful, just as I had designed them to be 🙂 .

Assembly

There aren’t a lot of components here, this should have been pretty standard stuff but I had lead-free solder paste and that was a big pain to work with a toothpick, without a stencil. I should have probably ordered one along with my boards. And the last week internship rush meant that I couldn’t have enough time – had to choose between doing the firmware or building all 40 on a night stretch – I got a few assembled and that was it.

Firmware

This was the the first time I was using a PIC microcontroller. Moving to a new microcontroller has its own surprises – it took me an hour to realize that the PWM generator won’t update its duty cycle automatically on changing contents in the duty cycle register and a bit has to be set in another register. The MPLAB IDE was mostly okay-ish, although I’d try and see if I can get it working with the SDCC compiler for future firmware revisions.

The MPLAB code configurator provided an easy way to implement the touch sensing functionality here as it had an mTouch library implementation and I was able to get it working just in time. [jaromir]’s PIC programming software worked well and I was able to quickly iterate and build v0.1 .

The chip being a LF series has pretty low standby current but there wasn’t enough time to bake that functionality in. I chose to run the MCU at a lower clock frequency instead (500kHz) to get active currents of the order of 0.3mA. Battery life is two weeks after which the LED dims out.

Here’s a close-up of the finished result. The 5 pins are for programming. A 2mm berg strip is manually held to the headers to program.
namecard

Future

I was very satisfied with the finished result. Matte black with a gold finish looks beautiful and to me, was worth it. Also there was excellent service from Elecrow which I would whole-heartedly recommend based on my experience with them. [jaromir]’s PIC programmer allowed me to use one of my Arduino boards to program the PICs, it helped me a lot during this project. Thanks a lot!

With a working v0.1, I was able to build a few and give away. I’ve given away some blank boards too, they look pretty in their own right.

I want to rework the firmware, most likely with SDCC and add some more fade effects on the tri-color LED. And also implement proper low power support (likely by using a WDT to sleep every second and wake up and check for a touch). In the next PCB rev, I would:

  • Make the boards 0.8mm thick. Or even 0.6mm.
  • Make the QR code larger for better readability and push it to the back side of the PCB – it’s currently all white silkscreen
  • Add a little more clearance between the touch sensor pad and the ground plane all around it. It probably decreases the touch sensitivity a bit.
  • Use a slot in the board and add a split battery holder leading to a lower Z-height.
  • Make a pogo pin set and a 3D printed jig to hold the programming header in place. It’s awkward to hold and press the headers everytime something needs to be flashed.

I’m not posting the board design files yet. However I might post the firmware after adding more effects.

That’s all for this one. If we ever meet in person, ask me to show you and I might even give you one of these.

Here’s an animated GIF:

via GIPHY

A day with Hackaday

The year 2015 saw my project BeagleLogic as a Best Product finalist in the 2015 Hackaday Prize, and my other project Smarter Power Pack  as a semifinalist in the main event. I also got to attend the Google Summer of Code Mentor Summit at Sunnyvale, CA (thanks to BeagleBoard.org) in November 2015 where I met many interesting people and had a great time.

Just the next weekend was Hackaday’s first hardware conference – the Hackaday SuperConference – which would later go on to be a grand success. I however knew that I couldn’t stretch my 8000-mile trip to the weekend because my university end-term examinations began next week and I had to leave on the Thursday before, the 12th of November. I let Sophi (of Hackaday) know and they invited me for lunch with them Thursday afternoon at the Supplyframe office at San Francisco.

Thursday morning, I boarded the Caltrain to San Francisco, and then roughly a 10-minute walk from the station to the office. This is how my entry was announced at the “Hackaday SuperConference” group chat channel at Hackaday.io :

supercon-chat-screensnip

The office at that time was packed and brimming with activity as the entire Hackaday crew had gathered and working together towards the Superconference. I sat on a table beside [Aleksandar Bradic] (CTO, Supplyframe) and [Chris Gammell] (of AmpHour podcasts and Contextual Electronics). Behind me were [Rich] and [Sophi] working on a video-shoot for the Hackaday Omnibus 2015 release (yes, I saw a part of the shoot that day). Here is a link to the released video on Vimeo.

supplyframe-office-1

Thanks to [Jasmine], I did not miss the SuperCon badge and T-Shirt. As a proofreader for the Hackaday Omnibus 2015, I received my copy as well.

badge

Now there’s an interesting backstory of the badge here that I think I can share with you: As I put on the lanyard onto the badge, they realized that the drill hole for putting the lanyard on the badges was a tight fit and it would be cumbersome to remove and re-attach the badge without scratching the solder mask on top. The solution? A bunch of keyring rings which would then go on between the badge and the lanyard – like here.

I got to play with the new NVIDIA Jetson TX1 for a while, a test unit of which had just arrived at Hackaday ([Brian] would later publish a hands-on with it, which can be read here). I saw [Brian] and [Mike] typing on what would be the posts that would later go on to the Hackaday blog, and also the HaD tip line, in the short time I was there.

Once [Sophi] and [Rich] were done with a round of shooting for the Omnibus video, we proceeded for lunch to a nearby restaurant. The food was great. The lunch time conversations, even more great.

lunch-group-pic

After lunch we walked back to the Supplyframe office and I bid goodbye to the entire team, and boarded my flight back to India later that night. I had got to see the team behind Hackaday up really close, and my respect for them has only grown since. They are doing a great job with their blog, the Hackaday.io community and the SuperConference which I really missed being a part of this year. A big shout out to them, and also to [Sophi] for making an exception while you all were so busy preparing for the SuperCon so that I could get to be there, and interact with you all. Thanks for having me there! Looking forward to meeting you all again.

Wishing all readers a very Happy New Year 2016 from The Embedded Kitchen.

~Abhishek

An Adventure in self-fabricating PCBs

An Embedded Kitchen wouldn’t have been complete without the ability to fabricate circuit boards for rapidly prototyping circuits without waiting on the board house [fail fast, fail often applied to hardware design]. This week, it gained the capability to fabricate boards using the well-known toner transfer method.

I had done toner transfer first when I was at school, the results had been terrible. So terrible that I turned to wire-wrap prototyping for my circuits, even when I started using SMD components later. However the realization that dead-bugging SMD parts is too much effort which doesn’t scale brought me back to PCBs. This time because I couldn’t wait for two weeks to get my boards manufactured so I decided to take on toner transfer again. I knew the steps. Clean the board, print the design, iron it on. After the ironing when I rinsed the board under cold water, I was pleasantly surprised to see near-perfect pattern transfer from paper to board. Then I went on to etch them with ferric chloride.

The first boards to be so fabricated are an early stage prototype of my project Smarter Power Pack which uses spare laptop batteries to realize a better power bank (interested? here’s a link for further reading), and a respin of the LCD connector board for my BeagleBone LCD cape. Here are pics of the boards so fabricated:

IMG_20150904_135429_HDR

IMG_20150904_135451_HDR

IMG_20150904_134059_HDR

After this was done, I threw in an additional step of tinning the whole board to protect it from tarnishing and also patch-up any imperfections in traces. Then placing components and reflowing the boards are usual. Here are the results.

IMG_20150905_233900_HDR

IMG_20150905_204424_HDR

They’re not as pretty as the ones got from the board house, but they’re beautiful in their own way. They’re cheaper in terms of money but more expensive in terms of extra effort (drilling and hole plating). And I don’t need to have 5 or 10 copies of tea coasters if I used a wrong footprint or inverted it. But in the end, it’s all worth it when you can get from an idea to prototype in days and not weeks.

The BeagleLogic cape: Assembly and Testing

A day before Christmas, I was greeted by a yellow DHL packet from Hong Kong. The panels had finally arrived after 8 days – I had chosen rush (48hrs turnaround) and express shipping, and it did work out well as I received them before Christmas. The boards turned out to be nice. Not dirty at all and at a price which was reasonable to me.

Assembly

Ready for assembly
Before assembly – the board with applied solder paste and a few parts

I reflowed the board with a hot air gun. Applied solder paste with a toothpick and placed the parts with the naked eye using a pair of good quality tweezers. The passives are all 0603 size (1.5mm x 0.76mm). Since I was yet to receive the batch of BSS138 FETs I ordered, I used a BC847 NPN transistor for the build instead. Reflowing left a couple of solder bridges on the 74LVCH16T245 (now onwards referred to as ‘the 245’) buffer chip (smallest pitched part on board – 0.5mm) which I removed using a solder wick. Then soldered the pin headers manually.

Cleaned up after soldering using nail polish remover. It’s terribly inefficient, and I plan to get a bottle of concentrated isopropyl alcohol (IPA) at some point of time. Here’s the finished result:

“Smoke Test”

A colloquial reference to the first power-on of the assembled circuit. I plugged the cape into the BeagleBone Black and powered on the assembly. The LEDs lit up and the board booted. No smoke or burning smell. Woohoo, test passed, or …

Errata

I then probed the BeagleBone P8 header pins which serve as inputs to BeagleLogic using an LED, and did the same with the input pin headers. The LED were brighter on the inputs to the ‘245 than the P8 pins, which was contrary to expectations. A quick check on the schematics and turns out that I wired the 245 to translate from rail B to rail A while connecting the inputs to rail A and the Bone pins to rail B. Whoops! However I quickly resolved the problem by lifting pads 1 and 24 (DIR1 and DIR2) off the PCB (which was simple as those were on the ends) and soldered a bit of magnet wire through and to one of the pads of C1 going to +3.3V. Neatly done, and a lesson not to design and send off PCBs to a fab while pulling an all-nighter 😛 .

Testing

Once this was done all was back on track and the circuit worked as expected. The cape as designed did not interfere with the boot-up process due to the action of the transistor pull-down that ensured that the buffer did not drive the P8 pins until SYS_RESETn signal was high.

I tested it with SPI signals upto 24 MHz using the BeagleBoard itself and results are good at a 100Msps sample rate. I could also subject the input pins to 5V freely, without fear that I would burn the board. That’s exactly what the cape is meant for, and I’m happy with the results.

I am planning to give away the surplus boards from the first batch so anyone interested in testing it out can get in touch and depending upon where you are, I may be able to send you one of the surplus unpopulated boards (no parts included) which can be assembled yourself (1 IC, 4 passives, 1 transistor and pin headers). The Cape EEPROM section can be left unpopulated without affecting the functionality.

The design files are now available here. I made some changes to the design after fixing the errata, so the cape version is bumped to 1.1 .

Suggestions and feedback on the cape are welcome. The design is Open Hardware, so you have the freedom to use it and improve it as you like. Let me know if there’s anything that could be added in the cape as there is plenty of board real estate.

Introducing: The BeagleLogic Cape

BeagleLogic Cape - 3D Render

After coding up the BeagleLogic project, I thought that it would be great to have an add-on cape for the project that provides buffering and also makes the inputs of the BeagleBone Black tolerant to TTL logic voltage levels (up to 5.5V) allowing BeagleLogic to debug external projects with ease. Hence introducing the BeagleLogic cape, the 3D render of which you can see above. The design is done in KiCad.

The design source and gerbers will be made available on the BeagleLogic GitHub repository after I physically assemble and verify the design.

Design & Layout

The cape design is simple enough to just have a single layer layout, as you can see in the render above the top layer is entirely a ground plane but for a single trace. Since the top isn’t much populated I added useful information on the top silkscreen including indexing the pin headers on the Bone on both sides.

The logic channels are accessed via 2×14 right angled pin headers. The upper row of headers are the actual logic channels while the bottom row is all GND pins. The pin headers are arranged in a MSB-to-LSB fashion. This means that the rightmost pin when viewed from the top is raw bit 0 of the captured logic samples. Note that sigrok will use the names of the actual Bone pins so bit 0 (Channel 1) is to be identified as P8_45, bit 1 (Ch2) is P8_46 and so on. The numbering is a little non-obvious but it’s because that’s the way the pins are arranged on the BeagleBone GPIO header. But don’t worry as the cape lists the pin ID of each logic channel so you don’t have to look it up in the pin diagrams.

One important point here. Only the first 12 channels can be used by default. To use the last two channels, you must disable eMMC first and solder 0R resistors or bridge the two resistors R8 and R9 on the bottom side to enable them. Otherwise the buffer will drive those two pins and you will damage the eMMC of the board and also void the warranty.

Here’s a shot of the schematic (click to enlarge). This is for reference only with respect to the current board and the released schematic may or may not be the same

Cape Schematic

The active buffer is a TI 74LVCH16T245 or equivalent. The buffer is powered from the VDD_3V3B power rail. The OE pin initially pulled is driven using an arrangment of a BSS138 N-MOSFET whose gate is connected to SYS_RESETn of the Bone. This should ensure that the logic input pins, which are also the system boot pins, are not driven by the buffer until the startup has completed.

This version of the design has a 0R resistor through which the VDD_3V3B powers the VDDA side rail of the 16245. If you remove the short and connect it to a 1.8V supply it should become compatible with 1.8V logic levels. I am however thinking of a better solution to the problem and should address this in the next released design.

There’s the officially required cape EEPROM on the bottom side as well, I presume this could be rendered redundant as the community moves towards the Universal Cape concept. But the footprints are there, just in case.

Manufacturing

The first prototype cape has been manufactured by DirtyPCBs.com as a 2-layer Black 10x10cm protopack. It has been shipped as of the time of writing and should reach me next week. I ordered the boards as a Rush order (48h turnaround time) and got it shipped via DHL so that I could have the boards in hand before Christmas rush. I would be using their services further if the boards work out well, looking forward to receive them!

Since I had left space on the panel, and there’s free panelizing so I managed to squeeze some more of my designs into the panel and make the best use of the available real estate. I would write more about those in the coming posts.

So that’s pretty much it. Design suggestions are welcome, and I’ll see if they can be accomodated in the subsequent hardware revisions. Once I test and it all works, the design files will be made available as I have written above.

Re-furnishing

I just refurnished The Embedded Kitchen, both on the outside as well on the inside, or I should say, on the front-end and hosting levels; it is still powered by WordPress. I was contemplating moving the site to static pages using Jekyll or Nikola, but WordPress (with Jetpack) now also supports Markdown-based content authoring so the biggest reason for migration to a static system is no longer there so this decision may be deferred indefinitely.

The site is now powered by OpenShift by RedHat PaaS (hover over the word for the definition).

Phase 1 – I just want a Sandbox

I had come across OpenShift some time before and (almost immediately) signed up for the free tier of the service – which gives me 3 “gears” to experiment with whatever I like – PHP, Node.JS, MySQL, MongoDB … . Since I had been contemplating installing a new theme on the website and didn’t want to fiddle with the old site too much so I exported all my data in the WordPress XML format, and created a test site on OpenShift and used it as a sandbox to try out various themes. I settled on Nirvana first (too many choices, I was overwhelmed) and then stumbled across the Freelancer child theme based on the GeneratePress theme framework and liked it more. So that’s the current theme on the website.

After checking my site with PingDom I thought it might be a good idea to migrate the site to OpenShift.

And so wp-embeddedkitchen.rhcloud.com was born.

Phase 2 – blog.theembdeddedkitchen.net

I decided to give the OpenShift version of my blog a proper subdomain blog.theembdeddedkitchen.net (does not exist as of now). This was simple, just one CNAME record to add to my DNS Zone settings, and tell OpenShift and WordPress (admin panel) about it, and boom. Checkpoint 2 crossed.

Now the acid test – getting theeembeddedkitchen.net to point to my blog. I had read enough about CNAME at the root DNS level (since the IP address of RedHat’s service could change without notice, so I cannot just use an A record of the current IP) to be wary of this.

In my excitement, I updated my new blog address in the WordPress admin panel from blog.theembeddedkitchen.net to theembeddedkitchen.net at the point where the DNS hadn’t moved. Yikes! The transition is going to happen faster than it should have.

I added a “Moving” sticky post to the old blog just in case someone might view the site in the transition phase.

Phase 3 – Enter CloudFlare

Of all the alternatives out there, CloudFlare (at least) looked to me the safest. As a side effect, its CDN infrastructure should accelerate my website and help Akismet further in deterring spammers (In over 7 months I guess I had tens and thousands of spam comments)

Configuring CloudFlare was as easy as advertised, just a quick DNS Server change and I was on board CloudFlare. I then added CNAME records and configured OpenShift to catch theembeddedkitchen.net and www.theembeddedkitchen.net for my application. I waited for the DNS changes to take effect and opened theembeddedkitchen.net . All looks well, I think I could call it a day now.

But when I opened www.theembeddedkitchen.net , the site just hung up and I get – “too many redirects”. Wait. A redirect loop! Ok, no problem – I changed my blog URL in WordPress to www.theembeddedkitchen.net and it seems that the problem is fixed. Then I open http://theembeddedkitchen.net and get the same redirect loop. It seemed like a cat-and-mouse game.

However on more digging I figured out that the missing piece of the Jigsaw puzzle to set up a redirect rule on CloudFlare to give a HTTP 301 redirect from http://www.theembeddedkitchen.net/* to http://theembeddedkitchen.net/$1. So if you are stuck in a redirect loop and using both OpenShift and CloudFlare, here’s what you have to do (assuming your-domain.com):

  • In the DNS Control panel in CloudFlare settings, add a CNAME for your-domain.com to your destination (theembeddedkitchen.net => wp-embeddedkitchen.rhcloud.com).
    If you do this correctly, CloudFlare will tell you that “CNAME Flattening will be applied to this record”.
  • Add CNAME www and point it to your-domain.com (theembeddedkitchen.net)
  • Goto the Rules section and set up a redirect rule [HTTP 301] from http://www.your-domain.com/* to http://your-domain.com/$1). This is important to curtail that nasty redirect loop, so that the WordPress installation gets requests only for the non-www domain [Needless to say, the blog address in WordPress should be http://your-domain.com] and CloudFlare takes care of that even before OpenShift kicks in.

All this done the site was back online to its full glory. Now just a few finishing touches…

Phase 4 – Plugins

I installed the Jetpack plugin first so that I could get all the goodies and a site check every 24 hours which ensures that the site never “idles” (apps in the free tier are put into standby if it doesn’t receive an HTTP request in 24 hours).

Also I decided to put a Disqus comment system in place of the old comment form. This was as simple as setting up my Disqus account and installing the Disqus comments plugin.

There’s also WP Super cache that makes this (almost) a static site. Not sure if N levels of caching are going to help anyway but I think it might speed up things a bit.

I am thankful to the shared PHP hosting service provided by edaboard.com to its members which powered my website so far. The old content would still be there, albeit not really accessible for the time being.

And yes, I write this I am finalizing a panel to be sent to the board house. What the circuits are about, is in the next post.
EDIT: Panels are already sent to the board house and I’m waiting for them to arrive. Yay!

BeagleLogic goes kernel-mode with PRU remoteproc[Week 2-3]

The first week was spent well in prototyping the PRU firmware. Problems with the memory management [Maximum of 8 MB of memory] and dismal memory copy speeds [10-20 MB/s] with UIO and libprussdrv prompted me to escalate the back-end to the remoteproc kernel driver. It took me a while before I started off based on the WS28xx lighting firmware example to build up the necessary kernel driver infrastructure for BeagleLogic, and it’s now close to the first set of stress tests and actual data capture for the PRU.

Going into the kernel driver, here is a summary of what’s coming up in the next update [the experiment is with dummy data, the PRU’s aren’t engaged] :

Screenshot from 2014-06-11 23:01:19