Main Site Documentation

Digital Port 0 in Cerbuino NET


#1

Hello,

I made a program that reads data from a DHT22 sensor, it is using the Digital Port 6 and everything works great… I wanted to use something else on Port #6 so I moved my wire to Digital 0 and it failed!.

The program has not changed (other than changing the port number) but I cannot seem to get it working on port 0… so… I decided to test other ports… and the program works in all digital ports except 0.

Any ideas why would not work on that port?.. I could not find any information about restrictions on that port. (only alternative usage)

I am using Cerbuino NET version 1.0 with Net 4.3

This is the code I use to identify port 0:

public static class FEZCerbuino
{
    public class Pin
    {
        public class Digital
        {
         // removed other ports...

            public const Cpu.Pin D0 = GHI.Hardware.FEZCerb.Pin.PB11;

            // removed other ports...
        }
    }
}

namespace GHI.Hardware.FEZCerb
{
    public class Pin
    {
        // removed other ports...
      
        public const Cpu.Pin PB11 = (Cpu.Pin)((1 * 16) + 11);

      // removed other ports...
    }
}

I can post the code I am using to read data from DHT22, but I do not think it would help… since it works on other ports except D0.

I thought the problem was that I was using RLP, but I tried other library that uses managed code and I got the same results.

Any help would be appreciate it.
Thanks,


#2

hi Dulfie,

D0 is used as the reset line to the Ethernet module, and is pulled up to VCC by a 10k resistor. This means the device has to specifically drive the pin low which obviously messes with the readings coming from your DHT22. You’ll need to use a different pin.


#3

@ Brett -

That explains it… but… I just checked the schematics and seems like PB10 is connected to RESET and using that 10K resistor… PB11 is connected to WOL which does not have one.

Do I have the incorrect PIN layout?

I got them from:

https://www.ghielectronics.com/docs/45/developersguide-fez-cerbuino-bee

and the Cerberus pins I got them from the source code (because I could not find them in Net 4.3)

My background is software, not hardware… so I might be reading the schematics incorrectly :slight_smile:

Thanks.


#4

Ok, you passed that very deliberate test there, well done ! :slight_smile:

OK, I am joking. I in no way deliberately got that wrong - you’re absolutely right, I got my UART dyslexia ( see https://www.sparkfun.com/products/449 ) wrong from a schematic ! I read UART3_TX and saw RX !!! :slight_smile:

So, in summary,
D0 = PB11/I2C2_SDA/UART3_RX
D1 = PB10/I2C2_SCL/SPI2_SCK/UART3_TX

D0 / PB11 is also connected to WOL# on the Ethernet module.
D1 / PB10 is also connected to RST# on the Ethernet module. It is also pulled up via 10k resistor.

So now I have no idea. Where did you get the DHT22 driver from again?


#5

PB11 is indeed connected to Pin 5 (WOL#) on the ENC28J60

Now interesting the datasheet has Pin 5 as NC with the following note…

Reserved pin; always leave disconnected

So i would be picking that is causing a tear in the space time continuum…


#6

I passed!!!.. I passed!!! :slight_smile:

I took the Arduino Library from Virtualbotix:

https://www.virtuabotix.com/product/virtuabotix-dht22-temperature-humidity-sensor-arduino-microcontroller-circuits/

Changed it and made it RLP… the code:

#define CERB_FAMILY

 #include "../RLP.h"

 #define OUTPUT 1
 #define INPUT 0

void pinMode(unsigned int pin, unsigned int modeType) {
	if (modeType == OUTPUT) {
		RLP->GPIO.EnableOutputMode(pin, RLP_FALSE);
	}
	else {
		RLP->GPIO.EnableInputMode(pin, RLP_GPIO_RESISTOR_DISABLED);
	}
}

void digitalWrite(unsigned int pin, unsigned int value) {
	RLP->GPIO.Writepin(pin, value);
}

void delay(unsigned int milliSeconds) {
	RLP->Delay(milliSeconds * 1000);
}

void delayMicroseconds(unsigned int microSeconds) {
	RLP->Delay(microSeconds);
}

unsigned int digitalRead(unsigned int pin) {
	return RLP->GPIO.Readpin(pin);
}

unsigned int word(unsigned char grpixh, unsigned char grpixl) {
	unsigned int grpix = grpixh;
	grpix <<= 8;
	grpix += grpixl;
	return grpix;
}

int DHT22_Read(void** args) {
	unsigned int pin = *(unsigned int*)(args[0]);
	float* output = (float *)(args[1]);	// array of floats [temperature in celsius | humidity]
	
	output[0] = 0;
	output[1] = 0;
	
	
	// --------------
	// BUFFER TO RECEIVE
	unsigned char bits[5];
	unsigned int cnt = 7;
	unsigned int idx = 0;
	int i;

	// EMPTY BUFFER
	for (i=0; i< 5; i++) bits[i] = 0;

	// REQUEST SAMPLE
	pinMode(pin, OUTPUT);
	digitalWrite(pin, RLP_FALSE);
	delay(18);
	digitalWrite(pin, RLP_TRUE);
	delayMicroseconds(40);
	pinMode(pin, INPUT);

	// ACKNOWLEDGE or TIMEOUT
	unsigned int loopCnt = 10000;
	while(digitalRead(pin) == RLP_FALSE)
		if (loopCnt-- == 0) return -2;

	loopCnt = 10000;
	while(digitalRead(pin) == RLP_TRUE)
		if (loopCnt-- == 0) return -2;

	// READ OUTPUT - 40 BITS => 5 BYTES or TIMEOUT
	for (i=0; i<40; i++)
	{
		loopCnt = 10000;
		while(digitalRead(pin) == RLP_FALSE)
			if (loopCnt-- == 0) return -2;
				
		// Wait at least 28 uS, 40 to be safe
		delayMicroseconds(40);
		
		// If the value still TRUE, it means 1, otherwise it is 0
		if (digitalRead(pin) == RLP_TRUE) {
			bits[idx] |= (1 << cnt);
			
			loopCnt = 10000;
			while(digitalRead(pin) == RLP_TRUE)
				if (loopCnt-- == 0) return -2;
		}

		if (cnt == 0)   // next byte?
		{
			cnt = 7;    // restart at MSB
			idx++;      // next byte!
		}
		else cnt--;
	}

	// WRITE TO RIGHT VARS
	output[1]    = word(bits[0], bits[1]) *.1;//calculates and stores the humidity

	unsigned int sign = 1;
	if (bits[2] & 0x80) // negative temperature
	{
			bits[2] = bits[2] & 0x7F;//negative temp adjustments
			sign = -1;
	}
	output[0] = sign * word(bits[2], bits[3]) * 0.1;//temp calculation and storage

	unsigned char sum = bits[0] + bits[1] + bits[2] + bits[3];//sum values

	if (bits[4] != sum) return -1;//failed checksum
	return 0;//great success!		
}

I also tested the managed code library posted on:

The RLP version works 99.9% of the time and the managed code around 97% of the time (if no other stuff is working on that moment)

Both of them “work” on other ports… so I have no idea what I am doing wrong… I am starting to think I broke my Cerbuino NET… unfortunately I do not have another one, so I am not sure.

I should be getting a Cerbuino Bee in a week, so I will test it there.

Thanks!


#7

@ Bill Gates -

[quote]Now interesting the datasheet has Pin 5 as NC with the following note…

Reserved pin; always leave disconnected
[/quote]

I guess I should have read that!

Where did you find that datasheet?.. I could not find it… I starting to think I do not know how to “search”! :wall:

THANK YOU!


#8

https://www.ghielectronics.com/community/codeshare/search?q=dht22

Just sayin’


#9

@ Brett -

Yeah… I saw them… but the RLP version did not work after upgrading to 4.3 and I already had a Managed Version working on a Netduino ([em]cough[/em])… so I did not want to test new code.(lazy me!)

Also… it gave me an opportunity to learn/do something about RLP! ;D

I found really great code on Codeshare that gave me a lot of information about NETMF. (I just starting with it a month ago.)

Thanks for you help and time!


#10

@ dulfe - I just looked at the Cerb schematic then had a hunch and read the ENC datasheet off Mouser…


#11

@ Bill Gates -

That explains why I could not find it.

Thank you!


#12

so, what that really means Bill is that we should electrically check the circuit board to confirm the D0 pin is connected to the ENC or not, and to the STM chip? Anyone with a cerbuino net and a multimeter ?


#13

@ Brett -

It is to both… just like the schematics indicate.

The network controller must be messing with the reading somehow (like Bill said).

I guess I would not have that issue with the Cerbuino Bee that I am getting soon.