I recently discovered I have problems when controlling the PCF8575 (16-bit I2C controlled IO expander) in such a way, that P0.7 is put as input (so, P0.7 is high).
Whenever P0.7 is put high, all other pins (P0.0 - P0.6 as well as P1.0 - P1.7) are becoming inputs too, whatever their previous state (input or output).
Also, the PCF8575 does not detect any input changes any more...
I still have no clue at all as to why this IO expander is behaving so strange.
The moment I switch P0.7 as output, all my other pins behave correct again (as input as well as output).
Still looking for a possible cause...
Sunday, 18 November 2007
Friday, 9 November 2007
3V to 5V I2C translation problem
Knowing the FoxBoard is running on 3V3, this means the levels of my I2C output are between 0V and 3V3.
However, I want to power my own devices with 5V, if possible. This is because most devices I'm going to use, are working just fine at 5V (some of them are also capable of working at lower voltages, but for simplicity I will stick to one supply of 5V).
Luckily, nowadays lots of IC's are available, which are able to do very nice things. Such IC is the PCA9518 from NXP (formerly known as Philips), an expandable 5-channel I2C hub.
This device is mainly developed to solve the capacitance load an I2C bus is allowed to have (max. 400pF). It has one "main" I2C input, while it can have up to 4 extra I2C outputs, completely isolated one from the other. So, the main I2C input doesn't see neither of the output loads. Each output load individually also doesn't "see" the capacitance load of the other outputs.
This way, you can have multiple I2C paths while adhering the max. bus capacitance of 400pF.
Next, this device has 5V tolerant I2C lines. That means, the device itself is powered with 3V3 (so, can be connected to the power supply of the FoxBoard), but the pins can "communicate" with I2C levels that go till 5V. Result: device can be used as a 3V3 to 5V translator, without having to have complex voltage levelling circuitry in between. This is a very important input for me, since that will solve my voltage level problem.
Another nice thing about the PCA9518 is that it can be "cascaded" with other PCA9518 chips, extending your I2C bus almost infinitely.
More information about the PCA9518 can be found here.
If you check the application note on page 10, then you will see that in the example given there are two PCA9518 devices, cascaded one to the other. Bpth PCA9518 devices are powered with 3V3, together with the I2C bus master.
But all the other I2C devices are powered with 5V, showing you it's simple doable to "convert" the levels from 3V3 to 5V.
However, I want to power my own devices with 5V, if possible. This is because most devices I'm going to use, are working just fine at 5V (some of them are also capable of working at lower voltages, but for simplicity I will stick to one supply of 5V).
Luckily, nowadays lots of IC's are available, which are able to do very nice things. Such IC is the PCA9518 from NXP (formerly known as Philips), an expandable 5-channel I2C hub.
This device is mainly developed to solve the capacitance load an I2C bus is allowed to have (max. 400pF). It has one "main" I2C input, while it can have up to 4 extra I2C outputs, completely isolated one from the other. So, the main I2C input doesn't see neither of the output loads. Each output load individually also doesn't "see" the capacitance load of the other outputs.
This way, you can have multiple I2C paths while adhering the max. bus capacitance of 400pF.
Next, this device has 5V tolerant I2C lines. That means, the device itself is powered with 3V3 (so, can be connected to the power supply of the FoxBoard), but the pins can "communicate" with I2C levels that go till 5V. Result: device can be used as a 3V3 to 5V translator, without having to have complex voltage levelling circuitry in between. This is a very important input for me, since that will solve my voltage level problem.
Another nice thing about the PCA9518 is that it can be "cascaded" with other PCA9518 chips, extending your I2C bus almost infinitely.
More information about the PCA9518 can be found here.
If you check the application note on page 10, then you will see that in the example given there are two PCA9518 devices, cascaded one to the other. Bpth PCA9518 devices are powered with 3V3, together with the I2C bus master.
But all the other I2C devices are powered with 5V, showing you it's simple doable to "convert" the levels from 3V3 to 5V.
Thursday, 8 November 2007
Putting my application on a USB stick...
In case the 4MB of FRAM of the FoxBoard type MCM would not be sufficient, I can/will put my application on a USB stick and when the FoxBoard starts up, I can run my application from the USB stick.
This way, I can make bigger applications (there's 16MB of RAM available in the MCM version) and I don't have to flash the application in FRAM all the time too.
That's a time gainer and it will also prevent my FoxBoard FRAM from wearing out (although there are tens of thousands of writes that can be done).
Activating the USB feature during boot-up of the Linux kernel was/is quite easy. A small script must be put in a writeable FRAM location (see my Wiki pages for more details about this.
For the newer board I have, an FS version, this will be even more luxurious, since that board has 8MB of FRAM and 32MB of SDRAM...
This way, I can make bigger applications (there's 16MB of RAM available in the MCM version) and I don't have to flash the application in FRAM all the time too.
That's a time gainer and it will also prevent my FoxBoard FRAM from wearing out (although there are tens of thousands of writes that can be done).
Activating the USB feature during boot-up of the Linux kernel was/is quite easy. A small script must be put in a writeable FRAM location (see my Wiki pages for more details about this.
For the newer board I have, an FS version, this will be even more luxurious, since that board has 8MB of FRAM and 32MB of SDRAM...
Queue is fully operational!
The queue mechanism I was working on, is fully operational! Nice to see it smoothless working...
As a test case, I've written the following software:
When I press and release a button, the time is measured. That info is sent to the message queue and when it arrives in the message queue manager, the data is analysed.
First, the message type is representing the IO expander which has caused that message. Next, I know the pin which has changed and I also know the time that pin has been low (so, the time the button has been pressed).
If the time is less than 1 sec, I'm lighting up a certain LED from an IO expander which has been configured as OUTPUT.
When the time is equal or more than 1 sec, another LED of the same IO expander is activated.
This way, I know my queue mechanism is working and I know I can measure the time a button has been pressed. Out of this, I can decide if I want to give a second (and in extreme conditions even a third) function to that button.
I still have to clean up a bit, but that's another part of my domotics system which is already working.
I'm satisfied about the progress
Oh, I love the FoxBoard!!! It's working so smooth!!!
As a test case, I've written the following software:
When I press and release a button, the time is measured. That info is sent to the message queue and when it arrives in the message queue manager, the data is analysed.
First, the message type is representing the IO expander which has caused that message. Next, I know the pin which has changed and I also know the time that pin has been low (so, the time the button has been pressed).
If the time is less than 1 sec, I'm lighting up a certain LED from an IO expander which has been configured as OUTPUT.
When the time is equal or more than 1 sec, another LED of the same IO expander is activated.
This way, I know my queue mechanism is working and I know I can measure the time a button has been pressed. Out of this, I can decide if I want to give a second (and in extreme conditions even a third) function to that button.
I still have to clean up a bit, but that's another part of my domotics system which is already working.
I'm satisfied about the progress
Oh, I love the FoxBoard!!! It's working so smooth!!!
Wednesday, 7 November 2007
Queueing, queueing, queueing...
I'm currently busy making a mechanism whereby my IO expanders, used as inputs, are polling their inputs at a rate of a multiple of 10ms.
Each input pin can be polled independently at different times (but always a multiple of 10ms, with 10ms as a minimum poll time). For instance, if I take the PCF8575 IO expander, all 16 pins can have an individual polling time.
Polling is done on a separate thread. The thread is made as a "while ( 1 )" loop, with a "sleep" condition of 10ms. That sleep is accomplished using the function "select()", which normally is doing some IO to external devices.
However, you can set a time-out time and that's what I'm "misusing" for the moment. All other parameters are 0 or NULL, while the time-out is set to 10ms.
Every 10ms, a check is done to see if for (a) certain pin(s) the polling time has elapsed.
For instance, suppose the polling time for pin 1 is every 40ms and for pin 3 every 60ms, then at 40, 80 and 120ms pin 1 will be checked and at 60 and 120ms pin 3 will be checked. You see that every 120ms both pins 1 and 3 are checked!
When I have the result, I should of course do something with it. The IO pins are checking if a connected button is pressed or not. Since I'm checking at regular times, I can know when the button has been pressed, but also when the button has been released. So, I can measure the time the button has been pressed.
This is very interesting: this way, I can give multiple functions to one and the same button. For instance, if a button is pressed less than 500ms, it has a "normal" function (e.g. switching on/off a certain light), but if it has been pressed for more than, say, 2 seconds, I can for instance start dimming up/down that certain light!
All this info is gathered at the level of the IO expander class, but it has also to be sent to another IO expander which is used as output (for instance, to control a relays).
Since more than one IO expander is used as input, I needed a mechanism to not loose any information (which button is pressed, how long has it been pressed, to which IO expander is the button connected, etc.)
Therefore, I've created a structure which contains all that data. Next to this, I've created a message queue (in the same process, so not an IPC message queue). That message queue is bringing all that information into a queue manager.
That queue manager has a blocking receive call on the message queue and the moment a message arrives, the queue manager will analyse that message and see which destination it has to addressed it to.
I'm currently implementing that queue mechanism and the last thing I have to do, is to allow the queue manager (messages are already sent from the IO input expanders via the message queue to the queue manager, that already works great) to distribute the received data.
Each input pin can be polled independently at different times (but always a multiple of 10ms, with 10ms as a minimum poll time). For instance, if I take the PCF8575 IO expander, all 16 pins can have an individual polling time.
Polling is done on a separate thread. The thread is made as a "while ( 1 )" loop, with a "sleep" condition of 10ms. That sleep is accomplished using the function "select()", which normally is doing some IO to external devices.
However, you can set a time-out time and that's what I'm "misusing" for the moment. All other parameters are 0 or NULL, while the time-out is set to 10ms.
Every 10ms, a check is done to see if for (a) certain pin(s) the polling time has elapsed.
For instance, suppose the polling time for pin 1 is every 40ms and for pin 3 every 60ms, then at 40, 80 and 120ms pin 1 will be checked and at 60 and 120ms pin 3 will be checked. You see that every 120ms both pins 1 and 3 are checked!
When I have the result, I should of course do something with it. The IO pins are checking if a connected button is pressed or not. Since I'm checking at regular times, I can know when the button has been pressed, but also when the button has been released. So, I can measure the time the button has been pressed.
This is very interesting: this way, I can give multiple functions to one and the same button. For instance, if a button is pressed less than 500ms, it has a "normal" function (e.g. switching on/off a certain light), but if it has been pressed for more than, say, 2 seconds, I can for instance start dimming up/down that certain light!
All this info is gathered at the level of the IO expander class, but it has also to be sent to another IO expander which is used as output (for instance, to control a relays).
Since more than one IO expander is used as input, I needed a mechanism to not loose any information (which button is pressed, how long has it been pressed, to which IO expander is the button connected, etc.)
Therefore, I've created a structure which contains all that data. Next to this, I've created a message queue (in the same process, so not an IPC message queue). That message queue is bringing all that information into a queue manager.
That queue manager has a blocking receive call on the message queue and the moment a message arrives, the queue manager will analyse that message and see which destination it has to addressed it to.
I'm currently implementing that queue mechanism and the last thing I have to do, is to allow the queue manager (messages are already sent from the IO input expanders via the message queue to the queue manager, that already works great) to distribute the received data.
Sunday, 4 November 2007
My development set-up
To develop my software for/on the FoxBoard, I've chosen to use the following set-up:
For those interested: I also have a Wiki page explaining some stuff much more in detail.
Pls. visit http://www.gevawebsolutions.com/wiki/index.php?title=Main_Page to read more.
- My PC is a Pentium 4, 3.2GHz with 1GB RAM and two internal harddisks of 160GB each.
Next to this, there are another two external harddisks of 160GB each. Both external harddisks are connected using a FireWire connection (aka 1394).
You can see my set-up below:
On the left, you see the monitor for my Linux sessions (and occasionally also some Windows applications if the right monitor gets too busy).
Yes, I'm an animal lover,hence the wolf as a background picture (but in fact, tigers are my favourite ones...).
Next to this monitor, the monitor for my Windows applications.
If you click the picture, you will also see the two external harddisks (while a third one is waiting to be build into a harddisk case). - My main OS is (sorry, Linux freaks) WinXP Home Edition SP2. But I do like Linux more... See further.
- On my PC, I've installed VmWare, so that I'm able to run Linux in a virtual machine (here you go, Linux freaks, I'm one of them too...)
I've done this to avoid having to use a second PC to run Linux. This way of working not only saves space on my desk, it also is much less power consuming
Taking care of the environment is one of my hobbit horses and I'm doing whatever I can to save as much as possible resources... - I'm running Kubuntu Gutsy Gibbon as Linux OS, where I've installed the SDK of Axis (with lots of modifications done by John Crispin).
I recently re-installed the SDK (due to a crash with Kubuntu while upgrading from verions 6.10 to 7.10, see another article in this blog...), using the SVN installation script as explained on the Acme Website. - I've also installed Samba on my Linux machine, to be able to see the content of certain directories under Windows too.
- I also have two LCD monitors: one for my Windows applications and one for my Linux applications.
"But, you idiot, if the environment is so important to you, why do you use two monitors then", one can ask? Well, let me try to "defend" myself:- Both monitors are of the LCD type, so together they're consuming less than one "classic" monitor
- It's very unhandy if you have to "control" the screens of two different operating systems on one monitor
- Both monitors are of the LCD type, so together they're consuming less than one "classic" monitor
- To edit my files, I'm using NotePad++ (visit http://notepad-plus.sourceforge.net/uk/site.htm for more info about this wonderful editor).
This editor is running under Windows.
But why did I choose again for a Windows application to develop Linux stuff??? Well, see below:- I'm spoiled by the Windows GUI for more than 15 years now, so kicking the habbit is quite "heavy"
- I didn't find any decent and competitive editor running under Linux. I've tried Eclipse, NetBeans, KDevelop, Kate,...
All have their own pro's and con's, but none of them could compete with the ease of use of NotePad++ - I'm able to in fact do almost everything from my Windows environment (even running Linux tasks), so why would I switch constantly between Linux and Windows?
- To compile my FoxBoard software, I'm using (of course) the compiler/linker which is part of the SDK provided by AcmeSystems (http://www.acmesystems.it). This one is (for sure) running on my Linux virtual machine.
- To debug my FoxBoard software (yes, I indeed need a debugger from time to time), I'm using Insight from RedHat (visit http://sources.redhat.com/insight to know more about this debugger).
- I've found a way to start my makes on the Linux machine from within NotePad++. This is extremely handy, since I really like this editor and now I can even start my builds on the Linux machine and see the feedback in a console window of NotPad++.
To acomplish this "trick", I wrote a small parametrised shell script that I'm calling from NotePad++.
But there's more to it: to be able to call a Linux script from Windows, you need a tool like plink to "bridge" the gap between Linux and Windows. The whole Putty suite (including plink) can be found here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
Plink needs a private/public key to see if it's allowed to run a script on a Linux machine, coming from a Windows environment.
Once plink is installed correctly (create a private/public key using puttygen, part of the Putty suite, for this), I can call this application with the necessary parameters to run the build on my Linux environment. - To be able to do that in NotePad++, you need to install a plug-in (NotePad++ has an open architecture, that is, you can create plug-ins for NotePad++ yourself) called NppExec. This plug-in is written by Vitaliy Dovgan and can be downloaded here: http://sourceforge.net/project/showfiles.php?group_id=189927&package_id=224034.
The image below shows my NotePad++ editor with the console window showing the compilation steps of a build:
- At the end of every compilation, I've a script running that automatically downloads the new program to the FoxBoard, using FTP (file transfer protocol).
The FoxBoard is connected to my Linux machine via my router (so, using ethernet connections).
I've created a special directory on the FoxBoard root file system in RAM, to which I FTP my new executable after every build. As said before, this is done automatically.
So, very frequently downloading the application for testing purposes in that memory area cannot harm the life span of the FoxBoard memory, since it's RAM. - Once the application is more or less ready for another test phase, I'm copying the application in a USB memory stick, connect that stick to the FoxBoard, restart the FoxBoard and automatically this application is read out while booting up the FoxBoard.
The application starts automatically to run.
For those interested: I also have a Wiki page explaining some stuff much more in detail.
Pls. visit http://www.gevawebsolutions.com/wiki/index.php?title=Main_Page to read more.
What I'm currently doing (Nov. 2007)
After having improved the I2C driver for the FoxBoard, I started to develop different component classes for I2C devices.
As already said in a previous post, my whole domotics system is based on components capable of handling the I2C protocol.
This protocol is very simple and yet, very powerful. There are only two wires involved: one data line, called SDA (serial data) and one clock line, called SCL (serial clock).
The clock line is mainly there for synchronisation purposes between a master (the one who sends out the I2C commands, mostly a [micro]processor such as the FoxBoard) and the slave (the one who reacts upon the commands sent by the master).
A complete description of the I2C protocol can be found on the NXP (formerly known as Philips) website:
http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf
This spec dates from January 2000, but I recently found a (very recent) update of that spec here:
http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf
The fact there are only two communication wires involved, makes it very interesting wrt PCB space, when developing the hardware.
That said, I'm currently developing a C++ based hardware abstraction layer. The purpose of this layer is to hide the peculiarities one can have when a direct Linux kernel call is to be made. It's quite cumbersome and error prone to do so, hence one of the main reasons I developed that HAL.
Calling I2C functions is now very easy and very transparent: understandable calls can be made, which "under the hood" do all the dirty work, away from the user.
The HAL is next to finished, so I'm going one step higher in the creation of component classes for I2C devices: classes for the I2C devices themselves.
Those classes are all communicating to the I2C driver in the kernel, through the HAL. So, I immediately benefit from my own HAL class... ;-)
The components I am/will using/use for my domotics system, are (all I2C controlled):
Classes which are already more or less complete (well... what is complete anyway...):
On the picture above, you can see a close-up of my "test environment". On the image, there are (click on the image to see the big version):
As already said in a previous post, my whole domotics system is based on components capable of handling the I2C protocol.
This protocol is very simple and yet, very powerful. There are only two wires involved: one data line, called SDA (serial data) and one clock line, called SCL (serial clock).
The clock line is mainly there for synchronisation purposes between a master (the one who sends out the I2C commands, mostly a [micro]processor such as the FoxBoard) and the slave (the one who reacts upon the commands sent by the master).
A complete description of the I2C protocol can be found on the NXP (formerly known as Philips) website:
http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf
This spec dates from January 2000, but I recently found a (very recent) update of that spec here:
http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf
The fact there are only two communication wires involved, makes it very interesting wrt PCB space, when developing the hardware.
That said, I'm currently developing a C++ based hardware abstraction layer. The purpose of this layer is to hide the peculiarities one can have when a direct Linux kernel call is to be made. It's quite cumbersome and error prone to do so, hence one of the main reasons I developed that HAL.
Calling I2C functions is now very easy and very transparent: understandable calls can be made, which "under the hood" do all the dirty work, away from the user.
The HAL is next to finished, so I'm going one step higher in the creation of component classes for I2C devices: classes for the I2C devices themselves.
Those classes are all communicating to the I2C driver in the kernel, through the HAL. So, I immediately benefit from my own HAL class... ;-)
The components I am/will using/use for my domotics system, are (all I2C controlled):
- PCF8574: an Input/Output expander (short: IO expander) which can detect changes at its input pins (when used as input) or control the status of the output pins (when used as outputs).
The advantage of such device is:- I2C controlled
- Each pin can individually be set as input (to measure) or output (to control) at any moment in time
- PCF8575: Similar to the PCF8574, but this one has 16 IO pins iso "only" 8 IO pins.
- PCF8591: an ADC device (analogue to digital converter) capable of measuring analogue signals (light, temperature, movement) and translate it in digital information.
- TDA8444: a DAC device (digital to analogue converter), which does just the opposite of a PCF8591. It converts digital information to analogue values.
This device will be used to control dimmers etc. Mostly, dimmers can be controlled by applying an analogue voltage between 0 and (mostly) 5 to 10 V. This corresponds with no power at all at the output of the dimmer (when applying 0V) to maximum power (when applying 5 or 10V, depending on the type used).
Those dimmers will be used to create different atmospheres in some rooms (for instance, when watching television, you want another light compared to reading the newspaper in a seat in the living room). - PCF8563: a RTC device (real time counter) which is necessary to keep track of the time in the system. This device has a high level of accuracy and can be used to synchronise the clock of the Linux system, after -for instance- the system comes out of stand-by.
- 24C32: a NVM device (non-volatile memory) which is needed to store values that will be needed again at a later time (for instance, store the intensity of a certain dimmer at a certain moment, store the reference temperature for the different rooms,...).
- LM75A: a temperature measuring device. Such device will be placed in every room to be able to measure/control the temperature individually.
Also, this device will be used to measure the outgoing and incoming water temperature of the floor heating system and to measure the temperature in the hot water boilers. - Maybe others will be added...
Classes which are already more or less complete (well... what is complete anyway...):
- PCF8563
- PCF8574
- PCF8575
On the picture above, you can see a close-up of my "test environment". On the image, there are (click on the image to see the big version):
- Two PCF8575-IO expander components (the two greenish parts)
- One PCF8574-IO expander (top left of the white breadboard)
- One PCF8583-RTC (bottom left of the white breadboard)
- Another PCF8563-RTC (small green PCB on the left of the white breadboard)
The great discovery: FoxBoard
While looking for a decent processor for my domotics system, I initially started with a good old 8051 derivative (Philips 89C668 version).
However, soon it appeared this processor was way to "small" to fulfil the needs I had. Small in the sense that it had too few memory (both ROM as well as RAM).
Also, there was no basic functionality available, such as a robust OS, USB functionality, ethernet functionality, web server, etc. etc.
Pure by luck, I met a colleague at the office who was experimenting with a couple of 8051 alternatives, to extent their automatic test cases environment (testing high quality Philips televisions). One of their test cases was the FoxBoard.
Honesty obeys me to say I'd never heard of it before. But since I heard it was running embedded Linux (waaawww!!!!), I was immediately triggered (read: very much interested).
I got some information from this colleague and one of the first things I did, was surfing on the inet to find more information about this small device.
I must say: when I read the specs of that device, I was really astonished! So much on such small board, running Linux!!!
There was USB, RS232, Ethernet, FTP, SSH, WebServer, Telnet,... Next to complete!
I immediately got me such board and ever since, I'm working on it to develop my home automation system (aka. domotics).
This is how the board I currently use, looks like:
This is the famous MCM Classic Red FoxBoard.
MCM means multi components module, since this chip contains next to the processor, also the RAM and FLASH chips (and maybe more), all in one.
I must say, I'm very satisfied about the board and have spent already many, many hours developing software on it.
One of the first things I needed, was a decently working I2C driver. The original one was not really performing the way I wanted it to perform, so I decided to rewrite most of the existing driver.
That resulted in a stable, reliable and fast I2C driver which I made freely available under the GPL license to the FoxBoard community. You can find it here: Tuned I2C driver
Since my whole system is running on the I2C protocol, I don't have to worry about this one any more. At least, my basic protocol is working fine, the rest of the software/hardware is based on this protocol.
In the mean time, there's a newer version available, which has more FRAM and RAM. Here's a picture of the new version:
This new board has 16MB of FRAM and 32MB or RAM! More than enough to do wonderful things with it...
You can find lots of information on the AcmeSystems web site:
http://www.acmesystems.it
There's also a newsgroup about the FoxBoard, which you can find here:
http://tech.groups.yahoo.com/group/foxboard/
Attention: a Yahoo account is needed to be able to actively participate in this newsgroup.
--Geert
However, soon it appeared this processor was way to "small" to fulfil the needs I had. Small in the sense that it had too few memory (both ROM as well as RAM).
Also, there was no basic functionality available, such as a robust OS, USB functionality, ethernet functionality, web server, etc. etc.
Pure by luck, I met a colleague at the office who was experimenting with a couple of 8051 alternatives, to extent their automatic test cases environment (testing high quality Philips televisions). One of their test cases was the FoxBoard.
Honesty obeys me to say I'd never heard of it before. But since I heard it was running embedded Linux (waaawww!!!!), I was immediately triggered (read: very much interested).
I got some information from this colleague and one of the first things I did, was surfing on the inet to find more information about this small device.
I must say: when I read the specs of that device, I was really astonished! So much on such small board, running Linux!!!
There was USB, RS232, Ethernet, FTP, SSH, WebServer, Telnet,... Next to complete!
I immediately got me such board and ever since, I'm working on it to develop my home automation system (aka. domotics).
This is how the board I currently use, looks like:
This is the famous MCM Classic Red FoxBoard.
MCM means multi components module, since this chip contains next to the processor, also the RAM and FLASH chips (and maybe more), all in one.
I must say, I'm very satisfied about the board and have spent already many, many hours developing software on it.
One of the first things I needed, was a decently working I2C driver. The original one was not really performing the way I wanted it to perform, so I decided to rewrite most of the existing driver.
That resulted in a stable, reliable and fast I2C driver which I made freely available under the GPL license to the FoxBoard community. You can find it here: Tuned I2C driver
Since my whole system is running on the I2C protocol, I don't have to worry about this one any more. At least, my basic protocol is working fine, the rest of the software/hardware is based on this protocol.
In the mean time, there's a newer version available, which has more FRAM and RAM. Here's a picture of the new version:
This new board has 16MB of FRAM and 32MB or RAM! More than enough to do wonderful things with it...
You can find lots of information on the AcmeSystems web site:
http://www.acmesystems.it
There's also a newsgroup about the FoxBoard, which you can find here:
http://tech.groups.yahoo.com/group/foxboard/
Attention: a Yahoo account is needed to be able to actively participate in this newsgroup.
--Geert
Subscribe to:
Posts (Atom)