687 karma · joined August 12, 2014
There are SATA drives that understand SCSI over ATAPI albeit in a limited way just to be clear.
Cool looking web site
if it's an eval board, then do they provide schematics which are typical of other eval board producers?
Having the schematic might aid in getting things working assuming the MAC <-> PHY circuitry supports what you want to do.
Simple, John Deere, probably like us, has spent more testing the software than you could ever do on your own.
You can't judge complex software just by looking at it. It must be tested. People who fail to understand this wind up making these uneducated comments. Go study ISO26262 and the MTB calculations required to pass it and maybe you'll change your tune.
Tested software runs on real vehicles and simulators at large companies, as I stated, running into the multi-million dollar price range. There is zero amount of code inspection the general public can do that would give the same assurances you get through testing.
Bottom line: just looking at code is not enough. You must test it. This is unit tests, simulations, field tests, harsh temperature, vibration, power cycle, high side/low side power distribution, code coverage, etc... None of this is possible by you inspecting code.
Keep in mind that these are factories on wheels which means not only do we consume a tremendous amount of data, we also generate it. For example, 3D maps are built on the fly to show the customer where product has been sprayed, seeds planted, etc... On these vehicles, it's quite typical to see 1GB Data/hour generated which for an embedded device with no traditional hard drive, that's a lot. Flash memory is susceptible to extreme heat/cold so we have to be creative in this regard too (I can't talk much about this but suffice to say it's challenging).
That being a case of many, there is always a trade-off between performance and what you can reasonable keep separated either within the same PCB or between separate modules.
Thus, as much as I would like to keep separated, you simply can't sometimes. Current state of the art only allows for so much.
You also seem to be conflating right to repair vs. right to inspect code because you feel you have the right to do so for some reason (safety, don't like how it works, etc...). You don't have that right just like you don't have the right to walk into an assembly plant to see how your vehicle is assembled.
"The code, safety critical code especially, should be clear and should itself document the quirks of whatever it interacts with"
Agree and it does and we are audited by a 3rd party trained to looked at code written according to functional safety guidelines (ISO26262). Companies, like mine, don't have resources to respond to folks untrained on such matters. And for the non-safety aspects of the code, that's our intellectual property and our competitive advantage.
"Embedded has a culture of punting on abstractions due to the pervasiveness of cross cutting and global concerns"
You have data or proof of this or are you just talking from your personal experience? I assure you we take safety very seriously. Multiple millions are spent, as I said above, on testing to make sure code performs as expected; especially when a 3rd party audit and billions are on the line and, more importantly, the safety of our customers. You're inspection of the same code simply can't compete with the level of testing & auditing. You're really kidding yourself if you think otherwise.
"but 32-bit devices with dynamic allocation performing high level logical processing" Certain ASIL ratings dictate thou shall not perform dynamic allocations. You don't appear to be up to speed on functional safety matters.
"unreasonable is to force purchasers and users of heavy equipment to blindly trust the software controlling those devices."
Not true, disagree. It's unreasonable to assume we don't take safety seriously and demand to see our code when you can look at any company's functional safety audit records (they are public). To presume a right to change the code because you're not happy with some aspect of some functionality or you're concerned about safety is not your right and no company has the resources to support these requests from the general customer or public base. Moreover, as I already pointed out, it's our IP.
IP type code in this field is heavily guarded. Swath generation, swath acquisition, path planning are all very interesting algorithms that represent a company's IP.
One clever idea I learned when I was a kid tinkering with C64 was how the ROM resided at the same memory address as RAM. By toggling a bit, you can switch between the two. Applications back in the day would toggle this bit really fast to give the capability of having an assembly language program running in the background while your basic program interacted with it.
I learned this and it stuck with me over the years. C-Net BBS by a company called Perspective Software, if I recall correctly, did just this.
Cool article!
Tractors and Combines use DEF and I hear reports of people defeating it. Our software has checks to look for such activity.
No, disagree. If I laid out our source code for you, there is no way you would have any way to understand it without all the internal documentation from which the software was architected and developed from. Non computer people always have this misconception that if they see the code, they see everything it's doing. To a degree you can see what code is doing but understanding why certain logic exists is not always clear without supporting documentations.
Additionally, some of our code is 3rd party licensed and that adds an entire new wrinkle to things.
For an over simplified example, our CAN buses have thousands of signals. A single CAN frame may have 20 to 30 internal signals and several signals across many CAN buses are examined to make decisions and I've only scratched the surface here. There is no amount of code study you can do to understand this without some coaching or review of associated internal specifications.
For me or any company to support someone's quest to understand the code would be a very costly endeavor that you're simply not entitled too or nor would it be a reasonable request.
Umm, well people lie. Or you make the change for yourself and your fellow farmer. Your fellow farmer is killed and his wife sues the tractor company. Do you need more examples or is it clear now?
This is just my opinion. Customers are not entitled to source code or what I call the work product. You're entitled to the end product you purchased, the binary, which the source code is compiled to produce.
You hack or change software on a vehicle and cause the auto-guidance to run over and kill someone or you circumvent a safety check in software unbeknownst to you due to your software changes and a spinny sharp thing that should have stopped doesn't and hurts or mames you or calibration changes cause engine to to over-heat and burn up and generally the company is held responsible for it.
As much time is spent testing software as is writing software. All our testing is there to make sure the software works as expected. Millions are spent on test equipment and millions of hours and man hours are spent making sure software works as expected.
I happen to work for a major agricultural company and I'm a lead software architect for their guidance + autonomous vehicles + precision farming embedded devices. We are one of John Deere's major competitors.
Currently targeting the C++ language. The guy is writing it in C++ and is targeting Windows & Linux. I think he's using openGL.
I only run mine on private/home networks with no remote access in to them.
Curious about the version difference...
1. In the Terms & Conditions, Microsoft claims they get your IMEI number from mobile connect devices as part of their telemetry and then go on to say it's not PII (Personally Identifiable). Jerry explains how this is not true and explains how Microsoft through corporate partnerships can eventually link your IMEI data back to logs previously collected.
2. Jerry explains that there are two levels in the new Windows Creator program: A basic level and another, I forget what he called it, more verbose level. Jerry explains that 90% of the telementry data you might think is in the more verbose level is collected at the basic level. Kind of a moot point.
3. If you have turned off telemetry collecting features such as cortana and edge, by upgrading to Windows10 creator, these features are re-enabled and Microsoft says this is a bug but Jerry claims it's intentional.
These were the salient points I recall from the video. If you get a chance to view, I suggest giving it a watch. It's interesting.