SiLabs CP2110 USB UART

T Chap · 2014-10-28 17:28

http://www.silabs.com/Support%20Documents/TechnicalDocs/CP2110-Short.pdf

I will have this tomorrow and am looking for info on where to start learning how to make this work for a Prop loader direct out of BST or other IDE. If it is too much work to tackle, then the other will be to just upload 32k to spare eeprom space from my own GUI, verify the transfer, then move the 32k to eeprom bootload space. The real goal is a driverless field replaceable firmware method with my own GUI. For shop development, there can be a FT232 based board if the Silabs is not going to be programmable via BST(bstl). The field replacement will always be with my own mac/pc GUI, so it is not such a big deal to me to handle the Prop load protocol. The odds of crashing during an I2C eeprom transfer from higher address to lower address are small.

Here is some serial loader info Mike Green posted, but this is surely way over my head. I am not messing with any variant of C.

http://forums.parallax.com/showthread.php/150460-Propeller-Serial-Loader

Tonyp12 loader with C# and SiLabs.

http://forums.parallax.com/showthread.php/138549-C-Prop-Serial-Boot-loader-example-for-the-Silabs-CP2110

I have a test board in the works for the SiLabs>Prop tester, which is a week or so out if anyone is interested let me know I will send it if someone wants to work on this.

jmg · 2014-10-28 18:12

T Chap wrote: »

... to start learning how to make this work for a Prop loader direct out of BST or other IDE.
...
The real goal is a driverless field replaceable firmware method with my own GUI.

'direct out of' may be a challenge, - the CP2110 does not use a Virtual Com port, it uses HID calls, as in your 2nd link in C#.

T Chap wrote: »

Here is some serial loader info Mike Green posted, but this is surely way over my head. I am not messing with any variant of C.

What language did you want to use ?

C might not be pretty, but it is portable.

You could also look at things like SimpleIDE - not sure if that supports CP2110 yet, but it could be possible to show both COMxx list (ie VCP), and also HID options, to allow driverless support.

T Chap · 2014-10-28 18:41

I am working with Xojo and a third party USB plugin to start. Supposedly the plugin will read and write to the SiLab(any HID device). Below is the USB plugin.

http://www.macsw.de/plugin/PDF/MBS%20USB%20Plugin.pdf

From the plugin company: "We have classes to directly talk to general USB devices or HID devices in special."

T Chap · 2014-10-29 11:16

I made some progress on the SiLabs kit sending data to the Prop back and forth. Still some work to do learning how to manage things on my GUI, but a lot of the work has already been done with the plugins I am using.

I have an idea to use some of the GPIO or flow control pins to connect to the Prop eeprom and have the GUI send the .eeprom data via USB>UART>I2C and update the Prop that way and forget the Prop loading protocol. I think it will be a simple matter to directly access the eeprom from the UART and write the program then reset the Prop.

jmg · 2014-10-29 13:02

T Chap wrote: »

... have the GUI send the .eeprom data via USB>UART>I2C and update the Prop that way and forget the Prop loading protocol. .

Interesting idea, but you would need native i2c support to get tolerable speed - which would mean a CP2112.
(and that drops the UART).
Nice would be a CP2105 variant that had 1 x UART and 1 x i2c, but SiLabs do not make that yet...
That could be done with a C8051F38C, when Silabs release HID libraries.

T Chap · 2014-10-29 13:49

I will find out soon how fast I can toggle some pins for SCL purposes. For field purposes to upgrade firmware, it doesn't matter if it takes some time to write the eeprom, it will be rare and not done often enough to care if it even took 30 seconds. I am liking the driverless communication approach.

jmg · 2014-10-29 15:43

Let us know what speeds you achieve.
From memory when I checked this approach, around 250bps was possible, which I decided was glacial, but may be tolerable in your case.

T Chap wrote: »

I am liking the driverless communication approach.

