April 2023 - pacsat-dev - mailman.amsat.org

Re: Filesystem code
by Corey Minyard 08 Apr '23

08 Apr '23

On Sat, Apr 08, 2023 at 09:52:49PM +0000, Chris Thompson via pacsat-dev wrote: > Reading and writing works fine! > > This looks fantastic Corey. No doubt there is a lot of work still to tweak > all the settings and make sure it will be reliable, but my initial > impression is very good. Well done. Well, you and Burns did a lot of the work of testing and debugging. If I hadn't removed the initMRAM() call from main.c it would have gone a lot better. It reminds me of the olden days when the people that wrote the code sent it to another group to punch onto cards and submit it and bring you back the results. It does make you review your code more carefully. We need to figure out what to do with the volume name and maybe tweak partition sizes. But it could probably go to the main branch at this point. Thanks for working on this, -corey

1 0

Re: Filesystem code
by Chris Thompson 08 Apr '23

08 Apr '23

Reading and writing works fine! This looks fantastic Corey. No doubt there is a lot of work still to tweak all the settings and make sure it will be reliable, but my initial impression is very good. Well done. 73 Chris On Sat, Apr 8, 2023 at 4:50 PM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > I pulled your branch directly and now it runs without the errors. > Something strange had happened in the merge. > > Anyway, that was the issue. Now I can write to the file system. You do > need / as the volume name and / as the root dir. So //test_file worked. > /test_file did not. Despite the documentation suggesting it would. > > I'll try to read it back next. > > 73 > Chris > > On Sat, Apr 8, 2023 at 4:38 PM Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Better check if there is a call to initMRAM in main.c immediately after >> SPIInit(MRAM3Dev). It is line 206 for me. That's what I had to do in >> order to avoid all the errors at startup. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Sat, Apr 8, 2023 at 4:26 PM Chris Thompson via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> From what I can tell in the developer guide, "//test_file" should have >>> worked. But so should "/test_file". It says that as a special case a >>> volume prefix by itself is interpreted as a reference to the root directory. >>> >>> So, hmmm.... >>> >>> Chris >>> >>> On Sat, Apr 8, 2023 at 3:36 PM Chris Thompson via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>>> Burns, I think the initMRAM() is there. I merged your branch in. I >>>> see the function call in ConsolTask() right after the SPInit() calls for >>>> the MRAMs. But I also see a lot of MRAM errors at boot. Error 19s and >>>> Error 20s... >>>> >>>> Corey, I tried //test_file and that did not work either. >>>> >>>> 73 >>>> Chris >>>> >>>> On Sat, Apr 8, 2023 at 2:54 PM Burns Fisher (AMSAT) via pacsat-dev < >>>> pacsat-dev(a)amsat.org> wrote: >>>> >>>>> Chris, I assume that you did add the "initMRAM" near boot (right after >>>>> the SPI init). If not, you may have to do format the file system after >>>>> doing it because it may have the size and the partition setup wrong >>>>> otherwise. >>>>> >>>>> 73, >>>>> >>>>> Burns Fisher, WB1FJ >>>>> *AMSAT(R) Engineering -- Flight Software* >>>>> >>>>> >>>>> On Sat, Apr 8, 2023 at 2:39 PM Corey Minyard <minyard(a)acm.org> wrote: >>>>> >>>>>> On Sat, Apr 08, 2023 at 02:19:29PM -0400, Chris Thompson wrote: >>>>>> > I tried a simple example but I can't open a file. Is there a >>>>>> volume name >>>>>> > that I need to specify? I presume you don't need to create a >>>>>> directory. >>>>>> >>>>>> "/" should be the volume name, but maybe you need two of them? I >>>>>> wasn't >>>>>> sure from what the documentation said. >>>>>> >>>>>> If you can open "//test_file", then that's what it is. >>>>>> >>>>>> -corey >>>>>> >>>>>> > >>>>>> > Here is the code, but the open fails with "No such file or >>>>>> directory" >>>>>> > >>>>>> > // TEST File System >>>>>> > char *test_string = "This is data"; >>>>>> > int32_t fp; >>>>>> > printf("FS Test: Writing:\n"); >>>>>> > fp = red_open("/test_file", RED_O_CREAT | RED_O_WRONLY); >>>>>> > if (fp != -1) { >>>>>> > printf("Writing string\n"); >>>>>> > int32_t numOfBytesWritten = red_write(fp, test_string, >>>>>> > strlen(test_string)); >>>>>> > if (numOfBytesWritten == strlen(test_string)) { >>>>>> > printf("Success\n"); >>>>>> > } else { >>>>>> > printf("Write returned: %d\n",numOfBytesWritten); >>>>>> > if (numOfBytesWritten == -1) >>>>>> > printf("Unable to write to file: %s\n", >>>>>> > red_strerror(red_errno)); >>>>>> > } >>>>>> > int32_t rc = red_close(fp); >>>>>> > if (rc != 0) { >>>>>> > printf("Unable to close file: %s\n", >>>>>> red_strerror(red_errno)); >>>>>> > } >>>>>> > >>>>>> > } else { >>>>>> > printf("Unable to open file: %s\n", >>>>>> red_strerror(red_errno)); >>>>>> > } >>>>>> > >>>>>> > Any thoughts? >>>>>> > >>>>>> > 73 >>>>>> > Chris >>>>>> > >>>>>> > On Fri, Apr 7, 2023 at 5:10 PM Burns Fisher (AMSAT) via pacsat-dev < >>>>>> > pacsat-dev(a)amsat.org> wrote: >>>>>> > >>>>>> > > >I assumed that since this was ARM it was little endian. >>>>>> > > >>>>>> > > Yeah, I would have too. But apparently ARM can go either way. >>>>>> Turns out >>>>>> > > that for some reason the automotive world seems to standardize on >>>>>> big >>>>>> > > endian. This has caused nothing but hassle on the TMS570 (the >>>>>> STM32L is >>>>>> > > little). >>>>>> > > >>>>>> > > >>>>>> > > ----------------------------------------------------------- >>>>>> > > >>>>>> > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>>>> > > View archives of this mailing list at >>>>>> > > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>>>>> > > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>>>> > > Manage all of your AMSAT-NA mailing list preferences at >>>>>> > > https://mailman.amsat.org >>>>>> > > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Chris E. Thompson >>>>>> > chrisethompson(a)gmail.com >>>>>> > g0kla(a)arrl.net >>>>>> >>>>> >>>>> ----------------------------------------------------------- >>>>> >>>>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>>> View archives of this mailing list at >>>>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>>>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>>> Manage all of your AMSAT-NA mailing list preferences at >>>>> https://mailman.amsat.org >>>>> >>>> >>>> >>>> -- >>>> Chris E. Thompson >>>> chrisethompson(a)gmail.com >>>> g0kla(a)arrl.net >>>> >>>> ----------------------------------------------------------- >>>> >>>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>> View archives of this mailing list at >>>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>> Manage all of your AMSAT-NA mailing list preferences at >>>> https://mailman.amsat.org >>>> >>> >>> >>> -- >>> Chris E. Thompson >>> chrisethompson(a)gmail.com >>> g0kla(a)arrl.net >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > > -- > Chris E. Thompson > chrisethompson(a)gmail.com > g0kla(a)arrl.net > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Filesystem code
by Chris Thompson 08 Apr '23

