Crash Course/Documentation on Station Code Flow?

[kjones27]

I've started poking around the code on the pi, to try to make sense of the flow of things, and what I'll need to change for RTE. Is there any kind of documentation or a quick crash course in how the code flows? I'm sure I can figure it out on my own, but If anyone had any tips for speeding up the process, I'm all ears. :)

I looked at the readme.txt, and some of the references in there (sve) seemed maybe outdated? Unless I'm missing something.

Also, how are folks developing for the stations? Linux? Windows? Text editor? PyDev? etc? Any tips for troubleshooting python code (I'm sure I'll be debugging the LCD and button interaction).

[ellerychan]

I'm happy to help where I can, since I did the LCD-specific code. However, I don't know that I ever really got my head around the common framework that runs all the stations. Somehow, I was able to figure out where to stick my bits of code so they ran at the right times.

I agree, that it is a small display. It is also a pretty slow display, so it is difficult to do any nice animation.

Given those constraints, I think a dialogue style of interaction works better. If you look at my code you will see my attempt at setting up that sequence of interactions. I hope I made a little flow diagram or something to help explain what is going on. Probably the base sequencing mechanism could be enhanced to be more configurable and less messy. (I haven't looked at the code since before the last competition, so I hope I'm not being inaccurate.)

I did my development in Eclipse/PyDev on a laptop. It can be Windows or Linux. I set it up to automatically copy the files over to the Pi when they were saved from Eclipse (by configuring the build rules to rsync the files to the Pi). I would have multiple windows on my desktop ssh'ed into the Pi running tail -f on the relevant log files. So if you are on Windows, you will want to install Cygwin.

My debugging was mostly via adding temporary log messages. I never tried running a Python IDE on the Pi. If you did, then Eclipse would be a bad choice.

[DragonmasterJ]

When you mention code flow, do you mean the CTS in particular (Ellery's expertise), or the whole station-server system in general (Jawaad's expertise)?

I may have some notes from last year hiding on my virtual machine regarding the latter, so I will try to dig them up. Most likely we need to create something better anyway.

As far as developing, I used an Ubuntu virtual machine which was also my "virtual station". I did my python editing with Spyder. Since access to the pi hardware will be easier this year, I may stick with Windows and Eclipse w/PyDev or IDLE (my machine is coming in years and I'm now scared to run the VM).

[jawaad-ahmad]

I should be able to help as well regarding any questions. Yes, some of the info probably is outdated. (Sorry!) Anytime you're free please let me know and I can give you an overview; I'll have to jog my own memory by looking at the code myself.

How are folks developing for the stations?

I started on my Linux laptop then switched to developing directly on the RPi, but tried to maintain the Linux side so I could continue to run without any hardware when necessary. While on the RPi, I mounted the directory using sshfs so I could cd into it from my laptop and modify files directly (similar to NFS but no extra packages needed to be installed).

I believe I used a text editor at the time. If I used PyDev, Eclipse, or another IDE, it wouldn't have mattered that I was on the RPi because it would've been transparent over sshfs.

Same thing as Ellery regarding the tail -f windows.

Any tips for troubleshooting python code (I'm sure I'll be debugging the LCD and button interaction).

For newbies like me, have an active Internet connection for Google searches. :)

When you mention code flow, do you mean the CTS in particular (Ellery's expertise), or the whole station-server system in general (Jawaad's expertise)?

I wonder if @kjones27 means starting from main and walking through everything.

I may have some notes from last year hiding on my virtual machine regarding the latter, so I will try to dig them up. Most likely we need to create something better anyway.

How about posting that on the wiki?

[DragonmasterJ]

Whoops, fell behind on this one. I have some basic notes about the states, I thought I had more but maybe I was just using that and the spec information to fill my knowledge gaps. Edit: I have to check it again, but the state information was really basic, aside from including some investigation addressing whether we had wanted more states under certain circumstances.

Maybe we could dress it up as a state diagram and actually add some details regarding the the system between the master server, the connection code, and the stations? Then we could naturally bring that down lower to the code flow of the station code itself.

I'd also have to dig through the code to remember it, but making the diagrams will help in the future (easier refresher for us and more helpful for someone else in my position last year).

Don't know if that would fully address the needs based on this post though. Thoughts?

[ellerychan]

When I was starting to write station code, I needed to know the basic architecture of the station framework:

