ESP8266 friendly tweaks

[shaneapowell]

I had to make a couple of pretty minor changes to have your AES library be compatible with my ESP8266 board. Thought I'd share the changes with you in case you want to add support for the ESP board. So far I've only tested encryption. I'll let you know once I get a chance to also test decryption.

[spaniakos]

thank you for the info. i will test the changes on Monday and hopefully commit the changes.

[shaneapowell]

Just a heads up.. both encryption and decryption work fine on my ESP8266 board. Granted, the payloads I'm dealing with are only about 500 bytes in size, but the performance is very fast on this little board too.

[jfresen]

Just wondering: I had to guard the line with fdevopen in printf.h with #if define(ESP8266) as well, otherwise it wouldn't compile for me when building for the ESP8266. How come you didn't have to do this?

[shaneapowell]

That's a good question. Could have something to do with my using PlatformIO to compile for my ESP8266? Perhaps my environment blocks that fdevopen line with the #ifdef on line 20. I'll try and take a look and see what is different.

[spaniakos]

Its library specific error. I will try to identofy it aftet i get from web summit.

On Nov 11, 2016 22:30, "Shane Powell" notifications@github.com wrote:

That's a good question. Could have something to do with my using PlatformIO to compile for my ESP8266? Perhaps my environment blocks that fdevopen line with the #ifdef on line 20. I'll try and take a look and see what is different.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spaniakos/AES/pull/3#issuecomment-260070785, or mute the thread https://github.com/notifications/unsubscribe-auth/ABnM6leaenJliXLoHD5duhzPffjnLjhgks5q9OyYgaJpZM4KEVPm .

[jfresen]

Any updates? I would like to know if my fix is correct (see jfresen/AES@5770ea79b299e24a9bddc4ec49f629d8d258177e).

[jfresen]

BTW, I'm looking at some other forks now and I see this commit tcz001/AES@4291efeaab863726e1ca9638c80103f557b3efaf. I haven't checked it out yet, but it looks like it will be a more generic fix for the problem of the avr include. Maybe worth checking that out and using that fix instead?

[spaniakos]

yes, it looks like tha tcz001 fix is more generic and would work with most machines.

On Mon, Nov 21, 2016 at 11:51 PM, Jelle Fresen notifications@github.com wrote:

BTW, I'm looking at some other forks now and I see this commit tcz001/AES@ 4291efe https://github.com/tcz001/AES/commit/4291efeaab863726e1ca9638c80103f557b3efaf. I haven't checked it out yet, but it looks like it will be a more generic fix for the problem of the avr include. Maybe worth checking that out and using that fix instead?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spaniakos/AES/pull/3#issuecomment-262078748, or mute the thread https://github.com/notifications/unsubscribe-auth/ABnM6se2qnnioYeitHgrBkFN1jKHt_mMks5rAhJXgaJpZM4KEVPm .

[spaniakos]

@shaneapowell i saw again your fixes. consider the following :

elif defined ( ESP8266 )

include

define PSTR(x) (x)

else

instead of adding all different kind of printf for your board. if it works on your board, please make a new pull request and i will add it.

[shaneapowell]

Indeed... you're cleaner suggestion seems to compile and work just fine.