Project Logs

Collapse

• Wii Controllers Demo

  Matthew Pearce • 04/25/2022 at 13:02 • 0 comments

  2 Wii controllers are supported by the Gameduino board. They are stored in the Inputs response from the dazzler. The following information is available from 2 controllers:

  https://cdn.hackaday.io/files/1805367724052224/gameduino-3x-dazzler.pdf
  

  The controller can be seen working here: 

• USB Host #5 - Buttons

  Matthew Pearce • 04/22/2022 at 20:49 • 0 comments

  Here's a demo of the final code for the USB Keyboard and Mouse with a GUI button shown working for the first time. Code will be added to github soon.

• USB Host #4 - Mouse control (with a bit of Amiga)

  Matthew Pearce • 04/20/2022 at 19:27 • 0 comments

  First stab at USB mouse control. Using the USB host shield and 328p to translate HID to PS2. There is a bit of a lag, but it seems to work. Will need to debug the MCU code I think to see what is causing the delay.
  
  

• USB Host #3

  Matthew Pearce • 03/21/2022 at 12:31 • 0 comments

  USB Keyboard & Hub connected and now working. I created a quick sketch to convert HID codes from the keyboard to PS2 scan codes so it will just continue to work with the main hardware design with no modifications.

• USB Host #2

  Matthew Pearce • 03/16/2022 at 13:52 • 0 comments

  I have my cheapo mini usb host shield (max3421e) connected up to a 3.3v 328p feather board. the arduino code translates the USB HID data to ps2 data for the fpga system - giving usb mouse and keyboard via a powered hub. I think I may have space for usb midi translation as well. I've been umming and aaahing about which MCU but the adafruit feather 328p seems best as it is 3.3v by default, supports all existing arduino libraries and has a lipo battery charger and pin which I can also use for battery backup to the sram controller (ds1314).

  https://www.adafruit.com/product/3458

  https://chome.nerpa.tech/arduino_usb_host_shield_projects/
  

• USB Host

  Matthew Pearce • 03/10/2022 at 17:24 • 0 comments

  Purchased a cheap USB Host shield which uses a MAX3421e SPI USB controller. I'm currently finishing off the circuit design for the next version of the expansion card and I may put one of those on it. I need to port the USB Host library first to use my proven SPI code. I don't think it will be too complicated. At the moment I checked that the shield works by retrieving the Firmware version number using plain SPI. I'll pick this up again later.
  
  https://github.com/mattuna15/USB_Host_Shield_2.0

  https://www.maximintegrated.com/en/products/interface/controllers-expanders/MAX3421E.html

• Expansion Board #1

  Matthew Pearce • 02/21/2022 at 15:14 • 0 comments

  Received the first prototype PCB to expand the Arty. I've created a board which has 4 pmod connectors for 8 bit data, plus another connector which uses some more GPIO pins to handle upper 8bits plus other signals such as chip selects and the like.
  

  It needed a bit of bodge wiring to the read/write signals due to a typo on my behalf (doh). 8 bit data works perfectly to 1 3.3v sram chip. The upper 8bits seem to be working ok with a decent cable length.
  
  I've also added a DS1314 soic chip to provide a battery backup and warning led to maintain memory at shutdown. The board also breaks out the full bus to a 64pin expansion connector. I'll be using that to test various level shifters and other options.
  

