[Mario]

Definitely needed that extra board space!
This is an extremely rough initial component placement, I basically just threw everything on approximately where it needs to go, to make sure everything will fit. Looks like it'll be pretty packed, but everything should fit without too much trouble.
Now to start routing traces and figuring out where all these parts actually need to go to make it all work!

 

[mudder]

Estimates on layer count? Even 4 layers looks pretty tight... particularly with that MCU slammed into the top right corner.

 

[Mario]

Should be alright in 4 layers.
Top - Majority of local component-to-component routing, short jumps to bottom layer if needed
Signal 1 - Dedicated ground plane
Signal 2 - Mostly power pours, but some signal routing as needed
Bottom - Majority of across-the-board routing, getting signals to the micro

The bottlenecks around the LCD connectors in the middle may pose a problem. I tried to keep the majority of signals that go to the micro on the right half of the board. We'll see how it goes!
0.15mm trace/space helps

 

[Mario]

Looking good! Everything is ready to be wired up, all the components have been placed such that I already know where each trace will go (at least, for everything on the top layer). Then I have to get everything over to the microcontroller. But it's coming along great!

 

[C3p0h]

im very intrested in this

 

[Mario]

Routing a tight board always takes a while, managed to make it all fit though! It was also easier than I expected to get all the signals to the microcontroller.
I actually ended up being about 5 GPIO short, I'd just figured I'd never use all the pins on the micro since I had so many! Luckily it was easy to combine some signals and get rid of others, they were added only for convenience. (Sorry @mudder, the separate RE/DE lines were one of the first to go. But there really should be no need for collision detection, as Pegasus would only transmit after receiving a request for data or a command from a master, such as LiMCM. Only a single master)

I won't order the boards right away, it's a good idea to let it sit a couple days to make sure I didn't forget anything. I want to double-check some things and add some more silkscreen labels too. But soon!

 

[mudder]

You should post your power and ground layers, too... poor power and ground always getting left out in design reviews . Excited to test out the new hardware soon!

 

[Mario]

You should post your power and ground layers, too... poor power and ground always getting left out in design reviews . Excited to test out the new hardware soon!

I won't post the ground layer, it's 100% only ground without a single extra signal. But here's the power layer!
The pour is 3.3V, the thick traces are switched 3.3V and 5V lines, and 5V and 12V for user ports. Not ideal to have small-ish traces rather than big pours, but everything has local decoupling capacitance... plus we're talking like 500mA at the most on any of these.

 

[Mario]

About a week ago I submitted the PCB for fabrication, made a couple minor tweaks and thankfully realized I had chosen the wrong footprint for the 5V regulator's inductor, so I was able to fix that. Also ordered the rest of the components I need to make the handful of initial prototype boards, and the solder paste stencil.

Over the past couple weeks I dug an old 3D printer I had out of storage and have been calibrating and tuning it, and getting the dual extrusion dialed in. I'm very happy with the results I've gotten, and I've been working on the plastics for the controller. Most of these parts have been tweaked and re-printed at least a dozen times, and one took 26 tries before I was happy with the geometry! (the springy clip on the back)
The main case body and the buttons are dual-extruded, combining clear and opaque filaments for a high-contrast appearance even when the LEDs are off. It also took a while to figure out good print parameters to diffuse the light well. The ring around the knob still has some hot spots, but it's about as good as I can get it given the print orientation and physical location of the LEDs.

The two buttons, "dot" and "dash", are differentiable by touch. The dot button has a smooth concave surface. The dash button is flat with the dash raised, very easy to feel.
This is a complex little bit of kit with fine tolerances and 6 printed parts and I'm very happy with how it came out!

Some things will still be tweaked of course, I'm going to change the dot, dash, and knob to a different color, probably black or a darker gray.

 

[*sean*]

Those buttons are totally awesome. I love the design.

I am working on a single DIN HDMI touchscreen to fit in the radio slot. This would make an awesome set of knobs and buttons for them. Display fake buttons, and spin the real ones. These would be PERFECT FOR THAT.

 

[C3p0h]

Please take my money

 

[mudder]

Looking fantastic!
That's a huge upgrade from the previous knob version, which is still holding up just fine after two years.

How much 'fun' did you have sourcing all the parts?

 

[Mario]

Looking fantastic!
That's a huge upgrade from the previous knob version, which is still holding up just fine after two years.

How much 'fun' did you have sourcing all the parts?

Thank you!
I already bought all the "rare" stuff quite a while back (flash chip, power supplies, MCU, level translators, etc), so everything left was mostly jellybean parts. Things do seem to be recovering a bit as well! Though, the MCU I'm using is still out of stock. I have enough for 49 boards, but after that we'll have to see.

 

[Drtye]

Very elegant design on the switches.

 

[*sean*]

Hi @Mario,

I am considering a number of use cases for Pegasus. I have several new sensors planned (coolant tank level, EGR noise detector) and mods (car operation without ICE) that would benefit from access to the LCD via commands from, say, a serial port (or, in some cases, USB, if Pegasus has a USB programming interface). I am wondering if firmware source will be available, or even just a basic .h file identifying what is connected to what port?

