Daughter card proposal

[gbulmer]

[Folknology]

@gbulmer your Interesting idea of using a µc to make interfacing more simple has some complications. The most obvious one is that you have to program it and need the tools and interfaces to do that, This in many ways makes it more complex than Ziports especially if need to add JTAG as well as the toolchains etc. It did however make me think that you could add a popular mini Arduino (atmega328 or some such) on a board and just add a couple of fet level shifters to the Power PEC Uart Rx/Tx. That won't need any JTAGs and can just use a boot Arduino boot loader for instance. Clearly an Arm Arduino version would be better if you can find a suitable one as you can reuse the on board ARM toochain, maybe the STM32 series (Maple like) as they do have serial bootloader (and Arduino) support I believe.

regards
Al

[gbulmer]

[gbulmer]

I simplified the MCU interface too much in my previous post.

An AVR needs more than SPI MOSI, MISO and Clock for upload, it also needs Reset.
An STM32 needs more than UART Rx and Tx for upload, it also needs Reset and, at least BOOT0, to select between the manufactured-in System ROM bootloader, and booting from Flash. Ideally BOOT1 control would be available to select booting from RAM.

So, SPI, UART, at least 2 "GPIO" and power would be enough for a range of MCU managed daughterboards. Those interfaces would be sufficient for both programming and communications with the MCU. The two GPIO do not have high performance requirements, they would be toggling Reset and BOOT, so they could be provided by an I2C mechanism, but in the interest of simplicity, could be GPIO. Having all of those signals available on a single socket would reduce the part-cost of MCU-managed daughterboards.

[gbulmer]

Here's an interesting graph, comparing the .

I think the difference is significant enough, and the spread for Linux broad enough, to explain why I like MCU managed daughterboards. However, the article says that graph shows one of the two Zinq A9's running Linux, and the other an RTOS. I'd have to think about that approach, though it still feels like the bigger issue is easily adding the large range of peripherals via MCUs, rather than response time jitter.

[jnaujok]

I know it's been a while since I was doing embedded work, but to me, at least, this seems over-engineered. While I understand the desire for extreme low-latency, I'm wondering if a simple 8 pin connector, and a commodity gigabit ethernet chip wouldn't be a better solution. Using ethernet, each card has a unique MAC address, and there's no reason a simple TCP/IP and DHCP stack couldn't be coded onto a standard chip (which I'm pretty sure exists on silicon already) which would give you auto-assignment, and easy communication on your own private little internet inside the tab stack. Since ethernet and TCP/IP are all commodity items, it would be easy to implement, and and the latency on a gigabit ethernet would be low enough for almost all cases, as well as providing a big pipe for data transfer when needed.

As I said, it has been a long time since I was doing embedded code, but it just seems a simpler solution than the (admittedly creative) zip-tab connector.

Jeff Naujok

[tschaboo]

I love Al's Ziport concept and gbulmer's ideas.

I'm exactly one of those people gbulmer has in mind: played around with microcontrollers and low speed peripherals (temperature and humidity sensors, RS485...) but I don't know enough about electronics to feel comfortable with high speed signals or other advanced stuff.

The perfect daughter card for me would look like that:
1.) There are 6 wires reserved on the opposite side of the first Ziport: SCLK, MOSI, MISO, 3xSS. Those are passed through the daughter boards without shifting.
2.) The daughter card lets me select which of the three SS I want to assign (jumper, solder-bridge, DIP switch, whatever).
3.) Right after the input and selector there is a level shifter which brings the SPI signals to 3.3V or 5V. (Would an optocoupler be slow? expensive? bad idea for another reason?)
4.) This is fed into an ATmega (can operate from 1.8V to 5V).
5.) The outputs of the ATmega go to the 0.1" headers.

There would be one "factory" preloaded firmware which transforms this card into an I/O card. I could certainly help with this firmware. Anyone else can grab a programmer (search for USBasp at eBay.com -> those are 7 USD including worldwide shipping) and do all the stuff gbulmer mentioned.

Actually the perfect board would also have
6.) 1-3 RC filters for ultra cheap and slow DAC (since the Atmels unfortunately miss those).

The ATmega probably costs the same as a single deserializer and you would have a board which could be made Arduino compatible, except for the form factor and the expensive USB port. ADCs, PWM, I2C, UART, everything there - for free!

As far as I understood the discussion, Al has two major concerns regarding gbulmer's proposal:
(a) giving up valuable high-speed "wires"
(b) added complexity when using a uC on the I/O board.

IMHO (a) is not really a problem: Having the 6 (or maybe even 8) wires there will be the default. If someone really wants to use all as Ziports you just need another configuration for the PL. Only if one specific card uses more than ~21 LVDS pairs, the card needs to violate the specification. Which doesn't matter, because then this would be the only card anyway.

Regarding (b): I think it's worth the trouble. And it would be feasible if there is only one default firmware.

I also think that an I/O card would need level shifters anyway. The advantage of my proposal is, that there are only unidirectional level shifters on the few SPI signals and everything else operates at the desired voltage. Most ATmegas can operate from 1.8V to 5.0V.

Many people use an Arduino connected to a PC for real-world connection. With this card you could have the Arduino including a dual core PC plus an Epiphany accelerator all in one (tiny) piece - smaller than an Arduino UNO!

[hmiranda]

Hi,

I was thinking if there we can plug two optional cards. (one redundant power supply unit + -48V ) Unit (communications or Firewall use this kind of connectors usually ).
And Ethernet connector (G Ethernet ) in order to build a firewall with this main board.

As a firewall use no so much memory this build can fit with no problem.

Please, let me know it that is possible.

Other alternative for this board is build in a Daughter card with GPS, accelerometer (detect collisions ) and Bluetooth to connect with other devices in the car or bus. (currently some models for cars come with the connector to talk to the engine ) so how the driver use the car can be recorded and store in the memory card (if the bus is going in a road without cellular signal ).

This two applications I think can go viral.