C library for the Basic Atom Pro 28 and Pro 40

Sorry, it has been awhile since I looked at MinionBuilder’s version of the libraries… I have my own C/C++ libraries that I use and have for example a Phoenix (3 dof Hex) running on an Arc32. These libraries also reasonably work for Bap40 and Bap28. When I say reasonably work, I mean to say that as I am simply doing it for my own fun, only those parts that I need or want are implemented and the parts that I use more are tested more… There is more details and libraries up on the thread: viewtopic.php?f=8&t=6196

In my version of the libraries, and I believe in MinionBuilder’s. There are functions to talk to the IO lines. The pin numbers mentioned in these functions are in the same order as are defined by the actual BAP you are using. So for example if you do something like:

[code]int main(void)
{
//[INIT]
bap_initialize();
low(9); // Sound
output(9);

//Timer
InitSystemTimer();			// Initialize the system timer
enable();					//enables all interrupts
output (0);
while (1) {
	toggle(0);
	pause(500);
}

}
[/code]
It should toggle IO pin 0 every half second (more or less)… There are tables setup for the three different Baps (Bap28, Bap40, Arc32) that do all of the mapping of IO pin to the appropriate set of registers. Some of my functions are not 100% functionally the same as the Basic version. That is for example my functions: low, high, toggle, don’t do the work to switch into output mode… Easy to add, but I left it out… So with both sets of libraries you need to make sure you have defined and built it for the right processor…

Again more details in the thread I mentioned.

Kurt

I have been reading the thread that you suggested. I checked out your files in the various Phoenix folders. I am trying to get to terms with all the terminology of your source code.In the “CPhoenix with Arduinosh lib” folder, I see a BAP folder which consists of a number of source files and the project file. I tried to run the TestBAP project file but I get the following error:

“C:\PROGRA~2\BASICM~1\BASICM~1\H8300-~1\bin…\lib\gcc-lib\h8300-coff\3.2-GNUH8_v0301…\h8300-coff\bin\ld.exe: cannot open linker script file c:\users\kyle\desktop\baplib\project36X4.xlc: Invalid argument”

My first question is, would you recommend using the TESTBAP project file along with its source files and try to expand off that? Right now, I would just like to send a high to Pin 0 of the bot2 board which would power my motor which is connected to a sabertooth motor controller. This would be a start and I would be able to branch off and start to develop code for my project.

My second question is, depending on whether or not you think using the TESTBAP project would be a good idea, which of your project files would you recommend that I start with.

Thanks for responding to my post earlier and I hope my questions for this post are clear.

Kyle

Hi Kyle,

As I mentioned these files/projects are a thing in motion, so some things work with some processors and some work with others. The TestBap Project was last setup for the Arc32. At least the current version that is on my computer it builds correctly (did not try to run it) if you make sure to set the processor type in the IDE to BasicAtomProArc32. It may also build on a BasicAtomPro40. It would not be hard to make it run on the BasicAtomPro28 as well. Need to update the project36x4.xlc file some to update the paths to the libraries as mentioned in the readme file in the zip file. Also would need to make some minor updates to the source files as the S_IN/S_OUT of the BAP28 is not on the first hardware serial port and the like, and would probably change around which IO pins are used… but pretty easy stuff…

Should probably continue this on the other thread or create a new thread as not to hijack this thread…

Kurt

Hi Kyle. Are you still trying to get a test C program to compile and execute?

My C library has several projects included. One is a very simple “Hello World” type program.
This program will output some text on the hardware COM ports COM1 (and COM2 for BAP40) and the DB9 port (software serial IO).
The pins for these ports are defined as COM_RD/COM_TD and COM2_RD/COM2_TD and SIN/SOUT.

The library has a define for the software logging port output, found in source file ConsConfig.h. It is currently set to SOUT (for the DB9 port on the BAP28/BAP40).
The BAP unit default is for the BAP40, so you will need to change that. Also in the ConsConfig.h file.
You will see this line: #define BAP40 // currently BAP28 and BAP40.
Change it to this: #define BAP28 // currently BAP28 and BAP40.
This MUST be done. If the library is compiled for a BAP40 it will NOT work on a BAP28.

Check out the project C_cHello.prj and the source file C\Hello.c.