If so, where does Pegasus stand with extra usable ports, serial and/or SPI/I2C interfaces? I'm toying around with installing a small SPI LCD panel where the up/down shift lights are for indicators like lean burn status and other things. Also toying with the idea of repurposing the unused idiot lights replacing with a multicolor or addressable RGB LEDs for things like a lean burn indication, overspeed indicator, "message waiting" from one of my other sensors, etc.

Second, my plan to install a full HDMI panel in place of the stock LCD panel is on indefinite hold as it requires extensive interfacing; I intend to keep the cluster electronics online if only to maintain the existing odometer functionality. Here too, Pegasus could eliminate a lot of work, if connected to the MCU (Pi, likely) driving the display. Is there a show stopper that would prevent Pegasus from being employed to provide a data stream of parameters to a Pi that's driving an HDMI panel installed where the LCD panel is now? (I recognize there is still a tremendous amount of software that I would have to write both in Pegasus and the Pi to do this, and destructive physical mods to the cluster case and the inside of the dash to get the target panel to fit.)

 

[Mario]

@*sean*

Here is every interface Pegasus exposes to the user:

• 2x I/O ports (12V power, 0-16V analog read, 3.3V/5V/12V digital input, 150mA-capable low-side switch with PWM)
• 2x I2C ports (one on the mainboard in the cluster (5V/150mA power) and one on the controller (5V/100mA), these are separate busses. Could also be used as 2x GPIO instead of SCL/SDA)
• 2x CAN FD ports (one on the mainboard and one at the OBDII plug, these are the same bus. 5V/250mA power)
• 1x USB (at the OBDII plug, for now this is only intended for firmware updates but could offer more functionality)
• 2x UART (in the form of the H and K lines on the slave OBDII plug)

For the I/O ports, I plan to allow configuring them to be compatible with various Pegasus functionality. You could have the output turn on when a parameter hits a certain value, or only when you press a button on the controller, or read a voltage to be displayed as a parameter, or hook up a button to control Pegasus, etc. And the state of the ports could be read or controlled by commands issued through the various other ports.

The I2C and CAN ports will allow reading or writing parameters, reading what's being shown on the stock cluster, adding extra sensors to Pegasus, developing your own boards to interface with it, etc. You could really do anything through these ports. There would be a spec document that describes the communication protocol.

USB, like I said, is only planned to be for firmware updates (Pegasus shows up as a flash drive, just drag the new firmware on). But it could offer other functionality like downloading logs or also sending/receiving parameter or display data.

The UARTs are intended for the K/H lines on the slave OBDII port, used when plugging in certain supported peripherals (like OBDIIC&C or retepsnikrep's IMAC&C joystick, maybe a generic OBDII reader) so they will function like they're plugged into the car. But there's no reason they couldn't be used as ordinary serial lines.

Some or all of this functionality won't be available in the initial firmware release, but likely will eventually.
I also hope to make an Arduino library to make it easy to talk to Pegasus through I2C or CAN (this is way down the list of priorities though).


Sounds like a couple things you want could be done with the I/O ports, but the best way is probably to make a board that does what you need (reads coolant tank level and EGR sensors, drives the tiny LCD and RGB LEDs, etc) and send/receives data from Pegasus as needed through I2C or CAN, depending on where you locate the board. I wouldn't trust I2C more than a few inches in a noisy vehicle environment.
You could definitely use one of those ports to get all the data needed for an HDMI LCD display replacement.

 

[*sean*]

That's awesome. Thanks for the detailed info.

 

[Mario]

The PCBs arrived! Though I won't be assembling them for a bit, I want to finish the firmware I've been writing first (bootloader for the controller).

 

[mudder]

My how much you've grown, senior Pegasus!
I always love unwrapping a new PCB!

 

[Mario]

Finished the controller bootloader code! Everything works great, I've tested all error conditions and loading an application with it works great.
The controller only has 32k of flash, so I wanted to keep the bootloader small. I was able to squeeze it into 4k with 12 bytes to spare!

The bootloader is the piece of code that lets me load firmware onto the controller without using a special programmer. Normally to program the chip you need an ST-Link, and I don't want to require customers to buy one plus a special programming connector if I ever update the controller firmware. Now Pegasus will be able to update it through the SPI interface it uses to talk to the controller.

I still need to write the actual controller firmware to make it do stuff. I just have some test code that blinks the LEDs right now. That will come later though, along with the Pegasus mainboard bootloader and firmware.


The controller board is very small and is pretty packed with components, so I didn't have space to put a normal programming header on it (I still need to load the bootloader with a dedicated programmer). When I designed the board, I broke out the programming pins to some pads along the edge, leaving it up to future me to design a custom programming connector for it. Here's that connector! It uses itty-bitty pogo pins to touch the pads and a pin to hold the board in place.

Next week I'll assemble one Pegasus mainboard and start writing test code and probing everything to make sure it all works as expected!