This is a bad strategy. NEVER do something which you don't under- stand. At least TRY to understand things before blindly following others.
I should not start an argument here, but: Sometimes understanding follows seeing the solution.
I thought that CFG_HARD_I2C would do everything on its own - and there's
Remember, this is software. Never will "everything" happen "on its own". You will always have to program each and every action yourself.
But ... another assumption of mine ... normally hardware support makes things easier than if there is no hardware support, for noone implements hardware support for something that can be done in software quite simple... or not?
less to configure in the /include/configs/board.h file. Why is the HARD I2c so much more difficult?
Just look at the code.
Okay, the HARD code is twice as long and looks more complicated, but this could - theoretically - also be the fault of the coder, not the hardware.
No, that's an 8xx, and should work. However, I still recommend to use soft-i2c instead.
Got it compiling with HARD support. Misspelled CONFIG_HARD_I2C (wrote CFG_HARD_I2C) and didn't see it until grep'ing all other HARD-using board sources.
needed. Again, I recommend to use soft-i2c instead. There is zero advantages with hard-i2c, just a lot of trouble.
I'll also prepare SOFT support - the prototype of the board still is being faciliated, so I can't test anything in real life anyway.
You're the expert, I'm convinced ;-)
Again, this is not a good strategy. Of course I feel flattered if you call me an expert, but I'd prefer if you make your decisions based on understanding, not on hearsay.
At least believing in and following experts is a good excuse in case you fail (Noone ever got fired for buying IBM - or trusting experts). It also saves time - if it works - which it does most time.
Best regards,
Peter Asemann