January 2024 - pacsat-dev - mailman.amsat.org

Re: Schematic of Blinky
by Burns Fisher (AMSAT) 31 Jan '24

31 Jan '24

Thanks for the spreadsheet. But I can't search in the schematic you sent either. PRINT is not the way to go for a searchable PDF. You need to PLOT. It does not seem to make any difference other than the text. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Wed, Jan 31, 2024 at 2:25 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > I believe the copy on GitHub was printed but here is one I just made which > for sure is printed. > Note this is Rev D and includes some changes but most of these are not > related to software. > > I am also attaching the spread sheet I did in the past and updated > recently which is a list of pin assignments from the CPU. This is easier to > work with for a software reference. > > Bob > > > > > > On Jan 31, 2024, at 12:18 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Actually, I just found them on the PC104. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Wed, Jan 31, 2024 at 1:13 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > > Hi Bob, > > I'm just getting started on software for the Blinky, but to do that, I > need to find things on the schematic. I found the schematic on gihub > (Schematic_231004.pdf) but it is not searchable, so I really can't find > (easily) where traces connect. For example, I found "UART_TX1 (as well as > RX1,2 and Tx2) but can't easily see what they connect to. Is there a > header somewhere (I could not see that on the physical board). > > If you can tell me where the UART lines go reasonbly soon, that would > help, but in the slightly longer term if you can make a KiCad PDF schematic > with the "plot" command rather than the "print" command (the ONLY thing > that I know about Kicad, I might add), that will produce a PDF with actual > text in it such that it can be searched. > > Thanks! > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > ----------------------------------------------------------- > > 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 >

1 0

Re: Schematic of Blinky
by Bob Stricklin 31 Jan '24

31 Jan '24

Burns, I believe the copy on GitHub was printed but here is one I just made which for sure is printed. Note this is Rev D and includes some changes but most of these are not related to software. I am also attaching the spread sheet I did in the past and updated recently which is a list of pin assignments from the CPU. This is easier to work with for a software reference. Bob On Jan 31, 2024, at 12:18 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Actually, I just found them on the PC104. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Jan 31, 2024 at 1:13 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Hi Bob, I'm just getting started on software for the Blinky, but to do that, I need to find things on the schematic. I found the schematic on gihub (Schematic_231004.pdf) but it is not searchable, so I really can't find (easily) where traces connect. For example, I found "UART_TX1 (as well as RX1,2 and Tx2) but can't easily see what they connect to. Is there a header somewhere (I could not see that on the physical board). If you can tell me where the UART lines go reasonbly soon, that would help, but in the slightly longer term if you can make a KiCad PDF schematic with the "plot" command rather than the "print" command (the ONLY thing that I know about Kicad, I might add), that will produce a PDF with actual text in it such that it can be searched. Thanks! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- 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

1 0

Schematic of Blinky
by Burns Fisher (AMSAT) 31 Jan '24

31 Jan '24

Hi Bob, I'm just getting started on software for the Blinky, but to do that, I need to find things on the schematic. I found the schematic on gihub (Schematic_231004.pdf) but it is not searchable, so I really can't find (easily) where traces connect. For example, I found "UART_TX1 (as well as RX1,2 and Tx2) but can't easily see what they connect to. Is there a header somewhere (I could not see that on the physical board). If you can tell me where the UART lines go reasonbly soon, that would help, but in the slightly longer term if you can make a KiCad PDF schematic with the "plot" command rather than the "print" command (the ONLY thing that I know about Kicad, I might add), that will produce a PDF with actual text in it such that it can be searched. Thanks! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 1

Flight software description
by Burns Fisher (AMSAT) 30 Jan '24

30 Jan '24

