I'm part of a project building an autonomous quad-rotor UAV. my job is the electronics hardware and firmware. I want to provide an API to the guys doing the algorithmic programming (to make it actually be autonomous) so that they don't have to deal with hardware when they need to read a sensor or change a motor's speed. We have a 3-axis accelerometer and a 3-axis gyro, plus a barometric pressure sensor, ultrasonic sounder and stereo ccd cameras.

How do you go about writing an API for an embedded processor? Their code will be (most of) the main program running on the processor

Can they just use variable types like int, char, bool, etc in their program, or do they need to use processor-specific types? (i'm assuming processor specific)

Thanks guys. I'm kind of flying blind with the api, no pun intended

 

They can and should use familiar data types. If I were you, I would think about implementing a client server model with message passing as the primary method of passing information. In this fashion you can hide practically all of the details that the algorithm developers don't need to worry about.

Let me know what I can do to help you get where you need to be.

__________________
We never have time to do it right; but we always have time to do it over.

 

what do you mean by the client/server model?

 

Assuming this is a nonthreaded, DSP microcontroller, I'm not sure the "interface" will meet the definition of an API.

You can (must) write in structured, well documented tasks in either C or assembly for strong, flexible reuse. In C, the int and char type are definitely used, as are structs. C is used all the time, but high-performance numerically intensive stuff needs frequently requires assembly. But, asm tasks can actually be called from C. For dsPICs, the true DSP ops using the Accumulator won't even be invoked by standard C math, although there are some built-in special-purpose function calls which can invoke the DSP core ops for specific jobs.

But you cannot let in application developers who aren't familiar the controller used. For example, the "fractional" type is very powerful on dsPIC controllers, but float/double are a slow boondoogle to avoid at any cost. Developers need to understand how interrupts may change data mid-calculation.

What controller are you looking at?

__________________
I thought what I'd do was I'd pretend I was one of those deaf-mutes.

 

i guess by API what i meant was that I want to provide some functions (get_accel(), set_motor(motor,speed), etc) so that they can interface with the hardware without dealing with the hardware itself.

These guys doing the algorithm stuff are all (as a friend put it) from "computer science la la land." They're not really used to working with micros. How to deal with that?

Not sure on the controller yet. I was thinking about using an ATXmega but i'm willing to go to something else. ARM7's crossed my radar too

 

In a client server model there are two entities. The client sends requests and receives responses. The other endpoint, called a server receives requests and sends responses. It is not necessary for either the client or the server to know anything about the other. It is only necessary for them to know how to talk to each other. They could be running on the same machine or different machines connected by some kind of nework. In the case that client and server run ondifferent machines one could be written in assembly language and one could be written in Java. What is important is that both endpoints must agree on both the syntax, and the semantics of the messages that are exchanged.

If both are running on the same machine it provides a very clean framework for interprocess communications and is well suited to OO techniques. This beats the pure hell out of trying to remember a large library of function calls each with its own list of parameters and return values -- IMHO.

__________________
We never have time to do it right; but we always have time to do it over.

 

Well, "how to deal with that" is someone has to know micros. Either they explain what needs to happen and someone interprets the task into microcontroller code, or they need to understand it.

In many cases a BASIC-like "get_something()" sequential task just isn't efficient. The ADC, for example, would need to be set up, left in acquisition time, then converted. This not only takes up an unnecessary amount of time if the code just waits on these steps, the spacing of the ADC samples may be irregular. More often we like to configure the ADC to automatically collect readings and an adc_done interrupt allows the program to access them in an orderly fashion. The ISR might store the ADC reading in a buffer and get_ADC() retrieves it, but even this may be an inefficient type of solution. If the system is demanding of performance- and it kinda sounds like it- then it may not be able to afford sloppy programming.

So that's the thing. You generally can't just use an interface to make computer-science guys' code which wasn't written for a microcontroller to work well on a microcontroller. Learning new skills is essential to being "good". Assuming this is a class project, that was kind of the point.

__________________
I thought what I'd do was I'd pretend I was one of those deaf-mutes.

 

Some of the decisions depend on the hardware you are using. If this is a single processor doing all the work then just a subroutine library might be good. As things get bigger maybe client server would make sense. Will all the computing be done on one uc?

 

How are they communicating with mcu? Are they writing code on it or for pc?

__________________
AtomSofts eBay Store
AtomSoftTech: C18 TIPS & TRICKS v9 PDF
Nokia 6100 Driver/Software

My Name: Jason Lopez
http://atomsofttech.info/ | My YouTube Videos!
My Favorite Store:
dipmicro Electronics

 

Client/server seems like an option. They'd be running on the same chip. My biggest worry is that this has to be real-time. How would scheduling work?

I'd really like it to be a single processor. If that can't happen, so be it. As of right now, it is one processor

Well, it's looking like the electronics team and the software team are almost the same set of people. What I was thinking for the ADCs (which take in all the sensor values) was to get a maximum update rate from the software team and setting up a timer/counter match interrupt to run and store all the conversion values in memory at least as quickly as they'd need it. The get_value() functions would simply return the most recent value.

they're writing code directly for the micro

Got any recommendations of a DSP micro?