• Is it one thread or multiple concurrent threads?
• What is the control flow?
  • How and when does it receive messages?
  • What happens when it receives a message?
  • Where do I put my code so it gets executed?
  • When do I have to relinquish control?

I made some assumptions and guesses, and through trial-and-error was able to insert my code into the proper places. But I don't think I ever really got a clear picture of the structure of the program. Pretty sure I never found the main event dispatch loop or knew how to extend it if, say, I had to add a new message handler.

Anyway, that's what I wanted to see last year.

[kjones27]

Sorry for the delay. Let me answer some of these questions, so you get an idea of what I'm looking for:

When you mention code flow, do you mean the CTS in particular (Ellery's expertise), or the whole station-server system in general (Jawaad's expertise)?

I mean both, actually. If I knew the latter (station-server system in general), I could probably find the CTS code. But, as it is, I was struggling to find the CTS code last weekend. Again, given enough time I'll figure it out, but I was hoping I could leverage the brain nuggets y'all have, to expedite the process. :-)

I did my python editing with Spyder.

@DragonmasterJ Did you install and run this on the pi?

I wonder if @kjones27 means starting from main and walking through everything.

Yeah, that's kinda what I meant.

Anytime you're free please let me know and I can give you an overview;

@jawaad-ahmad I think a little sit-down would be great. I'm not sure what your availability is, but I'm free after work today. I could trek over to the HTC, if that works for you. I definitely appreciate the offer.

And I echo @ellerychan 's basic architecture questions.

[ellerychan]

The CTS-specific code is here.

The LCD display driver interface code his here in the Display class.

It utilizes the 3rd party Adafruit_CharLCD module which actually talks to the hardware. You would only need to look at that to understand the hardware capabilities when you get to the point of squeezing more out of the display.

[ellerychan]

One other thing about the CTS station configuration: During development, it was difficult sometimes to know what state the Pi is in. And as I was trying to do my development without having a display connected directly to the Pi, it was very useful to know the IP address of the station. Because the CTS has an attached display, I put a startup script in the appropriate place (I forget exactly where that is), that is supposed to display the IP address on the LCD when the machine comes up. I don't know that it always gets it right, especially with WiFi vs Ethernet. But it definitely was helpful when it worked, because it gave the address I could use to ssh in.

[kjones27]

Thanks, @ellerychan. That's helpful! I don't remember an IP address popping up on the LCD, but that could be because I don't have it configured for my wifi network, which is something else I need to get set up/figure out. I assume, once it's on a network, the IP address will display, which will make the ssh-ing, as you described easier.

[ellerychan]

As I recall, the WiFi stuff could be finicky. It also helps to have a WiFi dongle with the flashing LED. You can learn to recognize when there is a connection from the flickering. Not all had the LED.

[DragonmasterJ]

Did you install and run this on the pi?

No I didn't use the physical pi when I was coding last year. I used my Ubuntu VM to simulate the pi, and then used the same process that we discussed today to mock the other stuff. So I just did the python on the VM too, since a coworker suggested Spyder when he did pi development in Linux.

@ellerychan I saw you mentioned the state diagram you made from last year in the RTE issue. I slightly remember that, which is probably why my state notes didn't have one with them. Hopefully you can find it!

[ellerychan]

You can't get too far developing the LCD code without running it on the real hardware. However, I did my editing on a laptop attached to a big screen, and just ran it on the Pi.

I'm looking for the diagram, but no luck yet.

[DragonmasterJ]

Should've put more context with that blockquote. I used the VM because it was viable for the HMB. Hence I just did my programming in it too (and it allowed me to use git directly in terminal).

[jawaad-ahmad]

it allowed me to use git directly in terminal

FYI for anyone interested Atlassian has a free tool called SourceTree that's an approved tool for us. Submit a software request if interested in trying it out. It appears to be the Git equivalent of ClearCase Explorer. If I recall it only runs on Windows and Mac.

[ellerychan]

@kjones27: I created a branch to add a new CTS state transition diagram. I created a new Pull Request Add CTS state transition diagram. Pull Request #15 to add it to the repository. If you think it should go into the Wiki instead we can withdraw the Pull Request. If you want to keep it, you can merge it into hsdc-2016.

I looked a lot but couldn't find the original, so I had to reverse engineer it to make a new one. Including it here because GitHub lets me put a PNG image in a comment (but not an SVG):

[DragonmasterJ]

@thoughtmonk Here's the other information related to starting up with the RTE.