I have told about a zillion people about a zillion times that there are reasonably detailed description of the flight software in a Wiki in our Redmine repository. What is Redmine you ask? Well, you see the problem. It was created for problem and document tracking at the start of the Golf project, but no one paid attention or used it except for Zack and me. So I have not even bothered to create accounts for new people. In any case, more people are asking about the flight software. The description, while really written for Golf, is essentially true for Golf, Pacsat, and Fox, Thus I decided to put it in the Golf SVN (and I'll put it in the PacSat document git repo soon). It is in https://svn.amsat.org/golf/FlightSoftwareDescriptions. There are 4 pdf files there with different things of interest. And I just realized I have a duplicate and am missing one file, but I have to leave now,. The most important 3 are there: Multiple_CPUs_with_Code_Composer_Studio.pdf Software_Description.pdf Use_of_HalCoGen_with_Golf_and_PacSat_Flight_Software.pdf These are PDFs. The source is in Redmine. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: Test data and Updated Box
by Burns Fisher (AMSAT) 29 Jan '24

29 Jan '24

I told Bob a few minutes ago I had gotten but not opened the package. I had a couple minutes, so I just opened it and plugged it in. Blinky is blinking! So it appears that all is well shipping-wise. Thanks!

1 0

Re: Test data and Updated Box
by Burns Fisher (AMSAT) 29 Jan '24

29 Jan '24

So does that mean that you have been able to talk to the AX5043s and you know SPI is working? How about MRAM? 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sun, Jan 28, 2024 at 11:08 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > All, > > I spent a time this weekend testing the boards and tweaking/changing the > part values mostly in the 2M PreAmp and power divider section. > > I created a new folder in Github PacSatDoc for TestData and uploaded the > photos and a video to this folder. Not sure how Github feels about this but > I will see. > We can delete things after people have a chance to take a look. > > The boiled down results are the PreAmp frontend has a range of 10 dB gain > through the FET + Filter+ Power divider to 5 dB on the lowest. I checked > all 8 of the balanced ports and found them to be mostly the same. > > I turned down the 140 MHz carrier until I could see it just about the > noise on the spectrum analyze and the most sensitive channel was working at > -94dB. > > Power supply info/photos was also uploaded. > > Over the next few days I hope the test the final amplifier. > > Uploaded a new set of STL files for the box. I looking at options to get > these printed now. > > Tomorrow i will push the code I have up to my GitHub site. > > Bob > > > > > > > ----------------------------------------------------------- > > 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

Test data and Updated Box
by Bob Stricklin 29 Jan '24

29 Jan '24

All, I spent a time this weekend testing the boards and tweaking/changing the part values mostly in the 2M PreAmp and power divider section. I created a new folder in Github PacSatDoc for TestData and uploaded the photos and a video to this folder. Not sure how Github feels about this but I will see. We can delete things after people have a chance to take a look. The boiled down results are the PreAmp frontend has a range of 10 dB gain through the FET + Filter+ Power divider to 5 dB on the lowest. I checked all 8 of the balanced ports and found them to be mostly the same. I turned down the 140 MHz carrier until I could see it just about the noise on the spectrum analyze and the most sensitive channel was working at -94dB. Power supply info/photos was also uploaded. Over the next few days I hope the test the final amplifier. Uploaded a new set of STL files for the box. I looking at options to get these printed now. Tomorrow i will push the code I have up to my GitHub site. Bob

1 0

Re: Status of the three boards
by Jim McCullers 26 Jan '24

26 Jan '24

Paranoia is helpful until it's not. Congrats I realized the other three boards were not working due to my paranoia. The 5V regulator must have at least 10 mA of current draw and I had all the follow on circuits disconnected. When I put a load in place all working fine. All three of these boards are working with blinking leds program now. Bob ----------------------------------------------------------- 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

Status of the three boards
by Bob Stricklin 26 Jan '24

26 Jan '24

I realized the other three boards were not working due to my paranoia. The 5V regulator must have at least 10 mA of current draw and I had all the follow on circuits disconnected. When I put a load in place all working fine. All three of these boards are working with blinking leds program now. Bob

1 0

Pacsat dev mtg 1/25/2024
by Bill 25 Jan '24

25 Jan '24

Pacsat dev mtg 1/25/2024 Thu, Jan 25, 2024 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/652852245 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (872) 240-3212 - One-touch: tel:+18722403212,,652852245# Access Code: 652-852-245 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 652 852 245 Or dial directly: 652852245(a)67.217.95.2 or 67.217.95.2##652852245 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Progress
by Burns Fisher (AMSAT) 23 Jan '24

23 Jan '24

Bob, why don't you not both doing the HalCoGen changes and let me get the software. I'm so familiar with how I did HalCoGen and everything else that I can probably do it faster. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Jan 23, 2024 at 9:34 AM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Working hard on the boards. Spent the weekend swamping out and adding > parts to the 3 untouched boards. A few more parts need to be added. > > Have the power supply sections working. The chip for the 1.2 volt supply > is the most difficult to work with. > > Goal is to ship these out to people soon. I wanted to get one out to Burns > yesterday but taking longer to get them ready. > > Today is tied up with travel and doctors visits. > > I realize looking through the code that the bits on the IO lines are being > changed individually. This means that getting HCG correct was just a piece > of what we needed. Getting all the bits correct will take some time. > > Bob > > ----------------------------------------------------------- > > 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

Progress
by Bob Stricklin 23 Jan '24

23 Jan '24

Working hard on the boards. Spent the weekend swamping out and adding parts to the 3 untouched boards. A few more parts need to be added. Have the power supply sections working. The chip for the 1.2 volt supply is the most difficult to work with. Goal is to ship these out to people soon. I wanted to get one out to Burns yesterday but taking longer to get them ready. Today is tied up with travel and doctors visits. I realize looking through the code that the bits on the IO lines are being changed individually. This means that getting HCG correct was just a piece of what we needed. Getting all the bits correct will take some time. Bob

1 0

Software problems on blinky
by Burns Fisher (AMSAT) 19 Jan '24

19 Jan '24

Hi Bob, I was not able to go to the meeting last night, but I hear you are still having problems with the software. I just spent several hours debugging/staring at/thinking about a subtle problem causing an OS crash on my own Golf software, so I guess my thought is that I'm not too likely to be able to suggest a quick fix for you without a lot of hands-on. That said, if you want to send me a copy of the board, (and I understand that it may have flaws), I'm more than willing to look into the s/w problem. I'm sometimes pretty good at finding simple hw problems too. Let me know what you think. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Pacsat dev mtg 1/18/2024
by Bill 18 Jan '24

18 Jan '24

Pacsat dev mtg 1/18/2024 Thu, Jan 18, 2024 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/863270357 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (872) 240-3311 - One-touch: tel:+18722403311,,863270357# Access Code: 863-270-357 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 863 270 357 Or dial directly: 863270357(a)67.217.95.2 or 67.217.95.2##863270357 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Not here tomorrow
by Corey Minyard 18 Jan '24

18 Jan '24

On Thu, Jan 18, 2024 at 02:57:43AM +0000, Burns Fisher (AMSAT) via pacsat-dev wrote: > Snow on Tuesday moved my band rehearsal from Tuesday to Thurs, so I won't > be there for another week. Today is my monthly day where I can't make it, either. -corey > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > ----------------------------------------------------------- > > 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

Not here tomorrow
by Burns Fisher (AMSAT) 18 Jan '24

18 Jan '24

Snow on Tuesday moved my band rehearsal from Tuesday to Thurs, so I won't be there for another week. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: Moving my project to Github
by Burns Fisher (AMSAT) 17 Jan '24

17 Jan '24

Does Bob need one of those very long random passwords that github generates, or else a public key to actuallly push code there now? Is that the problem possibly? I know I did the long pw sometime but it must have been saved. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Wed, Jan 17, 2024 at 9:16 AM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I suggest applying the code changes to a branch rather than pushing a new > repo. Create a branch in the original repo, check out the branch then copy > all the new repo code over it. Including the halogen changes. Then commit > and push the branch. > > 73 > Chris > > On Tue, Jan 16, 2024, 17:46 Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Any ideas, Chris? You are more of a git expert than I. >> >> Have you seen the memory issue either? >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Tue, Jan 16, 2024 at 5:41 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> I used the Git tool in CCS to clone the PacSatSWV2 repository locally. >>> Then I copied all the files into the cloned area and now trying to push it >>> back up. >>> >>> >>> >>> Bob >>> >>> >>> >>> >>> >>> *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> >>> *Sent:* Tuesday, January 16, 2024 4:36 PM >>> *To:* Bob Stricklin <bstrick(a)n5brg.com> >>> *Cc:* Pacsat Dev <pacsat-dev(a)amsat.org> >>> *Subject:* [pacsat-dev] Re: Moving my project to Github >>> >>> >>> >>> How did you get it in the first place? If you pulled it down from >>> github then it should just push right back up there? It's been a long time >>> since I tried to set it up new. I'll try to get some time to look tomorrow >>> if just pushing it does not work. >>> >>> >>> >>> OH, that is why Bill wanted a new repository. It would have been so >>> much easier just to pull Jim's version down and make a branch for yours on >>> the same repository. >>> >>> >>> 73, >>> >>> >>> >>> Burns Fisher, WB1FJ >>> >>> *AMSAT**(R) **Engineering -- Flight Software* >>> >>> >>> >>> >>> >>> On Tue, Jan 16, 2024 at 5:31 PM Bob Stricklin via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>> Do any of you know the proper steps for me to get this initial code into >>> Github? Here is a image of what I have done. I thought it was going to post >>> but a cannot get the commit button at bottom to take action. >>> >>> >>> >>> Bob >>> >>> >>> >>> >>> ----------------------------------------------------------- >>> >>> 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 >>> >> >> ----------------------------------------------------------- >> >> 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 >

1 0

Re: Moving my project to Github
by Chris Thompson 17 Jan '24

17 Jan '24

I suggest applying the code changes to a branch rather than pushing a new repo. Create a branch in the original repo, check out the branch then copy all the new repo code over it. Including the halogen changes. Then commit and push the branch. 73 Chris On Tue, Jan 16, 2024, 17:46 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Any ideas, Chris? You are more of a git expert than I. > > Have you seen the memory issue either? > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Tue, Jan 16, 2024 at 5:41 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> I used the Git tool in CCS to clone the PacSatSWV2 repository locally. >> Then I copied all the files into the cloned area and now trying to push it >> back up. >> >> >> >> Bob >> >> >> >> >> >> *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> >> *Sent:* Tuesday, January 16, 2024 4:36 PM >> *To:* Bob Stricklin <bstrick(a)n5brg.com> >> *Cc:* Pacsat Dev <pacsat-dev(a)amsat.org> >> *Subject:* [pacsat-dev] Re: Moving my project to Github >> >> >> >> How did you get it in the first place? If you pulled it down from github >> then it should just push right back up there? It's been a long time since >> I tried to set it up new. I'll try to get some time to look tomorrow if >> just pushing it does not work. >> >> >> >> OH, that is why Bill wanted a new repository. It would have been so much >> easier just to pull Jim's version down and make a branch for yours on the >> same repository. >> >> >> 73, >> >> >> >> Burns Fisher, WB1FJ >> >> *AMSAT**(R) **Engineering -- Flight Software* >> >> >> >> >> >> On Tue, Jan 16, 2024 at 5:31 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> Do any of you know the proper steps for me to get this initial code into >> Github? Here is a image of what I have done. I thought it was going to post >> but a cannot get the commit button at bottom to take action. >> >> >> >> Bob >> >> >> >> >> ----------------------------------------------------------- >> >> 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 >> > > ----------------------------------------------------------- > > 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: Moving my project to Github
by Bob Stricklin 17 Jan '24

17 Jan '24

The GIT issue may be a permissions problem. I had a problem like this when I started and Jonathan did something to fix things. When I try to push I get prompted for username and password which I enter. Then I am declined. Maybe compare permissions on PacSatDocs to this new repository. Bob On Jan 16, 2024, at 4:46 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Any ideas, Chris? You are more of a git expert than I. Have you seen the memory issue either? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 5:41 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I used the Git tool in CCS to clone the PacSatSWV2 repository locally. Then I copied all the files into the cloned area and now trying to push it back up. Bob From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Sent: Tuesday, January 16, 2024 4:36 PM To: Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> Cc: Pacsat Dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: [pacsat-dev] Re: Moving my project to Github How did you get it in the first place? If you pulled it down from github then it should just push right back up there? It's been a long time since I tried to set it up new. I'll try to get some time to look tomorrow if just pushing it does not work. OH, that is why Bill wanted a new repository. It would have been so much easier just to pull Jim's version down and make a branch for yours on the same repository. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 5:31 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Do any of you know the proper steps for me to get this initial code into Github? Here is a image of what I have done. I thought it was going to post but a cannot get the commit button at bottom to take action. Bob ----------------------------------------------------------- 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<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: Memory Problem on PacSatSW
by Bob Stricklin 17 Jan '24

17 Jan '24

This seems to fix the short term issue… I changed FreeRTOSConfig.h like this: //#define configTOTAL_HEAP_SIZE ( ( size_t ) 32768 ) //Default //#define configTOTAL_HEAP_SIZE ( ( size_t ) (2*65536 )) /*BF Changed*/ #define configTOTAL_HEAP_SIZE ( ( size_t ) (65536 + 20000)) /*N5BRG Changed 240116*/ With the code this way we are using 85% of available space. This will be fine for me to continue testing chips. I will get back to test the board. Thanks for help. Bob From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Tuesday, January 16, 2024 2:21 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW Thanks. I have a few comments (all numbers are hex) * (this is true of Golf too--I never noticed) the psect named STACKS is unused. That is wasting 1500 bytes of RAM. * The actual stacks are allocated out of the module named os_heap. That is using 20000 bytes. See if you have the command "heap free" . That will tell you how much you can reduce that heap size by (but of course you want to leave some!) You can change the size in FreeRTOSConfig.h. Change "configTOTAL_HEAP_SIZE" Right now it is double what I had it at (it is 128K, was 64K) * I don't see a problem with flash or RAM memory. It says you have 10c112 bytes unused in flash and 932b unused in RAM. If we need to find some available memory, we can probably do it, but I don't see a problem here right now. Your "out of memory" must be a runtime message? Exactly what does that error look like? Is it in the file system (i.e. MRAM)? That is a totally different story. You might try "get mram size" to see if it matches the amount you think you have. The MRAM code (if I remember correctly) fixes itself up based on the size and number of MRAM chips, so if one or more are not working it might just quietly compensate. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 2:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Here is the map file you were looking for. Bob From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Sent: Tuesday, January 16, 2024 12:04 PM To: Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> Cc: Pacsat Dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW The MRAMmap that you sent has nothing to do with the linker complaining. MRAM is totally external and the linker knows nothing about it. I did not know about View/Memory that Jim pointed out. To me the most useful thing, and what I mean by the Link Map or Memory Map is under the Debug folder (or Release folder depending on which way you are building) and is called programname.map, for example PacSat.map. It shows how much each module is using in both code (flash memory) and RAM. Here is a section showing how much code (.text in Unix terms) is being used. SECTION ALLOCATION MAP output attributes/ section page origin length input sections -------- ---- ---------- ---------- ---------------- .intvecs 0 00000000 00000020 00000000 00000020 sys_intvecs.obj (.intvecs) .text 0 00000020 00048338 00000020 000046f4 Ax25Task.obj (.text) 00004714 00003d54 UplinkTask.obj (.text) 00008468 00003b14 PbTask.obj (.text) 0000bf7c 000033f0 ConsoleTask.obj (.text) 0000f36c 0000314c pacsat_header.obj (.text) 000124b8 00002b7c sys_selftest.obj (.text) 00015034 00002860 os_tasks.obj (.text) 00017894 000026b8 inodedata.obj (.text) 00019f4c 000020d0 nonvolManagement.obj (.text) 0001c01c 00002008 posix.obj (.text) ========================= And here is how much RAM is getting used. .bss 0 08001500 00024752 UNINITIALIZED 08001500 00020000 os_heap.obj (.bss:ucHeap) 08021500 00000acc Ax25Task.obj (.bss:data_link_state_machine) 08021fcc 00000a00 PbTask.obj (.bss:pb_list) 080229cc 0000067c buffer.obj (.bss:gBufCtx) 08023048 00000360 CommandTask.obj (.bss:UplinkCommandBuffer) 080233a8 00000320 posix.obj (.bss:gaHandle) 080236c8 00000200 UplinkTask.obj (.bss:ftl0_pfh_byte_buffer$2) 080238c8 00000200 pacsat_dir.obj (.bss:pfh_byte_buffer) 08023ac8 000001d4 UplinkTask.obj (.bss:ftl0_pfh_buffer$1) 08023c9c 000001d4 pacsat_dir.obj (.bss:pfh_buffer) 08023e70 00000128 (.common:gaRedCoreVol) 08023f98 00000120 rtsv7R4_T_be_v3D16_eabi.lib : trgmsg.c.obj (.bss:_CIOBUF_) 080240b8 00000118 UplinkTask.obj (.bss:ax25_event) 080241d0 00000118 Ax25Task.obj (.bss:ax25_received_event) 080242e8 00000118 Ax25Task.obj (.bss:lm_event) 08024400 00000118 Ax25Task.obj (.bss:send_event_buffer) 08024518 00000118 UplinkTask.obj (.bss:send_event_buffer) 08024630 00000118 Ax25Task.obj (.bss:timer_event) ========================= Notice that you can tell which is in flash and which is in memory by the address (080xxxxx is ram, 0004xxxx is flash). This is totally an output file. What you changed was the link command file sys_lnk.cmd which is input to the linker. You essentially "lied" to the linker so it would not complain, I think. Clever way to find out how much it really wanted! But if you can send the PacSat.map (or whatever it is called), that will tell exactly who is using the memory. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 12:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Jim, Make sure you are looking at: View -> Memory Allocation And not Memory Browser Memory Allocation should open in a TAB in a window within CCS. My TAB is at the bottom of CCS along with a bunch more TABs. Bob From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Sent: Monday, January 15, 2024 6:31 PM To: 'Pacsat Dev' <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I’m showing 80% utilization. The majority is in ucHeap (about 131k). I’ll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be ‘fun’ to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA48AF.3CC1A010] ----------------------------------------------------------- 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<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

1 0

Re: Moving my project to Github
by Burns Fisher (AMSAT) 16 Jan '24

16 Jan '24

Any ideas, Chris? You are more of a git expert than I. Have you seen the memory issue either? 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Jan 16, 2024 at 5:41 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I used the Git tool in CCS to clone the PacSatSWV2 repository locally. > Then I copied all the files into the cloned area and now trying to push it > back up. > > > > Bob > > > > > > *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> > *Sent:* Tuesday, January 16, 2024 4:36 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Pacsat Dev <pacsat-dev(a)amsat.org> > *Subject:* [pacsat-dev] Re: Moving my project to Github > > > > How did you get it in the first place? If you pulled it down from github > then it should just push right back up there? It's been a long time since > I tried to set it up new. I'll try to get some time to look tomorrow if > just pushing it does not work. > > > > OH, that is why Bill wanted a new repository. It would have been so much > easier just to pull Jim's version down and make a branch for yours on the > same repository. > > > 73, > > > > Burns Fisher, WB1FJ > > *AMSAT**(R) **Engineering -- Flight Software* > > > > > > On Tue, Jan 16, 2024 at 5:31 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Do any of you know the proper steps for me to get this initial code into > Github? Here is a image of what I have done. I thought it was going to post > but a cannot get the commit button at bottom to take action. > > > > Bob > > > > > ----------------------------------------------------------- > > 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 >

1 0

Re: Memory Problem on PacSatSW
by Bob Stricklin 16 Jan '24

16 Jan '24

The Error Message: Description Resource Path Location Type <a href="file:/E:/ti/ccs1250/ccs/tools/compiler/dmed/HTML/10099.html">#10099-D</a> program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. run placement with alignment fails for section ".bss" size 0x24466. Available memory ranges: sys_link.cmd /PacSatSWV2/source line 92 C/C++ Problem I will try the change you suggested in RTOS and let you know later. Have to feed cows and get them more water since lines are frozen. Bob From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Tuesday, January 16, 2024 2:21 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW Thanks. I have a few comments (all numbers are hex) * (this is true of Golf too--I never noticed) the psect named STACKS is unused. That is wasting 1500 bytes of RAM. * The actual stacks are allocated out of the module named os_heap. That is using 20000 bytes. See if you have the command "heap free" . That will tell you how much you can reduce that heap size by (but of course you want to leave some!) You can change the size in FreeRTOSConfig.h. Change "configTOTAL_HEAP_SIZE" Right now it is double what I had it at (it is 128K, was 64K) * I don't see a problem with flash or RAM memory. It says you have 10c112 bytes unused in flash and 932b unused in RAM. If we need to find some available memory, we can probably do it, but I don't see a problem here right now. Your "out of memory" must be a runtime message? Exactly what does that error look like? Is it in the file system (i.e. MRAM)? That is a totally different story. You might try "get mram size" to see if it matches the amount you think you have. The MRAM code (if I remember correctly) fixes itself up based on the size and number of MRAM chips, so if one or more are not working it might just quietly compensate. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 2:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Here is the map file you were looking for. Bob From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Sent: Tuesday, January 16, 2024 12:04 PM To: Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> Cc: Pacsat Dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW The MRAMmap that you sent has nothing to do with the linker complaining. MRAM is totally external and the linker knows nothing about it. I did not know about View/Memory that Jim pointed out. To me the most useful thing, and what I mean by the Link Map or Memory Map is under the Debug folder (or Release folder depending on which way you are building) and is called programname.map, for example PacSat.map. It shows how much each module is using in both code (flash memory) and RAM. Here is a section showing how much code (.text in Unix terms) is being used. SECTION ALLOCATION MAP output attributes/ section page origin length input sections -------- ---- ---------- ---------- ---------------- .intvecs 0 00000000 00000020 00000000 00000020 sys_intvecs.obj (.intvecs) .text 0 00000020 00048338 00000020 000046f4 Ax25Task.obj (.text) 00004714 00003d54 UplinkTask.obj (.text) 00008468 00003b14 PbTask.obj (.text) 0000bf7c 000033f0 ConsoleTask.obj (.text) 0000f36c 0000314c pacsat_header.obj (.text) 000124b8 00002b7c sys_selftest.obj (.text) 00015034 00002860 os_tasks.obj (.text) 00017894 000026b8 inodedata.obj (.text) 00019f4c 000020d0 nonvolManagement.obj (.text) 0001c01c 00002008 posix.obj (.text) ========================= And here is how much RAM is getting used. .bss 0 08001500 00024752 UNINITIALIZED 08001500 00020000 os_heap.obj (.bss:ucHeap) 08021500 00000acc Ax25Task.obj (.bss:data_link_state_machine) 08021fcc 00000a00 PbTask.obj (.bss:pb_list) 080229cc 0000067c buffer.obj (.bss:gBufCtx) 08023048 00000360 CommandTask.obj (.bss:UplinkCommandBuffer) 080233a8 00000320 posix.obj (.bss:gaHandle) 080236c8 00000200 UplinkTask.obj (.bss:ftl0_pfh_byte_buffer$2) 080238c8 00000200 pacsat_dir.obj (.bss:pfh_byte_buffer) 08023ac8 000001d4 UplinkTask.obj (.bss:ftl0_pfh_buffer$1) 08023c9c 000001d4 pacsat_dir.obj (.bss:pfh_buffer) 08023e70 00000128 (.common:gaRedCoreVol) 08023f98 00000120 rtsv7R4_T_be_v3D16_eabi.lib : trgmsg.c.obj (.bss:_CIOBUF_) 080240b8 00000118 UplinkTask.obj (.bss:ax25_event) 080241d0 00000118 Ax25Task.obj (.bss:ax25_received_event) 080242e8 00000118 Ax25Task.obj (.bss:lm_event) 08024400 00000118 Ax25Task.obj (.bss:send_event_buffer) 08024518 00000118 UplinkTask.obj (.bss:send_event_buffer) 08024630 00000118 Ax25Task.obj (.bss:timer_event) ========================= Notice that you can tell which is in flash and which is in memory by the address (080xxxxx is ram, 0004xxxx is flash). This is totally an output file. What you changed was the link command file sys_lnk.cmd which is input to the linker. You essentially "lied" to the linker so it would not complain, I think. Clever way to find out how much it really wanted! But if you can send the PacSat.map (or whatever it is called), that will tell exactly who is using the memory. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 12:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Jim, Make sure you are looking at: View -> Memory Allocation And not Memory Browser Memory Allocation should open in a TAB in a window within CCS. My TAB is at the bottom of CCS along with a bunch more TABs. Bob From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Sent: Monday, January 15, 2024 6:31 PM To: 'Pacsat Dev' <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I’m showing 80% utilization. The majority is in ucHeap (about 131k). I’ll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be ‘fun’ to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA489A.A3DE9DD0] ----------------------------------------------------------- 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<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

2 1

Re: Moving my project to Github
by Bob Stricklin 16 Jan '24

16 Jan '24

I used the Git tool in CCS to clone the PacSatSWV2 repository locally. Then I copied all the files into the cloned area and now trying to push it back up. Bob From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Tuesday, January 16, 2024 4:36 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Moving my project to Github How did you get it in the first place? If you pulled it down from github then it should just push right back up there? It's been a long time since I tried to set it up new. I'll try to get some time to look tomorrow if just pushing it does not work. OH, that is why Bill wanted a new repository. It would have been so much easier just to pull Jim's version down and make a branch for yours on the same repository. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 5:31 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Do any of you know the proper steps for me to get this initial code into Github? Here is a image of what I have done. I thought it was going to post but a cannot get the commit button at bottom to take action. Bob ----------------------------------------------------------- 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

1 0

Re: Moving my project to Github
by Burns Fisher (AMSAT) 16 Jan '24

16 Jan '24

How did you get it in the first place? If you pulled it down from github then it should just push right back up there? It's been a long time since I tried to set it up new. I'll try to get some time to look tomorrow if just pushing it does not work. OH, that is why Bill wanted a new repository. It would have been so much easier just to pull Jim's version down and make a branch for yours on the same repository. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Jan 16, 2024 at 5:31 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Do any of you know the proper steps for me to get this initial code into > Github? Here is a image of what I have done. I thought it was going to post > but a cannot get the commit button at bottom to take action. > > > > Bob > > > > ----------------------------------------------------------- > > 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

Moving my project to Github
by Bob Stricklin 16 Jan '24

16 Jan '24

Do any of you know the proper steps for me to get this initial code into Github? Here is a image of what I have done. I thought it was going to post but a cannot get the commit button at bottom to take action. Bob

1 0

Re: Memory Problem on PacSatSW
by Burns Fisher (AMSAT) 16 Jan '24

16 Jan '24

Thanks. I have a few comments (all numbers are hex) * (this is true of Golf too--I never noticed) the psect named STACKS is unused. That is wasting 1500 bytes of RAM. * The actual stacks are allocated out of the module named os_heap. That is using 20000 bytes. See if you have the command "heap free" . That will tell you how much you can reduce that heap size by (but of course you want to leave some!) You can change the size in FreeRTOSConfig.h. Change "configTOTAL_HEAP_SIZE" Right now it is double what I had it at (it is 128K, was 64K) * I don't see a problem with flash or RAM memory. It says you have 10c112 bytes unused in flash and 932b unused in RAM. If we need to find some available memory, we can probably do it, but I don't see a problem here right now. Your "out of memory" must be a runtime message? Exactly what does that error look like? Is it in the file system (i.e. MRAM)? That is a totally different story. You might try "get mram size" to see if it matches the amount you think you have. The MRAM code (if I remember correctly) fixes itself up based on the size and number of MRAM chips, so if one or more are not working it might just quietly compensate. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Jan 16, 2024 at 2:30 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Here is the map file you were looking for. > > > > Bob > > > > *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> > *Sent:* Tuesday, January 16, 2024 12:04 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Pacsat Dev <pacsat-dev(a)amsat.org> > *Subject:* [pacsat-dev] Re: Memory Problem on PacSatSW > > > > The MRAMmap that you sent has nothing to do with the linker complaining. > MRAM is totally external and the linker knows nothing about it. > > > > I did not know about View/Memory that Jim pointed out. To me the most > useful thing, and what I mean by the Link Map or Memory Map is under the > Debug folder (or Release folder depending on which way you are building) > and is called programname.map, for example PacSat.map. It shows how much > each module is using in both code (flash memory) and RAM. Here is a > section showing how much code (.text in Unix terms) is being used. > > > > SECTION ALLOCATION MAP > > output attributes/ > section page origin length input sections > -------- ---- ---------- ---------- ---------------- > .intvecs 0 00000000 00000020 > 00000000 00000020 sys_intvecs.obj (.intvecs) > > .text 0 00000020 00048338 > 00000020 000046f4 Ax25Task.obj (.text) > 00004714 00003d54 UplinkTask.obj (.text) > 00008468 00003b14 PbTask.obj (.text) > 0000bf7c 000033f0 ConsoleTask.obj (.text) > 0000f36c 0000314c pacsat_header.obj (.text) > 000124b8 00002b7c sys_selftest.obj (.text) > 00015034 00002860 os_tasks.obj (.text) > 00017894 000026b8 inodedata.obj (.text) > 00019f4c 000020d0 nonvolManagement.obj (.text) > 0001c01c 00002008 posix.obj (.text) > > > > ========================= > > And here is how much RAM is getting used. > > > > .bss 0 08001500 00024752 UNINITIALIZED > 08001500 00020000 os_heap.obj (.bss:ucHeap) > 08021500 00000acc Ax25Task.obj > (.bss:data_link_state_machine) > 08021fcc 00000a00 PbTask.obj (.bss:pb_list) > 080229cc 0000067c buffer.obj (.bss:gBufCtx) > 08023048 00000360 CommandTask.obj > (.bss:UplinkCommandBuffer) > 080233a8 00000320 posix.obj (.bss:gaHandle) > 080236c8 00000200 UplinkTask.obj > (.bss:ftl0_pfh_byte_buffer$2) > 080238c8 00000200 pacsat_dir.obj > (.bss:pfh_byte_buffer) > 08023ac8 000001d4 UplinkTask.obj > (.bss:ftl0_pfh_buffer$1) > 08023c9c 000001d4 pacsat_dir.obj (.bss:pfh_buffer) > 08023e70 00000128 (.common:gaRedCoreVol) > 08023f98 00000120 rtsv7R4_T_be_v3D16_eabi.lib : > trgmsg.c.obj (.bss:_CIOBUF_) > 080240b8 00000118 UplinkTask.obj (.bss:ax25_event) > 080241d0 00000118 Ax25Task.obj > (.bss:ax25_received_event) > 080242e8 00000118 Ax25Task.obj (.bss:lm_event) > 08024400 00000118 Ax25Task.obj > (.bss:send_event_buffer) > 08024518 00000118 UplinkTask.obj > (.bss:send_event_buffer) > 08024630 00000118 Ax25Task.obj (.bss:timer_event) > > > > > > ========================= > > > > Notice that you can tell which is in flash and which is in memory by the > address (080xxxxx is ram, 0004xxxx is flash). > > > > This is totally an output file. What you changed was the link command > file sys_lnk.cmd which is input to the linker. You essentially "lied" to > the linker so it would not complain, I think. Clever way to find out how > much it really wanted! But if you can send the PacSat.map (or whatever it > is called), that will tell exactly who is using the memory. > > > > 73, > > > > Burns Fisher, WB1FJ > > *AMSAT**(R) **Engineering -- Flight Software* > > > > > > On Tue, Jan 16, 2024 at 12:30 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Jim, > > > > Make sure you are looking at: > > > > View -> Memory Allocation > > > > And not Memory Browser > > > > Memory Allocation should open in a TAB in a window within CCS. My TAB is > at the bottom of CCS along with a bunch more TABs. > > > > Bob > > > > > > *From:* Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org> > *Sent:* Monday, January 15, 2024 6:31 PM > *To:* 'Pacsat Dev' <pacsat-dev(a)amsat.org> > *Subject:* [pacsat-dev] Re: Memory Problem on PacSatSW > > > > My version of CSS is either different or how did you turn on the green > lines with summary data? > > I get a popup status message with similar info but not as stable or > detailed as yours. > > > > On my system, I’m showing 80% utilization. > > The majority is in ucHeap (about 131k). > > I’ll bet on a function somewhere allocating a chunk of memory or > repeatedly doing so and never using or releasing it. > > Should be ‘fun’ to find. > > > > Jim McCullers > > WA4CWI > > > > > > > > Looks like we have an issue with memory usage in RAM > > > > If you load up CCS with the current project PacSatSW and build it then you > can select VIEW -> Memory Allocation and look at the tab. You will see the > package needs 154K or RAM and the Launpad has 191K. In the case of the > TMS570LS0914 we have 128K max. > > You can expand RAM and the subfolders and see where the memory is being > used. > > > > I worked for the last few days getting a HalCoGen setup for the LS0914 and > then murging this HCG file with the code of the Launcpad project. After > working through some issues it built but when it ran the linker it errored > out with not enough memory. So faked it out and told the linker I had more > memory. Then it would build and generate a .out file and the Memory > Allocation info. It matches the launch pad build. > > > > Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, > move buffers to external memory, or take out code. > > > > I will be looking for things here to try and complete a basic build of the > code for the LS0914. Please look for ideas and post any that you come up > with. We probably should target RAM usage at about 80% of the max or about > 100KB. We could change processors later but that would need some study. > > > > Bob > > > > > ----------------------------------------------------------- > > 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 >

1 0

Re: Memory Problem on PacSatSW
by Bob Stricklin 16 Jan '24

16 Jan '24

Here is the map file you were looking for. Bob From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Tuesday, January 16, 2024 12:04 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW The MRAMmap that you sent has nothing to do with the linker complaining. MRAM is totally external and the linker knows nothing about it. I did not know about View/Memory that Jim pointed out. To me the most useful thing, and what I mean by the Link Map or Memory Map is under the Debug folder (or Release folder depending on which way you are building) and is called programname.map, for example PacSat.map. It shows how much each module is using in both code (flash memory) and RAM. Here is a section showing how much code (.text in Unix terms) is being used. SECTION ALLOCATION MAP output attributes/ section page origin length input sections -------- ---- ---------- ---------- ---------------- .intvecs 0 00000000 00000020 00000000 00000020 sys_intvecs.obj (.intvecs) .text 0 00000020 00048338 00000020 000046f4 Ax25Task.obj (.text) 00004714 00003d54 UplinkTask.obj (.text) 00008468 00003b14 PbTask.obj (.text) 0000bf7c 000033f0 ConsoleTask.obj (.text) 0000f36c 0000314c pacsat_header.obj (.text) 000124b8 00002b7c sys_selftest.obj (.text) 00015034 00002860 os_tasks.obj (.text) 00017894 000026b8 inodedata.obj (.text) 00019f4c 000020d0 nonvolManagement.obj (.text) 0001c01c 00002008 posix.obj (.text) ========================= And here is how much RAM is getting used. .bss 0 08001500 00024752 UNINITIALIZED 08001500 00020000 os_heap.obj (.bss:ucHeap) 08021500 00000acc Ax25Task.obj (.bss:data_link_state_machine) 08021fcc 00000a00 PbTask.obj (.bss:pb_list) 080229cc 0000067c buffer.obj (.bss:gBufCtx) 08023048 00000360 CommandTask.obj (.bss:UplinkCommandBuffer) 080233a8 00000320 posix.obj (.bss:gaHandle) 080236c8 00000200 UplinkTask.obj (.bss:ftl0_pfh_byte_buffer$2) 080238c8 00000200 pacsat_dir.obj (.bss:pfh_byte_buffer) 08023ac8 000001d4 UplinkTask.obj (.bss:ftl0_pfh_buffer$1) 08023c9c 000001d4 pacsat_dir.obj (.bss:pfh_buffer) 08023e70 00000128 (.common:gaRedCoreVol) 08023f98 00000120 rtsv7R4_T_be_v3D16_eabi.lib : trgmsg.c.obj (.bss:_CIOBUF_) 080240b8 00000118 UplinkTask.obj (.bss:ax25_event) 080241d0 00000118 Ax25Task.obj (.bss:ax25_received_event) 080242e8 00000118 Ax25Task.obj (.bss:lm_event) 08024400 00000118 Ax25Task.obj (.bss:send_event_buffer) 08024518 00000118 UplinkTask.obj (.bss:send_event_buffer) 08024630 00000118 Ax25Task.obj (.bss:timer_event) ========================= Notice that you can tell which is in flash and which is in memory by the address (080xxxxx is ram, 0004xxxx is flash). This is totally an output file. What you changed was the link command file sys_lnk.cmd which is input to the linker. You essentially "lied" to the linker so it would not complain, I think. Clever way to find out how much it really wanted! But if you can send the PacSat.map (or whatever it is called), that will tell exactly who is using the memory. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Jan 16, 2024 at 12:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Jim, Make sure you are looking at: View -> Memory Allocation And not Memory Browser Memory Allocation should open in a TAB in a window within CCS. My TAB is at the bottom of CCS along with a bunch more TABs. Bob From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Sent: Monday, January 15, 2024 6:31 PM To: 'Pacsat Dev' <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I’m showing 80% utilization. The majority is in ucHeap (about 131k). I’ll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be ‘fun’ to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA4880.1BEE3260] ----------------------------------------------------------- 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

