2017-04-30
2017-04-30
It has been a while since the last update and for good reasons. So after screwing around with the DAC on the BeagleBone I decided that I really didn’t like it. What’s with this 1.8 volt max nonsense? Now I’m no EE, so please forgive the laymen’s terminology. The BeagleBone has a 12 bit ADC on-board which means that it can split the supplied 1.8V (max) into 4096 discrete steps. Which works out (if my arithmetic is correct) to 0.000439453 volts per step. That’s 439uV or approximately half a millivolt! That’s just nuts. No way can I design a circuit to within half a millivolt accuracy. Comparatively, a 5V, 12 bit ADC has an output of 0.001220703 volts per step or approximately 1mV.
What’s a fella to do. Well this fella dug out his Microchip (http://www.microchip.com/) controllers from six-ish years ago when he started experimenting with microcontrollers. In particular the PIC24 and the dsPIC30 series. If specificity is desired, a dsPIC30F4011 and a PIC24FV32KA302. The reason I chose these particular chips is because I had a handful of each on hand. I had a PIC24 already hooked up to a MAX RS232 serial driver chip. Fortunately, I also have the DB9 serial port (header really) still in my workstation. On a side note, I’m doing this on a workstation that’s fast approaching 10 years old. There’s certainly something to be said about buying high quality stuff from the get go. Along with microcontrollers I also found my I2C and serial routine code. Joy of joys.
Hardware that I haven’t touched in six years combined with software written as a learning exercise also six years ago? Perfect! Let do this. Here are the broad design goals/spec:
The PIC24 will be used as the communications front end. The dsPIC will be the I/O controller. The PIC24 will act as a bridge between the outside world and the dsPIC30. The two chips will communicate via I2C. The board will have the following I/O:
- 4 x ICTD input
- 4 x 4-20mA loop inputs
- 4 x Digital outputs in the form of DIN mounted relays.
The sensors and the relays will be driven by 24VDC. The logic of the board will run at 5VDC. Interface will be via RS232 at proper levels, none of this TTL nonsense. A nice side affect of a proper RS232 interface is that I’ll be able to connect to it directly with any standard PC or laptop.
The first hurdle was getting two chips talking to one another via I2C. The code I had on hand did work superficially, but it fell apart when at first sign of a bus collision. So I had to go through all of the code, clean it up, and generally make it suck less. For some reason, in an uncharacteristic moment of clarity all those yeas ago I documented the code real well. Kudos to me.
The thing I like about Microchip products is their documentation. I consider it absolutely excellent. Of course it has to be given how absolutely broken their silicon is. On this project so far, I encountered the following issues. Now to be fair they are documented real well and workarounds are provided.
- PIC24 – broken serial UART. Like completely broken.
- dsPIC30 – two separate issues with the I2C module
- 1 — on startup it screws up the bus
- 2 — an overflow condition in the slave receive logic.
None of those problems are some weird corner cases and all of them should have been caught during testing.
Another thing that had me banging my head against the wall for a few days is the fact that the PIC24 and dsPIC30 consider different slave addresses as invalid. I was working off of the dsPIC30 documentation and just couldn’t get the PIC24 to invoke the I2C slave vector. Drove me nuts. I even bought a DSO to help in the troubleshooting. Turned out that a slave address that was valid according to the dsPIC30 documentation was invalid for use on the PIC24. Fuck me sideways.
Yet another little annoyance is that the dsPIC30 shares the SDA/SCL pins with PGC/PGD. So every time I want to reprogram the chip I have to
- Unhook the bus jumpers
- Hookup the PICkit
- Do the programming
- Unhook the PICkit
- Hook the bus jumper back up
Now do that a few hundred times. Just about drove me out of my mind, but that was a real good reason to get an ICD3. Using the PIC3 will allow me to use the alternate debug pin which will speed up the process considerably. It’s on order and should be here tomorrow.
All in all, considerable progress has been made. The “board” accepts commands and the two chips are communicating. Next step is getting up to speed with the ICD3 and getting some of the I/O functionality working.