No more mbed for now

Today I was having a go at putting together the firmware to reproduce the communication interface used by the USB host that’s part of USBhost-64: essentially an 8-bit bus plus a few control lines.
I started with mbed’s online compiler but I soon realised that the high-level wonders of the InterruptIn interface come with a severe limitation, especially when both edge triggers are enabled: As a result, my Cortex M3 running at 72 MHz proved to be unable to keep up with my C64 mockup consumer (the one causing trigger interrupts) unless the latter was slowed down by adding a 300 microsecond wait per byte read. That’s not good at all I am afraid. I read about people complaining about the maximum frequency at which interrupts will occur properly using the InterruptIn interface on mbed, and the common suggestion was to go low-level, manipulating registers directly. Well, if it comes to it, I might as well just use my own framework then!

Contrarily to my plans to have a proper rest for the rest of the day, I set myself to use my own framework core (essentially a start-up script in C and a header file put together using the MCU’s programming guide) to explore the workings of external interrupts on GPIO lines of the STM32 MCU I am using.
I started with EXTI0 without issues, moved to EXTI1 when I noticed a typo in the IRQ handler name, then moved to EXTI3 when I noticed I had to disable JTAG and SW debugging functions to make it work. At the end of the exercise I was able to extend my own framework with examples on how to reliably use external interrupts on GPIO lines.

Once the EXTI stuff was done and dusted I moved on to reimplementing the communication interface of the USB host. Again, I could not get it to work the way the original one does due to the maximum frequency at which interrupts can take place on GPIO lines, but this time a delay of just 3 microseconds per byte (i.e. the time a C64 takes to fetch a byte on the bus) was enough to achieve a stable communication channel. I was able to transfer long pieces of text back and forth using a C64 mock-up and my USB host mock-up, without any alteration of the information 🙂
I don’t exactly like the tweaks that were necessary to try and make the interface as fast as possible, but as it’s robust I guess it’s a starting point.

My first use of this USB host mock-up will be to attach it to an SDHC card and allow my C64 mock-up to interact with its contents. If I manage to get far enough with this without issues along the way, it won’t take long before my C64 itself will be able to interact with the USB host mock-up and access SDHC contents directly, without noticing that it’s dealing with something completely different than USBhost-64. That, in fact, is the goal: re-use my USBhost-64 drivers verbatim to access an SDHC, or a remote PC’s file system, instead of an USB flash drive.

As I commented before I might actually settle for a slightly different communication interface but I would not want to give up on the amount of abstraction I coded for USBhost-64 on top of the drivers!

This entry was posted in Retrocomputing, Technical and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s