1 0

Re: Memory Problem on PacSatSW
by Burns Fisher (AMSAT) 16 Jan '24

16 Jan '24

The MRAMmap that you sent has nothing to do with the linker complaining. MRAM is totally external and the linker knows nothing about it. I did not know about View/Memory that Jim pointed out. To me the most useful thing, and what I mean by the Link Map or Memory Map is under the Debug folder (or Release folder depending on which way you are building) and is called programname.map, for example PacSat.map. It shows how much each module is using in both code (flash memory) and RAM. Here is a section showing how much code (.text in Unix terms) is being used. SECTION ALLOCATION MAP output attributes/ section page origin length input sections -------- ---- ---------- ---------- ---------------- .intvecs 0 00000000 00000020 00000000 00000020 sys_intvecs.obj (.intvecs) .text 0 00000020 00048338 00000020 000046f4 Ax25Task.obj (.text) 00004714 00003d54 UplinkTask.obj (.text) 00008468 00003b14 PbTask.obj (.text) 0000bf7c 000033f0 ConsoleTask.obj (.text) 0000f36c 0000314c pacsat_header.obj (.text) 000124b8 00002b7c sys_selftest.obj (.text) 00015034 00002860 os_tasks.obj (.text) 00017894 000026b8 inodedata.obj (.text) 00019f4c 000020d0 nonvolManagement.obj (.text) 0001c01c 00002008 posix.obj (.text) ========================= And here is how much RAM is getting used. .bss 0 08001500 00024752 UNINITIALIZED 08001500 00020000 os_heap.obj (.bss:ucHeap) 08021500 00000acc Ax25Task.obj (.bss:data_link_state_machine) 08021fcc 00000a00 PbTask.obj (.bss:pb_list) 080229cc 0000067c buffer.obj (.bss:gBufCtx) 08023048 00000360 CommandTask.obj (.bss:UplinkCommandBuffer) 080233a8 00000320 posix.obj (.bss:gaHandle) 080236c8 00000200 UplinkTask.obj (.bss:ftl0_pfh_byte_buffer$2) 080238c8 00000200 pacsat_dir.obj (.bss:pfh_byte_buffer) 08023ac8 000001d4 UplinkTask.obj (.bss:ftl0_pfh_buffer$1) 08023c9c 000001d4 pacsat_dir.obj (.bss:pfh_buffer) 08023e70 00000128 (.common:gaRedCoreVol) 08023f98 00000120 rtsv7R4_T_be_v3D16_eabi.lib : trgmsg.c.obj (.bss:_CIOBUF_) 080240b8 00000118 UplinkTask.obj (.bss:ax25_event) 080241d0 00000118 Ax25Task.obj (.bss:ax25_received_event) 080242e8 00000118 Ax25Task.obj (.bss:lm_event) 08024400 00000118 Ax25Task.obj (.bss:send_event_buffer) 08024518 00000118 UplinkTask.obj (.bss:send_event_buffer) 08024630 00000118 Ax25Task.obj (.bss:timer_event) ========================= Notice that you can tell which is in flash and which is in memory by the address (080xxxxx is ram, 0004xxxx is flash). This is totally an output file. What you changed was the link command file sys_lnk.cmd which is input to the linker. You essentially "lied" to the linker so it would not complain, I think. Clever way to find out how much it really wanted! But if you can send the PacSat.map (or whatever it is called), that will tell exactly who is using the memory. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Jan 16, 2024 at 12:30 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Jim, > > > > Make sure you are looking at: > > > > View -> Memory Allocation > > > > And not Memory Browser > > > > Memory Allocation should open in a TAB in a window within CCS. My TAB is > at the bottom of CCS along with a bunch more TABs. > > > > Bob > > > > > > *From:* Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org> > *Sent:* Monday, January 15, 2024 6:31 PM > *To:* 'Pacsat Dev' <pacsat-dev(a)amsat.org> > *Subject:* [pacsat-dev] Re: Memory Problem on PacSatSW > > > > My version of CSS is either different or how did you turn on the green > lines with summary data? > > I get a popup status message with similar info but not as stable or > detailed as yours. > > > > On my system, I’m showing 80% utilization. > > The majority is in ucHeap (about 131k). > > I’ll bet on a function somewhere allocating a chunk of memory or > repeatedly doing so and never using or releasing it. > > Should be ‘fun’ to find. > > > > Jim McCullers > > WA4CWI > > > > > > > > Looks like we have an issue with memory usage in RAM > > > > If you load up CCS with the current project PacSatSW and build it then you > can select VIEW -> Memory Allocation and look at the tab. You will see the > package needs 154K or RAM and the Launpad has 191K. In the case of the > TMS570LS0914 we have 128K max. > > You can expand RAM and the subfolders and see where the memory is being > used. > > > > I worked for the last few days getting a HalCoGen setup for the LS0914 and > then murging this HCG file with the code of the Launcpad project. After > working through some issues it built but when it ran the linker it errored > out with not enough memory. So faked it out and told the linker I had more > memory. Then it would build and generate a .out file and the Memory > Allocation info. It matches the launch pad build. > > > > Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, > move buffers to external memory, or take out code. > > > > I will be looking for things here to try and complete a basic build of the > code for the LS0914. Please look for ideas and post any that you come up > with. We probably should target RAM usage at about 80% of the max or about > 100KB. We could change processors later but that would need some study. > > > > Bob > > > > > ----------------------------------------------------------- > > 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: Memory Problem on PacSatSW
by Bob Stricklin 16 Jan '24

