EXT Cartridge Module

Oh that’s smart, I got a Cisco serial cable around somewhere for RS45 to D-Sub.
Then 3 RJ-45s fit easily.


A switch to change the serial’s output level to CMOS/TTL/RS232 could fit, but would it be neccesary? Switching the output level would be nice but requires a level shifter, I don’t think the real estate on the board would accommodate this.

Still deliberating on either using an FTDI for RS-232 or using the DevTerm’s UART.
The case for the FTDI is that it’s truly plug and play through USB, for the DevTerm UART it’s less parts required but with additional configuration neccesary.

For the Ethernet chip I’m eyeing the LAN7850, tough soldering this one is going to be a challenge.
If anyone got a more accessible chip in mind, please do tell.

Sorry to break the bad news, but the cartridge system can only give out power,
not receive it and route it to the battery. Tough I got to admit, a power input module accepting low voltage AC or DC would be cool as hell.

2 Likes

Good news, I just assembled the revision 4 EXT module yesterday.
I’m still missing the GL850G USB hub tough, and the PWM fan controller and USB to UART I didn’t populate. Aside from that, it works very nicely!

Here’s the i2cdetect, all devices show up:

$ sudo i2cdetect -y -a 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  <<-- 0x20: MCP23008 Port Expander
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --   <<-- 0x68: DS1307 RTC
70: -- -- -- -- -- -- 76 -- -- -- -- -- -- -- -- --   <<-- 0x76: BME280 via breakout cartridge

Regarding the edge connector position, @yatli hit the nail on its head, it fits perfectly with the parts I designed early on.

The only cartridge I can test right now is only the breakout adapter,
but that works as expected, added a BME280 to the I2C bus and it reads out as expected.

Parts for the thermal printer and camera module will arrive next week, then I’ll give an update on that when I got to testing.
Tough the mechanical aspect for the printer is sorted out now, just needed to adjust the model slightly.

Lastly, the LAN/RS232 combo module, routing is 87% done and I expect it to be finished in two to three months, giving myself a little leeway here because this one is packed.

7 Likes

I’d like to substitute a user module where the cell phone chip goes.

Time for the monthly update on the project.

The RS232/dual Ethernet cart came in, and it works nicely.
Did a few tests pinging and connecting RX to TX, no problems with either.
However the activity LEDs for the RS232 port don’t seem to work, but that’s not that important.

In other good news, the printer cartridge is confirmed working.

With the camera module I have a few troubles, I can’t seem to get the OV5647 working.
It does get initialized by the kernel, but got no usable video devices yet.
If there are any experts who know the RK3399’s MIPI CSI well I could use some help in that regard.

6 Likes

could you share the devterm file for freecad ?

I am working with the meshes supplied by Clockwork Pi directly, but did some decimation to make it easier to render.
I tried converting them to solids but the meshes are too detailed for that.

Here’s a FreeCAD file with the meshes separated:
https://files.catbox.moe/pg73hg.FCStd

Also check out the git here:

1 Like

Wow I am slow to this awesome set of developments!! But is there any room for last minute suggested carts?

Pcie breakout to stick something like the rpi2040?

Some way to stick an ssd and possibly boot from it?

And this one I can’t get out of my head: a cassette tape record and playback? For making backups if course :wink:

Pcie breakout to stick something like the rpi2040?

I tried searching for an PCIe bridge chip, no dice so far.
You can however put a RPI pico via USB without any problems.

Some way to stick an ssd and possibly boot from it?

Searched for a chip that bridges USB to mSATA, and there is one actually, the Renesas D720231A.
Tough the availability of this one is not great, LCSC has it on pre-order only.
I mean theoretically possible, but I’d rather work on the software right now before spreading even thinner with more cartridge designs.

And this one I can’t get out of my head: a cassette tape record and playback? For making backups if course :wink:

Sadly there’s not enough room to fit a mechanism, a cartridge is pretty much the size of a cassette already. Having the mechanism outside of course can work, but that would be rather top heavy and look a bit silly. Then there’s the issue that cassette mechanisms nowadays suck, so it’s not worth it in my opinion.

