I have some weird ideas. I don't know if they makes any sense.

[technix]

Here are the ideas I wish you guys can evaluate:

1. Breadboard-friendly USB to Serial adapter with a USB Micro-B connector (to go along with my thumb drive form factor one)
2. 16-or-less pin breadboard-friendly USB capable STM32 dev board (SushiBits Zero Micro, based on STM32F042)
3. ATmega1284 adapter (converts ATmega1284-MU QFN-44 to -PU DIP-40 pinout)

[sokoloff]

Evaluate for what?
Profit-making feasibility if you did the design and fabrication and sold them on Aliexpress?

IMO, near zero and not worth the time, but then again, I don't understand how the economics of most things sold on Ali work. All I can tell is that it's a brutally competitive market.

Worth doing to learn and have around? That's up to you.

[tszaboo]

1) FTDI makes that. Ok, I dont know which USB it uses, but who cares?
2) STM32 red pill? Ok it has more pins, just saw off the board
3) ATmega1284 comes in DIP40 package.

[technix]

1) FTDI makes that. Ok, I dont know which USB it uses, but who cares?

It uses the WCH CH340B/C.

2) STM32 red pill? Ok it has more pins, just saw off the board

Similar. The board is much, MUCH smaller on that.

3) ATmega1284 comes in DIP40 package.

Try find one. Literally nobody I have asked on Taobao sells those any more.

[sokoloff]

3) ATmega1284 comes in DIP40 package.

Try find one. Literally nobody I have asked on Taobao sells those any more.

Aliexpress
Digikey (519 in stock)
Mouser (363 in stock)
Newark (125 in stock)

[ebclr]

This product already exist and will compete with your ideas

[Ian.M]

Ah yes, the STEMTera - just because its such a *wonderful* idea to put an Arduino inside a breadboard.  https://www.sparkfun.com/products/14082 

Breadboard real-estate is *VALUABLE*.  Covering it up with shields or DIP footprint USB serial modules is just dumb.   However a combined breadboard PSU and FTDI FT2232H breakout (so you can do I2C, SPI, and JTAG as well as asynch serial) that plugged into the end of the board power rails without obscuring the rest of the board would be an interesting combo.  FT2232H signals on a female header across the end of the board, with buffered status LEDs and for the PSU section, basic +5 and +3.3V from USB, or plug in external power to get the same + adjustable +/- supplies up to 15V 1A for analog stuff.

[technix]

Ah yes, the STEMTera - just because its such a *wonderful* idea to put an Arduino inside a breadboard.  https://www.sparkfun.com/products/14082 

Breadboard real-estate is *VALUABLE*.  Covering it up with shields or DIP footprint USB serial modules is just dumb.   However a combined breadboard PSU and FTDI FT2232H breakout (so you can do I2C, SPI, and JTAG as well as asynch serial) that plugged into the end of the board power rails without obscuring the rest of the board would be an interesting combo.  FT2232H signals on a female header across the end of the board, with buffered status LEDs and for the PSU section, basic +5 and +3.3V from USB, or plug in external power to get the same + adjustable +/- supplies up to 15V 1A for analog stuff.

This is an interesting idea... I might try this. How about this feature list:

* Switch-mode buck converter with input range of 4.5-17V. (TPS562200 or TPS563200)
* Adjustable output voltage: 0.8-5V, can be software calibrated
* Controlled and monitored over USB (ATmega16U2)
* 8-pin chaining connector for wider breadboards that shares the input power, ground and control signals. Control signals are based on RS485.

[donotdespisethesnake]

Here are the ideas I wish you guys can evaluate:

1. Breadboard-friendly USB to Serial adapter with a USB Micro-B connector (to go along with my thumb drive form factor one)
2. 16-or-less pin breadboard-friendly USB capable STM32 dev board (SushiBits Zero Micro, based on STM32F042)
3. ATmega1284 adapter (converts ATmega1284-MU QFN-44 to -PU DIP-40 pinout)

I guess that "SushiBits Zero Micro" is something we are supposed to google, but that leads straight back to this thread.

3) is pretty pointless, if it is just a supply issue.  Anyway, all 3 are pretty much done already. Of course, you may not get exactly what you want, the only way to do that is design and build your own.

[technix]

I guess that "SushiBits Zero Micro" is something we are supposed to google, but that leads straight back to this thread.