16 Jan '24

Jim, Make sure you are looking at: View -> Memory Allocation And not Memory Browser Memory Allocation should open in a TAB in a window within CCS. My TAB is at the bottom of CCS along with a bunch more TABs. Bob From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, January 15, 2024 6:31 PM To: 'Pacsat Dev' <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I'm showing 80% utilization. The majority is in ucHeap (about 131k). I'll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be 'fun' to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA486F.5D06AFE0]

1 0

Re: Memory Problem on PacSatSW
by Bob Stricklin 16 Jan '24

16 Jan '24

Chris, Your comments are the direction we need to move towards. I would like to just hack out what I can to make it build and load so I can test chip interface. Will be looking at doing this. I want to get to the point that when I take something out that green bar moves to the left. This bar is red when you exceed available memory and probably yellow just before you do. I worry the bar is based on inputs and not actual linker results. I agree constants want help much but if there are any tables of fixed data that can be helpful. The other thing to do is code with numbers and not use variables. Again, not much savings but just a coding style. The heap space and swap is set for 0x800 each. I tried making this 0x100 each and did not see a change in the Green bar. This seems like a problem. Bob From: Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Tuesday, January 16, 2024 10:39 AM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW I expect the code could be drastically optimized to reduce memory usage. It's fairly complex and I opted for simple static memory allocation. But there is plenty of duplication. Each task makes a copy of the received packet in an RTOS queue and likely in a temp buffer as well. In theory we could collapse all of that into one shared queue/buffer. In the short term you can reduce the heap size as Burns said. You could also remove some of the tasks temporarily as they each have a stack. The stack sizes can also probably be trimmed back in some cases as no optimization has been done. Most of the Globals are in MRAM but get mirrored in RAM. We could stop doing that but I doubt it is a lot of space. Finally we keep an index of the directory in the heap which does increase its size. We could remove that and only iterate over MRAM but that requires some redesign as it needs to be sorted by upload time. 73 Chris the On Mon, Jan 15, 2024, 16:01 Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Looks like we have an issue with memory usage in RAM. If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA47C3.B189E4D0] ----------------------------------------------------------- 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