The CP2112 is the same driverless communication approach, but has HW 400KHz i2c support, which should be (much?) faster than the Prop bit-wise download.

I guess a Prop COG could be coded to be i2c Slave for PC-Link if you needed that, similar size to UART and probably faster ?

Addit: A quick search finds this
http://obex.parallax.com/object/700
and this comment
["Newly added slave driver object, runs in a PASM cog with a Spin handler, and provides 32 byte-sized registers for a master running on another device to write to and read from. Tested okay up to ~769Kbps (max speed of my master object). Includes demo for the slave object."]

So that should allow a CP2112 to do
* Direct very fast EEPROM i2c Updates
* Fast PC link for user code, using the same pins
( just avoid a Slave address anywhere near the EEPROM

)
* use just 2 Prop pins ( & 1 line to hold in reset during i2c EE Writes)..

T Chap · 2014-10-29 16:10

Interesting idea. I will see what speeds I can get and go from there.

T Chap · 2014-10-29 20:07

jmg, I am curious what method you were using to test speeds? The way I see it, for I2C you would have two options.

Set Clock and Data on the same write.
Set Clock Low

Or

Set Data high or low
Set Clock high
Set Clock Low

I think option 2 is correct as option 1 does not allow time for data to be set before the SCL.

http://www.silabs.com/support%20documents/technicaldocs/AN434.pdf

jmg · 2014-10-29 21:14

T Chap wrote: »

jmg, I am curious what method you were using to test speeds?

I did not test an exact CP21110, but my USB GPIO/Handshake line toggle tests on CP2105, FT2xx, FT2xxH suggest the limit is the ~1ms USB frame rate (the FT232H can wiggle quite a bit faster, as the High Speed frame rate is less)

I did a Set/Clear in software and measured the frequency with a Frequency Counter.

I would guess something over 10 minutes for 32KB write, using SW toggles,
vs a HW based (CP2112) speed of a Chip-Erase limit of ~ 2.56s (max), and a 400KHz transport limit of ~ 0.74s.

T Chap wrote: »

I think option 2 is correct as option 1 does not allow time for data to be set before the SCL.

I agree, as you need to avoid false Start or Stop signals (Data change when CLK is hi)

You can do a little compression, by testing and skipping the Data write if the SDA value is unchanged

For read, I would read both SCL and SDA as a pair, and confirm SCL is always low in SW

jmg · 2014-10-30 15:24

I dug about and found my test notes from CP2105 testing (VCP driver) so it will be interesting to compare the CP2110 speeds via HID, when you have it working.

CP2105 File of   [U......U] LOOP BACK     b413  Right-click Paste
Size  		Baud   	TxSend  RxBack    FreqAv     FreqAv  Right-click Paste
100000  	3Mbd 	100000 	100000    627.942K   627.942k*2 = 1255884 ~ 3M*10/1255884 = 23.8875
100000  	1Mbd 	100000 	100000    408.505K   408.505k*2 = 817010  = 12.2397 bits, averags 
100000  	0.5Mbd 	100000 	100000    227.878Hz  227.878k*2 = 455756  10.970 bit slots
100000  	250kbd 	100000 	100000    2250k*10/(125240*2) = 9.9808 bit slots
Remove loopback : (send only)
100000  	3Mbd 	100000 	0    3M*10/(947.068k*2)    = 15.838 bit slots
100000  	1Mbd 	100000 	0    1M*10/(418.035k*2)    = 11.9607 bit slots
100000  	0.5Mbd 	100000 	0    500k*10/(227.8912k*2) = 10.9701 bit slots
100000  	250kbd 	100000 	0    250k*10/(125641*2)    = 9.948 bit slots

FT231X gave lower slip-bits @ 500K and 1M, but dropped chars when set to 3M

You can see low bauds send continually, and as the requested baud climbs, the finite engine speed starts to slip to the next bit slot.
Duplex (simple readback) has more overhead that shows on higher bauds.

We also counted chars out/back, as we found some code/settings combinations dropped chars.