I did investigate the possibility of installing 2.5" SATA drive in the expansion bay.

  1. Form factor;
    Thinner drives like SSD will fit, but thicker (still within valid 2.5" form factor…) ones like the spinning rust won’t.
  2. Power
    Again. SSD can be properly powered by a USB-sata cable, while spinning disks cannot, resulting in the drive restarting constantly.

You also have these usb-c

1 Like

Update Time: Preparations for a small production run

I’m back again on the project. As demand rose to +1,
I’m considering doing a small production run of this EXT module.

First of all, allow me to get a feel, would you even buy this?

  • Yes, I would buy the Cartridge EXT
  • No, I am not interested
0 voters

The price will change according to how much interest there is,
but for 10 pieces it’ll be estimated but sadly 100€.
I’m using 70€ as a baseline coming from the calculator at PCBWay,
for the Commodore 64 connector and fan it’s another 15€,
the rest is profit margin and work put into putting it together.

Then also, what cartridges would you buy if any?
These are among the designs that I’d classify as ready to be produced, see next paragraph for estimated prices.

  • Printer Kit
  • Dual Ethernet and Serial
  • Breakout Board Adapter
  • USB DIY Kit
0 voters

The cost for the Dual Ethernet and Serial cartridge is 26.84€ for the assembled PCB, rounded to 40€ for 3D printing the shell and profit margin.
The printer kit I’m estimating 30€.
The breakout adapter I’m estimating 25€ including a cable.
A USB DIY kit would be the cheapest option at an estimated 5€.

Onto the technicals, for this run I’ve forked @yatli’s design to improve a few things and using different parts that are available on LCSC or Mouser.
At the schematic level, not very much has changed except with the PWM Fan section.
Here I’m using the EMC2301 to generate the PWM signal. It also has TACH support.
It is supported in Linux kernel version 6.3.12 or higher, alternatively it’s trivial to adapt any of the existing fan daemons.
I’ve planned to use a CBM-35CF Series fan which has both TACH and PWM, but since it is not available yet I’ve also included support for the stock DevTerm fan.

Click to open schematic

From a routing perspective, I’ve adjusted the skew of the differential MIPI-CSI lines and will later optimize it as I suspect that signal integrity is not fully there in yatli’s Rev4.
Also, I estimate that the PWM controller routing will be finished next week.
Other than that, the design has proven itself and will remain mostly unchanged.

4 Likes

I have to admit I’ve not been keeping up with development of this but this looks really awesome and I’m impressed how far this has come. I’d definitely be up for it + printer & ethernet/serial carts.

2 Likes

Just want to preface this by saying im absolutely not bored with my DevTerm in favour of my uConsole as from the rest of the post you might think that I’m asking the world and thinking it should all change gears to the new and shiny product. This is purely meant to be hypothetical, I would still buy this cartridge system in a heartbeat.

As somebody who has little to no experience with electronics and hardware design, how likely is it that the cartridges could be used with the uConsole in some way?

The way I understand things (and please do correct me if I’m wrong on this stuff) is that this cartridge project would produce a replacement EXT. board to connect into the 3.14 mainboard.This then has an edge connector socket (?terminology) on this new EXT. board to accept the edge connector from a cartridge board.

The space inside the DevTerm for EXT. boards is obviously rather generous + the space above it currently only occupied by the thermal printer which allows for the cartridge to actually go (mostly) inside the machine.

Compare that to the uConsole, it obviously has the same capability to mount a new EXT. board but the main difference is that there is little to no space compared to what is provided with the DevTerm. The only current uConsole EXT. module is 37x77mm and that fills up pretty much all the space to the outside of the unit.

Which leads to the expansion port itself, with a really rough guesstimation the DevTerm’s is something like 70x15mm (with a flap) and the uConsole is only about 55x10mm which I assume means that even the edge connector (not sure of exact cartridge board dimensions) itself is too wide to go into the uConsole’s port.

So even if the DTC EXT. board could be shrunk down to the tiny size afforded by the uConsole’s internal space and the port was wide enough I guess you would still be left with the entire cartridge dangling out the side of the device with no support unless you create some kind of solid mounting bracket to go with it.

I’m assuming that the DTC EXT. board is doing some fairly clever stuff which makes just using the “naked” EXT. connector not particularly usable without external circuitry?

Over the course of this I think I’ve probably answered my own question and that is that no, it seems like DTC system would be incompatible at worst and totally impractical at best and that any new external modules made for the uConsole would be almost forced to only use the EXT. connector. and fewer pins to play with.

Yes, unfortunately the EXT Cartridge board would have to be significantly redesigned if all the chips for all the functionality would even fit, and even then it’s not compatible with the original cartridges. You are totally right with the measurements, the edge connector would not fit a uConsole :frowning:

It would be feasible tough to design specialized EXT boards, like one to pass through the IO from the PCIe connector or Ethernet with serial.

With this project I got enough on my plate and didn’t pre-order the uConsole anyhow, so that is up for the community to make. I already saw some neat progress on some modules, notably LoRa and GPS.

Regarding updates, I’m finishing up on the daemon to detect cartridges and do all the (de)initialization for plug and play. I’m developing it for yatli’s Archlinux branch in mind, it should be possible to compile it for other distros like Armbian but I haven’t tested anything yet. Next up are manuals, I’m sure one has to be included but I could be wrong.

News from PCBWay is that the EXT boards are done, and the printer boards are finishing up. Tough I made some mistakes with the BOM and I’d have to solder a significant number of parts manually. It’s the quartz for the USB hub chip and all electrostatic protection TVS diodes. This plus I opted to solder all through hole components myself, especially the edge connector, to keep cost down. Also the dual ethernet and serial cartridges have some errors too which need a little touch up.

This and all that means it’s that, if I’m fast with all the remaining tasks, in a month or so I’ll have all the products available on Tindie hardware wise. For the software there’s still a lot to be done that I haven’t figured out yet, like hosting the package manager repository.

1 Like

Absolutely, it was just partially a) me musing about the concept and 2) pre-empting the questions that might come in later. I have the uConsole but I still prefer my DevTerm and am in no way ready to abandon it just because the uConsole is here - the DevTerm still gets to keep my precious A06 core.