08 Apr '23

Burns, I pulled your branch directly and now it runs without the errors. Something strange had happened in the merge. Anyway, that was the issue. Now I can write to the file system. You do need / as the volume name and / as the root dir. So //test_file worked. /test_file did not. Despite the documentation suggesting it would. I'll try to read it back next. 73 Chris On Sat, Apr 8, 2023 at 4:38 PM Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Better check if there is a call to initMRAM in main.c immediately after > SPIInit(MRAM3Dev). It is line 206 for me. That's what I had to do in > order to avoid all the errors at startup. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Sat, Apr 8, 2023 at 4:26 PM Chris Thompson via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> From what I can tell in the developer guide, "//test_file" should have >> worked. But so should "/test_file". It says that as a special case a >> volume prefix by itself is interpreted as a reference to the root directory. >> >> So, hmmm.... >> >> Chris >> >> On Sat, Apr 8, 2023 at 3:36 PM Chris Thompson via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> Burns, I think the initMRAM() is there. I merged your branch in. I see >>> the function call in ConsolTask() right after the SPInit() calls for the >>> MRAMs. But I also see a lot of MRAM errors at boot. Error 19s and Error >>> 20s... >>> >>> Corey, I tried //test_file and that did not work either. >>> >>> 73 >>> Chris >>> >>> On Sat, Apr 8, 2023 at 2:54 PM Burns Fisher (AMSAT) via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>>> Chris, I assume that you did add the "initMRAM" near boot (right after >>>> the SPI init). If not, you may have to do format the file system after >>>> doing it because it may have the size and the partition setup wrong >>>> otherwise. >>>> >>>> 73, >>>> >>>> Burns Fisher, WB1FJ >>>> *AMSAT(R) Engineering -- Flight Software* >>>> >>>> >>>> On Sat, Apr 8, 2023 at 2:39 PM Corey Minyard <minyard(a)acm.org> wrote: >>>> >>>>> On Sat, Apr 08, 2023 at 02:19:29PM -0400, Chris Thompson wrote: >>>>> > I tried a simple example but I can't open a file. Is there a volume >>>>> name >>>>> > that I need to specify? I presume you don't need to create a >>>>> directory. >>>>> >>>>> "/" should be the volume name, but maybe you need two of them? I >>>>> wasn't >>>>> sure from what the documentation said. >>>>> >>>>> If you can open "//test_file", then that's what it is. >>>>> >>>>> -corey >>>>> >>>>> > >>>>> > Here is the code, but the open fails with "No such file or directory" >>>>> > >>>>> > // TEST File System >>>>> > char *test_string = "This is data"; >>>>> > int32_t fp; >>>>> > printf("FS Test: Writing:\n"); >>>>> > fp = red_open("/test_file", RED_O_CREAT | RED_O_WRONLY); >>>>> > if (fp != -1) { >>>>> > printf("Writing string\n"); >>>>> > int32_t numOfBytesWritten = red_write(fp, test_string, >>>>> > strlen(test_string)); >>>>> > if (numOfBytesWritten == strlen(test_string)) { >>>>> > printf("Success\n"); >>>>> > } else { >>>>> > printf("Write returned: %d\n",numOfBytesWritten); >>>>> > if (numOfBytesWritten == -1) >>>>> > printf("Unable to write to file: %s\n", >>>>> > red_strerror(red_errno)); >>>>> > } >>>>> > int32_t rc = red_close(fp); >>>>> > if (rc != 0) { >>>>> > printf("Unable to close file: %s\n", >>>>> red_strerror(red_errno)); >>>>> > } >>>>> > >>>>> > } else { >>>>> > printf("Unable to open file: %s\n", red_strerror(red_errno)); >>>>> > } >>>>> > >>>>> > Any thoughts? >>>>> > >>>>> > 73 >>>>> > Chris >>>>> > >>>>> > On Fri, Apr 7, 2023 at 5:10 PM Burns Fisher (AMSAT) via pacsat-dev < >>>>> > pacsat-dev(a)amsat.org> wrote: >>>>> > >>>>> > > >I assumed that since this was ARM it was little endian. >>>>> > > >>>>> > > Yeah, I would have too. But apparently ARM can go either way. >>>>> Turns out >>>>> > > that for some reason the automotive world seems to standardize on >>>>> big >>>>> > > endian. This has caused nothing but hassle on the TMS570 (the >>>>> STM32L is >>>>> > > little). >>>>> > > >>>>> > > >>>>> > > ----------------------------------------------------------- >>>>> > > >>>>> > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>>> > > View archives of this mailing list at >>>>> > > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>>>> > > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>>> > > Manage all of your AMSAT-NA mailing list preferences at >>>>> > > https://mailman.amsat.org >>>>> > > >>>>> > >>>>> > >>>>> > -- >>>>> > Chris E. Thompson >>>>> > chrisethompson(a)gmail.com >>>>> > g0kla(a)arrl.net >>>>> >>>> >>>> ----------------------------------------------------------- >>>> >>>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>> View archives of this mailing list at >>>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>> Manage all of your AMSAT-NA mailing list preferences at >>>> https://mailman.amsat.org >>>> >>> >>> >>> -- >>> Chris E. Thompson >>> chrisethompson(a)gmail.com >>> g0kla(a)arrl.net >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >> >> >> -- >> Chris E. Thompson >> chrisethompson(a)gmail.com >> g0kla(a)arrl.net >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Filesystem code
by Burns Fisher (AMSAT) 08 Apr '23

