Project Logs

Collapse

• Phase 1 is complete!

  Mangus Tiranus • 08/18/2022 at 09:31 • 0 comments

  Sorry for the lack of updates on this page, but I took  a little time off to focus on some other things after the hackaday competition ended. 

  But then I got back into getting this done. 

  Tons of work went into this so far. I had to create software for the PC and continued worked on the firmware.

  Full account of the work done is in the video bellow :)

  Phase 2 will happen sometime in the coming months. But right now I need to get some work done on some tricorders.

• GPU widget sort of working...

  Mangus Tiranus • 04/25/2022 at 20:45 • 0 comments

  So got the GPU widget sort of working. But got 2 main problems to deal with, first while the libra hardware monitor app shows the GPU power level. I cant for the life of me find it within the API. Im also having an odd issue with the activity graph. its inverted. Its something to do with the opengl stencil commands. Even though I have a clear stencil in the command list. The first one in the CPU is effecting the second one in the GPU. Something to play with.

  I now have to put this project aside for a few days, as I have to reintroduce myself to another project I'm working on and finish up. But I will be back on this again soon as I want to get a Phase 1 video up asap. 

• CPU widget working :D

  Mangus Tiranus • 04/24/2022 at 22:25 • 0 comments

  Honestly I wish I had a more fully working prototype but after struggling to get some API stuff to work earlier and a nightmare figuring out the special source for font assets, I've finally figured it all out and started getting the widgets to work...

  At the moment just got clock and the CPU widget working.

  The rest will follow :)

• Starting to code widgets!

  Mangus Tiranus • 04/21/2022 at 23:05 • 0 comments

  Talk about 11th hour reprieve! 

  Now fonts are working I can start writing the layout code for the widgets. 

  I dont think I can get this fully running before the 25th, but hopefully Ill have CPU and GPU and clock displaying real data by the end of tomorrow. 

  I certainly wont have any of the ARGB or side lights for the acrylic running by the 25th thats for sure. 

  Ive also currently cheated a little, the cluster of squares next to activity are meant to represent core threads. I will end up making this dynamic based on the number of threads detected, but for now its a hard coded grid. 

  
  

• WOOHOOO CRACKED IT!

  Mangus Tiranus • 04/21/2022 at 16:01 • 0 comments

  With help from my contact at Bridgetek , we finally managed to fix the font loading issue...

  
  Soooo, at the time the font is converted to the format the eve chip uses, bytes 144-148 are a 32bit unsigned int. That holds the fixed memory address the bitmap data for the font is located in ram. 

  This is why my combiner wasnt working. Because that address no longer is valid when the data is streamed and displaced from where the asset convert thinks it might go. 

  soooo, one way to fix this. Would be a very long winded manual process of adding files one at a time to my combiner, run the combining app, and log down each address, and then go back to the asset converter and manually enter each address + 148, then recombine to put into the flash....

  OR

  I could tweak my asset combiner code, put in a separate entry box for font assets, and in the program stream the data from the binaries, making sure to calculate the new locations these will go, and inject those addresses into the bytes 144-148 in the font assets steam before pushing to flash.

  And it works :D

  Im so glad I finally got round to learning desktop apps. no idea why I didnt do this far sooner. 

• oh well! I tried!

  Mangus Tiranus • 04/19/2022 at 15:41 • 0 comments

  Sadly I now have to accept I'm just not going to get a working prototype running before the 25th deadline.

  I've tried. I really have. But the latest problem has really got me stumped. 

  So I got asset data going from flash to ram at a nice speed. bitmaps load correctly, but I cant for the life of me figure out why I cant get my font data to display correctly. 

  I've gone through several datasheets guides and even looked through FTDI libraries to see if there's any trick to it. But it just refuses to load correctly. 

  I had hoped at least if I figured it out today I could get 1 maybe 2 of the widgets programmed to show by the 25th. But I just dont see how right now. 

  I think there might be some kind of byte alignment issue with how the chip addresses font data. But I've not managed to work it out.

  Before I was using the Gameduino library with its own GD2 files. But as I'm not using an SD card this time. I've had to create custom asset loading code to push from flash to ram. There must be something happening in the GD2 file that sets up the font file correctly. 

  I've emailed my contact at bridgetek to see if he has any ideas of what to try. But this obviously wont be in time for the deadline...

  Oh well:/ 

  Dont worry not abandoning the project. Just will have phase 1 done later than I want.

