yampp Discussion Board

Quote

I do miss a indicator for volyme when playing...

For what reason?

To be able to verify, and if needed, adjust the volyme before putting in the earpices, without having to switch to the volyme menu..

Some unstructured thoughts....

To minimize mem impact, we maybee should just load the GUI configuration and load the bmy's at demand ?

One solution could be, having a array of pointers, and when loading a GUI config, malloc space for each of the GUI component description, storing the pointer in the array.

The allocated memory, that describes:
What the GUI component represents, eg. GUI_PROGRESSBAR, should do with a byte ?
Type of GUI component, Text, graphic, should also do with a byte ?
Position x
Position y
And then a char array, if its a graphical GUI component that requires more than one bmy lets use ; as delimiter and then 0x00 teminated.

And then in the GUI update function,

eg. (Just pseudo code...)

while (g_pGuiComponent[idx] != NULL) {

  pGuiComp = g_pGuiComponent[idx];

  switch (pGuiComp[0]) {
    case GUI_PROGRESSBAR:
      switch (pGuiComp[1]) {
        case GRAPH:
           draw grapic at pGuiComp[2], pGuiComp[3], using bmy with index in delimited string based upon the value...
         break;
       default:
         //Handle it as text...
           draw text at pGuiComp[2], pGuiComp[3], using string with the value added...
       break;
     }
    ...
     break;
    case GUI_BATTERY:
}
}

Really, I think it´s Jespers previlige to decide on how work should be distributed and how the s/w should be designed, I hope he takes help from the forum to solve tasks and find solutions to design issues. I Would prefer that we posts code solutions and Jesper uses copy/paste to implement the best solutions, cause I think the quality of the code might suffer if more than a couple of people get write access in the SVN.

As to MIC´s less is more approach to the GUI... no lets go wild and crazy...   I would like an implementation where we have a config file at the SD card that describes what text or icons should be used for what info... That way MIC could have his simple gui with text, and I could have my shiny progress bar and funky battery icon  

eg.

config.ini
battery_icon=on
battery_icon_xy=10,10
battery100%=batt_icon100.bmy
battery75%=batt_icon75.bmy
battery50%=batt_icon50.bmy
battery25%=batt_icon25.bmy
battery0%=batt_icon0.bmy
#battery_icon=off
#battery_text="%d.%d Volt",10,10

/ToS

Did almost work... 

      if (pTitle != NULL) free(pTitle);
        if (pArti != NULL) free(pArti);
        
        pTitle = NULL;
        pArti = NULL;

      if (fatlseek(playstate.ps_fd, -128, SEEK_END ) != 0) {
          pCBuffer = (char*)malloc(128);
         FATFileRead(playstate.ps_fd, pCBuffer, 128);

         if (memcmp(pCBuffer, "TAG", 3) == 0) {
              cGenre = pCBuffer[127];
              sYear = ((pCBuffer[93]-48)*1000)+((pCBuffer[94]-48)*100)+((pCBuffer[95]-48)*10)+(pCBuffer[96]-48);
              if (pCBuffer[33] != NULL) {
                 pCBuffer[63] = NULL;
                 pArti = (char*)malloc(strlen(pCBuffer+33));
                 strcpy(pArti, pCBuffer+33);
              }                 

              if (pCBuffer[3] != NULL) {
                 pCBuffer[33] = NULL;
                 pTitle = (char*)malloc(strlen(pCBuffer+3));
                 strcpy(pTitle,pCBuffer+3);
              }
            }
         free(pCBuffer);
      }
            
      fatlseek(playstate.ps_fd,0,SEEK_SET);


And in update_playinfo (main.c)
   if (pArti != NULL) lcd_text2(4, 85, WHITE,BLACK, pArti);
   if (pTitle != NULL) lcd_text2(4, 94, WHITE,BLACK, pTitle);

And some declarations in main.c
char* pTitle;
char* pArti;
short sYear;
char  cGenre;

Skip to next song...

in main.c add function

int skip_play(void)
{
   next_in_playlist();
   return 1;
}

Change menu section in main.c to:

const menu_t play_menu_s[] = {
   {"Play Menu", NULL},         // first entry is title of menu

   {"Skip to next",    skip_play},
   {"Back",          player_refresh},
   {"Stop Playing",    stop_play},
   {"Browse Files",    option_browse},
   {"Main Menu",       totitlemenu},
   /*{"Option Menu",    option_menu},*/
   {NULL,NULL}
};

In helpers.h add:

void next_in_playlist(void);


Not fully tested, but seams to work...

/ToS

Ok, problem solved...

When I prepared the SD card, i unpacked the ycard_card_contents.zip into the card... And that structure have lower case in the
directory names... Recreated the structure with uppercase letters... And the fault is gone.... But this should be implemented so that the case on the directorys does not matter...

Caution..
The Circuit board are not fixed 100% in the case, the SD can get stuck... And if a headphone set with a large plastic sheilding are used, the connector might not go entire way in, causing bad connection to earth... (Bad sound quality).

Ok gave up, and solved the sam7flash problem by installing Visual C++ Express edition... Now I can run the flasher but get a device not connected msg... But really, a USB driver should be installed in XP, or not ? XP detects the USB device and executes the install new hardware dialog... Should I install a driver or not ? And wich one in such case ?

And now to the firmware bug, did a change in the software to read the icons from the root dir instead... And copied the icon files to the root of the SD... But since I have the flash problem I could not upload the new firmware... But left the files in the root at the SD.... And to my suprise.... The four icon meny appeared when i inserted the SD and power on... The fault should logicaly be in the fat.c code... If I get the flasher to work, I can test some more...

/ToS

Just to get some sound... Copy a mp3 file to the root (\) of the SD, select the file in the "browser meny" and it plays ok...

Ok about VS, I think there is a "small" package at msdn somewhere that installs the runtimes for VS without the whole VS environment, just a case of finding it on bills page...