T Chap · 2014-10-30 15:58

jmg, as you already probably know... this usb stuff is a time vortex. Still working on getting the proper communication/protocol between gui and CP2110.

T Chap · 2014-11-04 04:58

I am very close to having an app ready to test ControlTranfer, WritePipe, ReadPipe, etc to manage the Cp2110 as well as use the UART for Prop communication. The GPIO pins for I2C will certainly be too slow. But, what about a dedicated chip for serial from UART to I2C? Or some tiny PIC that reads the 32k serial data for .eeprom and write the eeprom. Surely there is some chip/pic on the market for a dollar or two. The last resort, since it will be easy to connect GPIO to the RST pin, how much of a challenge is it is write direct to the Prop just like PropTool, BST. I see code floating around that has done it.

jmg · 2014-11-04 14:28

T Chap wrote: »

I am very close to having an app ready to test ControlTranfer, WritePipe, ReadPipe, etc to manage the Cp2110 as well as use the UART for Prop communication.

Sounds good.

T Chap wrote: »

The GPIO pins for I2C will certainly be too slow. But, what about a dedicated chip for serial from UART to I2C? Or some tiny PIC that reads the 32k serial data for .eeprom and write the eeprom. Surely there is some chip/pic on the market for a dollar or two.

There is a USB-i2c part for a dollar or two, called CP2112

The merit I see on direct i2c, is much faster (limited only by EE write times) and it can also save pins.
That would allow the option of using a FM24W256, for even faster download times, sure to appeal to developers.

T Chap wrote: »

The last resort, since it will be easy to connect GPIO to the RST pin, how much of a challenge is it is write direct to the Prop just like PropTool, BST. I see code floating around that has done it.

Compared to getting the USB layer, this one I think is relatively simple.
The Prop download IIRC is a simple 3 bits per byte (as Low_Data_High sets), and the loader can manage ~115200 tops, once SW speed and RC margins are allowed for.
This bit-wise encoding makes it relatively slow, but very Baud rate tolerant.
You also need to flip the RST pin, but if you have GPIO and Serial working, the rest is not hard.

If you allow users full baud granularity, (the silicon supports it) then they could push the Baud a little higher on the bench, to prune some download time.

I think SiLabs are getting closer to release of Libraries for UART and i2c in one USB device
(but initially using VCP, not HID)

T Chap · 2014-11-04 15:15

Thanks jmg that is great info. I think the Cp2112 is a great idea, Silabs suggested the same today. Make the Prop an I2C slave like you said, and have direct access to the EEPROM to write it for firmware updates. The good thing is, the basic communication protocol is the same as the 2110, so the efforts so far are interchangeable. I am exploring it further.

BTW GPIO transactions are 1 per ms. Forget this for I2C.

In the AP495, it shows an addressable method to read (ie eeprom), but no addressable method to write. I sent a message to Silabs. Somebody on the forum there may have discussed a trick by sending first an addressable read but don't actually read anything, then do a write. This is not ideal but we will see.

I have a platform now for PC/Mac that allows adding all the functionality of the C libraries from Silabs. All the basics are up and running, now to get the GPIO pins working which is simple. After that it is ready for moving the parts over to a my real projecdt. If you have an interest in the xojo tester project files let me know. These are a breeze for making test apps to talk to the Prop. I can't figure out C so I have someone translate the files in such a way that it becomes very "basic" like for me to deal with. A CP2112 arrives tomorrow to test.

T Chap · 2014-11-05 05:23

From SiLabs re: writing to eeprom

The CP2112 should be able to write to an I2C EEPROM with normal write commands. I'm not sure which EEPROM that you're using, but I will use this as an example: http://ww1.microchip.com/downloads/en/devicedoc/21189f.pdf

For a byte write, you would send a write command of length 3, using the "control" byte as the address. Bytes 0 and 1 would be the address of the byte you wish to write, and the last byte, byte 2, would be the data byte you wish to write.