You can use this program to make sure that everything is working. Then you can start your own code to use the I/O pins that you need.
I have many device drivers already coded and you can look at how the pins are accessed.
You may want to look at the software I2C interface as it does some simple pin IO. See file C\SI2C.c (for Software I2C).
For hardware port access you can check out HSIO.c (Hardware Serial IO) and HI2C.c (Hardware I2C).

The pins are accessed using these definitions:

enum {_P0_=0, _P1_, _P2_, _P3_, _P4_, _P5_, _P6_, _P7_
, _P8_, _P9_, _P10_, _P11_, _P12_, _P13_, _P14_, _P15_
, _P16_, _P17_, _P18_, _P19_
, _SIN_, _SOUT_, _SCLI_, _SDAI_
, _BAP_PIN_COUNT_};

#define _ADC0_			_P0_ // hardware ADC channel 0. cannot be changed!
#define _ADC1_			_P1_ // hardware ADC channel 1. cannot be changed!
#define _ADC2_			_P2_ // hardware ADC channel 2. cannot be changed!
#define _ADC3_			_P3_ // hardware ADC channel 3. cannot be changed!

#define _HSDA_			_P6_ // hardware I2C SDA. cannot be changed!
#define _HSCL_			_P7_ // hardware I2C SCL. cannot be changed!

#define _ADC4_			_P18_ // hardware ADC channel 4. cannot be changed!
#define _ADC5_			_P19_ // hardware ADC channel 5. cannot be changed!
#define _ADC6_			_P17_ // hardware ADC channel 6. cannot be changed!
#define _ADC7_			_P16_ // hardware ADC channel 7. cannot be changed!

#define _COM_RD_		_P14_ // hardware COM receive line. cannot be changed!
#define _COM_TD_		_P15_ // hardware COM transmit line. cannot be changed!

The BAP initialization routines setup the hardware so that these pins will work.
The Px defines are directly mapped to the BAP pin of the same number. The internals of the Hitachi processor are mostly abstracted in the library.

-Bob

Hi Bob,

I keep meaning to get back into merging our two sets of libraries. You have a lot of great functionality that I should merge in! I have been mostly playing around with getting things like servos to work like the basic HSERVO subsystem on the Bap28 and 40. Likewise the Hservo2 system on the Arc32. Currently I am playing with adding the Analog to Digital code for the Arc32, that is part of the HSERVO code as you have to map the different groups of pins to be connected to the physical H8 AtoD pins and then scan them and then map the next 4…

One thing I have run into with our previous versions of the iopin.c code was problems when you have interrupts that change the state of IO pins. This causes problems that some of the IO changes that happen in the interrupt can be tromped on by the non-interrupt code… So my current versions of the code disable interrupts during the normal calls like high/low/toggle…

Let me know if you would like to work on a merged set of functionality.

Kurt

Hi Kurt.

I definitely want to merge the code base in some way. I think I am ready to go back to the BAP coding and take on some of these changes. I took a break from all that low-level Hitachi register stuff as I think It was driving me a bit batty. I have been working on the high-level code to operate my autonomous robots, using the C library device drivers. The device drivers seem to be working well.

I have mostly all I2C and serial devices in my robot and they handle all the timing stuff (like servo controllers, etc), so I have not really needed to write any of that. For this reason, my libraries are sorely missing timing support. I have no servo or PWM support at all. Serial read timeouts work, but with no interrupts. I am actually doing serial millisecond timeouts by hard-coding loop counts based on cycles per loop.
Sonar ping reply timing is also loop counter and cycles based. Pretty primitive, but it works. I have it all timed for a BAP40, and the timeouts will be wrong on a BAP28.

It would be nice to improve these things using your code.

What I do have working well is the I2C interface to the hardware devices. Software serial actually works pretty well, too, but it is based on loop counts.
I think my C library is nicely modular, in that it uses self-contained device drivers and abstracted interfaces for all device access.
I have the interrupt system working in my current library, but by default it is disabled. It was also driving me batty. Now I realize that I was likely experiencing the non-atomic pin operations side effects as you have described.
I have kept up on your posts as regards non-atomic pin operations and interrupts, but I have not made any changes to my library code. Yet.

