Awesome! 

Your mention that, at work, that you find that "the DNS entry is my home router, not my work DNS" is interesting.  What do you mean by that?  There's not a power-cycle-to-power-cycle persistent storage of a dynamically assigned dns name.

 

DNS server(s) appears to be up to two IP addresses.  Took my Netduino to work, and while it was using DHCP and the IP showed up in the proper 192.168.x.x range, it kept my home DNS in the 10.x.y.z. range.   I had been switching between static and dynamic IPs, and/or lost my network settings a few times too.  But I don't remember changing to static DNS.  The "fix" to call EnableDynamicDns() was unexpected.

 

Now everything is working fine.

More news.

 

I called net.EnableDynamicDns() [font="arial, helvetica, sans-serif;"]and now DNS is working again, including requesting and receiving DNS servers during DHCP.  My Netduino was recently reset and I had to reset the MAC address.  Not sure why the default would be to not ask for DNS servers in this state.[/font]

 

[font="arial, helvetica, sans-serif;"]So the original complaint is not complete, but there is something not quite right here that I have to call EnableDynamicDns() from this state.  This is not expected.[/font]

 

My Netduino Plus 2 (v4.2.2.2 Jan 26 2013) is working at home with networking, then I bring it to work today and network time protocol requests are failing.  I do some digging, and the DNS entry is my home router, not my work DNS.  DHCP is enabled, and the other parameters are okay (IP, subnet, router, etc.)

 

So I used WireShark to capture the relevant DHCP packets.  Netduino should be requesting DNS options but is not.  The BOOTP option 55 only includes Subnet Mask, Router, and Broadcast Address.  It should also include DNS as a requested parameter.  The DHCP server at home supplies the DNS entry anyways, but the DHCP server at work appears to be strictly complying with the parameter request and doesn't supply the DNS entry if not requested.

 

Option: (55) Parameter Request List Length: 3 Parameter Request List Item: (1) Subnet Mask Parameter Request List Item: (3) Router Parameter Request List Item: (28) Broadcast Address

 

There should be at least one more item included:

  Parameter Request List Item: (6) Domain Name Server

 

Relevant packet dump from work is attached.

Ah, the device supports both SPI and I2C.  Yeah, stick with SPI when you can get it to work.

 

I got confused when you called pin 5 of the Parallax module SDA.  That's for I2C.  The SPI function of that pin is SDI.

 

Sorry I don't have the module myself to try.  Hopefully another user can help.

 

Good luck!

You may have SPI and I2C confused. SDA and SCL are I2C connections, and there are dedicated (and mirrored) connections on the shield base.  You may also need 3V pull ups (e.g. 2.2k or similar) for SDA and SCL to work correctly.

 

And use the I2C APIs instead of the SPI APIs.

I have thought about the W5200. I has an integrated TCP/IP stack, so you really don't need a software TCP/IP stack. I think you are absolutely right that it would have been easier to code for, but it would likely be less flexible. But, with support for 8 simultaneous sockets, it's probably good for embedded class devices.

-Valkyrie-MT

Both the W5100 and W5200 have a MAC-Raw (MACRAW) mode that can be used from socket 0. It should be possible to ignore the WizNET TCP/IP stack, and port the managed stack from ENC28J60 to these chipsets as well. The possible advantage is bypassing the WizNET 4 or 8 simultaneous sockets restrictions, and building a driver that could support multiple Ethernet chipsets to support the majority of Arduino Ethernet shields. There may be performance issues, but the variety of compatibility would be very interesting.

The ZIF socket you are referring to has 0.7" pitch on both ends, so it helps with not having to solder the chip down (just the socket), but does not adapt to a standard size.

If you want to socket for the adapter you are building here is a cheaper one that may work.

There's also images on the web of bending every other pin when all you've got is standard 0.1" spaced perfboard or solder board.


Someone's blog entry in Japanese, or translated to English

I'd be too worried of breaking a pin off though.