For page writes, you would merely extend the number of bytes written after byte 2. Unfortunately, the CP2112 only supports total transfer lengths up to 61 bytes, or 59 total data-bytes, so you would need to break these into smaller chunks - possibly 32 bytes at a time, if possible. If that's not possible, and you're unable to write to the EEPROM in smaller than 64 byte chunks, then I don't believe the CP2112 will work for you.

I use the 24LC512-I/SN and will test with that today with the CP2112. I think we would be able to tackle the Prop load sequence, so I am curious if there is an advantage for one device over the other if the EEPROM can be written either via Propload or direct I2C. In this case, if the prop loader is working fine then I would prefer the UART.

Peter Jakacki · 2014-11-05 06:23

T Chap wrote: »

From SiLabs re: writing to eeprom

I use the 24LC512-I/SN and will test with that today with the CP2112. I think we would be able to tackle the Prop load sequence, so I am curious if there is an advantage for one device over the other if the EEPROM can be written either via Propload or direct I2C. In this case, if the prop loader is working fine then I would prefer the UART.

Just to chime in a little on this option of being able to load the EEPROM directly as this is something I build into every board with a PropPlug compatible header. I always thought it was dumb that the PropPlug only had the 4 lines which is fine for some situations but putting another 4 pins next to it didn't make it any less compatible. The other 4 pins have the I2C signals and +5V (in or out) so that the board could be powered from the same connector or that it could also serve as a peripheral expansion connector if need be.

However I use this simple connector as a means to directly program units in the field without requiring a PC or anything complicated, just a little board that plugs in and reads or programs the EEPROM directly within a couple of seconds. Since it costs nothing to add the extra pins and still leaves it compatible with PropPlug etc I just wonder why Parallax haven't cottoned onto this simple little enhancement and made it a standard, I know I wouldn't be without it.
PP8 HEADER

TXD
SDA

RXD
SCL

RST
(key)

GND
VCC

Cluso99 · 2014-11-05 12:43

I use a 1x6pin header on some of my boards...
5V, GND, /RST, SI, SO, x
where x is unused but can be a prop output (as a reset to another prop)

But, I am extending this to a 1x8pin header...
3V3, 5V, GND, /RST, SI(P31), SO(P30), SDA(P29), SCL(P28)
I have an optional transistor reset circuit on many of my boards so they will work with cheap USB-Serial boards as well as the PropPlug.

jmg · 2014-11-05 15:32

T Chap wrote: »

In the AP495, it shows an addressable method to read (ie eeprom), but no addressable method to write. I sent a message to Silabs. Somebody on the forum there may have discussed a trick by sending first an addressable read but don't actually read anything, then do a write.

The write address is just more data payload, so you send DeviceAdr.AddressU.AddressL.Data0,Data1.Data2...

There is one ?? detail in the data, that says 61 bytes max, (which I think is related to the USB packet limit) but it does mean a 64 byte page write is not going to be supported. (that would need 64+2+1 = 67 bytes)
Perhaps you could test if that is a real limit, once you have it working.

- I'd start with 32 byte 'pages' to confirm you can write, then expand.

I found this
http://www.atmel.com/Images/doc5237.pdf
Has Page and Address schemes for useful EEPROMs.
512k looks to have a larger page, would allow faster downloads,if you could send 131 byte messages.
1M has a Page Pin, so could HW select 2 Copies.

jmg · 2014-11-05 15:51

Peter Jakacki wrote: »

However I use this simple connector as a means to directly program units in the field without requiring a PC or anything complicated, just a little board that plugs in and reads or programs the EEPROM directly within a couple of seconds..

Nifty, and sounds close to what the OP is after.

What speeds do you get on UART vs I2c, and what i2c part number ?

What is on the "just a little board" ? - a small Micro and a master EEPROM ?

Peter Jakacki · 2014-11-05 16:25

jmg wrote: »