It looks like we have covered both ends of the spectrum. I have the modular device drivers and functions interface (I2C,SPI,EEPROM,tiny sprintf,strings,etc.) and you have the low-level timing and interrupt code. Integrating the code base would be great. I am not sure where to start. It does seem a bit of a daunting task, but I do have some time to work on this. I guess we just need to pick out the most useful update and start on it.

Now that my robot works well using the C library device drivers, I have been focusing on the artificial intelligence system that I am running on the Sony PlayStation Portable. Pretty cool to watch my 1/10 scale Hummer H2 drive itself around using sonar, sound and light detection, turn on and off the various lamps and LEDs, control servos and play appropriate MP3 tracks, etc., etc., as it interacts with the environment. All running using dynamic facts (from the various hardware sensors and devices) in a rule-based system. It’s a blast. I’m going to post some pics pretty soon as I think the hardware has finally been completed. I have over 2 dozen devices operating at once in the Hummer using the C library.

Wow, what a long winded post that was. :smiley:

-Bob

Sounds great!

I may have to soon start playing around again and see how hard it would be to merge. We have lots of duplicated stuff, but as you mentioned we both have covered different areas as well.

Some of the stuff we both have in common include:
a) Low level IO support: input, output, high, low, toggle, … I have made some changes to make these more robust with interrupts… As you mentioned, this may be what bit you as well. Took me a few days of pulling my hair out to figure it out and then went DAH…
b) Serial output including things like printf… Yours is more based on loop counting to measure the time for each bit. Mine was based off of using TimerV like my assembly language version for Basic. Did this as it was slightly less impacted by interrupts…
c) Hardware serial: Mine are interrupt based. I don’t remember if yours were or not. I also tried to provide mechanisms to abstract away from is it a hardware or software serial port.

d) Stuff I borrowed from you like some I2C and some EEPROM reading code…
e) Adin - IO Pin table driven for normal analog pins - plus now servo hservostate support for Arc32

Some of the things I have that you mentioned that you do not.
a) Timing. I have some system timer code (TimerA/TimerB1) that has interrupt handler that counts up plus some conversion macros. Also added in some support for Arduino type calls (millis, micros, FTimeHasElapsed). Note: my servo implementation on both Bap40 and Arc32 keep overflow counts, may have these take over when available for these other system timers.

b) Servo support - This one has taken me awhile and can still use some optimizing…

What has driven me at different times to add different things to the library was to get the necessary support to port the Phoenix code to C and I now have it working both with and without the SSC-32. Also I have ported the Brat Biped code as well, which I used to test the servo code for Bap28.

My code is currently not as modular as I would like. That is I should break up some of the files, such that when you link with the library it only brings in the code that is necessary for your program. Also since the link scripts are only per H8 family of processors, needed to work out how to only have Arc32 code included in Arc32 run programs likewise Bap40 code only linked into Bap40 programs… So far it is not an issue for the Bap28 as this is the only one I have supported so far in this family (IE I have not supported the Bap24). I have broken out the Bap40 and Arc32 servo code into different files so far and I probably can do more…

I am still building mine in two steps. One is to build the libraries, which I use nmake for as the IDE still has no support for building libraries. Then I have to edit the Editor Scripts to include the library as the compiler/link options don’t work for me…

So maybe soon!

Kurt

I have completed standardizing the ‘C’ library and making the device drivers more '“C like”, using structs, etc.
All the ‘C’ code was originally ported directly from my BASIC library. The ‘C’ code is now much cleaner.

Here’s a rundown of a few of the changes:

fixed a constant for hardware serial IO for 4800 baud, so that’s working now.
the Basic Atom ADC code is more reliable. the battery routine averages out the ADC readings to get less variance.
added a new device driver for the ADS7828 I2C ADC.
switched from the VRBot voice-recognition module to the successor product EasyVR. The driver works with either one.
finally got hardware I2C working for most of the I2C drivers. The are a couple that still don’t work. I am currently attempting to get all I2C device drivers working using hardware I2C.
not tested on the BAP28. I am only using the BAP40 myself, and the newer BasicMicro devices are based on the BAP40 anyway, so that is my main focus.
still no timing or servo support. I don’t really need much of that as I use I2C devices to do all the low-level stuff. limited loop-based millisecond timeout support is provided for hardware and software serial IO. This is what likely won’t work right on the BAP28.

-Bob

Sounds great, I would love to play with it.