1 0

Faking Memory Size
by Bob Stricklin 16 Jan '24

16 Jan '24

You can see the file I edited and the change I made to make CCS build the project so I could see how much memory it used. This file and info is initially supplied by HCG. I am getting exact same information I see in Launchpad code and I see no reason for it to be much different. Bob

1 0

Memory File Linker
by Bob Stricklin 16 Jan '24

16 Jan '24

Burns, Tied up with doctors visit here earlier. Going to forward a couple of files related to this. I do not see a MAP file generated by the Linker. I feel there should be one some place. The only thing I see related to this is the Memory Allocation relating memory use to code routines. Using the same input of code here used by Launchpad and PacSatSW project with HCG changes. I plan to put my code on GitHub today. Have not tried to manually modify the Memory Map file. I have project set for automatic and my understanding is CCS does this for you. I will send a second email showing changes I made to make CCS think I had more memory and build project. Bob

1 0

Re: Memory Problem on PacSatSW
by Burns Fisher (AMSAT) 16 Jan '24

16 Jan '24

Just a reminder, Chris, that if you are using the OS heap (as gets used for stacks) reducing what you request will not reduce the memory that the linker sees being used. You have to also reduce the heap size. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Jan 16, 2024 at 11:38 AM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I expect the code could be drastically optimized to reduce memory usage. > It's fairly complex and I opted for simple static memory allocation. But > there is plenty of duplication. Each task makes a copy of the received > packet in an RTOS queue and likely in a temp buffer as well. In theory we > could collapse all of that into one shared queue/buffer. > > In the short term you can reduce the heap size as Burns said. You could > also remove some of the tasks temporarily as they each have a stack. The > stack sizes can also probably be trimmed back in some cases as no > optimization has been done. > > Most of the Globals are in MRAM but get mirrored in RAM. We could stop > doing that but I doubt it is a lot of space. > > Finally we keep an index of the directory in the heap which does increase > its size. We could remove that and only iterate over MRAM but that > requires some redesign as it needs to be sorted by upload time. > > 73 > Chris the > > > On Mon, Jan 15, 2024, 16:01 Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Looks like we have an issue with memory usage in RAM. >> >> >> >> If you load up CCS with the current project PacSatSW and build it then >> you can select VIEW -> Memory Allocation and look at the tab. You will see >> the package needs 154K or RAM and the Launpad has 191K. In the case of the >> TMS570LS0914 we have 128K max. >> >> You can expand RAM and the subfolders and see where the memory is being >> used. >> >> >> >> I worked for the last few days getting a HalCoGen setup for the LS0914 >> and then murging this HCG file with the code of the Launcpad project. After >> working through some issues it built but when it ran the linker it errored >> out with not enough memory. So faked it out and told the linker I had more >> memory. Then it would build and generate a .out file and the Memory >> Allocation info. It matches the launch pad build. >> >> >> >> Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, >> move buffers to external memory, or take out code. >> >> >> >> I will be looking for things here to try and complete a basic build of >> the code for the LS0914. Please look for ideas and post any that you come >> up with. We probably should target RAM usage at about 80% of the max or >> about 100KB. We could change processors later but that would need some >> study. >> >> >> >> Bob >> >> >> >> >> ----------------------------------------------------------- >> >> 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 >