I nabbed the SushiBits name as a trademark already Should I do this small USB-capable board I would name it SushiBits Zero Micro.

Anyway, all 3 are pretty much done already. Of course, you may not get exactly what you want, the only way to do that is design and build your own.

I think I would focus on the breadboard PSU now.

[Ian.M]

As I said, the combo of breadboard power and USB <> serial is quite attractive.  Maybe, instead of a USB<>serial chip, put a  ATmega32U4 on there with an Arduino compatible bootloader so the user can reflash it with other firmware to handle other protocols.  If you make the PSU voltage software controlled, I strongly recommend putting unpopulated footprints for a multi-turn preset, a jumper to select between hardware and software control, and an AVR-ISP header so that users don't have to run your special firmware that controls the PSU while providing serial comms, but can load other firmware without worrying about the PSU control

[technix]

As I said, the combo of breadboard power and USB <> serial is quite attractive.  Maybe, instead of a USB<>serial chip, put a  ATmega32U4 on there with an Arduino compatible bootloader so the user can reflash it with other firmware to handle other protocols.  If you make the PSU voltage software controlled, I strongly recommend putting unpopulated footprints for a multi-turn preset, a jumper to select between hardware and software control, and an AVR-ISP header so that users don't have to run your special firmware that controls the PSU while providing serial comms, but can load other firmware without worrying about the PSU control

I will probably use the ATmega16U2 instead (smaller chip) + HoodLoader2 bootloader (Arduino compatible) or STM32F103CBT6 (also smaller chip, and it have full hardware support of RS485 for chaining.) The default firmware provides level shifted serial port and software controlled power supply at the same time. Should an individual 10-turn pot be needed a 0 ohm link can be desoldered to detach the d-pot from the SMPS IC.

[Ian.M]

You need to stay as 'mainstream' as possible to maximise your market, and like it or not, more end users buy Arduinos and compatibles than any other type of development system.
You also need to differentiate your product from all the dirt cheap USB serial boards and DC converter boards flooding the market.

32U4 gives you immediate Arduino Leonardo software compatibility.  There are no official Arduinos with 16U2 as their main processor.   The cost difference would be insignificant compared to total cost of your board so why cripple it?

[ebclr]

If you wanna be unique to a wireless USB serial converter based on cypress chip, this one can reach good price as a product, any board based on CH341, FTDI232 CP2102 are all commodities will sell for 1 to 2 USD

http://www.cypress.com/products/wirelessusb-nx

[Ian.M]

On the subject of staying mainstream - maybe give the board a standard set of Arduino headers, with the digital one next to the end of the breadboard?  This will require a lot more overhang off the side of the breadboard, but if you add two adjustable standoffs consisting of M3 nylon cheese head machine screws each with two nuts to clamp either side of the board's corner mounting holes, it will still be stable when plugged into a breadboard.  Put M3 mounting holes in the other two corners as well to cover the usage case of bolting the board down with the breadboard power rail header pins removed.  Also add breakout pads for all Arduino pins and uncommitted 32U4 pins and as much 0.1" pitch PTH proto area + spare  unpopulated SOIC footprints on the underside so users can do stuff like add their own interface circuits.

[janekm]

