Xmega Webserver Board [120126]

Originally dedicated as hardware, which can act as master in ElektorBus-applications (instead of a PC or an Android device), this board could be used for many microcontroller-applications, which need a powerful controller, web-access, SD-card storage and/or a display. As far as I know, this is the first Xmega-Board developped for Elektor.Features

Features

ATXmega256A3 with 256K Flash
Alphanumerical display module with LED-backlight and SPI-interface
RS485-driver, screwclamps for ElektorBus
Additional UART-Pins on Mini-DIN-connector (ElektorBus)
Can be equipped with Webserver/client module WIZNET WIZ812MJ
SD-Card socket
4 Buttons, 4 LEDs
PDI-header for in-system-programming
Embedded Extension Connector: 3x ADC, 2 GPIO + SPI/I2C-interface on extension connector, the same pinout than on the Elektor Linux Board
FTDI-Cable and BOB-Pinheader for USB-connection

The circuit and PCB was developped by KöpLe Engineering GbR, Oberasbach, Germany.

Current status
The second revision of the Board is now ready. An article is planned for June 2013.

The board is supported by the Embedded Firmware Library EFL, so there will be software-support for all the features of the Board!

Find more infos and software download at

www.elektor-labs.com/EFL

Discussie (2 opmerking(en))

Günter Gerold 11 jaar geleden

Please route the JTAG PINs to an header!

UPDATE:

JTAG is not necessary. Debugging dont work with PDI and the AVRISP mkII but it works fine with PDI and the JTAGICE3

Antwoord

Toon meer

0 Opmerking(en)

ClemensValens 11 jaar geleden

I was asked to have a look at this project and give my opinion on how to continue with it. Also I am supposed to write software for it. Prototype V1 is a nice effort and appears to be working.

Correct me if I am wrong, but this project is essentially a bridge between Ethernet and RS485, right? If it is, why do you need all these extension connectors? Or is it an ATXmega dev board with Ethernet and RS485? In this case, why do you have such a strange RS485 bus on it? You should make a choice. If it is a dev board then you need lots of accessible connectors. If it is an Ethernet RS485 bridge then you don’t need all this extra stuff and you can really simplify the schematic. If it is just a webserver then you don’t need much more than some sort of extension connector (Elektor Bus?) together with the WIZnet module, the ATXmega & the SD card.

After inspecting one of the first two prototypes, here are my recommendations for a second prototype:

No components on the solder side of the board.
Keep all connectors on one side of the board so that it can slide/mount in a case that needs machining of only the front or rear panel. See photo below.
A webserver should not need an LCD as it is supposed to serve webpages instead. Make the LCD optional on a second PCB so that it can be mounted vertically. Put 4 push-buttons under it instead of next to it so you can easily make a menu. Use LEDs for important status only. Use a serial port for debugging.
Push buttons & LEDs should be vertical and on the same side as the connectors so that they can be accessed through the same front/rear panel.
What are all the power planes for? This is extremely short circuit sensitive, especially around the mounting holes since there is hardly any clearance left. A bold and a nut will create a short between power and gnd. Put ground on the solder side, don’t use power planes and certainly not both on both sides without enough clearance around mounting holes.
No need to debounce push-buttons, you do this in software.
Power supply: your inductors are huge. How much current can they provide? The board is essentially a 3V3 board; the 5V is only needed for the RS485 transceiver. Why not use a 2-in-1 regulator? An Elektor Bus system is 12V, why provide 5V on connectors?
LEDs on power supply are useless. Either the board works or it doesn’t. If it doesn’t, get your multimeter out. If you don’t trust the regulators put 0-ohms resistors in series so you can disconnect them.
Do not provide level shifters to create 5V serial ports. If you want them anyway, use two times the same chip. Keep the BOM simple. JP4 & JP5 are money wasters. In 3V3 position they waste level shifters.
Instead of screw terminals, use clamping terminals for easy (and vibration proof) cabling.
K3, K4 and K9 are inaccessible; they should be rotated 90 degrees. K9 would probably be more useful as a horizontal mount instead of vertical.
Correct footprint of WIZnet module.
Cable shield should connect through a resistor to ground, not through a jumper. If you don’t need the shield, do not connect it. BTW, why is the shield connection on the other extreme of the connector block compared to the RS485 signal lines? What is the signal ground doing here?