Nifty, and sounds close to what the OP is after.

What speeds do you get on UART vs I2c, and what i2c part number ?

What is on the "just a little board" ? - a small Micro and a master EEPROM ?

I mentioned this method as it might have some bearing on what the OP is after of at least offer an option. The I2C method always works as it has direct access to the EEPROM and of course can hold the Prop in reset while it's doing it. Whereas I've had problems loading boards from the serial port when the Prop is transmitting a lot of information which throws the PC timing off due to garbage in the FIFO.

For the little board I've mentioned in the other posts where I have just used exactly the same tiny board for the programmer as the one it's programming but I have other tiny boards too with PICs on them and EEPROM as it is very simple code to access the target EEPROM and read or write to it. At 400kHz and using ACK timing to find when the EEPROM is ready after a page write it takes only a couple of seconds to write the 32K EEPROM. The advantage of a device like this is that I can use it to read a Prop and then clone it onto the other Props and since it's so simple I can let someone else do it. This is especially useful when the units have to be upgraded in remote sites, I can email a binary that they load onto an SD card which plugs into one of my boards adapted for use as a programmer. All done and dusted with minimal fuss.

BTW, the 8-pin header I use can also accept my PL2 USB to serial adapter or a Bluetooth module instead that ends up plugging in as part of the unit (or not), so rather than building USB into a product I just leave a 8-pin header on the PCB and then I am still free to do with it what I want. This includes those little add-ons you find out you need so if I needed a 4-digit 7-segment display added on for instance then I can plug one of these I2C LED display modules directly into the 8-pin header and presto, instant expansion.

Since IDE cables aren't normally available in 8-pins I just use two of those cheap Dupont 4-way jumpers super-glued together. Here's a shot of one of my USB2SER PropPlug compatible adapters converted to an inline connection with the dual 4-way cables plugged into a Prop based PLC and powering the logic and LEDs while it's at it. The programmer simply replaces the USB2SER although it would be possible to insert it between the USB2SER so that the programmer EEPROM could be loaded as if it were a Prop in the first place.

T Chap · 2014-11-05 16:49

I like the idea Peter, but I guess I should clarify that my product is tethered to USB, so I am only looking for a USB method of firmware updates. I am also only after driverless USB. I love FTDI, but for products in the field it is a real pain. Today I spent 30 minutes of my day on the phone trying to help a client get win7 to install the FTDI driver that I supplied. There have been quite a number of days that I lose a chunk of time trying to get these drivers installed on all types of systems(walking clients through it over the phone= painful), some with protection, some with weird issues. So I must move away from FTDI. I believe that we will have the Propload direct from USB>UART handled over the next few days. Now that there is guidance on direct USB>I2C>EEPROM, the CP2112 is a piece of cake, however I am resisting using the Prop in slave mode whereas the GUI is polling. If I get the Propload working, I am using the CP2110 USB>UART. I too would prefer to see dual row headers for any type of programmers, a single row is too fragile IMO. JMG your ideas have been a big help on suggesting this IC.

richaj45 · 2014-11-05 17:58

Peter Jakacki wrote: »

I mentioned this method as it might have some bearing on what the OP is after of at least offer an option. The I2C method always works as it has direct access to the EEPROM and of course can hold the Prop in reset while it's doing it. Whereas I've had problems loading boards from the serial port when the Prop is transmitting a lot of information which throws the PC timing off due to garbage in the FIFO.

For the little board I've mentioned in the other posts where I have just used exactly the same tiny board for the programmer as the one it's programming but I have other tiny boards too with PICs on them and EEPROM as it is very simple code to access the target EEPROM and read or write to it. At 400kHz and using ACK timing to find when the EEPROM is ready after a page write it takes only a couple of seconds to write the 32K EEPROM. The advantage of a device like this is that I can use it to read a Prop and then clone it onto the other Props and since it's so simple I can let someone else do it. This is especially useful when the units have to be upgraded in remote sites, I can email a binary that they load onto an SD card which plugs into one of my boards adapted for use as a programmer. All done and dusted with minimal fuss.

