The homebrew_mini2 board is now a shared project at Osh Park. You can build your own HB_mini2 by ordering the board, here.

The parts list is as follows:

   z1/z2/z3 TVS diode 12vwm 250vc 0402 F2862CT-ND

   CONN USB MICRO B RECPT SMT R/A 609-4613-1-ND

   C7 CAP TANT 10UF 10V 20% 0603 718-1673-1-ND

   CONN IC SOCKET 24 POS DIP 30AU A35058-ND

   F1 PTC RESETTABLE 6V, .500A SMD 0805 F2772CT-ND

   Y1 CRYSTAL 25MHZ 18PF SMD 535-9128-1-ND

   IC1 IC REG LDO 5V .8A 8SOIC MC33269D-5.0GOS- ND

   IC2 IC REG LDO 3.3V 0.5A TSOT23-5 576-1910-1-ND

   ICU IC MCU 32BIT 1MB FLASH 64LQFP 497-11767-ND

   SWITCH TACTILE SPST-NO 0.05A 12V SW1104CT- ND

   7 x C 100n 0402

   3 x C 2u2 0402

   2 x C 18 pF 0402

   1 x C 1 uF 0402

   2 x R 40K 0402

   2 x R 22R 0402

Another thread that could be helpful can be found by following this link, here.

Below is the schematic for my homebrew mini2 in case anyone finds it useful. My design criteria were: I) incorporation of an STM32Fx chip to allow usage of the netduino 2/netduino plus 2 firmware, and II) all pins compatible with my dive computer/rebreather controller project pcb & associated parts developed with the netduino mini. Through the iterations I've had to solve a USB cable grounding issue and shuffle pins around several times to get backwards compatibility. The last iteration I left pins 2, 3 and 22 disconnected because I had everything I needed elsewhere and wanted to save a little time routing. I just finished chasing down a side effect bug with my 24 bit ADC. The HB mini2 v1.10 has been robust so far, and both the HB mini2 and the netduino mini are now interchangeable on my project pcb. 

homebrew_mini2 by cys1, on Flickr

As regards oled screens, there are lots of sources (eg digikey, mouser, newark, newhaven, sparkfun, adafruit, etc...).

Is it possible for you to point me to where to look for parts, e.g. pressure/temperature sensor and oled screen?

Additionally, you seem to have a very well made casing for the electronic parts. Do you have to expose the sensor to have contact with water? If you do, how was it accomplished to prevent water from getting in due to high pressure at depth? Sorry to bomb you with all the newbie questions.

I just happened to see recently that Sparkfun now offers an MS5803 pressure/temperature breakout. I use this sensor, but I made my own breakout board for it. There is a conversation about the breakout board on the bottom of the Sparkfun page that provides a link to schematics for sealing the sensor with an oring.

This was the start of the board, but a lot of changes were made: http://eleccelerator...breakout-board/ Getting everything into the mini format is challenging, especially because the routing of the pins isn't always natural due to making it backwards compatible with the real mini.

For now I'm just going to keep the home-brewed mini2 as my own hack. I've seen some irregularities (posted elsewhere here) with SPI that I've been able to work around with code that may or may not be homebrewed hardware related. I'm finding that the dive computer based on the real mini works so well for me -- I use it all the time -- that I haven't touched the HB-mini2 project for a while.

To make the gold pad accessible on some of my devices I've soldered a fine wire to the gold pad and run the other end of the wire to a via that is accessible.

I use a low tech solution. When I want to update the mini embedded in my project pcb, I temporarily solder wires to the RS232 pins.

It's been revised once, here.

It runs NETMF. I've been using the Netduino Plus 2 firmware (but recently tried Netduino 2 firmware and it works as well).

I tried the Netduino 2 firmware instead, and it gives the same spi issue.

Chris

Yes, quite significantly so, how silly of me :-)

That was for the non-expert readers. I even avoided saying it first thing... .

Very impressive, it requires quite some skill.

Partly reflow soldered or everything by hand?

What are the differences compared to Chris's version?

It was all soldered by hand.

Some differences are that pin 1 was converted to an analog pin, pins 2 and 3 to I2C, and pin 22 to a digital pin.  Some similarities are that SPI pins are still the same, and power and ground pins are still the same. Reassigning pin 1 and not reassigning SPI or power/ground were to make the move from the Netduino Mini version of my project to homebrew mini easier.

Of course the biggest differences are that the homebrew mini has an STM32 chip and USB.

Chris

Hey cys,

It's very cool that you've built a homebrewed mini

Chris

Hi Chris,

Thanks. It's an expression of how much I like the Netduino Mini.

Chris

Hi Chris,

