Many times I find it hard to find the information I want in to blog among the other entries. These tags will help to flag important information, to filter some of the more trivial stuff out(if you want more added to the list I will edit this post):
#NOTE: Something interesting that was found
#IMPROVE: Something that needs optimization
#FUTURE: Something that you want to remember to look into
#ATTENTION: Something that you want the other people on the project to read
#LIMITATION: For noting limiting factors such as memory constraints and what not
- Working on changes to ComUtil. Since the basic communication should work independent of all the other stuff sent over the wire, the state and size of the potential incoming packet will be transferred in the smallest way possible.
- Made the following changes to ComMgr:
- Made send and recieve as simple as possible so ComUtil does all the heavy lifting
- Took out all buffers at this level. The pointer to the buffer is passed into the methods
- After trying to figure out how to do this and writing and rewriting the same part, I decided to model this class after the typical controller.
- This class does not inherit from controller because I wanted it to be lighter weight
- This class also runs in Master and Slave mode. In the case of this program the PC will always be flagged master and the Arduino will be the slave. The master controls the uid incrementing and the slave always echos.
- A large buffer will be broken into smaller packets
- decided since the buffer was a static size, it made sense to just send the packets in a way to match that size. Its currently send 4 packets of 128 bytes regardless of if its full or not. I can change this later if there are speed issues.
- Finishing up ComMgr(Arduino)
- Designated some flags for blog entries to make finding important information easier.
#IMPROVE: ComMgr(PC) needs a non-blocking receive
#IMPROVE: Send and recieve expect the whole 512 buffer split into 4 128byte parts. This can be done more efficiently if needed.
8:30 – 4:30 FP
- Asked Dong to look at setting up the first pass of the chart applet using the potatoland.org/gl code as a possible foundation, since it seems to be the best example of working text overlays.
- Getting openGL running in FLTK, then porting the hand
- Got the CubeView program compiling and linking. To do this, I pointed the “additional include directories” to point to C:/FLTK/branch1.3, which has FL/ underneath it. Then I pointed the “additional libraries directories” to C:/FLTK/branch1.3/lib. The last thing I had to do was point at the proper libraries (note that these are debug directories):
- Once I got the system running, there were piles of “PDB” warning messages (i.e. “‘C:WindowsSysWOW64ntdll.dll’, Cannot find or open the PDB file “). You can fix these by getting the debug symbol tables from microsoft:
- Choose Debugging->Symbols from the list, then check “Microsoft Symbol Servers” then click OK and rebuild. Here’s a screenshot
- Having an odd problem with setting the background color. I need to set the glClearColor() in the predraw, before every frame, otherwise it comes up as black. Not sure why.
- Turns out that in FLTK GL windows, the graphics context is reset after things like a resize. THis means that the init code can’t be in the constructor, but rather needs to be in the draw function in the following way:
glEnv->init(w(), h()); // called when the context
// has been (re)created
Primary Goal: Get the controller test to work across the wire.
- Adding a isDirty flag is not as easy as it would seem. The only real link between the entry and the data is the void pointer.
- Added a new method for setting commands to the DataDictionary. The parameters for this method are the dd entry name and the command you want to set. Since we are using explicit command objects to set the command, we don’t need validation. If I go back and optimize memory usage, I will have to change this.
- I didn’t want to send an empty buffer when nothing was there, but it seems readfile requires data to be received or it waits there forever.
- In order to keep it synchronized at the start, the arduino does not start sending data until it recieves a empty packet from the pc. I can see the light flash showing the computer sending the packet, but it doesn’t change the state to start sending.
- The internal serial buffer of the arduino is only 128 bytes… Well I guess that is the solution to a ton of problems. I am going to have to change the way things work, to send each data item individually. Oh well, after yesterdays memory problems, I realized this would probably be the better route anyways.
- For some reason, the project isn’t recognizing that I changed the library which holds commgr to have a buffer of 128. Its overflowing the ComUtil and causing it to become corrupted.
- Need to try to find a non blocking serial method for windows
Arduino serial packets can only be 128bytes each. Larger items will have to be sent in multiple packets, but it should be large enough for most.
You must be logged in to post a comment.