08 Apr '23

Better check if there is a call to initMRAM in main.c immediately after SPIInit(MRAM3Dev). It is line 206 for me. That's what I had to do in order to avoid all the errors at startup. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sat, Apr 8, 2023 at 4:26 PM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > From what I can tell in the developer guide, "//test_file" should have > worked. But so should "/test_file". It says that as a special case a > volume prefix by itself is interpreted as a reference to the root directory. > > So, hmmm.... > > Chris > > On Sat, Apr 8, 2023 at 3:36 PM Chris Thompson via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Burns, I think the initMRAM() is there. I merged your branch in. I see >> the function call in ConsolTask() right after the SPInit() calls for the >> MRAMs. But I also see a lot of MRAM errors at boot. Error 19s and Error >> 20s... >> >> Corey, I tried //test_file and that did not work either. >> >> 73 >> Chris >> >> On Sat, Apr 8, 2023 at 2:54 PM Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> Chris, I assume that you did add the "initMRAM" near boot (right after >>> the SPI init). If not, you may have to do format the file system after >>> doing it because it may have the size and the partition setup wrong >>> otherwise. >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Sat, Apr 8, 2023 at 2:39 PM Corey Minyard <minyard(a)acm.org> wrote: >>> >>>> On Sat, Apr 08, 2023 at 02:19:29PM -0400, Chris Thompson wrote: >>>> > I tried a simple example but I can't open a file. Is there a volume >>>> name >>>> > that I need to specify? I presume you don't need to create a >>>> directory. >>>> >>>> "/" should be the volume name, but maybe you need two of them? I wasn't >>>> sure from what the documentation said. >>>> >>>> If you can open "//test_file", then that's what it is. >>>> >>>> -corey >>>> >>>> > >>>> > Here is the code, but the open fails with "No such file or directory" >>>> > >>>> > // TEST File System >>>> > char *test_string = "This is data"; >>>> > int32_t fp; >>>> > printf("FS Test: Writing:\n"); >>>> > fp = red_open("/test_file", RED_O_CREAT | RED_O_WRONLY); >>>> > if (fp != -1) { >>>> > printf("Writing string\n"); >>>> > int32_t numOfBytesWritten = red_write(fp, test_string, >>>> > strlen(test_string)); >>>> > if (numOfBytesWritten == strlen(test_string)) { >>>> > printf("Success\n"); >>>> > } else { >>>> > printf("Write returned: %d\n",numOfBytesWritten); >>>> > if (numOfBytesWritten == -1) >>>> > printf("Unable to write to file: %s\n", >>>> > red_strerror(red_errno)); >>>> > } >>>> > int32_t rc = red_close(fp); >>>> > if (rc != 0) { >>>> > printf("Unable to close file: %s\n", >>>> red_strerror(red_errno)); >>>> > } >>>> > >>>> > } else { >>>> > printf("Unable to open file: %s\n", red_strerror(red_errno)); >>>> > } >>>> > >>>> > Any thoughts? >>>> > >>>> > 73 >>>> > Chris >>>> > >>>> > On Fri, Apr 7, 2023 at 5:10 PM Burns Fisher (AMSAT) via pacsat-dev < >>>> > pacsat-dev(a)amsat.org> wrote: >>>> > >>>> > > >I assumed that since this was ARM it was little endian. >>>> > > >>>> > > Yeah, I would have too. But apparently ARM can go either way. >>>> Turns out >>>> > > that for some reason the automotive world seems to standardize on >>>> big >>>> > > endian. This has caused nothing but hassle on the TMS570 (the >>>> STM32L is >>>> > > little). >>>> > > >>>> > > >>>> > > ----------------------------------------------------------- >>>> > > >>>> > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>> > > View archives of this mailing list at >>>> > > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>>> > > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>> > > Manage all of your AMSAT-NA mailing list preferences at >>>> > > https://mailman.amsat.org >>>> > > >>>> > >>>> > >>>> > -- >>>> > Chris E. Thompson >>>> > chrisethompson(a)gmail.com >>>> > g0kla(a)arrl.net >>>> >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >> >> >> -- >> Chris E. Thompson >> chrisethompson(a)gmail.com >> g0kla(a)arrl.net >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > > -- > Chris E. Thompson > chrisethompson(a)gmail.com > g0kla(a)arrl.net > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Filesystem code
by Chris Thompson 08 Apr '23

08 Apr '23