Solution found for the STM8 SDIP chips. These breakout boards from SchmartBoard model # 201-0001-01 for $5 each do the trick. These boards are 0.1" spacing rows, but interleaved at 0.05". Sorry, they look like they are on backorder from the manufacturer, but you can probably find them in stock at your favorite electronics distributor, Fry's Electronics, etc. This board costs more than the chip, but when you've gotta have it now, it works, and is cleaner looking than dead bugging it.

If you use Pythagorean theorem on a right triangle with 0.05" sides, the hypotenuse has a side of 0.07071" which is close enough for our use (targetting 0.07"). From the first pin to the 16th pin, that's only off by about 0.01" total which is smaller than the size of a hole.




p.s. Each five consecutive pins in a row are connected, but due to the shape of the STM8 SDIP it appears that none of the cpus pins get shorted together.

Hint: when troubleshooting i2c it can be useful to put the transactional code into a loop, with a delay between iterations, so you can tweak your circuit to see if you get different results And update 2 works for me talking to Microchip 24FC1025 jumpered directly to SCL/SDA. Both running in debugger, and running standalone (USB removed, supplying external 5V power) outputing results to SerialPort.

Finally got the attachment

(nothing to see here, move along to the next reply)

Something subtle must be wrong for your DS1307 not to work on the NP2 while mine does. Try this attached project and compare the output to mine.

[Build]
------ Deploy started: Project: DS1307, Configuration: Debug Any CPU ------
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

[Micro Framework Device Deployment]
Incrementally deploying assemblies to device
Deploying assemblies for a total size of 1112 bytes
Assemblies successfully deployed to device.

[Debug]
Create TS.

 Loading start at 806a240, end 8085f7c

Assembly: mscorlib (4.2.0.0)

Assembly: Microsoft.SPOT.Native (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware (4.2.0.0)

Assembly: Microsoft.SPOT.Net (4.2.0.0)

Assembly: System (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0)

Assembly: Microsoft.SPOT.IO (4.2.0.0)

Assembly: System.IO (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)

Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0)

Assembly: SecretLabs.NETMF.Diagnostics (4.2.0.0)

Assembly: SecretLabs.NETMF.Hardware.Netduino (4.2.1.0)

Assembly: Microsoft.SPOT.Hardware.OneWire (4.2.0.0)

Assembly: Microsoft.SPOT.Time (4.2.0.0)

Loading Deployment Assemblies.

Attaching deployed file.

Assembly: DS1307 (1.0.0.0)

Resolving.

The debugging target runtime is loading the application assemblies and starting execution.
Ready.

I2C transacted 9 bytes
I2C transacted 9 bytes
55 59 23 06 30 11 12 00 
I2C transacted 9 bytes
56 59 23 06 30 11 12 00 
I2C transacted 9 bytes
57 59 23 06 30 11 12 00 
I2C transacted 9 bytes
58 59 23 06 30 11 12 00 
I2C transacted 9 bytes
59 59 23 06 30 11 12 00 
I2C transacted 9 bytes
00 00 00 07 01 12 12 00 
I2C transacted 9 bytes
01 00 00 07 01 12 12 00 

p.s. I'm seeing the Microsoft.SPOT.Hardware.Battery.ChargerModel in QuickWatch too for the I2CDevice. That's weird.

I played around with this a bit. Very useful code. I was able to get a few things up and running just for testing purposes. A few of the sensors I have don't seem to work with the Software solution. I didn't spend much time on it because it would be a major rewrite to get some of my code working. It still proved useful to get the DS1307 running in order to continue prototyping a portion of my project.

Thank you for contributing this.

Good to hear the feedback. And I'm lucky to be leveraging someone else's underlying software I2C driver so I can blame them for anything that didn't work :-)

As for the DS1307, I was able to wire a bare DS1307 PDIP-8 package, 32.768kHz crystal, plus 3.3K pull-up resistors, ground VBAT as not used, leaving SQW/OUT unwired, then wired directly to the Plus 2 using the SC/SD pins, and successfully communicated to it using the hardware solution (using NP2 Update 1 of course). I set the time at the top of my program, and on a loop see the time advance.

Have you been able to get the DS1307 to work using the hardware solution? Or are you using the software solution so you can use different pins?

Dave VanderWekke & egeorgiou

Please replace the Execute line in your code with the following to see how many total data bytes (reads and writes, not counting device addresses) have been sent in your transactions. This can help diagnose if the device is responding at all. The result should be the total number of bytes sent and received. Subtract the bytes sent (one in your case) and that's the total number of bytes received. If you haven't received any bytes, then probably don't print the read buffer contents.

int total = adxl345.Execute(actions, 1000);
Debug.Print(total + " bytes transferred successfully over I2C");

I have had success with DS1307 and 24FC1025 over both hardware and software I2C protocols with the Netduino Plus 2. Wishing you success soon too.

One more thing... it looks (according to SparkFun) like the 9 degrees of freedom stick can accept a variety of input voltages 3.3V-16V, while the ADXL345 breakout boards can only go up to 3.6V. I would only run a simple ADXL345 breakout at 3.3V, but as for that bigger board with more chips you may want to try an external power source or at least the 5V input instead. Or at least verify the current requirements. Just some thoughts to try to cover all the bases. And be careful with applying the right voltages.

Lol! I see Chris posted an I2C fix 25 minutes earlier than my workaround.

I am looking forward to trying out the fix, and will probably keep using the workaround to avoid jumpering SCL/SDA until the official Secret Labs mirroring I2C solution is available.

Hi guys! I posted a workaround for I2C issues as a new topic.

davervw

This SoftwareI2CBus class can be used to help workaround Netduino Plus 2 I2C problems.

I was able to successfully read from my I2C EEPROM. Another advantage is that you can choose to use different pins too.

(Note this leverages a software I2C driver written by our peers over at tinyclr and GHI. Note that a portion must be downloaded from the tinyclr site (link will show when you try to compile). The value I added was to replace the custom APIs with ones more compatible with the standard I2C APIs. Known issue: read/write timeouts are either fixed or otherwise ignored.)

Good luck guys! The Netduino Plus 2 is a great platform, and hopefully this can help one or two folks that hit the early defects in I2C.

Usage comparison between hardware and software I2C:

#define I2C_SOFTWARE
#if I2C_SOFTWARE
            SoftwareI2CBus i2cbus = new SoftwareI2CBus(Pins.GPIO_PIN_A5, Pins.GPIO_PIN_A4);
            SoftwareI2CBus.I2CDevice i2c = i2cbus.CreateI2CDevice(new I2CDevice.Configuration(0x50, 400));
#endif
#if I2C_HARDWARE
            I2CDevice i2c = new I2CDevice(new I2CDevice.Configuration(0x50, 400));
#endif

Receiving 7-bit or 8-bit RS-485 at a supported baud rate is pretty straightforward. Just wire up a MAX485 or similar to be always receiving, with the data out wired to D0 (Netduino's RX) for receiving as serial input. Then code up your stuff on the Netduino using a SerialPort object that is looking for available data. If you are just receiving, and the data format is known this should be simple.

If you need to send data back, that is more tricky, because you need to activate the transmission, but release it soon enough to be listening again. If the protocol is straight forward and only 7-bit or 8-bit, you may be able to use a standard RS-485 shield designed for Arduino.

Jack, recheck your TTL connection including power. I was able to flash my mini using both the RS232 and TTL versions of TinyBooterDecompressor successfully with SAM-BA v2.11, and then after powering off/on successfully pinged using MFDeploy and deployed ER_CONFIG, ER_FLASH successfully. The COM connections for MFDeploy changed accordingly. I am using a FTDI TTL223R 5V cable (USB to TTL), and a FTDI <-> Serial adapter (USB to 232) for the two connections.

Used the RS232 tinybooter and MFDeploy to flash the TTL firmware. Can't ping it, can't get device config, can't program it.

Reflashed with RS232 versions of everything. Works perfectly.

Any ideas?