That really pretty damn impressive pace… I can’t wait.

What kind of packages are we talking about here? This might be the side where if needed I can potentially help out if help is wanted. I’m pretty useless with actual electronics.

1 Like

It’s just creating and hosting pacman packages first for the base daemon and additionally one for any cartridge software, which is as of now only the printer. This is completely new territory for me. It might not be essential if installing from source is acceptable, but it would make installation neat and concise.

Out of interest why Pacman? Or are these packages expected to be installed via an Arch system first? I might be missing something essential here as to what your plans for this are.

I mentioned it in passing here that I’m developing on yatli’s Archlinux distro first because it’s way easier on me regarding the device tree stuff and because me and yatli got the same system to develop in, but also of my preference to it I must confess.

Maybe the best play is to make it installable from source only and testing it on Armbian too,
but that leaves the device tree stuff unaccounted for as of yet. That’ll be fun to provide support for in the future :upside_down_face:

Anyway, yeah, I should actually develop for most images as the EXT supports all boards.
I say most because I only got the A06, A04 and CM4 cores, didn’t bother with the R01 yet.
I’ll lean to the solution that is less work required, now I feel packaging binaries is more trouble than it’s worth.
Feeling uneasy now on the 1 month deadline. I don’t want to be responsible for yet another hardware project with no software to support it where the end user has to provide it, if you know you know.

1 Like

You did indeed and yet I still managed to miss that entirely :sweat_smile:, that makes a lot more sense now (time to dig out a spare SD card too…).

If it is developed as Pacman packages it might be a good idea to maybe target Pacstall later as it is (or at least was) relatively easy to convert the PKGBUILDs.

Agree, getting the things supported that can be supported are better than just adding in somebody’s preferred package format.

Makes sense to me, the R01 is by far the least practical day to day core, not only because of the more limited software but it is just so down on any kind of decent processing power. I’ve got a much more powerful RISCV SBC and if that was on a DevTerm core it would be a totally different story.
At least for a first batch it might be worth seeing what people actually have out of the people who want to buy them. If nobody has (or wants to use) the A04 and CM3 cores as an example then it might be easier to push those down the road a bit.

As much as I get making your own deadlines to push things forward I don’t think you lose anything by giving yourself a bit more time.

1 Like