From what I can tell in the developer guide, "//test_file" should have worked. But so should "/test_file". It says that as a special case a volume prefix by itself is interpreted as a reference to the root directory. So, hmmm.... Chris On Sat, Apr 8, 2023 at 3:36 PM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, I think the initMRAM() is there. I merged your branch in. I see > the function call in ConsolTask() right after the SPInit() calls for the > MRAMs. But I also see a lot of MRAM errors at boot. Error 19s and Error > 20s... > > Corey, I tried //test_file and that did not work either. > > 73 > Chris > > On Sat, Apr 8, 2023 at 2:54 PM Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Chris, I assume that you did add the "initMRAM" near boot (right after >> the SPI init). If not, you may have to do format the file system after >> doing it because it may have the size and the partition setup wrong >> otherwise. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Sat, Apr 8, 2023 at 2:39 PM Corey Minyard <minyard(a)acm.org> wrote: >> >>> On Sat, Apr 08, 2023 at 02:19:29PM -0400, Chris Thompson wrote: >>> > I tried a simple example but I can't open a file. Is there a volume >>> name >>> > that I need to specify? I presume you don't need to create a >>> directory. >>> >>> "/" should be the volume name, but maybe you need two of them? I wasn't >>> sure from what the documentation said. >>> >>> If you can open "//test_file", then that's what it is. >>> >>> -corey >>> >>> > >>> > Here is the code, but the open fails with "No such file or directory" >>> > >>> > // TEST File System >>> > char *test_string = "This is data"; >>> > int32_t fp; >>> > printf("FS Test: Writing:\n"); >>> > fp = red_open("/test_file", RED_O_CREAT | RED_O_WRONLY); >>> > if (fp != -1) { >>> > printf("Writing string\n"); >>> > int32_t numOfBytesWritten = red_write(fp, test_string, >>> > strlen(test_string)); >>> > if (numOfBytesWritten == strlen(test_string)) { >>> > printf("Success\n"); >>> > } else { >>> > printf("Write returned: %d\n",numOfBytesWritten); >>> > if (numOfBytesWritten == -1) >>> > printf("Unable to write to file: %s\n", >>> > red_strerror(red_errno)); >>> > } >>> > int32_t rc = red_close(fp); >>> > if (rc != 0) { >>> > printf("Unable to close file: %s\n", >>> red_strerror(red_errno)); >>> > } >>> > >>> > } else { >>> > printf("Unable to open file: %s\n", red_strerror(red_errno)); >>> > } >>> > >>> > Any thoughts? >>> > >>> > 73 >>> > Chris >>> > >>> > On Fri, Apr 7, 2023 at 5:10 PM Burns Fisher (AMSAT) via pacsat-dev < >>> > pacsat-dev(a)amsat.org> wrote: >>> > >>> > > >I assumed that since this was ARM it was little endian. >>> > > >>> > > Yeah, I would have too. But apparently ARM can go either way. >>> Turns out >>> > > that for some reason the automotive world seems to standardize on big >>> > > endian. This has caused nothing but hassle on the TMS570 (the >>> STM32L is >>> > > little). >>> > > >>> > > >>> > > ----------------------------------------------------------- >>> > > >>> > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> > > View archives of this mailing list at >>> > > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> > > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> > > Manage all of your AMSAT-NA mailing list preferences at >>> > > https://mailman.amsat.org >>> > > >>> > >>> > >>> > -- >>> > Chris E. Thompson >>> > chrisethompson(a)gmail.com >>> > g0kla(a)arrl.net >>> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > > -- > Chris E. Thompson > chrisethompson(a)gmail.com > g0kla(a)arrl.net > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Filesystem code
by Chris Thompson 08 Apr '23

08 Apr '23

Burns, I think the initMRAM() is there. I merged your branch in. I see the function call in ConsolTask() right after the SPInit() calls for the MRAMs. But I also see a lot of MRAM errors at boot. Error 19s and Error 20s... Corey, I tried //test_file and that did not work either. 73 Chris On Sat, Apr 8, 2023 at 2:54 PM Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Chris, I assume that you did add the "initMRAM" near boot (right after the > SPI init). If not, you may have to do format the file system after doing > it because it may have the size and the partition setup wrong otherwise. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Sat, Apr 8, 2023 at 2:39 PM Corey Minyard <minyard(a)acm.org> wrote: > >> On Sat, Apr 08, 2023 at 02:19:29PM -0400, Chris Thompson wrote: >> > I tried a simple example but I can't open a file. Is there a volume >> name >> > that I need to specify? I presume you don't need to create a directory. >> >> "/" should be the volume name, but maybe you need two of them? I wasn't >> sure from what the documentation said. >> >> If you can open "//test_file", then that's what it is. >> >> -corey >> >> > >> > Here is the code, but the open fails with "No such file or directory" >> > >> > // TEST File System >> > char *test_string = "This is data"; >> > int32_t fp; >> > printf("FS Test: Writing:\n"); >> > fp = red_open("/test_file", RED_O_CREAT | RED_O_WRONLY); >> > if (fp != -1) { >> > printf("Writing string\n"); >> > int32_t numOfBytesWritten = red_write(fp, test_string, >> > strlen(test_string)); >> > if (numOfBytesWritten == strlen(test_string)) { >> > printf("Success\n"); >> > } else { >> > printf("Write returned: %d\n",numOfBytesWritten); >> > if (numOfBytesWritten == -1) >> > printf("Unable to write to file: %s\n", >> > red_strerror(red_errno)); >> > } >> > int32_t rc = red_close(fp); >> > if (rc != 0) { >> > printf("Unable to close file: %s\n", >> red_strerror(red_errno)); >> > } >> > >> > } else { >> > printf("Unable to open file: %s\n", red_strerror(red_errno)); >> > } >> > >> > Any thoughts? >> > >> > 73 >> > Chris >> > >> > On Fri, Apr 7, 2023 at 5:10 PM Burns Fisher (AMSAT) via pacsat-dev < >> > pacsat-dev(a)amsat.org> wrote: >> > >> > > >I assumed that since this was ARM it was little endian. >> > > >> > > Yeah, I would have too. But apparently ARM can go either way. Turns >> out >> > > that for some reason the automotive world seems to standardize on big >> > > endian. This has caused nothing but hassle on the TMS570 (the STM32L >> is >> > > little). >> > > >> > > >> > > ----------------------------------------------------------- >> > > >> > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> > > View archives of this mailing list at >> > > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> > > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> > > Manage all of your AMSAT-NA mailing list preferences at >> > > https://mailman.amsat.org >> > > >> > >> > >> > -- >> > Chris E. Thompson >> > chrisethompson(a)gmail.com >> > g0kla(a)arrl.net >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Filesystem code
by Chris Thompson 08 Apr '23

08 Apr '23

I tried a simple example but I can't open a file. Is there a volume name that I need to specify? I presume you don't need to create a directory. Here is the code, but the open fails with "No such file or directory" // TEST File System char *test_string = "This is data"; int32_t fp; printf("FS Test: Writing:\n"); fp = red_open("/test_file", RED_O_CREAT | RED_O_WRONLY); if (fp != -1) { printf("Writing string\n"); int32_t numOfBytesWritten = red_write(fp, test_string, strlen(test_string)); if (numOfBytesWritten == strlen(test_string)) { printf("Success\n"); } else { printf("Write returned: %d\n",numOfBytesWritten); if (numOfBytesWritten == -1) printf("Unable to write to file: %s\n", red_strerror(red_errno)); } int32_t rc = red_close(fp); if (rc != 0) { printf("Unable to close file: %s\n", red_strerror(red_errno)); } } else { printf("Unable to open file: %s\n", red_strerror(red_errno)); } Any thoughts? 73 Chris On Fri, Apr 7, 2023 at 5:10 PM Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > >I assumed that since this was ARM it was little endian. > > Yeah, I would have too. But apparently ARM can go either way. Turns out > that for some reason the automotive world seems to standardize on big > endian. This has caused nothing but hassle on the TMS570 (the STM32L is > little). > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

