Controlling your World the Easy Way

Presumably only two I2C devices can be connected and controlled using this board? I'm hoping that the USB connection is not one of them. I'm brand new to embedded controllers and was thinking of buying a Picaxe board but I need to get my I2C humidity controller up and running as quick as I can.

Haven't bought an EzSCB1 yet but I'm fairly sure I will and I really do like what you have done with this board.

The EzSBC1 has one I2C port. That is, there are two pins for the I2C function and they are called SDA and SCL on p4 and p5 of the 40 pin module. One I2C port can control many I2C devices or slaves as they are called. The SDA and SCL pins drive two wires that go to pins with the same names on as many slaves as you need. The exact number of slaves that you can have depend on a few factors including how many of the same device you want to have. Each slave has an address and most slaves can have more than one address by tying some pins high or low. EEPROM devices can normally have 8 different addresses so you can have as many as eight (small) EEPROMs on the I2C bus. You can also have other slave devices on the bus as long as they have different addresses. I2C buses with half a dozen different slaves are fairly common in car radios and handheld devices like tablets. Since the address of the slaves is generally 7 bits long the number of slaves are limited to 127. http://www.best-microcontroller-project ... orial.html is a reasonably good tutorial. http://www.nxp.com/documents/user_manual/UM10204.pdf is the full specification.

I will post some code in the downloads section to drive two different slaves on the I2C bus. I hope this helps.

Daniel

Thanks Daniel for your reply.

As I understand it the Picaxe and Teensy products only work in master mode that is they have problems with other masters on the same bus. Can we say this is the same for the EzSCB1?

I'm a newly retired hobbyist returning to his first passion, electronics and byte conscious computing. My problem is that I2C devices are expensive and often their slave addresses are all hardwired and I have yet to find one where the addresses can be reconfigured at a sensible price?

Non I2C, non standard, devices like the SHT11 or its cheaper counterpart the DHT11 lack built in support from embedded controllers like the EzSCB1 and I really don't know why given their wide availability and usage?

Futurlec are selling a humidity+temperature sensor (Hanwei HHT2M1) with two analogue outputs at around 12 bucks each and it would cut out a load of programming hassle if these were connected to available A to D inputs?

The EzSBC1 has no problems with other masters on the bus as long as they play by the rules. That said, the EzSBC1 can not be addressed as a slave to another master, I have not made provision to provide a slave address or a slave mode other than a passive listener when it detects another master on the bus.

I had a quick look at the DHT11 and DHT22 datasheet and it will be tough to meet the timing from inside Control-BASIC but easy if it was done as a built in command. I will obtain a few devices and add a suitable command. Do you perhaps have English datasheets for the DHT11 and SHT11?

I noticed that I didn't say anything about the USB bus in my previous reply. The USB bus and related pins are completely internal to the EzSBC1 and the 33 I/O pins, I2C etc does not compromise the USB bus in any way, shape or form.

I will post a schedule for implementing an interface to the DHT11 style devices here by Monday.

Daniel

Chinese Guangzhou Aosong Electronics Co., Ltd manufactures the DHT11 and AM2315 humidity temperature sensors which are widely available in the channel. The latter is I2C with a slave address of 0xB8 however every device purchased has the same slave address 0xB8. They also make voltage output humidity sensors too.

http://www.aosong.com/en/products/index ... l%20Sensor

Swiss Sensirion manufactures the SHT11. The DHT11 is believed to be protocol compatible?

http://www.sensirion.com/en/products/hu ... sor-sht11/

With regard to Control BASIC and real time programming: I used to work with the Allen-Bradley BASIC Module (1771-DB) which uses Tiny Basic back in the early 90's. The interpreter used a fixed frame character length time cycle for each line of BASIC code. With Tiny BASIC you could use the colon to separate verbs on the same line which allowed you to pack the line with code thereby maximizing frame time processing. This was important because you could time lines of code in milliseconds.

Do you use a similar scheme or do you use a variable frame time for each line of interpreted code?

My user name by the way comes from the National Semiconductor 16 bit processor which I was assembly coding back in the late 70's.

http://www.antiquetech.com/chips/NSIMP-16.htm

You guys are really spoilt, I mean 4k of memory cost 5,000 dollars and the exec was loaded up using a punched tape optical reader. Mainframe memory used ferrite bead cores and the baud rate from the teletype was 30cps.

Thank you for the links. I ordered some parts and they should arrive next week and then I'll build an instruction for talking to these devices.

Regarding fixed time execution; I don't use it since it is wasteful of the CPU power. The cycle time has to be longer than the slowest instruction plus some wiggle room so than features can grow. If there is a big spread between fastest and slowest instruction a lot of time needs to be wasted for the fast instructions to wait for the end of the time slot. My solution to the problem is a background timer that is fast and precise. Most users don't care about the exact timing of the code as long as it is fast enough. For them time slot code is an expensive, unneeded overhead. If you care that your code should run at a constant rate such as once per millisecond then the background timer is a good solution.

The way the background timer works is that it increments a 32-bit counter once every 100us. At the start of the loop you wait for the background timer to reach the old value plus ten counts (for 1ms timing). You then immediately do the time sensitive stuff such are read the ADC, update the DAC etc, followed by the rest of the processing. Then you go to the beginning of the loop and wait for the timer to reach the next multiple of 1ms. With the background timer you can even run different sections of code at different rates.

Daniel

I forgot to mention Daniel that the AB 1771-DB was installed in a rack system whose slot cards were polled by the main processor card; hence I think the need for a fixed time frame.

