[Arm-netbook] passthrough card stm32f072 firmware

[Luke Kenneth Casson Leighton]

On Mon, Mar 13, 2017 at 9:33 PM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> Hi Luke,
>
> Le Mon, 13 Mar 2017 16:13:26 +0000
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:
>
>> ah!  albert!  did you get my email, am looking to invite you to help
>> with I2C EEPROM reading for the passthrough card (which has another
>> STM32F072...)
>
> Yes -- sorry I did not answer this week-end. Of course I'd be happy to
> help!

 aawesome okaaayy here's the schematic:
 http://hands.com/~lkcl/eoma/passthrough/
 EOMA68_PASSTHROUGH_3.pdf

 i just realised i made a couple of mistakes, the reset
"current-sinking-protecting-against-overvoltage" diode is the wrong
way round, and the BOOT0 TP should be a 3.3v not ground oh well that
explains a lot about why i can't see the damn thing on the USB bus
after trying to reset it... :)

 ok the primary task that's needed is: to read the VESA I2C EEPROM
from the microdesktop board and to feed the resultant data out, on
request, to the TFP401a.  so it's two main parts:

 * read (in bit-banging mode!) an I2C EEPROM
 * emulate an I2C EEPROM (probably best done via DMA and interrupts)

 let's track it through - microdesktop pinouts:
 http://hands.com/~lkcl/eoma/microdesktop/
 v1.7 schematic

 microdesktop SCL 17
 microdesktop SDA 22

and that goes through to....

GPIO_2 on passthrough schematic
MCU_PWM0 on passthrough schematic

which are

PC6 (needing to be SCL)
PA8 (needing to be SDA)

respectively.


the *secondary* task is that a userspace-programming firmware
bootloader/uploader is needed... *on the USB* interface - the
STM32F072 doesn't actually have one.  i could have left BOOT0 pulled
HIGH so that the STM32F072 always goes into bootloader mode but it may
be needed for early power-on initialisation and to have some sort of
"default" EDID response as well as bring up the TFP401a in cases where
people simply don't upload firmware to it at all.


the first part is critical to the functionality i believe - a first
prototype phase would be to just set up a static EDID buffer (static
string) and return that as an emulated I2C EEPROM "read" operation.

btw if you haven't _got_ an I2C EEPROM of some kind (AT24C64) kicking
around then perhaps simply wiring up two I2C interfaces back-to-back
in DMA mode would do the trick :)

*really* appreciated your help here albert.

l.