3 2

Re: Filesystem code
by Burns Fisher (AMSAT) 07 Apr '23

07 Apr '23

Jonathan, did I send you the extra Launchpad that I ended up with? In any case, do you want to give one to Corey? Corey, you may have to solder on some .1" header pins for Jim's board to have all the required connections. I know the headers are DNP around the outside where they are not used, but I'm not sure that all the inside ones are there either. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I have the filesystem code mostly ready. I changed the configuration > to use 256 byte block. It's available in the filesystem branch. > > So I will need a launchpad and a board with MRAM. My address is: > > 7406 Wheatfield Rd, Garland, TX 75044 > > Chris, you can test it if you like, too. I haven't written any tests > for anything yet, that needs to be added. > > There is code to automatically mount the filesystem on startup and > format the filesystem if it detects corruption. > > There are three new console commands: mount fs, unmount fs, and format fs. > > The commands are the normal POSIX commands with "red_" prefixed, > red_open(), red_close(), read_read(), etc. > > I need to write a README about how this is all set up. > > -corey > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

2 3

Re: Filesystem code
by Burns Fisher (AMSAT) 07 Apr '23

07 Apr '23

Ok, the initial MRAM errors (and I think actually a fs error that did not show) came because initMRAM has to be called way early in main before any calls are made to readMRAM (since otherwise "numberOfMRAMs" has not been initialized so getPartitionOffset fails. After I did that the fs was not correctly formatted anymore and format fs took a bit longer than it did before. But now it all seems well. Again, that is pushed up to the repo as BFFileSystem. Feel free to merge. That's probably it for today 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Apr 7, 2023 at 4:42 PM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Confirmed. I have it compiled and running here too. Corey has fixed the > path and endian issue in the Filesystem branch. > > Well done! > > I will see if I can write a file, but that will likely be tomorrow. > > 73 > Chris > > On Fri, Apr 7, 2023 at 4:31 PM Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Corey et al, >> >> I pulled down the filesystem branch and have gotten it running on my >> LaunchPad with 2 512K MRAMs. >> >> First, thanks for cleaning up the MRAM code. As you might have guessed, >> the read/write was originally to choose between the MRAM and Flash memory >> on the STM32L processor. On the RTIHU, I just cut out the stuff for the >> flash. Looks like you have used the same basic scheme between the two >> partitions in the MRAM. I like it! >> >> I have had to make two (identical) changes to get it to compile, and one >> more to get it to run: >> >> 1) I'm not entirely sure why the "reliance-edge" and its "core" >> subfolder were setup with different properties than everything else (that's >> the little key badge means, I think, although I've never been able to get >> rid of it once it was there!). But in any case, the changed setup had a >> path that was specific to your machine so it could not find <string.h>. I >> changed it to ${CG_TOOL_ROOT) in both places. Now it compiles. >> >> 2) Formatting the file system failed with a not-very-useful error message >> (Invalid Argument). The problem is that REDCONF_ENDIAN_BIG needs to be >> defined to 1 in redconf.h. >> >> So now it formats and mounts ok. I have not tried anything else. >> >> I'll push what I have right now up on my own branch named >> "BFFileSystem". Then I want to see why there are some MRAM errors when it >> first boots. Probably some old code. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Fri, Apr 7, 2023 at 12:40 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >>> Jonathan, did I send you the extra Launchpad that I ended up with? In >>> any case, do you want to give one to Corey? Corey, you may have to solder >>> on some .1" header pins for Jim's board to have all the required >>> connections. I know the headers are DNP around the outside where they are >>> not used, but I'm not sure that all the inside ones are there either. >>> >>> >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>>> I have the filesystem code mostly ready. I changed the configuration >>>> to use 256 byte block. It's available in the filesystem branch. >>>> >>>> So I will need a launchpad and a board with MRAM. My address is: >>>> >>>> 7406 Wheatfield Rd, Garland, TX 75044 >>>> >>>> Chris, you can test it if you like, too. I haven't written any tests >>>> for anything yet, that needs to be added. >>>> >>>> There is code to automatically mount the filesystem on startup and >>>> format the filesystem if it detects corruption. >>>> >>>> There are three new console commands: mount fs, unmount fs, and format >>>> fs. >>>> >>>> The commands are the normal POSIX commands with "red_" prefixed, >>>> red_open(), red_close(), read_read(), etc. >>>> >>>> I need to write a README about how this is all set up. >>>> >>>> -corey >>>> >>>> ----------------------------------------------------------- >>>> >>>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>> View archives of this mailing list at >>>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>> Manage all of your AMSAT-NA mailing list preferences at >>>> https://mailman.amsat.org >>>> >>> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > > -- > Chris E. Thompson > chrisethompson(a)gmail.com > g0kla(a)arrl.net > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

2 1

Re: Filesystem code
by Chris Thompson 07 Apr '23

07 Apr '23

