The tentative deadline for Phase1B is 18th November so there are two weeks left to donate the remaining 2600 euros. If we will reach the goal, the PCB with SI bus simulation should be ready by the middle of December.
In this case in before the end of 2020 we start working on production of the Prototypes together with the Prototypes Donation Campaign.
We have to give a name to the motherboard, suggestions still remain open few days more on our forum.
Our Open Hardware license and endianness suggestions at OSS 2020
We have talked about Cern Open Hardware License and Endianness at Open Source Summit + Embedded Linux Conference on Europe 27 Oct 2020
Cern Open Hardware License
Why not a software license such as GPL?
Hardware licenses are specific for hardware so they are written using the appropriate words: manufacturer, devices, CAD tool…
Why we choose the CERN Open Hardware Licence v1.2?
We think it offers a better protection for the licensor compared to other hw licenses such as TAPR Open Hardware License
So, who are the licensor and the licensee?
– In our project we (Power Progress Community) are the licensor and the licensee is the hardware producer.
The Licensee may manufacture or distribute Products
– Licensee could modify our work but the modification must be available under the same or equivalent license.
Licensor is protected
– Quality and responsabilities of the hardware belong to the licensee.
Other important notes
– Firmware, drivers and any other software would require their own license.
– Intellectual property belongs to the licensor.
– Documentation must be provided in the right format to be modified (using a CAD tool).
Endianness
What is Endianness
It’s the way data is ordered in computer memory.
It affects integer data that is bigger than 1 byte.
It could be a problem when two different architectures exchange data.
It’s one of primary problems that a software developer has to keep in mind when writing portable software.
Endianness in memory: Big Endian
Data is read from left to right.
The most significant byte is on the left.
The word at address 0x101 is:
0x0203 = 515
The double word at 0x100 is:
0x01020304 = 16909060
Endianness in memory: Little Endian
Data is read from right to left.
The most significant byte is on the right.
The word at address 0x101 is:
0x0302 = 770
The double word at 0x100 is:
0x04030201 = 67305985
Endianness conversion
There are a couple of method to swap endianness:
– manual swapping
– auto swapping
Manual Swapping
16 bit unsigned swap:
swapped = (num>>8) | (num<<8);
32 bit unsigned swap:
swapped = ((num>>24)&0xff) | // move byte 3 to byte 0
((num<<8)&0xff0000) | // move byte 1 to byte 2 ((num>>8)&0xff00) | // move byte 2 to byte 1
((num<<24)&0xff000000); // byte 0 to byte 3
There are ready-to-use functions that have the same behaviour:
bswap_16(x);
bswap_32(x);
bswap_64(x);
Architecture Detection
Manual swapping should be avoided:
It involves the awareness of the running architecture.
Architecture must be detected and specific cases have to be implemented, otherwise the code will not be architecture-independent.
Some useful tools can help architecture detection:
#if __BYTE_ORDER == __LITTLE_ENDIAN
<LITTLE ENDIAN SWAP DEFINITION>
#elif __BYTE_ORDER == __BIG_ENDIAN
<BIG ENDIAN SWAP DEFINITION>
#end
For example, if little endian is requested on a little endian platform, the “#if defined function” will return the data as is, otherwise a swap procedure will be called.
Conversion Functions
POSIX has useful tools for automatic endianness conversion called host-to-network and network-to-host:
#include <arpa/inet.h>
uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);
These functions are used everytime you have to deal with an endianness problem. Keep in mind that network order is “Most Significant Byte First”, in other words, it’s Big Endian.
There are others functions for big/little endian conversion.
They are nonstandard functions but they are very useful:
#include <endian.h>
uint16_t htobe16(uint16_t host_16bits);
uint16_t htole16(uint16_t host_16bits);
uint16_t be16toh(uint16_t big_endian_16bits);
uint16_t le16toh(uint16_t little_endian_16bits);
uint32_t htobe32(uint32_t host_32bits);
uint32_t htole32(uint32_t host_32bits);
uint32_t be32toh(uint32_t big_endian_32bits);
uint32_t le32toh(uint32_t little_endian_32bits);
uint64_t htobe64(uint64_t host_64bits);
uint64_t htole64(uint64_t host_64bits);
uint64_t be64toh(uint64_t big_endian_64bits);
uint64_t le64toh(uint64_t little_endian_64bits);
The design of our board layout is meant to fit inside the Slimbook Eclipse body. The PCB Design which is currently being worked on using Mentor Xpedition.
In September 2020 we have published on our gitlab repository the Orcad source file with the latest version (v0.6) of the Electrical Schematics, you can go deeply on these board layout by using the Orcad source.