BTW, the 8-pin header I use can also accept my PL2 USB to serial adapter or a Bluetooth module instead that ends up plugging in as part of the unit (or not), so rather than building USB into a product I just leave a 8-pin header on the PCB and then I am still free to do with it what I want. This includes those little add-ons you find out you need so if I needed a 4-digit 7-segment display added on for instance then I can plug one of these I2C LED display modules directly into the 8-pin header and presto, instant expansion.

Since IDE cables aren't normally available in 8-pins I just use two of those cheap Dupont 4-way jumpers super-glued together. Here's a shot of one of my USB2SER PropPlug compatible adapters converted to an inline connection with the dual 4-way cables plugged into a Prop based PLC and powering the logic and LEDs while it's at it. The programmer simply replaces the USB2SER although it would be possible to insert it between the USB2SER so that the programmer EEPROM could be loaded as if it were a Prop in the first place.

So Peter you have a PIC design for serial to i2c that is proven, cost almost nothing, and there is software to drive it?

Care to share the design, if you have time?

rich

Peter Jakacki · 2014-11-05 18:17

richaj45 wrote: »

So Peter you have a PIC design for serial to i2c that is proven, cost almost nothing, and there is software to drive it?

Care to share the design, if you have time?

rich

Sure, no probs, I use one of my existing boards though, a tiny little surface-mount LCD backpack with a PIC16F690 loaded with an otherwise optional EEPROM. I'm sure though that you could port that to any other PIC for that matter. The code doesn't include any Prop bootloader frontend though, but you can use this as a stand-alone field programmer and reader. It is possible to load the programmer's EEPROM through the PIC's serial port and if I did this I would just make it a simple Intel hex format load so that no special drivers are required, just a terminal and copy and paste the hex file into it for the programmer to load into it's EEPROM. Something that most customers could do. After that you can go around to all the units and load them up in seconds.

Is that what you were after? Of course you could use it as simple serial to I2C directly.

richaj45 · 2014-11-05 21:17

@Peter

What i am most interested in is what control protocol did you use to command the I2C interface over the UART serial interface?

That is what was the actual command format on the UART side?

thanks
rich

Peter Jakacki · 2014-11-05 21:39

richaj45 wrote: »

@Peter

What i am most interested in is what control protocol did you use to command the I2C interface over the UART serial interface?

That is what was the actual command format on the UART side?

thanks
rich

Well isn't that what you make it then? In this case though the Intel hex file is a simple hex file that can be copy and pasted etc and contains all the information in there to load a EEPROM.

In the case of a hex file this is part of it here:
:1000000000B4C4046FF61000BC7EC47E887EC87E37
:10001000AC7E0200787E00005EF46001000000000B
:100020000084030000400000000000000000000009
:10003000DD5D5DD700000000000000008D200000A5

So the :10 says there are 16 bytes of data, the 0000 is the address, 00 is the type, 16 bytes of data followed by a checksum, simple.

The last line has a type of 01 to indicate the end.
:107EC000FFFFF9FF000000000000000000000000BC
:00000001FF

Is there another method you were thinking of, I'm not exactly sure how you would be using this but the code is trivial.

richaj45 · 2014-11-05 21:49

@Peter

So you just send intel hex records to the PIC over UART and the PIC programs the EEPROM over I2C?
Ok
I just thought there might be more a more general i2c control protocol as using the PIC to control other i2c devices.
But then your simplicity make it robust for the intended purpose.
I understand. I think i try to make interface to complicated.

thanks much
rich

Peter Jakacki · 2014-11-05 22:03

richaj45 wrote: »

@Peter

So you just send intel hex records to the PIC over UART and the PIC programs the EEPROM over I2C?
Ok
I just thought there might be more a more general i2c control protocol as using the PIC to control other i2c devices.
But then your simplicity make it robust for the intended purpose.
I understand. I think i try to make interface to complicated.