1 0

Re: Memory Problem on PacSatSW
by Chris Thompson 16 Jan '24

16 Jan '24

I expect the code could be drastically optimized to reduce memory usage. It's fairly complex and I opted for simple static memory allocation. But there is plenty of duplication. Each task makes a copy of the received packet in an RTOS queue and likely in a temp buffer as well. In theory we could collapse all of that into one shared queue/buffer. In the short term you can reduce the heap size as Burns said. You could also remove some of the tasks temporarily as they each have a stack. The stack sizes can also probably be trimmed back in some cases as no optimization has been done. Most of the Globals are in MRAM but get mirrored in RAM. We could stop doing that but I doubt it is a lot of space. Finally we keep an index of the directory in the heap which does increase its size. We could remove that and only iterate over MRAM but that requires some redesign as it needs to be sorted by upload time. 73 Chris the On Mon, Jan 15, 2024, 16:01 Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Looks like we have an issue with memory usage in RAM. > > > > If you load up CCS with the current project PacSatSW and build it then you > can select VIEW -> Memory Allocation and look at the tab. You will see the > package needs 154K or RAM and the Launpad has 191K. In the case of the > TMS570LS0914 we have 128K max. > > You can expand RAM and the subfolders and see where the memory is being > used. > > > > I worked for the last few days getting a HalCoGen setup for the LS0914 and > then murging this HCG file with the code of the Launcpad project. After > working through some issues it built but when it ran the linker it errored > out with not enough memory. So faked it out and told the linker I had more > memory. Then it would build and generate a .out file and the Memory > Allocation info. It matches the launch pad build. > > > > Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, > move buffers to external memory, or take out code. > > > > I will be looking for things here to try and complete a basic build of the > code for the LS0914. Please look for ideas and post any that you come up > with. We probably should target RAM usage at about 80% of the max or about > 100KB. We could change processors later but that would need some study. > > > > Bob > > > > > ----------------------------------------------------------- > > 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: Memory Problem on PacSatSW
by Bob Stricklin 16 Jan '24

16 Jan '24

I am working with CCS version 12.5. Bob From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, January 15, 2024 6:31 PM To: 'Pacsat Dev' <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I'm showing 80% utilization. The majority is in ucHeap (about 131k). I'll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be 'fun' to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA47F2.CE257530]

1 0

Re: Memory Problem on PacSatSW
by Bob Stricklin 16 Jan '24

16 Jan '24

OK will have a look at this. Found this note also which probably applies to us also: On MSP430 (or other) devices with limited RAM, the linker may fail to allocate the .bss or other sections allocated to RAM. The .bss section is for uninitialized global variables, and goes into RAM, along with stack (.stack) and heap (.sysmem) sections . If the code has a large number of global variables, you may run out of RAM space. If this is the case, you may consider making some of the variables const so they go into the .const section instead (which gets placed in FLASH instead of RAM). From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, January 15, 2024 6:38 PM To: Jim McCullers <wa4cwi(a)bellsouth.net> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW When you mentioned the heap, you reminded me: FreeRTOS has a heap, which is essentially just a big array. The only thing it gets used for is allocating task stacks and the structures that represent semaphores, queues, etc. And they way that I have used the OS, they get allocated but never released. But the thing I meant to say is that allocating smaller stacks does not use less memory from the linker's point of view because the array that the stacks are allocated from is not changed. There is a routine you can use to ask how much heap is free. After it is all booted up, unless the new code uses it differently than I did, any "free heap" is wasted. I think the size of the heap is an OS parameter in one of the free rtos header files. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Jan 15, 2024 at 7:31 PM Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I’m showing 80% utilization. The majority is in ucHeap (about 131k). I’ll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be ‘fun’ to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA47F2.8D773AF0] ----------------------------------------------------------- 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

