TF CD32 Riser Revision 2 Design Complete

[arkadiusz.makarenko]

Can i check.. are you decoding / overriding BFE001? I'm not certain you need to as you can output on FIRE0/FIRE1 instead?

I did try both, with overriding BFE I had terrible slowdown, so I checked eagle schematic and found thst Fire0/1 were connected. Then I battled a little to find out that those pins need to be set up as Open drain (on push-pull Diagrom doesn't boot), and now I settled on Fire0/1 ... at least for now.

[terriblefire]

Well personally I think having Keyboard, Mouse and Joypad support via the riser as wireless *and* being able to view FMV from the 23D is my ideal setup. The board has room for future tinkering too . so its double win.

Currently the new boards are sitting in Germany waiting to clear customs.

[wairnair]

view FMV from the 23D is my ideal setup

sry for my ignorance but what's 23D?

Yeah.. with this new riser the CD32 will certainly be my childhood's dream Amiga - plus some more (didn't even think wireless back then)

[terriblefire]

view FMV from the 23D is my ideal setup

sry for my ignorance but what's 23D?

Yeah.. with this new riser the CD32 will certainly be my childhood's dream Amiga - plus some more (didn't even think wireless back then)

23 pin D

[arkadiusz.makarenko]

Currently the new boards are sitting in Germany waiting to clear customs.

I have ordered DB23s on eBay, and I would like to order stuff in Mouser to complete this(and parts to finish my A500++ build) soon, what do I would I need to order? All parts or connectors and cpld like last time?

[terriblefire]

Currently the new boards are sitting in Germany waiting to clear customs.

I have ordered DB23s on eBay, and I would like to order stuff in Mouser to complete this(and parts to finish my A500++ build) soon, what do I would I need to order? All parts or connectors and cpld like last time?

Should just be connectors and CPLD like before. I have the video chips so i'll solder that on for you. No idea if that will work btw..

[terriblefire]

OK so i had an ARM expert look at your code @arkadiusz.makarenko.. .specifically why its slow. Jamie doesnt pull punches so take a breath.

https://github.com/arkadiuszmakarenko/T ... ain.c#L740 because he goes through the HAL which involves a lot of dicking about with an I/O setup structure on every write instead of poking the data direction registers.

Jamie: Also he's setting one pin at a time. With a function call for each pin. Fix that one function.
Jamie: Once the port is generally set up, you only need to toggle input/output modes.
Jamie: Which is one 32-bit write.

8f4791c8-0ab5-46f8-bd47-6bab00c2a616.jpg

Jamie: Also going pin-by-pin involves messing about with the single-pin set/reset registers vs. putting all the data into one value and writing it to the port data reg in one go.

Code: Select all

				//Put data on 8 bit section of databus
				for (int i=0;i<8;i++)
				{
					//Write Pin method compared to Init should be fast enough
							HAL_GPIO_WritePin(GPIOB,1<<i,(data&(1<<i)));
				}

^ Don't do that. Write PORTB in one go.

Jamie: Need to just add some sensible bulk read-the-whole-port functions.
Jamie: All the registers for doing it are defined in

https://raw.githubusercontent.com/arka ... 32f722xx.h as they should be.

[terriblefire]

Anyways thats why its horrifically slow. Need to impement a ReadPort and WritePort function and use them.

Code: Select all

GPIO_PinState HAL_GPIO_ReadPin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
  GPIO_PinState bitstatus;

  /* Check the parameters */
  assert_param(IS_GPIO_PIN(GPIO_Pin));

  if((GPIOx->IDR & GPIO_Pin) != (uint32_t)GPIO_PIN_RESET)
  {
    bitstatus = GPIO_PIN_SET;
  }
  else
  {
    bitstatus = GPIO_PIN_RESET;
  }
  return bitstatus;
}

this could be changed to

Code: Select all

 
// Dont even call the function.. 
data = GPIOB->IDR; 

then you can mask off the bits you want.

ReadData can just become a macro

#define ReadData {GPIOB->IDR & 0xFF;}

or make it an inline function.

[arkadiusz.makarenko]

Code review is always welcome.
Thank you.

This make perfect sense!

Initially I had code to redefine Data GPIOs directly on registers as it is one GPIO port and entry and exit settings are fixed. But I wasn't sure about some settings so using HAL is easier to adapt and check if it is what I need. It will be easy to change now as I know exactly what need to be done.

What I didn't think of is reading/writing whole Data/Address values at once from register, this will reduce amount of cycles dramatically. I assumed GPIO reads/writes are fairly cheap, what I didn't think of is that formatting data + cheap read/write times 5 (addresses) + 8(data) is not cheap any more.

[terriblefire]

Code review is always welcome.
Thank you.

This make perfect sense!

Initially I had code to redefine Data GPIOs directly on registers as it is one GPIO port and entry and exit settings are fixed. But I wasn't sure about some settings so using HAL is easier to adapt and check if it is what I need. It will be easy to change now as I know exactly what need to be done.

What I didn't think of is reading/writing whole Data/Address values at once from register, this will reduce amount of cycles dramatically. I assumed GPIO reads/writes are fairly cheap, what I didn't think of is that formatting data + cheap read/write times 5 (addresses) + 8(data) is not cheap any more.

Also if you look at what GPIO init does its *ALOT*.. you probably want to make a cut down version of it. You do it twice in WriteData()

Code: Select all

for(position = 0; position < GPIO_NUMBER; position++)
  {
....
temp = GPIOx->PUPDR;
temp &= ~(GPIO_PUPDR_PUPDR0 << (position * 2));
temp |= ((GPIO_Init->Pull) << (position * 2));
GPIOx->PUPDR = temp;
...
}

Its doing type of setup for every configuration item per pin for every pin.