Hey guys,

I played around with my ArduinoMega and NXShield-M today and managed to make it work with a motor and a touch sensor. I had it working with the Magic Wand too but that was just blinking lights stuff, not very exciting.
Anyway, go check it out: http://botbench.com/blog/2012/05/20/rob ... ld-test-1/

- Xander

Very nice Xander.

It appears that all access to the sensor ports on the NXShield are made through I2C calls as well as setting speed/direction of the motors. Is that correct?

I wonder if all the ports are on the same I2C bus. If so... there would be a problem if you tried accessing the motors and the sensors from two separate RobotC tasks, right?

Say your main task set the speed & direction of the motors, and another task was constantly reading from sensors. Both tasks running at the same time would end up "doubling" the clock signals on the bus. Also both tasks would be attempting to write/read from the SDA line at the same time.

The only way around this problem would be to make all I2C calls on the same task... OR somehow make the I2C calls "thread safe" (or in RobotC terminology "task safe").

Is what I am asking making sense?

Dennis,

The shield is made up of two sub devices called banks. Each bank has 2 sensor ports and 2 motor ports. Each bank has its own I2C address, which is accessible through the hardware I2C pins (20/21, IIRC). ROBOTC does not support HW I2C yet but I am sure it's on the road map.
Anyway, you can access each sensor port separately via its own pins when using them as digital sensors, or read them as analogue sensor via that specific bank's I2C registers. When accessing the sensors through I2C, you'll need to bit bang it because there's only pins 20/21 that are hardware "accelerated".
You can only control one bank at a time through I2C since they use the same pins. Normally on a standard Arduino that is not a problem because it's so fast. When bit banging I2C it may pose a bit of an issue. Since this was just an experiment, I didn't really care.
In any case, multitasking is a no no if you're going to do any kind of function sharing anyway, so it's best to have a single task handle all the bank stuff.

- Xander

Ok. I only mention this because normally one doesn't think about setting motors and reading sensors as possibly conflicting with each other.

The motors can be given commands such as "move this many encoder ticks", "run for X seconds" or "brake when done". So there is not a whole lot you need from the motors. Unless you're keen to continuously poll the motor encoders, there's not a whole lot you need to talk to the motors about
Maybe when I understand the internals of the NXShield a bit better, I will write a tutorial on how to use it. It's not an overly complicated device when using it normally but it does have a lot of parameters that you can tweak to get it setup just the way you want it, especially when it comes to the motor's PID stuff.

Right now I am really just biding my time until HW I2C is implemented.

- Xander

Awesome. Wish I could afford that stuff.

I wouldn't be able to afford it if I had to buy that stuff. I am lucky that certain companies see fit to let me play with their products.

- Xander

Would this work (and how much effort if you know) with one of the .net adruino clones? I started to look at putting the .net framework on the NXT, which I understand is doable, but has 0 left over for user space. So, wanting to stick with NXT accessories, I am now thinking http://www.sparkfun.com/products/10749 with something like the NXTShield (http://www.openelectrons.com/index.php? ... &PAGE_id=7). Question is how much works out of the box if anyone knows?

Spiked3,

The most important thing is the pinout, if they're roughly equal where it matters then it would most likely work. It would be a very nice platform, I think. I'm a big fan of C#.

- Xander

I will probably try it soon. Not to take away any from RobotC, it is absolutely my preferred NXT environment so far, but I did really enjoy one small .Net MF project I did a while back. The IDE, the debugger, mature Object Oriented Language, it's just hard to beat.

Just had a quick look and it looks like the FEZ has its I2C pins on a totally different spot than the Arduino UNO, so that may be a problem.
The pins marked as red on the UNO image are the ones actually used as HW I2C to communicate with the NXShield.



You could work-around it using your own bit banged master code as a piece of unmanaged native code that you load as a library.

- Xander

sigh. So much for 'compatible'. thanks for looking.

Well it looks like pins 2 and 3 on the Fez would need to be reassigned to the analog pins 4 & 5 on the NXShield. Normally you could use a Go Between shield from Mayhew Labs ($14) which allows reassigning pins (very useful). In this case it would be a little more difficult to do since the pins are going from the Digital to Analog side. The Go Between is made for mapping one digital pin to another digital pin or one analog to another analog.

You could take a simple proto shield and clip the 4 & 5 pins on it and run wires from 2 & 3 pin over. In the end that is how most people end up reassigning pins and it works though it would make your device a bit larger.