1 0

Re: Memory Problem on PacSatSW
by Burns Fisher (AMSAT) 16 Jan '24

16 Jan '24

When you mentioned the heap, you reminded me: FreeRTOS has a heap, which is essentially just a big array. The only thing it gets used for is allocating task stacks and the structures that represent semaphores, queues, etc. And they way that I have used the OS, they get allocated but never released. But the thing I meant to say is that allocating smaller stacks does not use less memory from the linker's point of view because the array that the stacks are allocated from is not changed. There is a routine you can use to ask how much heap is free. After it is all booted up, unless the new code uses it differently than I did, any "free heap" is wasted. I think the size of the heap is an OS parameter in one of the free rtos header files. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Jan 15, 2024 at 7:31 PM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > My version of CSS is either different or how did you turn on the green > lines with summary data? > > I get a popup status message with similar info but not as stable or > detailed as yours. > > > > On my system, I’m showing 80% utilization. > > The majority is in ucHeap (about 131k). > > I’ll bet on a function somewhere allocating a chunk of memory or > repeatedly doing so and never using or releasing it. > > Should be ‘fun’ to find. > > > > Jim McCullers > > WA4CWI > > > > > > > > Looks like we have an issue with memory usage in RAM > > > > If you load up CCS with the current project PacSatSW and build it then you > can select VIEW -> Memory Allocation and look at the tab. You will see the > package needs 154K or RAM and the Launpad has 191K. In the case of the > TMS570LS0914 we have 128K max. > > You can expand RAM and the subfolders and see where the memory is being > used. > > > > I worked for the last few days getting a HalCoGen setup for the LS0914 and > then murging this HCG file with the code of the Launcpad project. After > working through some issues it built but when it ran the linker it errored > out with not enough memory. So faked it out and told the linker I had more > memory. Then it would build and generate a .out file and the Memory > Allocation info. It matches the launch pad build. > > > > Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, > move buffers to external memory, or take out code. > > > > I will be looking for things here to try and complete a basic build of the > code for the LS0914. Please look for ideas and post any that you come up > with. We probably should target RAM usage at about 80% of the max or about > 100KB. We could change processors later but that would need some study. > > > > Bob > > > > > ----------------------------------------------------------- > > 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: Memory Problem on PacSatSW
by Jim McCullers 16 Jan '24

16 Jan '24

My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I'm showing 80% utilization. The majority is in ucHeap (about 131k). I'll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be 'fun' to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob

1 0

Re: Memory Problem on PacSatSW
by Burns Fisher (AMSAT) 15 Jan '24

15 Jan '24

Is there a variant of the TMS570LS0914 that has more memory? That might be the easiest fix. Note that what you call "external memory", really MRAM, is relatively slow. MRAM is also fairly small. It's big advantage is that it is non-volatile and fairly radiation resistant (and has a lot of space heritage with AMSAT and others). 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Jan 15, 2024 at 4:16 PM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Since it ran and worked I never explored memory usage. > > I have to reconnect the development system and will cross check your > findings. > > That’s far more ram than I would have expected. > > > > Jim > > WA4CWI > > > > > > Looks like we have an issue with memory usage in RAM > > > > If you load up CCS with the current project PacSatSW and build it then you > can select VIEW -> Memory Allocation and look at the tab. You will see the > package needs 154K or RAM and the Launpad has 191K. In the case of the > TMS570LS0914 we have 128K max. > > You can expand RAM and the subfolders and see where the memory is being > used. > > > > I worked for the last few days getting a HalCoGen setup for the LS0914 and > then murging this HCG file with the code of the Launcpad project. After > working through some issues it built but when it ran the linker it errored > out with not enough memory. So faked it out and told the linker I had more > memory. Then it would build and generate a .out file and the Memory > Allocation info. It matches the launch pad build. > > > > Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, > move buffers to external memory, or take out code. > > > > I will be looking for things here to try and complete a basic build of the > code for the LS0914. Please look for ideas and post any that you come up > with. We probably should target RAM usage at about 80% of the max or about > 100KB. We could change processors later but that would need some study. > > > > Bob > > > > > ----------------------------------------------------------- > > 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: Memory Problem on PacSatSW
by Jim McCullers 15 Jan '24

15 Jan '24

Since it ran and worked I never explored memory usage. I have to reconnect the development system and will cross check your findings. That's far more ram than I would have expected. Jim WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob

1 0

Memory Problem on PacSatSW
by Bob Stricklin 15 Jan '24

15 Jan '24

Looks like we have an issue with memory usage in RAM. If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA47C3.B189E4D0]

1 0

Re: Using the Load-Pull Technique in RF Power Amplifier Design - Technical Articles
by Jim McCullers 13 Jan '24

13 Jan '24

Will give it read. Thanks Jim

1 0

Using the Load-Pull Technique in RF Power Amplifier Design - Technical Articles
by Bob Stricklin 13 Jan '24

13 Jan '24

https://www.allaboutcircuits.com/technical-articles/load-line-analysis-esti…

1 0

Re: Issue with touch in project
by Bob Stricklin 13 Jan '24

13 Jan '24

Yes, I am tracking Problems and also watching Console as things compile and post. Errors show up in Console that do not make it to Problems I noticed. I am now getting a clean build. You can turn all windows on in View Tab and with the icons on the left of screen. CCS arbitrarily turns them off I notice. Probably a way to override this with a personal IDE setup. I think under Window. I am not trying to say I have masted this. Still learning. Like I use the project view all the time and finally found the paste/folder icon on the left brings it up. I was using Window - ShowView. I have learned we are good on I2C and the Serial Port. Just have to check addresses used in CCS devices . H files. Working on SPI for AX5043s now and making sure there are no outputs in HalCoGen config on pins that will be driving outputs from other devices. I see what needs to be done just need to work through it. Hope to try testing this tomorrow. Any feedback is appreciated. I posted an order to mouser today for a few parts needed. Will have them Monday Maybe. Weather here may stop delivery. Ice possible. Bob On Jan 12, 2024, at 3:09 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Of course it is always difficult to find featuers in Eclipse-based IDEs, but on my CCS, there is a tab labelled "Problems" when I compile. That clearly shows all the compile errors. I think you can get it turned on by the menu (3 vertical dots) on that window below the source editor. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Fri, Jan 12, 2024 at 3:52 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Thank you for the posting Burns. I moved my CCS file from Windows back to Linux. Then I removed the touch in preconfigure and built the project. BTW it had my directory path there so our friends at TI may have played this touch command there. i see some error msg go by but can not find them after build is complete and I get a out file. Moved the project back to Windows and built there now I do not see an issue and I get a out file. I will continue to use HCG to try and make changes now to setup the serial port for this PCB build. I need to be able to go in and out of HCG and rebuild the project to get all the hardware changes made. I will be carefully saving copy of the project to make sure I do not have issues. One of the things I have done is to remove all references to CAN from the project. I have renamed it PacSat_DevSW. Bob On Jan 12, 2024, at 8:18 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: That location on disk is on my Linux build system. Most things one writes in the IDE you can talk about relative to the base directory of the code (see for example the way header file locations are specified) but either I added this before I knew about talking about the base, or it is not possible (since this looks like it might be a shell script). The only reason for this was so that when you boot the software and/or do "show status" I think, it would tell you when it was built. The idea is that this would tell you if the code might be different even if you did not update the version number. As I recall, there is a built-in in gcc that, at compile time, creates as text the current time and gcc version. I just use those as constants to print. I don't know why you get errors when you remove it. What kind of errors? But certainly you could replace my location with your own. Or perhaps (even better) there is a symbol you can use for the base location of the project in any build environment. (Actually, touch is a Linux command, so this would probably not work on Windows???) 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Jan 11, 2024 at 11:05 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Burns, It seems to me this line of code is referring to a folder that would be on the users system under his home directory called gitRepos. I have looking in Windows under user and my name (home folder) and on my linux computer which I built this code and not seeing this on either one. I do see errors referring to the touch. When I remove it I have lots of errors. It looks like something that was put in place a long time ago when the project was just rt-ihu. With the line in place the project will build but I don’t like seeing the errors. I have used touch to force creation of a file but did not know you could sweep through a project and update times to current time. I see it is used for this according to "man touch". I wonder if an older version of CCS was not handling time the way people wanted and this was a work around? Maybe I could fix this by changing the touch path to match my current system project path info. Am I really that worried about changing a time stamp? Strange how this causes issue when removed. Maybe the Makefile is not keeping up with project properties changes real time. Changing all the dates would force a make -B I haven’t figured out if Build Project generates a new Makefile on every build cycle. Bob On Jan 11, 2024, at 9:42 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I think console routines fetches the time that the compile happened, so rebuilding it forces it to include the time of the compile regardless of whether anything else has changed in that routine. Touch should just change the date on the file so make will always compile it. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Jan 11, 2024 at 10:38 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: <PacSatSW_Issue.jpeg> Here is the location of the “touch” issue? What is this for? Why does it break things if you remove it? ----------------------------------------------------------- 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<https://mailman.amsat.org/> ----------------------------------------------------------- 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<https://mailman.amsat.org/> ----------------------------------------------------------- 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<https://mailman.amsat.org/> ----------------------------------------------------------- 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 <Screenshot from 2024-01-12 16-06-11.png> ----------------------------------------------------------- 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: Issue with touch in project
by Burns Fisher (AMSAT) 12 Jan '24

