Genuino 101 compatibility troubles with ATmega code

Hardware Arduino 101
1

Hi to everybody,

I have some compatibility problems using code that is working fine with Mega or UNO, but not with 101.

For example, I want to generate MD5 hashes using the example sketches of this library: GitHub - spaniakos/ArduinoMD5: MD5 and HMAC library for Arduino and Raspberry pi. Well, with Mega no problems, the expected result is correct, but with 101 the generated hash is wrong.

I have similar problems with my own custom library that generates an hex string and writes it on serial port. It works fine in Mega, but with 101 the output is completely different (and wrong).

I think that the problem is related to the MCU archs (ATmega vs. Intel Curie).

Did anybody experiment the same issues? Did you know any workaround, different from porting tons of code?

Thanks a lot,

luigi

2

Just in case, try replacing the library with this one:

spaniakos forked the tzikis repository to add support for Raspberry Pi. I don't think any of the code they added will be helpful for use with the 101 and there's a chance some of the changes are the source of your problem.

3

Thanks for your reply.

I tried to replace with the lib you suggested but the result is always the same: the output is wrong with 101 and right with Mega.

Consider that MD5 is just an example: the core issue is the compatibility of the code between Mega and 101 and I don't know how to resolve it.

Do you have any suggestion?

4

Often these sorts of problems are caused when the code uses register names that are specific to a certain architecture. However, the ArduinoMD5 library doesn't do anything like that. So in this case I'm suspicious of another difference between the AVR and the Curie: 8 bit vs 32 bit. I know for a fact that there is at least one line of code in the library that will work differently but I don't understand the code well enough to say whether this difference matters. When I compile the MD5_Hash example for Mega I get the following warning (I have warning level set to "All" in the Arduino IDE):

E:\arduino\libraries\ArduinoMD5-master\MD5.cpp: In static member function 'static void MD5::MD5Update(void*, const void*, size_t)':

E:\arduino\libraries\ArduinoMD5-master\MD5.cpp:204:21: warning: right shift count >= width of type

  ctx->hi += size >> 29;

This is because the type of size is size_t, which is 16 bits on AVRs but I believe it's 32 bits on the 101.

This concerns me because I have a library that uses the ArduinoMD5 library and I've just been doing some work on it to make it compatible with 101, Zero, Due, etc. but I don't own any of those boards to actually test it out beyond making sure that it compiles.

5

Hi Pert,

you're right: sizeof(size_t) give me the following results:

  • in Mega: 2 bytes
  • in 101: 4 bytes

so, the problem could be related to this.

What was the solution you adopted? Anyway, if you want I can test your code on my two boards.
Thanks for the support,

Luigi

6

I didn't adopt any solution. I looked at the code because I wanted to fix that error when compiling for the 8 bit boards but I don't understand the code well enough to be confident that my fix wouldn't cause problems for the 32 bit boards. The code worked find for the 8 bit, I just like to fix warnings whenever possible. I have never used the library with a 32 bit board. The only 32 bit board I own is the ESP8266 but it comes with its own md5 library that has a name conflict with the ArduinoMD5 library if you try to use it so I made my library work with the MD5 library included with the core to avoid the conflict and also because that gets rid of one step of the installation process for people using my library on ESP8266.

I appreciate the offer to test my library on the 101. That would be very helpful. Unfortunately the library does require the MD5 to be correctly calculated so it would be best if we could find a fix for that problem. It does also have an unauthenticated mode where the ArduinoMD5 library is not used so I would still be grateful if you would test it out on the 101 even if we can't find a fix for the ArduinoMD5 issue. I have one last bug I'm going to try to find a solution for today and then I will be ready for the next release of the library so I'll reply again when I get there.

Hopefully someone else will be willing to help us out to figure out what the problem is with the ArduinoMD5 library on the 101. I looked around to find a good MD5 library for Arduino and, at least at that time, ArduinoMD5 seemed to be the best one.