Ideas/guidelines for microcontroller code

[James Irwin]

Here is where we begin design for our microcontroller code. We are writing code for the old sub's hardware, getting it up and running so that the CS team can begin testing their code in the water as soon as they are ready.Keep in mind that we might be using a microcontroller on the new sub, so move constants to header files where appropriate, and write all code with the idea of future migration in mind.

Communication calls must be interrupt based whenever possible. 

The big problem last year was that the original microcontroller code was written using the chipKIT/Arduino software libraries, so all functions were blocking and this ended up being extremely inefficient. We have to avoid this. This means we must spend a good amount of time thinking about the best way to solve this problem, and people should post ideas on this thread.

 We will be programming in C for Microchip microcontrollers, I would recommend downloading MPLAB for development.

 So here are the first things we need to work on right now (not necessarily in order):

• post ideas for how to manage interrupt-based communication while talking to multiple sensors
• read about the format of the data that will be coming out of each sensor
• read about how to configure the SPI/I2C/UART hardware devices on the PIC32 architecture (Microchip PIC32MX795F512 in particular)

The chipKIT board has a UART-USB bridge chip which allows us to communicate to the main computer.

I'm going to talk to the CS team about possibly getting onto their Github repository (we may just make a subrepository), but I would like to use git for managing code. If you don't know what git is, you can read about it here: http://git-scm.com/book/en/Getting-Started

[loganpevans]

Our intention is that all code should be kept in the github repository. It's fine if you want to create a sub-repository, but I'm not aware of any compelling reason for putting it in a sub-repository. The people who can add collaborators to github are Luke, Haily, Cameron, and myself (Logan).

As for the microcontroller... I've been under the impression that the major issue with the micro-controller last year was the serial communication between the micro-controller and the main computer. We had thousands of lines of code that dealt with communication, and at the competition, it was the serial communication that was broken. The arduino is (for the most part) an interrupt free environment, which makes it a real pain to respond to hardware events. I agree that it's an issue. I'm just not sure I agree it's the main issue.

A BeagleBoneBlack has several advantages over a micro-controller (trivial communication protocol, hardware interrupt handlers, a programming environment that everyone in the club can work in, etc). Correct me if I'm wrong, but didn't we decide that we were going to do our initial designs with the assumption that we're using a BeagleBone, and that we would only go with a micro-controller if we discover some issue that the BeagleBone is unable to handle?

[James Irwin]

Sorry Logan, I see that my words were ambiguous. I meant that we would definitely be using the github repository, and that maybe we would use a subrepository. I was only thinking of using a subrepository in order to reduce clutter in the main repository (in essence, functionalize the low-level code).

I'm afraid you are mistaken concerning the issue with the microcontroller last year. There is no inherent issue with serial communication (in fact, ethernet and TCP/IP sockets use serial communication). The entire cause of the issue was the Arduino software libraries running on top of the microcontroller. This has been an inherent problem with Arduino since its development. Arduino was first and foremost designed for the allowing people who were not familiar with microcontrollers to use them. The libraries were designed for ease of use, not efficiency. No matter how good the code written last year was, it was fatally hampered by the limitations of the Arduino library. The bloated libraries simply could not respond fast enough. There is no doubt that this was the issue.

A microcontroller also has hardware interrupt handlers; in fact, it will have more than the Beaglebone and they will be more configurable with less overhead than the Beaglebone's. While communication is slightly more complex, it is not difficult by any means. Communication with the microcontroller will be slower than ethernet on the Beaglebone, but it is more than adequate for transmitting all of the data coming off of the sensors and receiving motor/pneumatic control commands. The faster communication possible with the Beaglebone will realize zero benefits in our application. You are correct that the Beaglebone presents a programming environment that everyone in the club can use. That is the only "advantage", and I'm not convinced that is a good enough reason.

We did not decide whether we would use a Beaglebone or a microcontroller. What we decided is that we would move forward and the CS team would write code that is not dependant on what hardware is chosen. This microcontroller thread is simply for getting the old sub into a working state so that we can begin water testing as soon as possible.

[luke.renaud]

Frankly I have to agree with James here. The point of this is that we have a largely completed electrical platform we’d like to hand off to you guys for software test. It simply doesn’t make sense to mandate that we do electrical rewrite two to three months in advance for a system that we haven’t done any of the preliminary architectural design, to say nothing of the electrical rework. Replacing the microcontroller on the old sub would simply force us to do work ahead of time (poorly due to the lack of foresight we have at this point in the design process) in a way that would be totally redone in a manner that would likely necessitate a software redesign at the bottom layer as well.

There is nothing to say that we need a beaglebone outright for the old sub, and the majority of the software work that needs to take place on the layers above that should be largely independent of the lower layer hardware and software. We’re simply saying that for the old design it makes far more sense to go through some software rework to an interface you guys are expecting, rather than going through a couple of months of hardware redesign that will inevitably prove to be something we’ll start replacing the moment it’s done. This doesn’t speed up development of software, and puts members on our team on tasks that will prove to be highly frustrating.

