There are SATA drives that understand SCSI over ATAPI albeit in a limited way just to be clear.

https://www.youtube.com/watch?v=r10WuRo7c50

https://www.youtube.com/watch?v=eP9y_7it3ZM

https://m.youtube.com/watch?v=crc8n7D4kYg

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.