thanks much
rich

Well if you wanted to you could program up a small USB micro to handle HID to I2C conversion for you but the problem is how do you translate HID protocols to the various I2C devices? Many of the problems I see with USB stem from Windows insistence that it needs a "driver", even if it is just a USB Flash drive, I see Windows bing and bong, being ever so helpful, looking for a "driver" until it eventually works. Contrast this to Linux or perhaps even OSX and the stuff including FTDI just works straight-away, no fussin n no cussin.

Cluso99 · 2014-11-05 22:22

Peter,
IDE 2x4 cables are available on eBay for the 8pin program header for AVRs. There is also a 10pin version with incompatible pinouts.

Peter Jakacki · 2014-11-05 23:01

Cluso99 wrote: »

Peter,
IDE 2x4 cables are available on eBay for the 8pin program header for AVRs. There is also a 10pin version with incompatible pinouts.

Yeah, they do have them but I've found it very handy just to have a whole stack of these cables in stock for all kinds of things. No more crimping and only about 16 cents a cable!

When I glue them together I put the blank faces together plus I push a cut pin into one of the positions for a key.

T Chap · 2014-11-06 02:43

Peter, the SILabs CP2112 that we have been discussing is a driverless USB>I2C interface that comes with C Libraries. If you know anything about using the libraries/DLL then it is a breeze to use these devices. I don't know C but hired someone to translate the Libraries into a format I can use which is Xojo(multiplatform application development). Accessing the libraries is done at a basic level requiring zero C knowledge, I do not even need to look at the libraries. Making an app to send and receive data including .eeprom files is pretty simple, no C required, feels more like Spin.

Here is an example of what is involved behind the scenes to connect to the device by clicking a single button:

  // Open the device
  if HID2UART.Open(CP2110, 0, &h10C4, &hEA80) = HID2UART.SUCCESS then
    txtStatus.AppendText "Device opened successfully."
  else
    txtStatus.AppendText "Device open failed."
    return
  end if
  txtStatus.AppendText EndOfLine + EndOfLine

A button to write data to the UART:

  // Write to the UART
  dim numBytesWritten as Integer
  if HID2UART.Write(CP2110, "aaaaa", 5, numBytesWritten) = HID2UART.SUCCESS then
    txtStatus.AppendText "Text successfully sent."
  else
    txtStatus.AppendText "UART write failed."
    return
  end if
  txtStatus.AppendText EndOfLine + EndOfLine

Finally the tester has functionality for all the needed device access. GPIO control, read, write, UART config. I have GPIO connected to the Prop Reset and can toggle reset. Next goal is to tackle the Proploader. After that, load a file into the app and load to ram, ram+eeprom. The methods available are listed. These are accessible in Xojo very similar to Spin syntax. There is no looking at C. Possibly a command line version that loads a genenic .eeprom file ie temp.eeprom, run the app from some other application behind the scenes might be useful for development. The end goal is to send a client a zip of the app+eeprom or app w/embedded 32k file. Extract, press upload. For development, have an app running in the background watching for a key (an alternative F10/F11 to write to Silabs) that is not used on BST/PropTool. To upload ram on the bench, Compile and Save As EEPROM, then press the key which writes the program to ram or eeprom. This should only take one extra step to save the temp.eeprom, which is on a few seconds. The app behind the scenes reads a keypress(simulated F10), loads a file called temp.eeprom from the Propeller folder, and writes the 32k to ram on the device. Or even fancier, the app watches the temp.eeprom file for time stamps for last save, and if it was changed within the last second, write it to the device automatically. Or more fancy than that... have the app watch for a special keypress from BST, then load the file into the app and run bstc>save to eeprom as temp.eeprom > write to SiLabs. So it is a one touch operation just like F10/F11 for development.

SiLabs CP2110 USB UART

Comments