BasicMicro - Forums

I place these data sheets here as a service to those who own one of the AtomPro ARC Boards, the miniARC and ARC. The idea is to have something people can find if they do a search in the future.
Later!

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Interesting boards! I don't believe I've seen them on the BM website. Where can I find them?

Thanks!

Alan KM6VV

You can't. They are obsolete. Basic Micro no longer produces them. And that's a pity.
However, Lynxmotion(.com) has a better clone, the Bot Board II. The only detraction is it is serial only. It has no USB port, so if your PC has no serial port you'll need to add a serial plug in board (desktop PC, of course) or a USB-Serial adapter that controls all serial pins (or at least the RTS and DTR lines).
Take care.

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Hi Ken,

Yeah, I know about the BB2 boards! I have two of them currently running Atom and Atom Pro.

I too wish they had a few more interfaces. I2C would be quite useful.

Thanks!

Alan KM6VV

How so? Perhaps you could drop a few words in the ears at LynxMotion?

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Hi Ken and Alan,

I also agree it would be great if the boards made it easier to integrate I2C devices. A quick look at the ARC board looked like it only helped some for adding a I2c Memory chip like the ones that are added on the SSC-32 board. I did not check carefully enough, but I think it has a pull-up resistor on the SDA line, did not see one on the SCL line. Probably don't need this with newer BAP 28M chips as it already has a 4K EEPROM memory chip on the BAP chip.

However it would be great if we could more easily add on other I2C sensors like SRF08, CMP01, ...
We can wire are own, by providing pull-up resistors and then wiring up our own mechanism to daisy chain from one to the next, but it would be nice to have a semi-standard such as the brain-stem ones or the like. It would also be nice to be able to use the hardware I2C support that is built into the H8. I tried playing with it once, but without luck, I think the BAP is using it internally to access the EEPROM, so probably was a conflict. Would be nice to know.

Kurt

Yes, the BAP28M and -40M are using the I2C to access the external EEPROM. On the BAP24M, P6 is SDA (data) and P7 is SCL (clock), according to the data sheet. And yet there is a note on this forum or LynxMotion's stating these are P10 and P11. For now, I'd go with the data sheet. The schematic for the BAP28M shows a 4.7K Ohm pullup on SDA, nothing on SCL. Which figures, as these two pins do 3.3V output only. So, the clock (SCL) is good, but the SDA (data) has to be pulled up so 5v-only EEPROM parts can work with it.

I ran into this concern when working on the new EXP Development Board. SD cards were not working at first. These are powered off 3.3V, typically. So the SDA line only swings up to 3.3V. I found an article stating that the 16F877A (in use for tests at the time) made these pins Schmitt trigger inputs when configured for SPI work, which is what SD cards use in the minimum serial configuration. Schmitt wants to see 70% of Vcc (3.6V for a 5V Vcc) for a legal high, so the writer installed a pullup on his CD card's SDA. I did the same, but it didn't help in out this case. The problem was in software. Later I removed the pullup and things continued to work. That is, we could READ a card with data recorded into it by a PC, but couldn't write successfully. We are now redesigning the board for Atom/Pro use, and the SD card still remains unresolved. Bummer. However, when we get the EXP to work with SD cards, the Pro will absolutely shine, even the BAP24M. Thanks to their 2K and 4K RAM, they are natural candidates to work with HC (High Capacity) SD cards. These want to do 512 byte accesses (read/write), which is a problem for the BasicAtom parts with just 368 bytes of RAM. (However, there is a workaround for that, but not recommended...) How does a BAP24M with 32GB of storage grab you?

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Actually I would prefer to see the BAP40m as I could always use more IO pins!!!

Kurt

EXP Development Board? Is it offered yet? That sounds interesting. I don't know if I need all those GB's of data, but who knows! I'd be more interested in CF cards myself.

Too bad about the ARC boards. Kurt is correct, we need an I2C interface that permits standardized daisy-chaining. Jumpers should configure any pull-ups. I have SRF08 and Compass boards in need of an interface. I've done it myself on an 18F4620 board that I use a lot. I've also been considering other I2C boards to talk to.

Alan KM6VV

We just came up with a bussed serial system we are using on a bunch of products. I didn't really think about I2C but we could do a simple I2C extender? The AtomPro has a UART on P14 and P15. So we could build a little adapter to interface between I2C and probably SPI a serial port. Maybe make it an extender. A few I2C busses to the AtomPro. Any thoughts?

_________________
Servo Controller - ARC32!

Hi Dale,

It will be fun to try out the bussed serial stuff, without playing with it, it is hard for me to know how well it would do for interfacing in I2C and the like. But it might do a great job of it.

