I have been curious on CLion for some time. What holds me back is the price and the fact that it is written in Java (I know, the last one is a really bad reason).
It's a full IDE rather than a text editor with some IDE-like functionality. Most importantly (to me): much better refactoring tools and much better debugging tools.
No need to immediately hand over money, there's both a free 30-day trial, and you can regularly get an early access (i.e., beta) version of the new version for free.
Are any of these still needed, though? I kinda assumed they would be like Duff's Device and be a nifty historical relic, but firmly in the "Let the compiler do this for you" category in modern C.
Many of those are not standard functions (or were not, until very recently). You have to implement it somehow, so having a ready-made collection that also performs well is very nice to have.
What code specifically do you write instead of the code in TFA, in order to have the optimizer generate the code in TFA? In general compiling with optimizations enabled has not produced particularly good code in my experience.
"For example, the once-popular DEC VAX, DEC Alpha, and Sun SPARC ISAs are extinct."
Extinct is a bit harsh. SPARC V8 is alive and kicking in the space industry as the LEON processor models. Not the most performant CPU, but good enough for a lot of applications.
It would imprudent to base a whole new business on the SPARC ISA (if that's even possible - would Oracle license it?), unless you were in some niche like the space industry where interoperability is important.
And David is quite right that the Digital architectures are really extinct.
[Now I wonder if Compaq would open source the IP of Alpha. I think they licensed a lot of it to Intel so sadly they probably still make a bit of money from patents there.]
https://en.wikipedia.org/wiki/DEC_Alpha says compaq sold "all Alpha intellectual property" to intel in 02001, so probably they haven't made any money from it since then
also though any us patent filed since 01995 expires 20 years after filing, so any us αxp patents filed in the period 01995–02001 have expired already, and us patents filed before 01995 expire 17 years after issuance, so we only have to worry about pre-01995 us patents if first dec and then compaq and intel managed to delay their issuance, lemelson-style, until 02005 or later, which seems extremely unlikely
so αxp is almost certainly already open-source as an isa
dec's implementations are i suppose not open-source though, and casual glancing around on opencores and the like doesn't turn up any obvious candidates
I've never bothered to learn Python asyncio. When Python 3.5 came out I just thought it looked overly complex. Coming from a C/C++ background on Linux I just use the select package for waiting on blocking I/O, mainly sockets. Do you think there is something to gain for me by learning asyncio?
Personally, I don't think there is a benefit. If select is working for you, asyncio doesn't add anything performance wise. It is just meant to look more synchronous in how you write the code. But, using select and either throwing work onto a background thread or doing work quickly (if it isn't CPU bound) can be just as clear to read, if not clearer. Sometimes "async" and "await" calls only obfuscate the logic more.
This is not about SDR, it is about "software defined satellite". It is a generalization of the SDR concept, involving the whole satellite. Basically, it is about designing a more configurable satellite, suitable for a wider variety of tasks.
Seems the "software defined" in these things are mostly about reconfiguring antennas and radio beams. It's perhaps a bit more than a traditional SDR, after all there's not much modern radio communication not using SDRs, even the Mars rovers and satellites have them.
According to the press release, it is just a spaceborne SDR together with a very configurable antenna array, which can be used to provide various kinds of communication links.
But I think the space industry tries to communicate something other than SDR when they are talking about software-defined satellites. E.g., satellites as a service, allowing different customers time share a satellite and use it for different purposes by making the capabilities wider.
For now, the configurability of the sattelite appears to refer to using a configurable antenna array, which allows the configuration of a variable number of beams, in various directions, and with various directivity properties, presumably besides an SDR.
Yes, Google indexed many gu.com site hits, so then I believe there must have been a link to those pages somewhere and sometime which the Google crawler found. But searching for those short gu.com URLs now shows no external page hits on Google. (try searching for "gu.com/p/3menc" or "gu.com/p/cqekc" for instance)
RTEMS is fairly popular in space industry. I have been involved in two sateliite projects using RTEMS, one using the somewhat obscure OpenRISC architecture and one using LEON3/SPARC (also quite popular in space industry).
I was an intern at JPL 10 years ago. We used RTEMS + SPARC on the mission I worked on (GRACE FO - Earth science satellite). Unfortunately, I have no memory of how much it was used in other missions
While smaller ESA projects like satellite instruments are usually free to choose which version of RTEMS they use, larger and more important projects use ESA's own version. This version is known as the "EDISOFT" version because it was re-developed/qualified by a portuguese company of that name. It is basically a rewrite of a subset of the RTEMS API. You can read more about it here: https://www.esa.int/Enabling_Support/Space_Engineering_Techn...
Like most of ESA's software engineering tools, it is hopelessly outdated and relies on a patched GCC 4.2.1 which is missing a lot of useful features and bug fixes, especially for the SPARC architecture which is often used in ESA spacecraft. See -mfix-* switches here https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/SPARC-Options....
While RTEMS is GPL-licensed ESA does not want the code to be freely available -- you probably won't find it online. Some years ago they realized that, if they don't upstream their code, they have no chance to keep up to date and started an initiative to improve the situation: https://rtems-qual.io.esa.int, https://rtems-qual.io.esa.int/
This is ESA's fourth RTEMS qualification effort AFAIK. This time they are working with the community and have submitted things like requirements for a subset of RTEMS and requirements based tests. This is tracking the git master and SMP is included. We worked with NASA IV&V folks to get an outline for the RTEMS Software Engineering Guide which provides information expected in a qualification review.
Quietly an RTEMS core developer submitted GCC support for running gcov or gprof on embedded targets and getting the information off. This will be used to get coverage reports which meet ESA expectations. We do have very high code coverage.
ESA has also sponsored formal analysis of some parts of RTEMS.
I am quite happy ESA is working so well with our core developers and community this time.
I am trying to understand what differs the EDISOFT and upstream versions of RTEMS. The only concrete differences I can read out from the linked webpage is basically:
* SpaceWire support (LEON3)
* MIL-STD-1553 support (LEON3)
* kernel and application monitoring services (whatever that means)
Basically they made a list of a minimal set of functions that they want to support. They deleted all the other functions, then re-implemented the remaining code. For example, they axed the entire POSIX API, only kept the classic "rtems_" API. I don't know about quality of the SpW and M1553 code in the EDISOFT version but the quality of the driver code that Gaisler (now CAES) distributes for their processors is abysmal. Found here: https://www.gaisler.com/anonftp/rcc/src/ -- Among other issues: spaghetti-code, certain error flags not checked/reset resulting in lockups in case of errors, buffer sizes not configurable, unbounded loops/excessive wait delays. All big no-nos for safety-critical embedded software but understandable given limited manpower.
Nope, it's not. At least not entirely: https://www.rtems.org/license -- and the ESA version is definitely GPL-licensed.
Nothing against you personally, but I would really appreciate if instead of stating a certain believe, you actually look it up and point out a source for that bit of information.
What are the main pros compared to VSCode?