IEEE members now have access to more than 260 eBooks from the IEEE Press collection through IEEE Xplore. The eBook collection spans a number of today’s technologies across 15 different content areas, and includes:

practical handbooks;
introductory and advanced texts;
reference works;
professional books.

This collection of eBooks is offered to members at no additional cost. Newer eBooks will be added every year.

http://twitter.com/#!/netrinomike/status/153994403038502913

Sent from Echofon – http://www.echofon.com/

-> Larry

I’m most interested these technologies: LTE (my day job), wireless sensor networks and internet of things. The latter two are tied together by protocols, enabled by open source software and open hardware and implemented in embedded systems.

I think wireless sensor networks will be of the greatest value as humanity creates nervous systems for cities and regions. For example, a single air quality sensor node in Beijing is causing quite a political and media stir.

I will be keeping an eye our for more events like the Eyebeam Workshop: NYC Open Sensor Network and events sponsored by Internet of Things New York City Meetup.

Useful to know for wireless sensor networks. Harvesting energy from the sun is just a start though. Can’t always get reliable sunlight exposure though so further exploration of piezoelectric or RF harvesting, etc.

I’ll be paying particular attention to the IP (licenses, copyright, Creative Commons), toolchain issues and to anything dealing with telecom and wireless.

-> Larry

My own endianness experience falls into roughly three categories: sharing binary data between heterogeneous processors, in protocols (most famous: TCP/IP) and in TDD unit testing C code. The last one is what prompted this blog post.

Solutions? For more readable, portable code, I’m avoiding macro based solutions. There is a tools based approach: Detecting Endian Issues with Static Analysis Tools. Sometimes, I’ll get lucky and the processor is able to handle both such as some DSPs.

One method for TDD for embedded systems tests the same source code on both the development platform and the target platform. For my personal embedded project, each platform had different endianness. I used a wrapper function whose implementation was determined by the compiler preprocessor. On the host platform (Intel Linux) I used byte-by-byte operations. On the target platform, I used intrinsic functions to operate on multiple byte-sized data.

This problem should be addressed at the architecture and protocol level and highlights the importance of test vectors which will show errors when the endianess is wrong.

http://twitter.com/#!/openbuddha/status/99551613789806592

Sent from Echofon – http://www.echofon.com/

-> Larry