• Asteroids #4 - Ship control, lasers and collisions

  Matthew Pearce • 02/15/2022 at 15:35 • 0 comments

  So we have a ship rotation using keyboard controls. I just rotated the vectors in excel and added them to an array, the same with the thruster vectors which are drawn twice with additive blending to increase brightness. The bullet is a simple point in the direction of the ship nose. Collision detection is just using 2 circular boundaries. 
  

  The vectors are rotated using: 

  𝑥2=cos𝛽𝑥1−sin𝛽𝑦1 

  𝑦2=sin𝛽𝑥1+cos𝛽𝑦1

  where 𝛽 is the rotation angle in radians.

  collision detection is :

  asteroidX-shipX < shipBoundaryRadius + asteroidBoundaryRadius &&
  asteroidY-shipY < shipBoundaryRadius + asteroidBoundaryRadius

  This is translated into asm:
  

  *****************************************************
  * asteroid collisions
  *
  ast_collision:
  
          *a4x a5y - asteroid
  
          movem.l d0-d7/a0-a6,-(sp)        ; backup registers
  
          lea ship_x,a0
          lea ship_y,a1
  
          move.l #0,d0
          move.l #0,d1
          move.l #0,d2
  
          move.w (a0),d0
          move.w (a1),d1
          move.w (a4),d2
          move.w (a5),d3
  
          move.l #20,d4
          add #8,d4 
  
          sub.w d0,d2
          sub.w d1,d3
  
          cmp.w #0,d2
          bge chky 
  
          muls.w #-1,d2
  
  chky:
          cmp.w #0,d3
          bge chkcoll 
  
          muls.w #-1,d3
  
  chkcoll:
          cmp.w d2,d4
          blt endcoll
  
          cmp.w d3,d4
          blt endcoll
  
          sub.b #1,ship_lives   * 1 life down
  
          cmp #0,ship_lives * end!
          beq end
  
          movem.l (sp)+,d0-d7/a0-a6         ; restore registers
          bra restart
  
  endcoll:
          movem.l (sp)+,d0-d7/a0-a6         ; restore registers
          rts

  Next on the list is collisions between the laser and asteroids.
  

  As usual code is here:

  https://github.com/mattuna15/merlin-software/blob/master/asteroids/asteroids.s
  

• Asteroids #3 - Movement

  Matthew Pearce • 02/11/2022 at 14:08 • 0 comments

  So, having created the shapes for the asteroids, ufo and player ship. It's time to move them about. The number of asteroids will be governed by the level - I've set to 5 at the moment. The starting position (x,y), heading in furmans and speed for the asteroids are set randomly.
  
  At the moment the ship and ufo are moving perpendicular to each other. A polar conversion routine using sin/cos is used to translate the velocity and heading into cartesian coordinates. The GD library provides lookup functions for this purpose.
  
  Code will be available here:
  

  https://github.com/mattuna15/merlin-software/blob/master/asteroids/asteroids.s
  

• DDR3 Setup

  Matthew Pearce • 02/10/2022 at 09:24 • 0 comments

  This is the worst part. DDR3 - it took me ages to get it right. So I'll put some notes here to help people.
  
  The Arty DDR requires 2 clocks, a system clock and a reference clock:
  

    .sys_clk_i(clock166), //166 mhz
    .clk_ref_i(clock200), //200 mhz

   One is 166 and the other is 200mhz. 

  The next is the DDR reset & enable. It is very picky. 
  

  reset_proc : process
  begin   
  
      sys_resetn <= resetn and mem_ready and clk_locked;
  
      rstn_flag <= '0', '1' after 220us; -- 200 & 750
      cke_flag <= '0', '1' after 750us; 
  
      ddr3_reset_n <= '0' when rstn_flag = '0' else ddr_rstn;
      ddr3_cke <= "0" when cke_flag = '0' else ddr_cke;
  
      
      wait for 3us;
  end process;

   At power up the DDR must be held in reset for at least 200 micro seconds. Also the DDR enable flag must be held low for at least 750 micro seconds.

  Next is the MIG IP set up. There are lots of fiddly settings here. The clocks must be set as per the images attached to this post. In the Merlin project there is a memory block design which shows all of the correct settings. The input clock period must be 166mhz. This will give you a UI clock of 83mhz, which is the fastest speed the arty ddr will run at. I get round this by using a system cache IP running at the CPU speed at 100mhz and then letting the axi interconnects deal with it from there.
  
  Good Luck!
  
  
  

View all 54 project logs