I think the MCU in a breadboard formfactor is pretty useful.
Make one with an alternative MCU (I'd love an NRF52 one, others might like STM32) and decent power supplies built-in, at a "don't think about it" price <$10 and you'd be on to a winner.
CP2102 is a better choice than CH340 as it works better "out of the box" on Mac. Say what you will but people who buy Macs tend to have disposable income 

[technix]

You need to stay as 'mainstream' as possible to maximise your market, and like it or not, more end users buy Arduinos and compatibles than any other type of development system.
You also need to differentiate your product from all the dirt cheap USB serial boards and DC converter boards flooding the market.

32U4 gives you immediate Arduino Leonardo software compatibility.  There are no official Arduinos with 16U2 as their main processor.   The cost difference would be insignificant compared to total cost of your board so why cripple it?

If I am using the '32U4, how do I implement the chaining connector? The chaining connector should allow multiple breadboard PSUs being connected in parallel and being controlled by one USB connection. Here is the connector spec I am shooting for, using 8-pin dual-row 0.1in headers and 8-pin IDC hooking modules in parallel, and the pinout:

VIN	1	2	VIN
GND	3	4	GND
GND	5	6	GND
COMM1	7	8	COMM2

[Ian.M]

The Leodardo is slightly strange - its SPI interface is only available on the AVR-ISP header and the /SS pin is used for the RX LED.   

For your master/slave board idea, if you extend the ISP header by adding VIN, PB0/SS (RXLED) and PD5 (TXLED) and buffer the two LEDs  you'd have enough I/Os for a SPI daisychain or ring.   Alternatively simply bitbang I2C or any other protocol you like over the standard AVR-ISP pins.  The pullups would plug into a spare socket on the IDC cable.
However I suspect that the market for master/slave USB controlled breadboard PSUs is far smaller than you think and the extra effort to make it possible isn't worth it.

Instead an Arduino I2C PSU shield, that provides up to +/-15V and up to 6V, powered by an external power jack that also feeds the header Vin pin or with limited current capability from the Vin pin, with voltage and current metering and the option to preset it by loading the voltages into it then locking them by moving a jumper to write protect the voltages would be a far more versatile product.   Stack it on the Arduino footprint breadboard interface/PSU board if you need more rails for breadboarding , or use it for any Arduino based project, with or without the I2C active.

[technix]

For your master/slave board idea, if you extend the ISP header by adding VIN, PB0/SS (RXLED) and PD5 (TXLED) and buffer the two LEDs  you'd have enough I/Os for a SPI daisychain or ring.   Alternatively simply bitbang I2C or any other protocol you like over the standard AVR-ISP pins.  The pullups would plug into a spare socket on the IDC cable.
However I suspect that the market for master/slave USB controlled breadboard PSUs is far smaller than you think and the extra effort to make it possible isn't worth it.

I wonder if there can be some I2C or RS485 based solution that would allow the chained modules to negotiate its status on the bus and its address. I would assume that only one USB-connected board exist in the entire chain, and allow the behavior of having multiple USB-connected boards to be undefined.

[Ian.M]

I wonder if there can be some I2C or RS485 based solution that would allow the chained modules to negotiate its status on the bus and its address. I would assume that only one USB-connected board exist in the entire chain, and allow the behavior of having multiple USB-connected boards to be undefined.

Sure, as long as all the boards have a hardware serial number.  You also need a command in your protocol to get a response from an individual board 1 bit at a time so you can do a binary search to find boards present.

You start by sending a broadcast command to ask if any boards with the first bit '0' are present. All boards that meet that criteria ACK the last command byte (probably by sending a BREAK if using RS485).  If none are present, repeat asking if the first bit is '1'.   For any boards present you can move on to discovering the next address bit the same way.   

Finally when you have discovered all the addresses you can issue a broadcast command to each containing the discovered address that each board will match against to allocate the selected board a short-form single byte address to be used for all other commands.

If a board is USB connected, it could still respond to the above protocol.  Allocating a short address would make its USB PSU control interface read only until it was released by the master board or otherwise reset.   The first board you select in your app as would be the master for the others.  Deselect it and it would broadcast a short address release command so another board could become master.

[technix]

I wonder if there can be some I2C or RS485 based solution that would allow the chained modules to negotiate its status on the bus and its address. I would assume that only one USB-connected board exist in the entire chain, and allow the behavior of having multiple USB-connected boards to be undefined.

Sure, as long as all the boards have a hardware serial number.  You also need a command in your protocol to get a response from an individual board 1 bit at a time so you can do a binary search to find boards present.

You start by sending a broadcast command to ask if any boards with the first bit '0' are present. All boards that meet that criteria ACK the last command byte (probably by sending a BREAK if using RS485).  If none are present, repeat asking if the first bit is '1'.   For any boards present you can move on to discovering the next address bit the same way.   

Finally when you have discovered all the addresses you can issue a broadcast command to each containing the discovered address that each board will match against to allocate the selected board a short-form single byte address to be used for all other commands.

If a board is USB connected, it could still respond to the above protocol.  Allocating a short address would make its USB PSU control interface read only until it was released by the master board or otherwise reset.   The first board you select in your app as would be the master for the others.  Deselect it and it would broadcast a short address release command so another board could become master.

I think I2C have a broadcast address too?

I think that bit banged RS485 may be an easier PHY to use here. Maybe I should use a peer to peer protocol so it can handle nodes going online on any order, having nodes joining or leaving at any time, and allowing better multi-uplink behavior.