There are several levels of I2C integration that I would like to have. One is the ability to use some of the standard I2C devices as have been mentioned earlier. For the most part this can be done by some standard cable sets that bring, the SCL, SDA, GND, and power out. It would be interesting to decide if the devices should have second set of pins for daisy chaining or if that should be done by cables and/or an expansion board that has N sets of connections. Then you can still decide if this should be done by the hardare I2C support or as it currently is done by software bit bang functions.

Then the next level of I2C integration (or maybe some other) would be some standardized way to integrate multiple BAPs. For example I think it would be great if I could for example use something like a BAP Pro 1M to offload the processing of an RC receiver, with lets say something like 7 or 8 pins that I do all of the pulse measuring, deadband processing, and the like and then the main processor would be free to do all of the number crunching to make for example the hex robot walk faster. Maybe on this hex I would have a second BAP-P1M to handle foot contact switches or on a different one maybe encoder handling and the like. I think it would be fun to experiment with many different possibilities, especially if there were some simple boards to plug the secondary processors in and a standardized way for them to talk bidirectionally reliably at a high speed. That is where it would be great if the maybe supported both master and slave I2C communications in Basic. Possibly using the hardware support of the underlying chips. Not sure yet if this would be helped by supporting multi-master type communication and I have not studied the H8 documention well enough to see if it supports that or not.

Not sure if this makes any sense?

Kurt

That grabs me a lot! As a computer programmer, I was drawn to the BAP because of their strengths in the computing area compared to some similarly priced units. With the massive amount of data logging and processing required in so many applications, it just makes sense to me to have as much as possible done on location. so some people may think 32 gb of storage is crazy, but that is the kind of storage we are looking for!

When it comes to very large bandwidth monitoring, it makes perfect sense to keep a copy of the data (video, data stream, etc) that triggered the log. And on bad days these logs fill up very quickly....SD cards are a perfect candidate for their universal uses. Would a USB key be much more difficult? just wondering...

thanks for the work, and ideas.

Define "USB key".

Plenty of people have posted various levels of code on the web for drivers and libraries to handle SD cards, for PICs and AVRs. The BAP however is a Renesas chip in the H8 series. Anyone seen anything close on the Renesas site for large scale SPI storage of this nature?

Our former studies of SD cards revealed a thorn patch of unmet standards, SD controllers in proprietary formats, and just wrong descriptions of what to do to use them. At 2GB they become rather unwieldly to implement. I had my brother, a whiz at writing Unix drivers, take a crack at it while visiting the family here in the States. We worked with the programmer in France that BMicro hired to develop code for the EXP board, which never got released. (Long story, different board from one mentioned now, 'nother time...) Between them they had, at best, limited success. I went out and bought a fistfull of different SD cards, 512MB to 2GB, different manufacturers, and tried to get them to work. Without success. A few identified themselves properly, most didn't do as expected at initialization, and the whole thing ground to an unsatisfactory end. The PIC16F just doesn't lend itself to the task, it's 368 bytes isn't enough storage for intermediate data holding. PIC18Fs seem easy enough, there is plenty of code for them.

Last week I went out and bought two SD card adapters that take the microSD cards and allow you to plug them into the older full size SD card slot. I did this because there are sites that show how to solder standard 0.1" header pins to the full size cards and plug them into breadboards, allowing experimentaion with SD cards. The micro cards with these is a mere 512MB. I figure if we can get 512MB to work, then 1GB, then 2GB, then larger can follow. The plan is to get someone (my brother, maybe?) to take one of these after the header is attached and see if he/she can get the BAPro to work with one. Wouldn't that be sweet? Any takers? Send me an email and let's talk.
Later.

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

For the I2C guys, the ARC-32 (not to be confused with the old ARC boards) has a 4-pin I/O header with 4.7k pullups making it usable for I2C devices. Also on the AUX1 header the SDA and SCL pins are available with a 1k pullup on the SDA pin.

As for the SD stuff, I'm implementing SDHC support on the ARC-32 Daughter board based on a fairly clear example I found. It will support FAT32 file format. Since it will be running on a 3687 that runs the daughter board we'll be using the much better standardized 512 byte read/writes. This may become a new hardware command (ala HSDIN, HSDOUT etc) though I haven't decided yet. I'll know more once I'm done with the code.

KenJJ is very right, trying to use the MMC compatible command set for SD cards is a joke. Half to no implementation for most cards in the wild. I think the SD community just gave up on supporting it.

_________________
Nathan Scherdin
Basic Micro - Robotic Technology Evolved