Confirmed. I have it compiled and running here too. Corey has fixed the path and endian issue in the Filesystem branch. Well done! I will see if I can write a file, but that will likely be tomorrow. 73 Chris On Fri, Apr 7, 2023 at 4:31 PM Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Corey et al, > > I pulled down the filesystem branch and have gotten it running on my > LaunchPad with 2 512K MRAMs. > > First, thanks for cleaning up the MRAM code. As you might have guessed, > the read/write was originally to choose between the MRAM and Flash memory > on the STM32L processor. On the RTIHU, I just cut out the stuff for the > flash. Looks like you have used the same basic scheme between the two > partitions in the MRAM. I like it! > > I have had to make two (identical) changes to get it to compile, and one > more to get it to run: > > 1) I'm not entirely sure why the "reliance-edge" and its "core" subfolder > were setup with different properties than everything else (that's the > little key badge means, I think, although I've never been able to get rid > of it once it was there!). But in any case, the changed setup had a path > that was specific to your machine so it could not find <string.h>. I > changed it to ${CG_TOOL_ROOT) in both places. Now it compiles. > > 2) Formatting the file system failed with a not-very-useful error message > (Invalid Argument). The problem is that REDCONF_ENDIAN_BIG needs to be > defined to 1 in redconf.h. > > So now it formats and mounts ok. I have not tried anything else. > > I'll push what I have right now up on my own branch named "BFFileSystem". > Then I want to see why there are some MRAM errors when it first boots. > Probably some old code. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Fri, Apr 7, 2023 at 12:40 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > >> Jonathan, did I send you the extra Launchpad that I ended up with? In >> any case, do you want to give one to Corey? Corey, you may have to solder >> on some .1" header pins for Jim's board to have all the required >> connections. I know the headers are DNP around the outside where they are >> not used, but I'm not sure that all the inside ones are there either. >> >> >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> I have the filesystem code mostly ready. I changed the configuration >>> to use 256 byte block. It's available in the filesystem branch. >>> >>> So I will need a launchpad and a board with MRAM. My address is: >>> >>> 7406 Wheatfield Rd, Garland, TX 75044 >>> >>> Chris, you can test it if you like, too. I haven't written any tests >>> for anything yet, that needs to be added. >>> >>> There is code to automatically mount the filesystem on startup and >>> format the filesystem if it detects corruption. >>> >>> There are three new console commands: mount fs, unmount fs, and format >>> fs. >>> >>> The commands are the normal POSIX commands with "red_" prefixed, >>> red_open(), red_close(), read_read(), etc. >>> >>> I need to write a README about how this is all set up. >>> >>> -corey >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >> > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Filesystem code
by Burns Fisher (AMSAT) 07 Apr '23

07 Apr '23

Ok. And I confirmed that the two that a former volunteer gave me back are HERE. I did not give them to you. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Apr 7, 2023 at 2:21 PM Jonathan Brandenburg via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I have confirmed I have it... Now, how to best get it to Corey... I can > ship it from Addison post office, I can get it to Bill soon (if Corey is > going to see Bill at a club meeting or something), or Corey can pick it up > in Addison. > Thoughts? > Jonathan > > On 4/7/2023 11:41 AM, Burns Fisher (AMSAT) via pacsat-dev wrote: > > Jonathan, did I send you the extra Launchpad that I ended up with? In any > case, do you want to give one to Corey? Corey, you may have to solder on > some .1" header pins for Jim's board to have all the required connections. > I know the headers are DNP around the outside where they are not used, but > I'm not sure that all the inside ones are there either. > > > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> I have the filesystem code mostly ready. I changed the configuration >> to use 256 byte block. It's available in the filesystem branch. >> >> So I will need a launchpad and a board with MRAM. My address is: >> >> 7406 Wheatfield Rd, Garland, TX 75044 >> >> Chris, you can test it if you like, too. I haven't written any tests >> for anything yet, that needs to be added. >> >> There is code to automatically mount the filesystem on startup and >> format the filesystem if it detects corruption. >> >> There are three new console commands: mount fs, unmount fs, and format >> fs. >> >> The commands are the normal POSIX commands with "red_" prefixed, >> red_open(), red_close(), read_read(), etc. >> >> I need to write a README about how this is all set up. >> >> -corey >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org > > > -- > Jonathan Brandenburg, KF5IDY > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Filesystem code
by Jonathan Brandenburg 07 Apr '23

07 Apr '23

I have confirmed I have it... Now, how to best get it to Corey... I can ship it from Addison post office, I can get it to Bill soon (if Corey is going to see Bill at a club meeting or something), or Corey can pick it up in Addison. Thoughts? Jonathan On 4/7/2023 11:41 AM, Burns Fisher (AMSAT) via pacsat-dev wrote: > Jonathan, did I send you the extra Launchpad that I ended up with? In > any case, do you want to give one to Corey? Corey, you may have to > solder on some .1" header pins for Jim's board to have all the > required connections. I know the headers are DNP around the outside > where they are not used, but I'm not sure that all the inside ones are > there either. > > > > 73, > > Burns Fisher, WB1FJ > /AMSAT(R) Engineering -- Flight Software/ > > > On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev > <pacsat-dev(a)amsat.org> wrote: > > I have the filesystem code mostly ready. I changed the configuration > to use 256 byte block. It's available in the filesystem branch. > > So I will need a launchpad and a board with MRAM. My address is: > > 7406 Wheatfield Rd, Garland, TX 75044 > > Chris, you can test it if you like, too. I haven't written any tests > for anything yet, that needs to be added. > > There is code to automatically mount the filesystem on startup and > format the filesystem if it detects corruption. > > There are three new console commands: mount fs, unmount fs, and > format fs. > > The commands are the normal POSIX commands with "red_" prefixed, > red_open(), red_close(), read_read(), etc. > > I need to write a README about how this is all set up. > > -corey > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list --pacsat-dev(a)amsat.org > View archives of this mailing list athttps://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email topacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences athttps://mailman.amsat.org -- Jonathan Brandenburg, KF5IDY

1 0

Re: Filesystem code
by Jonathan Brandenburg (KF5IDY) 07 Apr '23

07 Apr '23

I don’t quite remember what my stock looks like but happy to allocate another to PACSAT. Jonathan Sent from my iPhone On Apr 7, 2023, at 11:41 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Jonathan, did I send you the extra Launchpad that I ended up with? In any case, do you want to give one to Corey? Corey, you may have to solder on some .1" header pins for Jim's board to have all the required connections. I know the headers are DNP around the outside where they are not used, but I'm not sure that all the inside ones are there either. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I have the filesystem code mostly ready. I changed the configuration to use 256 byte block. It's available in the filesystem branch. So I will need a launchpad and a board with MRAM. My address is: 7406 Wheatfield Rd, Garland, TX 75044 Chris, you can test it if you like, too. I haven't written any tests for anything yet, that needs to be added. There is code to automatically mount the filesystem on startup and format the filesystem if it detects corruption. There are three new console commands: mount fs, unmount fs, and format fs. The commands are the normal POSIX commands with "red_" prefixed, red_open(), red_close(), read_read(), etc. I need to write a README about how this is all set up. -corey ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Filesystem code
by Chris Thompson 07 Apr '23

07 Apr '23

