Blogue de Guillaume DALLAIRE's Blog

Cette semaine j’ai changé d’ordinateur portable pour un Dell Studio XPS 1340 (écran 13″ (bon ratio portabilité/ergonomie d’utilisation), Core 2 Duo 2.53GHz, 4GB DDR3 RAM, HD@7.2k RPM) : Voici un extrait de dmidecode:

System Information
        Manufacturer: Dell Inc.
        Product Name: Studio XPS 1340
        Version: A07

Je voulais plus de puissance pour rouler des machines virtuelles avec KVM. J’avais un netbook MSI U100 qui allait très bien mais qui était trop démuni pour supporter la virtualisation.

Nul besoin de dire que je n’ai même pas essayé cet ordinateur avec l’OS déjà installé par défaut (Vista) : Je l’ai soulagé en installant la dernière d’Ubuntu en version 64 bits.

Ce fût un succès, tous ses composants sont bien supportés (carte wifi, carte graphique Nvidia en mode deux écrans (dual head), et le reste sauf la caméra que je n’ai pas testée. Ce succès n’est pas une surprise car Dell offre ou a offert dans le passé ce modèle pré-installé avec Ubuntu.

Le seul défaut que je lui reproche est qu’il est un peu chaud après quelques minutes de fonctionnement (c’est légèrement désagréable quand on utilise son clavier, les mains sont appuyées sur le boitier et on sent la chaleur). Peut-être qu’il faudrait que je fasse quelques ajustements sous Linux pour qu’il limite les accès au disque ou autres choses qui génèrent trop d’activités. Apparemment je ne suis pas le seul avec ce problème.

Autrement tout va bien, je peux rouler une VM Windows 7 en faisant pleins d’autres choses (Eclipse, Open Office, etc….) sans problème et l’expérience est “agréable”.

En terminant, voici le résultat de la commande lspci:

00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b2)
00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1)
00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1)
00:0a.0 Ethernet controller: nVidia Corporation MCP79 Ethernet (rev b1)
00:0b.0 SATA controller: nVidia Corporation MCP79 AHCI Controller (rev b1)
00:0c.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:10.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:16.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:17.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:18.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
01:07.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
01:07.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
01:07.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
01:07.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
01:07.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)
02:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 9200M GS] (rev a1)
03:00.0 VGA compatible controller: nVidia Corporation C79 [GeForce 9400M G] (rev b1)
06:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01)

Recently I started wondering about the fact that most of my MCU based projects use a RS232 serial port to exchange data between my “base” computer and every modules. Since the number of serial ports is limited (normally 2) on a normal PC, this is a problem.

After some reading, I decided to try a RS485 bus: A multipoint serial communication channel that would be both simple and cheap to implement inside my projects. The first thing to do is to test this technology by prototyping a half-duplex RS485 bus with some Arduino MCU.

75176 RS485 Transceiver pinout

Let’s find a transceiver. Two chips seem to be commonly used : The MAX485 (or DS485, the Nationnal Semiconductor equivalent) and the SN75176BP. See this Maxim comparision page. I choose the SN75176BP, only 0.71$CAD.

Connection between the Arduino and the 75176

Each MCU has its own 75176 connected to the UART (RO and DI). The RE and DE pins are connected together to a digital output allowing the MCU to control the “direction” of the data flow with the bus. When this line is LOW, the transceiver is in “receiving” mode. At a HIGH level, the transceiver switch to the “sending” mode.

Note that the RE/DE pins can be connected to any MCU’s digital output.

The RS485’s topology is multipoint. This means that every node in the network shares the same media, then without collision avoidance mechanism (which is relatively complex to implement), only one node can be defined as a master. The master sends commands or data and zero or more slaves respond to the master (It’s an important limitation).

I built my prototype around 1 master and 3 slaves:

My bench

The blue and white wires are the RS485 physical bus. Slave #1 has 2 sensors (barometric and RH), slave #2 and #3 are simple LED display. The master reads the sensors by sending slave’s #1 address, this slave sends the values (current RH+pressure), the master reads it and finally, it sets the displays by calling each slave’s (#2 and #3) address with the data to show. The RS485 transmit function looks like this:

void rs485TxMsg(char *msg)
{
  Serial.flush();
  digitalWrite(txPin, HIGH);
  delay(10);
  Serial.println(msg);
  delay(10);
  digitalWrite(txPin, LOW);
}

The read function :

void rs485RxMsg(char *msg, byte msgLen)
{
  byte i = 0;
  char val;
  msg[0] = 0;
  while(Serial.available())
  {
    val = Serial.read();
    if (val == '\r')
      msg[i++] = 0;
    if (val == '\n')
    {
      msg[i++] = 0;
      return;
    }
    msg[i++] = val;
    if (i>msgLen)
      return;
  }
}

The “message” separator are the “\r\n” characters. A more elaborate format would be needed in production and CRC checking (or equivalent) would be also a good thing.

For now I succesfully got a working system very easily. RS485 is simple and cheap to implement for a MCU based system.