If you feel that my comments are too harsh or incorrect, please comment.

connectors.jpg (42kb)

Antwoord

achim 12 jaar geleden

Thanks for the suggestions. Below my comments. • No components on the solder side of the board. 1. The capacitors in the power supply are not longer optimal, but this doesn't affect the Board in this frequency range. It is no problem to bring the components on a page. • Keep all connectors on one side of the board so that it can slide/mount in a case that needs machining of only the front or rear panel. See photo below. 2. With the exception of the display and the screw terminals it should be possible, to bring all connectors on one side (e.g. rear panel) without changing the size of the Board (100 x 100). Display, buttons and LEDs on another side (e.g. front panel). • A webserver should not need an LCD as it is supposed to serve webpages instead. Make the LCD optional on a second PCB so that it can be mounted vertically. Put 4 push-buttons under it instead of next to it so you can easily make a menu. Use LEDs for important status only. Use a serial port for debugging. 3. With housing, it would be my suggestion to better attach the display via a plug connection on a separate circuit board. The display was a request. Debugging is possible through the PDI interface. • Push buttons & LEDs should be vertical and on the same side as the connectors so that they can be accessed through the same front/rear panel. 4. The buttons and LEDs are optional. Are fitted on the prototype and can externally be connected on K7 or see number 2. • What are all the power planes for? This is extremely short circuit sensitive, especially around the mounting holes. Put ground on the solder side, don’t use power planes. 5. Thus the impedance is kept as small as possible. The power plane to the ground plane makes small capacities. In AC-View, relating to interference, there is no difference between ground planes and power planes. Makes no additional cost. Again in this frequency range it doesn't matter. Can be removed if desired. • No need to debounce push-buttons, you do this in software. 6. That's right. We leave it out. • Power supply: your inductors are huge. How much current can they provide? The board is essentially a 3V3 board; the 5V is only needed for the RS485 transceiver. Why not use a 2-in-1 regulator? An Elektor Bus system is 12V, why provide 5V on connectors? 7. The 5V is a requirement, because various Boards can be connected. The power supply provides 500mA. Short term 750mA. We don't know how much power the connected Boards need. The MC34063A is a very cheap way. • LEDs on power supply are useless. Either the board works or it doesn’t. If it doesn’t, get your multimeter out. If you don’t trust the regulators put 0-ohms resistors in series so you can disconnect them. 8. This was a request. • Do not provide level shifters to create 5V serial ports. If you want them anyway, use two times the same chip. Keep the BOM simple. JP4 & JP5 are money wasters. In 3V3 position they waste level shifters. 9. We do not know whether the external boards work with 3, 3V or 5V. Therefore the jumper. One is a 6-channel Levelshifter, because of the mini DIN connector. The FT232 BOB requires only a 4-channel Levelshifter. On request this can replace with a more expensive 6-channel one. With the FT232 BOB, the jumper may be omitted if there is no 3,3V-Version in the future. • Instead of screw terminals, use clamping terminals for easy (and vibration proof) cabling. 10. Screw terminals are available even on the Elektor-Bus-Plane. These have been carried over. • K3, K4 and K9 are inaccessible; they should be rotated 90 degrees. K9 would probably be more useful as a horizontal mount instead of vertical. 11. Yes, why not. • Correct footprint of WIZnet module. 12. It's done. • Cable shield should connect through a resistor to ground, not through a jumper. If you don’t need the shield, do not connect it. BTW, why is the shield connection on the other extreme of the connector block compared to the RS485 signal lines? What is the signal ground doing here? 13. I don't know. This pinout should be carried over.

Antwoord

JN 12 jaar geleden