With regard to actual implementation, I'd be in favor of a design based around a prototype that James described the other day. From a software standpoint, we use a set of timer based interupts to form a scheduler (sort of) which puts requests to read sensors into a queue. If a request already exists for that sensor in the queue, it simply omits adding another one. Then a high speed ISR manages I2C bus communication going through the states of communication, and switching between which device it's interacting with as the queue dictates. If we have multiple I2C devices, then the exact same ISR could actually be used provided that the memory space storing states for each device is manged separately.

A secondary routine would be used for interfacing with the UART (i.e. PC interface) handling requests for data, and requests to change the state of thrusters. A flow chart should be available soon to help break down the idea (hopefully from James, but otherwise from me). Due to the way that the sub is currently wired, each sensor would be on the same I2C bus.

On this note, we actually will also need someone to verify shorts and wiring on the I2C communications lines on the old sensors. I know that the ACL/GYRO are wired correctly, but I'm not certain about any of the other sensors. I was pretty tired in San Diego, and I believe we had the magnetics working, but I'm not sure.

-Luke

[luke.renaud]

Also the sensors on the old sub are as follows.

I2C -> PmodACL
I2C -> PodGYRO
I2C -> MPL115A2 (http://www.adafruit.com/products/992) Temp/Preasure in Battery tube
I2C -> Switching Device (Can't remember the number)
       |-> MAG3110 (x2) (https://www.sparkfun.com/products/10619)
ADC -> Depth Sensor (Calibration will be needed, it's highly linear though)

[loganpevans]

Can you provide an estimate for how many hours it will take to implement the micro-controller approach? I'm interested in several aspects of the task:
* Communication protocol
* Sensor interaction
* Motor/pneumatic control

If there are any current blocking issues that prevent us from starting on any of these tasks, it would be nice to know what they are.

How many people do we have who will be able to write, debug, or code review the microcontroller C code? Also, a clarification question: If we are trying to get the old sub to work so that we have a platform on which to test the AI code, is that going to be using the current hardware (meaning, the arduino)? Or would the old sub need to be revised with a different micro-controller or with a BeagleBone regardless?

[James Irwin]

The chipkit development board currently installed is fine. It's just the Arduino software running on it that is bad. As Luke stated above, the advantage of this is that we won't have to replace any hardware.

We've got several people that can do microcontroller C code. I personally know Luke, Korey, Nate, Ian, and myself are all very familiar with microcontrollers. I'm not sure about Tyler and Miao. Several of the new members on the EE team say they know microcontrollers, but I have not personally seen their skills. If I've missed anyone else, please reply on this thread.

I would estimate 24-36 hours max. Most likely less.

I'm not sure what you mean by:

If there are any current blocking issues that prevent us from starting on any of these tasks, it would be nice to know what they are. 

Could you elaborate?

[loganpevans]

I only asked whether there are any current blocking issues because we need to create a work queue. (If you can specify any tasks, then you should list them here.)

Is the 24-36 hour estimate for just one part of the micro-controller rewrite, or is that for everything? Considering how much time and effort went into the communication between the main computer and the micro-controller last year (I would guess hundreds of hours), I suspect that the 24-36 hour estimate doesn't include the serial communication.

Since the micro-controller proved to be a poor design decision last year, it needs to be thoroughly justified if we're going to use it again this year. I propose that we draw up a comparison chart between the two approaches (PIC32 microcontroller and BeagleBone Black). Here are some categories that I think we need to consider:

Categories:
Cost
Communication protocol development time
Sensor reading development time
Output command development time
Development environment
Development flexibility (i.e. how easy is it to add a sensor or use a different sensor)
Available manpower (i.e. how many club members can work on the code)
Power consumption
Debugging tools
Ease of creating a mock module
Ease of communication with main computer
Educational benefit (i.e. do we gain valuable skills or breadth of knowledge by using this device)
Ability to handle large numbers of sensors
Ability to work with the old sub

Feel free to add any categories if there's something important that I'm leaving out.

[luke.renaud]

I've whipped up a simple block diagram trying to show how (I think) we were proposing a basic draft for the system to work on last years sub. The system is largely interrupt based, has no blocking calls, and could be implemented in a relatively light footprint. This diagram makes no claims about specific registers to be read from various sensors, which I2C interface sensors would be on (note that due to the current board all sensors will likely be on a single interface)

Furthermore, it makes no claim as to the exact form that communication between the PC and the microcontroller takes, other than recognizing that it will be serial (as that's what the actual electrical hookup is), and will likely include some pre-agreed upon packet structure to minimize overhead and maximize immunity to communication error.

[James Irwin]

Here are some high-level diagrams for I2C and UART communication. I haven't finished flushing things out yet.

[James Irwin]

Here are PDF copies so everyone can see them.