By contrast to what you said re the timer; on the assembler software I worked with (nothing to do with AB) the IMP-16 CPU ran a small looping exec core which sent tasks/data to peripheral devices and waited for an interrupt to occur before processing the results. The exec loop was re-entrant, that is, stacks were pushed and popped to allow this. When the exec ran code, the code would simply execute and then stop.

This was the essential difference between Digital Research's looping DrDOS and Microsoft's interrupt driven MSDos. In common both versions had to have an OEM merge module that allowed it to interface with hardware.

Generally, when writing assembler code you can time the loop by adding up the clock cycles involved with each instruction. Later flavors of BASIC allowed insertion of object code in the program flow for critical time processing. I guess you cannot time a Control-BASIC instruction in clock cycles nor can you allow the insertion of native code, or can you?

One thing I asked the good folks at Revolution (Picaxe) was whether their BASIC code could be recompiled to run as native code on a standard chip. Their answer was no, which makes sense as the Picaxe is an inexpensive very well supported educational toy. They also said their chips had fuses to prevent read reverse engineering and that nobody had broke this protection. I guess the truth is that they are so cheap nobody has bothered.

So respectfully at what level are you pitching the EzSBC1?

Assuming you generate the economies of scale and given you use the term 'Control-BASIC' do you see the device being used at the heart of a control system? If so and to prevent the reverse engineering of the EzSBC1 should you invest in a compiler that recompiles Control-BASIC to microcontroller native code?

The reality is that any protection can be broken and easily as well. For devices that store code in flash with a security bit a small amount of money and a little more knowledge is all hat is needed. In the semiconductor industry the reality is that most chips don't work the first time they go through the fab and there is an extensive array of tools to modify the chips. I'm not going to make this a tutorial on how to break protection so I will restrict what I say to what doesn't work all that well. One way is to put the programmed part into a device programmer and repeated 'blow' or program the protection fuse. With luck it will fail in such a way that the code is exposed. This has mostly been defeated by better design of the fuse circuitry. For UV eraseable parts the security fuse was designed to be the last to erase. That meant it looked different from the others. Some free time and a microscope and you could identify the security fuse through inspection. Or you could program only the security fuse and some tricks to find where the charge was different from the other fuses. Now a simple UV laser and some target practice and you can erase just the security bit leaving the code vulnerable. Microchip fell foul of this some years ago and put their security fuse under a metal shield to prevent them from being erased through the window.

In the semiconductor design field we do something called 'FIB' experiments. The FIB stands for Focused Ion Beam and here in the Valley I know of at least half a dozen vendors with machines for hire. These machines are expensive but the service cost a few hundred dollars per hour of machine time. These machines are magic for designers with broken designs. You can cut metal, drill vias and make new connections (stitches) even in the lower layers of the metal, say layer 1 of four layers of metal. The machine can 'drill' a hole in the passivation, deposit tungsten to make a new connection and route it somewhere else. As long as the lines are shorter than a 100 micron or so and the mod is not too elaborate the success rate is high. The legitimate use of the machine is to test design fixes before we buy masks or to isolate a problem. But I can easily cut off the security fuse. So when someone say 'My security is unbroken' they are lying or no-one has tried or they don't know who about their broken security. The only security that is hard to beat is where everything is in RAM, encrypted, battery backed and potted with temp sensors, light sensors and micro fine wires connecting the battery to RAM and self destruct mechanisms. I know, I made them in the past, around 1995 to 2000 for the banking industry.

The majority of users for the EzSBC1 use them as controllers in test systems. They want a system that is easy to program, flexible and cost effective for a few dedicated systems. It is also used by the rapid prototyping industry for proof of concept demonstrations. It is pretty popular as a robot controller for school science projects. In Si-Valley there are literally thousands of semiconductor companies who test things and are forever looking for a quick and easy way to send commands on an I2C bus or an SPI bus or wiggle pins as part of a lab setup. They are good customers.

It would irritate me if the code is 'popped' and placed on some web site so people in the far east can clone my design but I don't loose sleep over the possibility or inevitability. The vast majority of customers buy from the source even if a ripoff is available. The open source hardware movement (that I support) is proof of that. Arduino has more clones than you can wave a stick at but they go from strength to strength because the majority of customers support them voluntarily. The code in the EzSBC1 is 22 modules and total about 100,000 lines of C with the interpreter being about 5000 lines of code. The bulk of the code deals with the hardware and with tricky things such as downloading code while writing to the Flash and executing code from the same Flash memory. It took me a long, long time to write the documentation, test the code and get the hardware bulletproof. I spend a lot of time answering questions and making improvements to the design. I wish the sales volume would pick up some more so I can afford another price reduction but the micros remain stubbornly expensive at the present volumes.

Right now I don't have plans to allow assembler code directly. It is hard to allow and maintain reliability of the system. If I make a compiler it will not be a true native code compiler because they exist and it defeats my objective of hiding the complexity of the processor from the user. It will probably be a hybrid, like Visual Basic 6 and earlier, that has a substantial run time environment that supports the hardware hiding so all the Control BASIC commands still work. Another thing about compilers with run time environments is that you have to have a way to 'unbrick' a module once the user has loaded some code and set security and now the module just sits there doing nothing because it crashes in a tight loop. This can happen because the user code can break the run time environment in more ways than I can imagine.

We have drifted off topic quite a bit.

Daniel

OT perhaps, but fascinating all the same.