12 Jan '24

Of course it is always difficult to find featuers in Eclipse-based IDEs, but on my CCS, there is a tab labelled "Problems" when I compile. That clearly shows all the compile errors. I think you can get it turned on by the menu (3 vertical dots) on that window below the source editor. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Jan 12, 2024 at 3:52 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Thank you for the posting Burns. > > I moved my CCS file from Windows back to Linux. Then I removed the touch > in preconfigure and built the project. BTW it had my directory path there > so our friends at TI may have played this touch command there. > > i see some error msg go by but can not find them after build is complete > and I get a out file. > > Moved the project back to Windows and built there now I do not see an > issue and I get a out file. > > I will continue to use HCG to try and make changes now to setup the serial > port for this PCB build. > > I need to be able to go in and out of HCG and rebuild the project to get > all the hardware changes made. I will be carefully saving copy of the > project to make sure I do not have issues. > > One of the things I have done is to remove all references to CAN from the > project. I have renamed it PacSat_DevSW. > > Bob > > > On Jan 12, 2024, at 8:18 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> wrote: > > That location on disk is on my Linux build system. Most things one writes > in the IDE you can talk about relative to the base directory of the code > (see for example the way header file locations are specified) but either I > added this before I knew about talking about the base, or it is not > possible (since this looks like it might be a shell script). > > The only reason for this was so that when you boot the software and/or do > "show status" I think, it would tell you when it was built. The idea is > that this would tell you if the code might be different even if you did not > update the version number. As I recall, there is a built-in in gcc that, > at compile time, creates as text the current time and gcc version. I just > use those as constants to print. > > I don't know why you get errors when you remove it. What kind of errors? > But certainly you could replace my location with your own. Or perhaps > (even better) there is a symbol you can use for the base location of the > project in any build environment. (Actually, touch is a Linux command, so > this would probably not work on Windows???) > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Thu, Jan 11, 2024 at 11:05 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Burns, >> >> It seems to me this line of code is referring to a folder that would be >> on the users system under his home directory called gitRepos. >> I have looking in Windows under user and my name (home folder) and on my >> linux computer which I built this code and not seeing this on either one. >> I do see errors referring to the touch. When I remove it I have lots of >> errors. >> >> It looks like something that was put in place a long time ago when the >> project was just rt-ihu. >> >> With the line in place the project will build but I don’t like seeing the >> errors. >> >> I have used touch to force creation of a file but did not know you could >> sweep through a project and update times to current time. I see it is used >> for this according to "man touch". >> >> I wonder if an older version of CCS was not handling time the way people >> wanted and this was a work around? >> >> Maybe I could fix this by changing the touch path to match my current >> system project path info. >> >> Am I really that worried about changing a time stamp? >> >> Strange how this causes issue when removed. Maybe the Makefile is not >> keeping up with project properties changes real time. >> Changing all the dates would force a make -B >> I haven’t figured out if Build Project generates a new Makefile on every >> build cycle. >> >> Bob >> >> >> On Jan 11, 2024, at 9:42 PM, Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> I think console routines fetches the time that the compile happened, so >> rebuilding it forces it to include the time of the compile regardless of >> whether anything else has changed in that routine. >> >> Touch should just change the date on the file so make will always compile >> it. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Thu, Jan 11, 2024 at 10:38 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> <PacSatSW_Issue.jpeg> >>> >>> Here is the location of the “touch” issue? >>> >>> What is this for? >>> >>> Why does it break things if you remove it? >>> >>> ----------------------------------------------------------- >>> >>> 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 >> >> >> >> ----------------------------------------------------------- >> >> 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 >

1 0

Re: Issue with touch in project
by Burns Fisher (AMSAT) 12 Jan '24

12 Jan '24

That location on disk is on my Linux build system. Most things one writes in the IDE you can talk about relative to the base directory of the code (see for example the way header file locations are specified) but either I added this before I knew about talking about the base, or it is not possible (since this looks like it might be a shell script). The only reason for this was so that when you boot the software and/or do "show status" I think, it would tell you when it was built. The idea is that this would tell you if the code might be different even if you did not update the version number. As I recall, there is a built-in in gcc that, at compile time, creates as text the current time and gcc version. I just use those as constants to print. I don't know why you get errors when you remove it. What kind of errors? But certainly you could replace my location with your own. Or perhaps (even better) there is a symbol you can use for the base location of the project in any build environment. (Actually, touch is a Linux command, so this would probably not work on Windows???) 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Jan 11, 2024 at 11:05 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > It seems to me this line of code is referring to a folder that would be on > the users system under his home directory called gitRepos. > I have looking in Windows under user and my name (home folder) and on my > linux computer which I built this code and not seeing this on either one. > I do see errors referring to the touch. When I remove it I have lots of > errors. > > It looks like something that was put in place a long time ago when the > project was just rt-ihu. > > With the line in place the project will build but I don’t like seeing the > errors. > > I have used touch to force creation of a file but did not know you could > sweep through a project and update times to current time. I see it is used > for this according to "man touch". > > I wonder if an older version of CCS was not handling time the way people > wanted and this was a work around? > > Maybe I could fix this by changing the touch path to match my current > system project path info. > > Am I really that worried about changing a time stamp? > > Strange how this causes issue when removed. Maybe the Makefile is not > keeping up with project properties changes real time. > Changing all the dates would force a make -B > I haven’t figured out if Build Project generates a new Makefile on every > build cycle. > > Bob > > > On Jan 11, 2024, at 9:42 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I think console routines fetches the time that the compile happened, so > rebuilding it forces it to include the time of the compile regardless of > whether anything else has changed in that routine. > > Touch should just change the date on the file so make will always compile > it. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Thu, Jan 11, 2024 at 10:38 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> <PacSatSW_Issue.jpeg> >> >> Here is the location of the “touch” issue? >> >> What is this for? >> >> Why does it break things if you remove it? >> >> ----------------------------------------------------------- >> >> 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 > > > > ----------------------------------------------------------- > > 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

First pass at 2024 budget
by Bill Reed 12 Jan '24

12 Jan '24

Zach, here is my budget thinking at this point. Let's discuss when you can. Pacsat dev team please comment. *AMSAT Engineering Pacsat Project 2024 Budget submitted by NX5R Circuit Board Production - Pacsat AX5043 based design, Cubesat 1U, 92mm X92mm, PC104 interface. 2 production runs during 2024. 4-5 boards manufactured Spring 2024. 5-6 boards manufactured October 2024. - Total $24,000.* *JTAG support Hardware - Support hardware for 8 programmers. - Total $300* *AX5043 Inventory - The AX5043 went out of production in 2023. Parts are still available from some sources. We need to build inventory to protect our current design. - Total $5000* *Shipping and Miscellaneous parts - Estimate - Total $500 * *Marketing and Deployment - Promotion of Pacsat product and launch support. Travel for team members. Brochures and other printing costs. - Total $14,000 Total 2024 Budget = $43,800.*

1 0

Re: Issue with touch in project
by Bob Stricklin 12 Jan '24

12 Jan '24

Burns, It seems to me this line of code is referring to a folder that would be on the users system under his home directory called gitRepos. I have looking in Windows under user and my name (home folder) and on my linux computer which I built this code and not seeing this on either one. I do see errors referring to the touch. When I remove it I have lots of errors. It looks like something that was put in place a long time ago when the project was just rt-ihu. With the line in place the project will build but I don’t like seeing the errors. I have used touch to force creation of a file but did not know you could sweep through a project and update times to current time. I see it is used for this according to "man touch". I wonder if an older version of CCS was not handling time the way people wanted and this was a work around? Maybe I could fix this by changing the touch path to match my current system project path info. Am I really that worried about changing a time stamp? Strange how this causes issue when removed. Maybe the Makefile is not keeping up with project properties changes real time. Changing all the dates would force a make -B I haven’t figured out if Build Project generates a new Makefile on every build cycle. Bob On Jan 11, 2024, at 9:42 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I think console routines fetches the time that the compile happened, so rebuilding it forces it to include the time of the compile regardless of whether anything else has changed in that routine. Touch should just change the date on the file so make will always compile it. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Jan 11, 2024 at 10:38 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: <PacSatSW_Issue.jpeg> Here is the location of the “touch” issue? What is this for? Why does it break things if you remove it? ----------------------------------------------------------- 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<https://mailman.amsat.org/> ----------------------------------------------------------- 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

1 0

Re: Issue with touch in project
by Burns Fisher (AMSAT) 12 Jan '24

12 Jan '24

I think console routines fetches the time that the compile happened, so rebuilding it forces it to include the time of the compile regardless of whether anything else has changed in that routine. Touch should just change the date on the file so make will always compile it. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Jan 11, 2024 at 10:38 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > > Here is the location of the “touch” issue? > > What is this for? > > Why does it break things if you remove it? > > ----------------------------------------------------------- > > 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

Issue with touch in project
by Bob Stricklin 12 Jan '24

12 Jan '24

[cid:27FC6D12-DABD-4B1A-8483-A2D48DEE25D3@StricklinRanch.com] Here is the location of the “touch” issue? What is this for? Why does it break things if you remove it?

1 0