1. If you do come back to this issue, can you test it on actual Netduino hardware--to see if you get the same issue?

I've used the real Netduino Mini with firmware 4.1 without any spi issues with the same program and device for a couple years now. 

2. Have you tested this using the Netduino 2 firmware instead? Not having the Ethernet chip, etc. on board could throw off the runtime, internally.

I'll give that a shot. Thanks!

Chris

Hi Chris,

From the logic analyzer capture you did, it appears that the data is being sent properly--but the device is not responding properly--correct?
 

Yes and no. In first two logic analyzer captures the device does not respond correctly (labeled 1st time and 2nd time in the pdf), but in the second two captures the device does respond correctly (labeled 3rd time and 4th time). As an addendum, I would add that all readings after the second reading are correct (but none are shown in the pdf after the 4th reading).

To clarify: if you wait a little while before querying the device, the device responds correctly?
 

No, waiting before querying the device does not lead to a correct response. I tried adding a thread sleep of 5 seconds before querying the device and the response was still corrupt.

What is happening is the first two responses from the device are corrupt -- no matter how long of a pause is used before querying the device -- but all later responses are correct. My workaround is to toss the results from the first two device responses, as the device works flawlessly afterwards. Therefore, in a bizarre twist, when the program loops around and hits the two spots at program entry where the corrupt readings occurred initially, the readings are correct (the surface mode of this dive program loops continuously, with three separate command lines where the device is queried interspersed with other code).

I'm not impeded from using the program at the moment. I do eventually want to figure out what is going on. I've spent a lot of time troubleshooting it already, playing with program structure, etc. The workaround is the result of that effort so far.

I have to again note that I'm using the Netduino Plus 2 firmware with the home brew stm32mini.

Chris

Hi Gutworks,

I changed over to the Netduino spi class, but it didn't fix the issue. Also, all static objects are initialized in the Main class. Thanks much for the suggestions.

I tried adding a long pause before the sensor is read for the first time to see if sensor stability was an issue, and there was no change.

In general, the program has been working for several years under 4.1 without issue. I've done a matrix of timing changes for the sensor when moving over to 4.2/4.3, both in terms of bus speed and between program arguments in the driver. I guess I'm happy with my strange workaround for now. If anyone has any more suggestions of things to try, I'll give those a shot. 

Chris

On reflection, it may well be that the power consumption of the STM32 is affecting the stability of the sensor briefly at startup, as looking at the logic traces it seems the sensor output is the issue. I will try adding a brief pause at program start to let things settle/stabilize and see if that fixes it.

Hi Chris,

The logic analysis attached as a pdf in post #9 in this thread shows what is happening on the wire using firmware 4.2. Actually I didn't rearrange the code. The logic analysis showed the first two readings from the sensor (different lines in the program) are corrupt but later readings (later lines in the code) are correct. Strangely, what I found was if I put a counter in place that omits the first two readings after program start only (the first program loop), all later sensor readings after the first program loop are correct (even the first two that were corrupt in the first program loop). In the pdf -- logic traces labeled 1st time and 2nd time are the first two readings after the program starts (corrupt), and logic traces labeled 3rd time are 4th time are the next two readings in the first loop (not corrupt). I can do the logic analysis for firmware 4.3, but right now the behavior looks the same as what I saw with 4.2.

Chris

Hi Chris,

I just tried 4.3.1, and my spi problem is still present, unchanged.

Hi Chris,

The workaround was the best I could do to resolve it. I will try 4.3.1 and report back.

Thanks!

Chris

After untangling some things further, I have found that if I place the "init/coefficient read" of the pressure sensor at the end of my surface subroutine, the sensor is initialized correctly and the coefficients are also read correctly, and they remain stable through further pressure readings. Under firmware 4.1 the pressure sensor "init/coefficient read" occurred near the start of the program, and functioned flawlessly. Under firmware 4.2 corrupt data resulted with this aforementioned placement, along with placement in the beginning or middle of the surface mode subroutine, a little further into the program. Only when the "init/coefficient read" is placed at the end of the surface subroutine is it successful. Strange. 

Below is what I see with a logic analyzer. There are 13 transactions with the pressure sensor for each pressure reading. Attached is what the first 3 transactions look like from the first 4 pressure readings. Stable pressure readings are seen in my program beginning with the 3rd pressure reading, consistent with the logic analyzer data. (I have not yet done the logic analysis to try and figure out why I need to reset/read coefficients each time I want to read pressure, as opposed to reset/read coefficients once on program initialization).

Chris

If I had to speculate, I would suggest that there was some kind of esd/overvoltage event. Most likely it's toast.

I'll work on getting access to one. Once I do, I'll post the results.

Thanks,

Chris