Well done Corey. I will see if I can get it to compile here and try to flash the chip. 73 Chris On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I have the filesystem code mostly ready. I changed the configuration > to use 256 byte block. It's available in the filesystem branch. > > So I will need a launchpad and a board with MRAM. My address is: > > 7406 Wheatfield Rd, Garland, TX 75044 > > Chris, you can test it if you like, too. I haven't written any tests > for anything yet, that needs to be added. > > There is code to automatically mount the filesystem on startup and > format the filesystem if it detects corruption. > > There are three new console commands: mount fs, unmount fs, and format fs. > > The commands are the normal POSIX commands with "red_" prefixed, > red_open(), red_close(), read_read(), etc. > > I need to write a README about how this is all set up. > > -corey > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Filesystem code
by Corey Minyard 07 Apr '23

07 Apr '23

I have the filesystem code mostly ready. I changed the configuration to use 256 byte block. It's available in the filesystem branch. So I will need a launchpad and a board with MRAM. My address is: 7406 Wheatfield Rd, Garland, TX 75044 Chris, you can test it if you like, too. I haven't written any tests for anything yet, that needs to be added. There is code to automatically mount the filesystem on startup and format the filesystem if it detects corruption. There are three new console commands: mount fs, unmount fs, and format fs. The commands are the normal POSIX commands with "red_" prefixed, red_open(), red_close(), read_read(), etc. I need to write a README about how this is all set up. -corey

1 1

Re: Test
by Jim McCullers 07 Apr '23

07 Apr '23

GOT IT! 73 Jim This is sent from my gmail account. Can someone respond if they get this? -corey ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Test
by Chris Thompson 07 Apr '23

07 Apr '23

Received! 73 Chris On Fri, Apr 7, 2023 at 12:09 PM Corey Minyard via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > This is sent from my gmail account. > > Can someone respond if they get this? > > -corey > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Test
by Corey Minyard 07 Apr '23

07 Apr '23

This is sent from my gmail account. Can someone respond if they get this? -corey

1 0

Re: PC-104 "Standard"
by Bob Stricklin 07 Apr '23

07 Apr '23

Jonathan, Thanks for your email on this topic. These connectors mainly eat up a lot of board space. Reducing the pin count to something more realistic should befit all. Every pin you have in a connector is a potential reliability issue. Reliability in the actual connection interface and in the increase of complexity of the electrical design. Each pin with routed signals requires more effort to rout signals on the PCB. These connectors are adding mass to one side of the CubeSat moving the center of gravity. This will effect the orbital dynamics and stabilization systems. Some AMSAT designs use multiple bus systems, RS232, I2C, CAN, IO signals. These busses require different interface chips, power voltages, power consumption, firmware, and user knowledge. Reducing to a single communication bus system would reduce pin count, chip count, power needs and improve reliability. The connector systems marketed are not all equal. If a 104 pin standard is used then there should also be a specification for which connector are to be used. This will define the pin size, plating layers - nickel gold, socket sizes and pin hardness. I suggest using the pin size that is soldered in place. If the press pin socket pins/holes are used then they should be soldered after assembly. During prototype and production of flight hardware these connectors are difficult to work with. Each board/connector will have to be disassembly and reassembly many times. We need Battery voltage, and an I2C (2 pins) possibly a signal ground, and possible a hard reset signal. Bob > On Apr 7, 2023, at 9:26 AM, Jonathan Brandenburg via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > Following up on last night's conversation... > > When there is talk about CubeSats using the PC-104 standard, what that really means is the use of the PC-104 form factor in terms of board size, mounting hole placement, and the 2x2x26 connector. CubeSats don't adhere to any of the signalling or protocol aspects of PC-104 standards (including additional connectors defined in the PC-104 standard). > > There hasn't been any standards body define this form factor for Cubesats (as far as I know) so I imagine it just sort of grew organically from the first university satellites looking around for something to copy and noticed the small form-factor computer. > > As correctly noted, CubeSats don't standardize the use of the pins in the PC-104 connector but it seems like component manufacturers looked around to see how others had been using pins and followed suit. Thus if PACSAT is using I2C, power, and ground pins there will be little conflict. What I've seen is CubeSat component manufacturers offer an option sheet that allows the customer to select from a set of options. Along the lines of "put I2C pins here or there or do not connect" kind of options. > > I hear the comments about how "This a large connector!" and "How many pins are really needed?" and "How are they used by different components?" All that is true. At same time it's also true that if somebody is adding a component to their CubeSat it will most likely expecting boards with the PC-104 form factor. AMSAT is an exception but even then we had to partially adapt our boards to the PC-104 form factor for use by non-AMSAT organizations. > > When I'm at CubeSat Developers Workshop later this month, I'll do a survey. While I will see at least one university eschew the PC-104 form factor (because they're developing ALL the components in-house and prefer a plug-in-slot configuration because it simplifies assembly a lot) I expect most will have purchased the bus (including structure, C&DH, EPS, and any ADCS) which will be in the PC-104 form factor. But I could be surprised and the tide may be turning. > > Comments? > > Jonathan > > -- > Jonathan Brandenburg, KF5IDY > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq… > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi…

1 0

Re: PC-104 "Standard"
by Jonathan Brandenburg 07 Apr '23

07 Apr '23

On 4/7/2023 9:45 AM, Burns Fisher (AMSAT) via pacsat-dev wrote: > I'd be interested if those who use PC104 actually use them throughout > the satellite (i.e. they use them like Fox/Golf uses the QxN > connectors where most of the signals pass through). Also what board > spacing where these connectors are used if there is anything typical. > (I think Eric said there were choices for the PC-104 connectors). I'll include these questions in my survey... it would be interesting to know the prevalence of ribbon cables for sure. Jonathan -- Jonathan Brandenburg, KF5IDY

1 0

Re: PC-104 "Standard"
by Burns Fisher (AMSAT) 07 Apr '23

07 Apr '23

I'd be interested if those who use PC104 actually use them throughout the satellite (i.e. they use them like Fox/Golf uses the QxN connectors where most of the signals pass through). Also what board spacing where these connectors are used if there is anything typical. (I think Eric said there were choices for the PC-104 connectors). 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Apr 7, 2023 at 10:26 AM Jonathan Brandenburg via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Following up on last night's conversation... > > When there is talk about CubeSats using the PC-104 standard, what that > really means is the use of the PC-104 form factor in terms of board > size, mounting hole placement, and the 2x2x26 connector. CubeSats don't > adhere to any of the signalling or protocol aspects of PC-104 standards > (including additional connectors defined in the PC-104 standard). > > There hasn't been any standards body define this form factor for > Cubesats (as far as I know) so I imagine it just sort of grew > organically from the first university satellites looking around for > something to copy and noticed the small form-factor computer. > > As correctly noted, CubeSats don't standardize the use of the pins in > the PC-104 connector but it seems like component manufacturers looked > around to see how others had been using pins and followed suit. Thus if > PACSAT is using I2C, power, and ground pins there will be little > conflict. What I've seen is CubeSat component manufacturers offer an > option sheet that allows the customer to select from a set of options. > Along the lines of "put I2C pins here or there or do not connect" kind > of options. > > I hear the comments about how "This a large connector!" and "How many > pins are really needed?" and "How are they used by different > components?" All that is true. At same time it's also true that if > somebody is adding a component to their CubeSat it will most likely > expecting boards with the PC-104 form factor. AMSAT is an exception but > even then we had to partially adapt our boards to the PC-104 form factor > for use by non-AMSAT organizations. > > When I'm at CubeSat Developers Workshop later this month, I'll do a > survey. While I will see at least one university eschew the PC-104 form > factor (because they're developing ALL the components in-house and > prefer a plug-in-slot configuration because it simplifies assembly a > lot) I expect most will have purchased the bus (including structure, > C&DH, EPS, and any ADCS) which will be in the PC-104 form factor. But I > could be surprised and the tide may be turning. > > Comments? > > Jonathan > > -- > Jonathan Brandenburg, KF5IDY > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