• Faster flash data loading!

  Mangus Tiranus • 04/17/2022 at 21:40 • 0 comments

  So while I have shown pushing to assets to flash via the serial is working, and loading assets to g ram was working. It was only working* ... 

  It still wasnt perfect. The main issue I was having was with the way I was pushing data to ram. I had to push byte by byte through one command and this seemed to have several over heads. That meant putting 350k of data to the gram took about 10 seconds. 

  Which was far too long in my book. Using the library normally would load assets from an SD card to gram and would do a full 1meg of data in about 3 or 4 seconds. 

  Clearly this wasnt right. Today I was mostly looking into ways to make this faster.

  My first approach was to reverse engineer the method the SD card was being pushed. And put my data in the place of the sd card data buffer. But for some reason that I've still yet to figure out, would cause the g ram to crash. No idea why. 

  Looking a little more at the official library, funnily for pic chips. I found the method Bridgetek recommend for streaming bytes to g ram with little over head.

  Going full into optimise mode, I first adapted this method to my project, and then stripped all the unnecessary stuff out. Going pretty bare bones (though not quite bare metal) streaming data out from flash and into gram via a loop. Ive got the loading time down to about 2 seconds from 10. 

  I know there must be ways to make this faster. maybe I can link up the DMA between SPI 1 and SPI 2 and just stream the data directly without normal instructions. Sadly full hardware level stuff is still a little on the hard side. And given the time I have left to get this prototype functioning. Now is not the right time to try. 2 seconds is good enough for now :) 

  if anyone cares to know heres the code to load the assets! Pretty basic really. Using the w25q16 library for arduino. Tweaked a little by me. 

  #define MEM_WRITE   0x80            // FT800 Host Memory Write
  void EVE_AddrForWr(uint32_t ftAddress) // <<< from the pic library
  {
      // Send three bytes of a register address which has to be subsequently written. Ignore return values as this is an SPI write only.
     SPI.write(((ftAddress >> 16) | MEM_WRITE) );  // Send high byte of address with 'write' bits set
     SPI.write((ftAddress >> 8) );                 // Send middle byte of address
     SPI.write((ftAddress) );                      // Send low byte of address
  }
  void hwmon_loadAssets ()
  {
  
  
    uint32_t offset = 0;
    uint32_t size = 329988;
  
  
    flash.notBusy();
    flash.initStreamRead (0, 0);
  
  
    GD.__end();
  
   digitalWrite(DEFAULT_CS,LOW);                                                              // CS low begins SPI transaction
   EVE_AddrForWr(0);//<< originally from pic library supplied by BridgeTek really stripped down to speed up as much as possible. 
  
    while (offset < size)
      {
      SPI.write(flash.streamRead());// << streaming the data
      offset++;
      }
    digitalWrite(DEFAULT_CS,LOW);
    flash.closeStreamRead ();
  
  }
  

  [edit}

  This might actually be a fraction faster. 

  void hwmon_loadAssets ()
  {
  
    uint32_t offset = 0;
    const uint32_t size = 329988;
  
    flash.notBusy ();
    flash.initStreamRead (0, 0);
  
    GD.__end ();
  
    digitalWrite (DEFAULT_CS, LOW);                                                              // CS low begins SPI transaction
    EVE_AddrForWr (0);
  
  
    uint16_t n =0;
    byte buf[512];
  
    while (offset < size)
      {
        n = ((512) < (size - offset) ? (512) : (size - offset));
        for (uint16_t i = 0; i < n; i++)
          {
            buf[i] = flash.streamRead ();
          }
        SPI.write (buf, n);
  
        offset += n;
      }
  
    digitalWrite (DEFAULT_CS, LOW);
    flash.closeStreamRead ();
  
  }