Clemens, let me answer on the questions and recommendations about the board-features, because most of these features were suggested by our former colleague Antoine Authier and me. The board was originally planned as a master-board for the ElektorBus, which you can use instead of a PC or Android-device. We got many mails from readers that a web-interface for the bus is needed (some readers experimented with other ATmega-Webserver-boards, for example with the Webserver-Board from Ulrich Radig, which is quite popular in Germany). So it was clear that we wanted to integrate a Webserver-interface on the board. Because we made good experiences with the Wiznet-modules, we decided to use a module from that company. It was clear in my mind that we should use the same bus-features on this board than we used for the Android-bridge-PCB Andropod, which has also a section dedicated for the ElektorBus. I want to promote the ElektorBus as some standard for (home)automation projects in Elektor, and I think we made some steps towards this direction by having and planning more and more compatible hardware and software. The ElektorBus is based on 4 wires (12V, GND, RS485 A, RS485 B). A pair of screwclamps for each of these wires makes it easier to wire the board in a daisy-chain-arrangement. Additionally, we integrated the Mini-DIN-connector. You can also find this Mini-DIN-Connector on the Andropod-PCB, connected to RX/TX of the microcontroller. I have plans in my mind that we can have slave devices which are also equipped with this Mini-DIN-connector, maybe multimeter-boards or sensor-boards. One could connect such a slave device to the Andropod/Android-smartphone or this board, as you want. And one can also use the ElektorBus-Protocols in that case. As you know, the protocols are independent from the physical layer. You can use it together with RS485-connections or just TTL-UART-connections. Some of the readers may also use the Board as (ElektorBus-)Development-Board. So I think is a good idea to have those extension connectors. We have a similar connector on the ExperimentalBoard of the ElektorBus, just to have an access to some analog-input-pins and digital input/output-pins of the microcontroller. The ElektorBus-C-library has some functions for reading ADC-values or setting and getting digital values. In the ElektorBus-speech, this interface is called EXTENSION_PORT. Every ElektorBus-Dev-Board should be equipped with such an interface. If you connect a sensor to an ADC-pin of this EXTENSION_PORT, you can use this sensor together with all of these boards. You can even use the same application code, even when the boards are equipped with different controllers. The additional connector with access to SPI-pins of the Xmega was an idea of Antoine. For example, one could connect a RFM12-module to that connector, to have a wireless access. It goes without saying that the board can be used for many other projects beside the ElektorBus. The readers don't have to use the Mini-DIN or the screwclamps. So in my eyes there is no need to "make a choice". The board is very valuable because it can be used for many different applications and projects. And that's the reason we wanted the level-shifters with jumpers to select 3,3V and 5V, too. You don't have to use the web-module either. But even if you use it, the display is a very valuable feature. Please keep in mind that the Wiznet-Module cannot only act as an HTTP-webserver, offering HTML-pages to a browser. But it can be used for sending any other TCP/IP-messages and even UDP-messages. I think it is even better to send small TCP/IP-messages when we want to have a web-access for the ElektorBus. I think a microcontroller is not the best device to store HTML-User-Interfaces. The User-Interface can be stored on the PC or Android-device, where you want to get Internet-access to your bus-system. A webserver offering HTML-pages is a good choice for an easy-to-use embedded device, so the users can easily change configuration settings on the device, without the need to install some software on the PC. But in case of an (home-)automation application, which is fairly individual, this approach may be not the best. I think it is better to have a lightweight connection between the remote-devices. So we better send small TCP/IP-messages instead of delivering the whole HTML-User-interface all the time. I think that Power-supply-LEDs are quite comfortable, but this maybe a matter of taste. You may be right with the Cable-shield-resistor instead of a jumper. If the jumper is really expensive, we can leave it away. We will delete the SIG-GND-screwclamp in the second version of the design, you are right, it makes no sense. The original idea behind that does not work as expected.

Antwoord

Toon meer

1 Bijlage(n) 2 Opmerking(en)