PC-104 "Standard"
by Jonathan Brandenburg 07 Apr '23

07 Apr '23

Following up on last night's conversation... When there is talk about CubeSats using the PC-104 standard, what that really means is the use of the PC-104 form factor in terms of board size, mounting hole placement, and the 2x2x26 connector. CubeSats don't adhere to any of the signalling or protocol aspects of PC-104 standards (including additional connectors defined in the PC-104 standard). There hasn't been any standards body define this form factor for Cubesats (as far as I know) so I imagine it just sort of grew organically from the first university satellites looking around for something to copy and noticed the small form-factor computer. As correctly noted, CubeSats don't standardize the use of the pins in the PC-104 connector but it seems like component manufacturers looked around to see how others had been using pins and followed suit. Thus if PACSAT is using I2C, power, and ground pins there will be little conflict. What I've seen is CubeSat component manufacturers offer an option sheet that allows the customer to select from a set of options. Along the lines of "put I2C pins here or there or do not connect" kind of options. I hear the comments about how "This a large connector!" and "How many pins are really needed?" and "How are they used by different components?" All that is true. At same time it's also true that if somebody is adding a component to their CubeSat it will most likely expecting boards with the PC-104 form factor. AMSAT is an exception but even then we had to partially adapt our boards to the PC-104 form factor for use by non-AMSAT organizations. When I'm at CubeSat Developers Workshop later this month, I'll do a survey. While I will see at least one university eschew the PC-104 form factor (because they're developing ALL the components in-house and prefer a plug-in-slot configuration because it simplifies assembly a lot) I expect most will have purchased the bus (including structure, C&DH, EPS, and any ADCS) which will be in the PC-104 form factor. But I could be surprised and the tide may be turning. Comments? Jonathan -- Jonathan Brandenburg, KF5IDY

1 0

Filesystem interface to mram
by Corey Minyard 06 Apr '23

06 Apr '23

Here's the email I sent earlier. You can ignore the questions about MRAM. I have integrated the Reliance Edge filesystem into the PacSatSw repository in the "filesystem" branch. However, it is still missing the lower level interface to the mram devices. The main filesystem interface is in reliance-edge/include/redposix.h, I have enabled POSIX support without rename. It's pretty straightforward. You can get a copy of the Reliance Edge development document from https://www.tuxera.com/resources/reliance-edge-developers-guide/, but I don't think you need it. I have a copy, and I don't see that I can't redistribute it, so maybe I'll add it to the repository. Are we using the mram code in the deviceSupport directory? If so, the read and write operations (readMRAMWord, writeMRAMWord) don't have prototypes in the header. But I can fix that and integrate. Jonathan, I guess I'll need a launchpad and a board with the mram, since the qemu stuff didn't work out. -corey

1 0

Mail delivery
by Bill 06 Apr '23

06 Apr '23

Corey, please try again...

1 0

test from bf
by Burns Fisher (AMSAT) 06 Apr '23

06 Apr '23

test 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Test
by Corey Minyard 06 Apr '23

06 Apr '23

Test is the mailing list is working. -corey

1 0

Re: Pacsat dev mtg 4/6/2023
by Jonathan Brandenburg 06 Apr '23

06 Apr '23

I'll likely be on the road back from Houston but will strive to dial in to listen. Jonathan On 4/6/23 10:37, Bill via pacsat-dev wrote: > > Thu, Apr 6, 2023 7:00 PM - 9:00 PM (CDT) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/325976013 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (571) 317-3122 > - One-touch: tel:+15713173122,,325976013# > > Access Code: 325-976-013 > > > Get the app now and be ready when your first meeting starts: > https://meet.goto.com/install > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066

1 0

Pacsat dev mtg 4/6/2023
by Bill 06 Apr '23

06 Apr '23

Thu, Apr 6, 2023 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/325976013 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (571) 317-3122 - One-touch: tel:+15713173122,,325976013# Access Code: 325-976-013 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Filesystem interface to mram
by Corey Minyard 04 Apr '23

04 Apr '23

I have integrated the Reliance Edge filesystem into the PacSatSw repository in the "filesystem" branch. However, it is still missing the lower level interface to the mram devices. Are we using the mram code in the deviceSupport directory? If so, the read and write operations (readMRAMWord, writeMRAMWord) don't have prototypes in the header. But I can fix that and integrate. Jonathan, I guess I'll need a launchpad and a board with the mram, since the qemu stuff didn't work out. -corey

1 0