• What a nightmare!

  Mangus Tiranus • 04/16/2022 at 17:34 • 0 comments

  This last couple of days I've been pulling out the non-existent hair on my head trying to get the flash working on the hardware. 

  I made a program that would take my binary files combine them and then push them to the flash chip on my project. 

  As I made this program from scratch, and heavily reworked my framed serial library I've previously made to work with this project. 

  So right away I was adding many points of failure. 

  I was also going into this with a basic assumption that I would be able to slightly reverse engineer the graphics chip library I'm using to get the data off the flash and into the graphics chip. The library is designed with SD cards in mind.

  So after seemingly getting the data to transfer from PC to the project as per my last post. I thought the next steps would be... fairly simple. 

  Of course it wasnt. 

  Most of yesterday I simple could not get the data to both send to the flash or read off the flash to the graphics chip. Each time I tried to do so, the project would hang, and I found is so hard to figure out why or where.

  Through tiny bits of trial and error and running the project with bits commented out to narrow down segments of code. I thought the issue might be some strange hardware level incompatibility.

  As I was jumping between Mode3 and Mode0 as I talked to each device, I thought maybe somewhere this was causing some data to trip one or the other up. So I did the one thing I didnt want to do.

  Hacked my PCB to connect the flash chip to the second SPI bus. 

  It wasnt pretty, I didnt like doing it. But with the deadline for the competition looming, there was no chance of my spinning another PCB. So this had to be done to move forward.... 
  

  And it didnt work.

  The project was still hanging... 

  At that point I did what any other sane person did, went to bed and screamed into a Pillow! 

  This morning, some what refreshed and coffee fed, I found an issue RIGHT away with the code. 

  It wasnt anything to do with switching between modes or some strange incompatibility. it was the INIT code for the flash simple was commented out. 

  At some point I commented it out and forgot to bring it back in. This was causing the hang. Pretty much a WHOLE DAY wasted on this! *bangs his head in the desk*

  So today I've mostly been refining my code being sent to the hardware, discovering how flash actually works (Ie must erase chip or sector first before writing data as it works subtractively) and then setting up a simple few lines of code to get it into the gram and hay presto!

  
  

  Assets are loading up onto the display now. !

  Now with less than 9 days to go I can start quickly putting together a working prototype program displaying all the data I want, and thats phase 1 complete! 

• Asset data upload nearly done!

  Mangus Tiranus • 04/14/2022 at 16:17 • 0 comments

  Just need to do some hop skip and jump code to commit the data to flash and run the display at the same time! As the flash and the display chip are on the same SPI line.

• How does it feel to have a PCB design correct, on the first order?

  Mangus Tiranus • 04/12/2022 at 10:39 • 0 comments

  Honestly I dont think I ever will feel the sheer undulating joy of getting a PCB design right the first time! 

  Ok I think I might have rushed this one out a little... Someone from discord helped spot the reason why my flash wasnt working.

  At first I was wondering if I had my SPI back to front. Turned out I neglected the Hold and WP pins. :( Simple hacky fix. but would have preferred to have got this right first time! 

  Also must admit when I got my new(1 year old now) phone I got it because the camera was reviewed well.... but as you can see its lens is very poor :/ Ultra narrow focus range :/ 

  Anyway the flash is working now. And now I need to finish the asset file combining and pushing app im currently putting together.

  The combiner I think is working. But I think I might have a carrying the 1 bug to deal with. But I want to test first.

  Currently adapting my framed serial code to c#, then I can figure out a good protocol to push the asset binarys to the flash. 

View all 14 project logs