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
Intel HEX is a great subset choice, as you say you can copy or send file.
There is also plenty of spare on intel hex, so superset extensions are possible.
eg in Type field, '00' to '05' are used by intel hex, so the upper nibble could write GPIO lines, which could embed RST and page commands in a HEX file.
There is also bandwidth wasted in HEX, so the Type field could tag 'binary following', to double the payload speed.
(you know how many bytes are coming, and the format,so flip back to ASCII.HEX at checksum RX)
Other tags can do Verify and Read operations. ( 'R', 'V' ? )
Fastest possible PGM, would be to re-size the hex line to match the EEPROM page size, and to flip to binary, and real speed freaks could use a FRAM/FERAM part.
I've seen some i2c-ascii designs that send S and P for start and stop, but I think the CP2112 is not that granular.
Here is an example of what is involved behind the scenes to connect to the device by clicking a single button:
Looks good progress, when you get it settled, I'd be interested in the upper speed limits, ie large block Send-only, and Loop--back of the CP2110, to compare with the CP2105 values I gave in #11.
I just got the proploader working from the GUI through the Silabs CP2110. It works perfectly. The GUI is built in Xojo, and can be built in Mac/PC/Linux. The C libraries from the SiLabs are accessed though the Xojo app in very simple language, the app could just as easily use the FT232. The goal for this is to have a driverless option for higher volume products so that the end user does not have to do much effort for firmware updates. I made a pretty crappy iphone video but it gets the point across. Thanks for the suggestions from everyone.
Looks good
Was that with control of the RST line too ?
Did you try upper baud speeds and download times for both UART and i2c paths ?
(adding some time reports into the code is a nice way to get accurate times, & it would allow others to report FeRAM times if anyone tries that.
I've also done sustained speed tests by sending large files of 'U' (2~20 seconds Tx time) and measuring the Hz on the TXD line.
Ideally, that is Baud/2, but as the baud pushes up, parts of the system struggle to keep up, and the Hz drops
Addit: oops, I guess you do not quite have a CP2112 yet, to test i2c..
A GPIO is in push pull mode direct to the reset pin, no transistor. I got in a CP2112 but never opened the box. I am preferring the proploader idea over I2C. Thanks for the help jmg. If you ever want to mess with the app let me know I can send you the xojo project file and you can load it right up. I will try to see if I can run that test and see what happens. I may not be completely clear of the test and how to measure it. If you can give a specific way to do this I can check it tomorrow.
A GPIO is in push pull mode direct to the reset pin, no transistor. I got in a CP2112 but never opened the box. I am preferring the proploader idea over I2C. Thanks for the help jmg. If you ever want to mess with the app let me know I can send you the xojo project file and you can load it right up.
I do not have xojo, but you could post the source as the calling details for the CP2110 are likely to be widely useful.
May even allow a FreeBasic command line version ?
If you do find time to get i2c going that would also be useful, as there are more UART download solutions than i2c ones...
I will try to see if I can run that test and see what happens. I may not be completely clear of the test and how to measure it. If you can give a specific way to do this I can check it tomorrow.
Tests suggested are pretty simple
a) For Prop download, start at 115200 and edge up until download breaks.
CP2xx parts I think all have a virtual baud clock of 12MHz, so you can do 115200, (should give 115384)
and also 116504, 117647 etc (ie quite fine steps) 150k+ might still work ?
b) for System Speed tests, just create a large single-line file filled with U's (55H's & nothing else) with a text editor (or pgm) and File-send.
Connect a frequency counter to TXD and record the freq. Should be Baud/2 at low speeds, dropping as limits occur.
If you also have a count (total) mode on your counter, check that too, for missing/dropped chars.
100k file should have 500,000 edges
Xojo is 100 for each platform that you want to be able to build for. You can run the app fully functional with in Run mode, but you can't build the app unless you pay for that platform.
I don't own a dedicated frequency counter but the Prop is already connected and can count at those speeds I believe. The CP2112 would be trivial to get running, considering all the ground work is done for the 2110. I won't have any extra time in the near future though for those CP2112 experiments. Adding libraries from the 2112 is pretty straight forward. I think it would be only a little effort to convert the app to a command line/console that could accept a filename, command number(1-3).
Tests suggested are pretty simple
a) For Prop download, start at 115200 and edge up until download breaks.
238,000 baud is consistent loading maxed out binaries. 250,000 is consistent for small files.
If you want this CP2112-Ek the pm an address and I will send it.
I attempted a test with the Parallax(Saleae) 24mhz logic analyzer. At a point, above baud 1843200 the frequency in the analyzer keeps showing 1mhz. In the image, the file name shows the baud that was set in the app sending the U's. I did not do any large files yet nor any counting.
I attempted a test with the Parallax(Saleae) 24mhz logic analyzer. At a point, above baud 1843200 the frequency in the analyzer keeps showing 1mhz. In the image, the file name shows the baud that was set in the app sending the U's. I did not do any large files yet nor any counting.
CP2110 Baud rates supported: 300 bps to 1 Mbps
The CP21xx series round to the nearest baud, so for that part it looks like anything above 1.8, rounds to 1,8
What size arrays were you sending ?
The freq values given are not picking up the extra stop bits, which you can see being added.
Looks similar to a CP2105 - (certainly not a lot worse), and I was wondering if the HID had speed caveats.
The CP2105 (with VCP driver) & care with buffer sizes (larger is always good ) we were able to get with no added stop bits at 250K and ~1 extra at 500k.
The 2110 plots look to have +1 @ 230k and +2 at 460, so ~one stop bit slower.
( I guess at 115k, there is no added stop bit?)
That is a USB-HID to On-Chip Flash loader, that would be relatively easy to flip to off-chip Serial EEPROM writing instead. (to load the Prop Serial memory directly, or to UART to the Prop loader)
and for fun, I downloaded and compiled with an older SDCC. (3.1x)
That gave some warnings, on inline calls, (but did create a hex file) so I grabbed SDCC 3.4.0, and the inline name warnings went away.
The ideal modern target for this ~1.5k footprint USB-HID loader, would be the C8051F38C (16KF & cheapest @ $1.49/1+ )
Thanks for the info jmg, that is interesting stuff. I am already quite invested in the CP2110 path. 1k quantities at digi are $1.27. I got in several different boards today with the Prop/Cp2110 combo. I posted a photo of a prop breakout board that has all the GPIO on a header and 28 pins from the prop on a header. The Prop loader is working flawlessly on the Cp2110, even have a console command line version that is very easy to drop into other apps. My own Spin editor app uses BSTC for compiling (I rely on the optimization heavily), A single button click or F10 will compile the spin code, save it to disk as temp.binary, then the Proploader sends that to the Prop via CP2110. You cannot tell the difference in speed or ease of use versus the F10 using FT232.
The issue with eeprom or flash loading is the speed of loading for development purposes. I want to send to Ram and check out the result asap. I am curious to know where you find that route as advantageous versus some variant of Proploader, are you looking at that as more of an in field firmware update method?
I am curious to know where you find that route as advantageous versus some variant of Proploader, are you looking at that as more of an in field firmware update method?
I added the gboot info mainly for others who may search for HID later.
The interest in USB(HID)->EEPROM is mainly because that is a less supported pathway - as you say, the present default is the Proploader 3b Serial.
For devices like P2, serial is going to struggle more, as not only is the P2 memory larger, but the SPI Flash is a whole lot larger again, and is likely to hold font info etc
I just got the proploader working from the GUI through the Silabs CP2110. It works perfectly. The GUI is built in Xojo, and can be built in Mac/PC/Linux. The C libraries from the SiLabs are accessed though the Xojo app in very simple language, the app could just as easily use the FT232. The goal for this is to have a driverless option for higher volume products so that the end user does not have to do much effort for firmware updates..
Curious what speeds did you get this working to ? - IIRC it was fine for P1 loading, but that has a lower ceiling, of something over 200k baud.
The WEB info I can find is vague on HID speeds. There seems general agreement of 64 bytes per 1ms frame, which indicates ~640kBaud equiv, but some posts I found said it needs 1ms each way. - which may limit it to ~320kBaud ?
The plots above do show extra stop bits expanding, as the Baud increases, if that's 50% at 1MBd, that's appx 500kBaud average sustained ?
Then I wondered about HIS at HS_USB - Attached is a USB HID report for 2 HID devices, the HS-USB MCU report has this
Device ID : HID\VID_0416&PID_8249\7&7255588&0&0000
Class : Mouse
...
----------------- Endpoint Descriptor -----------------
bLength : 0x07 (7 bytes)
bDescriptorType : 0x05 (Endpoint Descriptor)
bEndpointAddress : 0x81 (Direction=IN EndpointID=1)
bmAttributes : 0x03 (TransferType=Interrupt)
wMaxPacketSize : 0x0040
Bits 15..13 : 0x00 (reserved, must be zero)
Bits 12..11 : 0x00 (0 additional transactions per microframe -> allows 1..1024 bytes per packet)
Bits 10..0 : 0x40 (64 bytes per packet)
bInterval : 0x14 (20 ms)
Which has extra stuff not in the LS-USB or FS-USB ?
Suggests first 64 bytes per microframe, so that's ~ 5.12MBd, and then I see 1024 bytes per packet, might be possible via additional transactions per microframe 4 *64/microframe hits ~20MBd
Do you have any HID link speed-test code that can talk to the HS-USB HID part in this report, to test max data rates ?
I never tested speed because I only use it for loading the prop and the benefit of HID is no driver and I can’t be tied to FTDI which is a big pain having clients do updates. HID is flawless for sending out binaries. If you can suggest a easy method I can run a test. I’m not sure how to run a speed test. There was something funky with high speed prop loading. Was there extra stop bits? I don’t remember but it seems like on large binary uploads it wouldn’t load full speed.
I never tested speed because I only use it for loading the prop and the benefit of HID is no driver and I can’t be tied to FTDI which is a big pain having clients do updates. HID is flawless for sending out binaries.
Yes, that's partly why I'm looking into faster HID, for possibly loading P2 without needing drivers.
If you can suggest a easy method I can run a test. I’m not sure how to run a speed test.
I've not tried HID speed tests, but it looks like that USB into above, has enough to connect and repeat-send (or RX?) 64 bytes to the endpoint above ?
Looks like you can also send a request for Device Descriptor, (or Interface Descriptor) which should work on any mouse. (because my HS-USB board looks like a mouse)
If you alternated such requests, with some N numbers of packets to what looks like a valid endpoint, you could check if the device still was following.
There was something funky with high speed prop loading. Was there extra stop bits? I don’t remember but it seems like on large binary uploads it wouldn’t load full speed.
Maybe you are thinking of the extra stop bits that appear at the highest baud rates, where the MCU cannot quite keep up. (visible in the plots you gave above)
The baud (bit level timing) is correct (eg 1MBd) but the average byte rate is closer to 50kB/s than an ideal/theory 100kB/s
Comments
Intel HEX is a great subset choice, as you say you can copy or send file.
There is also plenty of spare on intel hex, so superset extensions are possible.
eg in Type field, '00' to '05' are used by intel hex, so the upper nibble could write GPIO lines, which could embed RST and page commands in a HEX file.
There is also bandwidth wasted in HEX, so the Type field could tag 'binary following', to double the payload speed.
(you know how many bytes are coming, and the format,so flip back to ASCII.HEX at checksum RX)
Other tags can do Verify and Read operations. ( 'R', 'V' ? )
Fastest possible PGM, would be to re-size the hex line to match the EEPROM page size, and to flip to binary, and real speed freaks could use a FRAM/FERAM part.
I've seen some i2c-ascii designs that send S and P for start and stop, but I think the CP2112 is not that granular.
Looks good progress, when you get it settled, I'd be interested in the upper speed limits, ie large block Send-only, and Loop--back of the CP2110, to compare with the CP2105 values I gave in #11.
I just got the proploader working from the GUI through the Silabs CP2110. It works perfectly. The GUI is built in Xojo, and can be built in Mac/PC/Linux. The C libraries from the SiLabs are accessed though the Xojo app in very simple language, the app could just as easily use the FT232. The goal for this is to have a driverless option for higher volume products so that the end user does not have to do much effort for firmware updates. I made a pretty crappy iphone video but it gets the point across. Thanks for the suggestions from everyone.
Was that with control of the RST line too ?
Did you try upper baud speeds and download times for both UART and i2c paths ?
(adding some time reports into the code is a nice way to get accurate times, & it would allow others to report FeRAM times if anyone tries that.
I've also done sustained speed tests by sending large files of 'U' (2~20 seconds Tx time) and measuring the Hz on the TXD line.
Ideally, that is Baud/2, but as the baud pushes up, parts of the system struggle to keep up, and the Hz drops
Addit: oops, I guess you do not quite have a CP2112 yet, to test i2c..
I do not have xojo, but you could post the source as the calling details for the CP2110 are likely to be widely useful.
May even allow a FreeBasic command line version ?
If you do find time to get i2c going that would also be useful, as there are more UART download solutions than i2c ones...
I find some discussions here on xojo
https://forum.xojo.com/1623-xojo-pricing/0
They seem to be nudging up prices ?
Tests suggested are pretty simple
a) For Prop download, start at 115200 and edge up until download breaks.
CP2xx parts I think all have a virtual baud clock of 12MHz, so you can do 115200, (should give 115384)
and also 116504, 117647 etc (ie quite fine steps) 150k+ might still work ?
b) for System Speed tests, just create a large single-line file filled with U's (55H's & nothing else) with a text editor (or pgm) and File-send.
Connect a frequency counter to TXD and record the freq. Should be Baud/2 at low speeds, dropping as limits occur.
If you also have a count (total) mode on your counter, check that too, for missing/dropped chars.
100k file should have 500,000 edges
I don't own a dedicated frequency counter but the Prop is already connected and can count at those speeds I believe. The CP2112 would be trivial to get running, considering all the ground work is done for the 2110. I won't have any extra time in the near future though for those CP2112 experiments. Adding libraries from the 2112 is pretty straight forward. I think it would be only a little effort to convert the app to a command line/console that could accept a filename, command number(1-3).
Tests suggested are pretty simple
a) For Prop download, start at 115200 and edge up until download breaks.
238,000 baud is consistent loading maxed out binaries. 250,000 is consistent for small files.
If you want this CP2112-Ek the pm an address and I will send it.
I attempted a test with the Parallax(Saleae) 24mhz logic analyzer. At a point, above baud 1843200 the frequency in the analyzer keeps showing 1mhz. In the image, the file name shows the baud that was set in the app sending the U's. I did not do any large files yet nor any counting.
CP2110 Baud rates supported: 300 bps to 1 Mbps
Sounds like worthwhile gains - and an advantage of the Granular baud settings.
The CP21xx series round to the nearest baud, so for that part it looks like anything above 1.8, rounds to 1,8
What size arrays were you sending ?
The freq values given are not picking up the extra stop bits, which you can see being added.
Looks similar to a CP2105 - (certainly not a lot worse), and I was wondering if the HID had speed caveats.
The CP2105 (with VCP driver) & care with buffer sizes (larger is always good
The 2110 plots look to have +1 @ 230k and +2 at 460, so ~one stop bit slower.
( I guess at 115k, there is no added stop bit?)
http://community.silabs.com/t5/8-bit-MCU/tiny-USB-HID-bootloader-for-F32x/m-p/29705/highlight/true#M14772
That is a USB-HID to On-Chip Flash loader, that would be relatively easy to flip to off-chip Serial EEPROM writing instead. (to load the Prop Serial memory directly, or to UART to the Prop loader)
Code is here http://gglabs.us/node/29
and for fun, I downloaded and compiled with an older SDCC. (3.1x)
That gave some warnings, on inline calls, (but did create a hex file) so I grabbed SDCC 3.4.0, and the inline name warnings went away.
The ideal modern target for this ~1.5k footprint USB-HID loader, would be the C8051F38C (16KF & cheapest @ $1.49/1+ )
The issue with eeprom or flash loading is the speed of loading for development purposes. I want to send to Ram and check out the result asap. I am curious to know where you find that route as advantageous versus some variant of Proploader, are you looking at that as more of an in field firmware update method?
I added the gboot info mainly for others who may search for HID later.
The interest in USB(HID)->EEPROM is mainly because that is a less supported pathway - as you say, the present default is the Proploader 3b Serial.
For devices like P2, serial is going to struggle more, as not only is the P2 memory larger, but the SPI Flash is a whole lot larger again, and is likely to hold font info etc
Nice looking buttons.
No ESD clamp visible on the USB/CP2110 ?
Curious what speeds did you get this working to ? - IIRC it was fine for P1 loading, but that has a lower ceiling, of something over 200k baud.
The WEB info I can find is vague on HID speeds. There seems general agreement of 64 bytes per 1ms frame, which indicates ~640kBaud equiv, but some posts I found said it needs 1ms each way. - which may limit it to ~320kBaud ?
The plots above do show extra stop bits expanding, as the Baud increases, if that's 50% at 1MBd, that's appx 500kBaud average sustained ?
Then I wondered about HIS at HS_USB - Attached is a USB HID report for 2 HID devices, the HS-USB MCU report has this
Device ID : HID\VID_0416&PID_8249\7&7255588&0&0000 Class : Mouse ... ----------------- Endpoint Descriptor ----------------- bLength : 0x07 (7 bytes) bDescriptorType : 0x05 (Endpoint Descriptor) bEndpointAddress : 0x81 (Direction=IN EndpointID=1) bmAttributes : 0x03 (TransferType=Interrupt) wMaxPacketSize : 0x0040 Bits 15..13 : 0x00 (reserved, must be zero) Bits 12..11 : 0x00 (0 additional transactions per microframe -> allows 1..1024 bytes per packet) Bits 10..0 : 0x40 (64 bytes per packet) bInterval : 0x14 (20 ms)Which has extra stuff not in the LS-USB or FS-USB ?
Suggests first 64 bytes per microframe, so that's ~ 5.12MBd, and then I see 1024 bytes per packet, might be possible via additional transactions per microframe 4 *64/microframe hits ~20MBd
Do you have any HID link speed-test code that can talk to the HS-USB HID part in this report, to test max data rates ?
I've not tried HID speed tests, but it looks like that USB into above, has enough to connect and repeat-send (or RX?) 64 bytes to the endpoint above ?
Looks like you can also send a request for Device Descriptor, (or Interface Descriptor) which should work on any mouse. (because my HS-USB board looks like a mouse)
If you alternated such requests, with some N numbers of packets to what looks like a valid endpoint, you could check if the device still was following.
Maybe you are thinking of the extra stop bits that appear at the highest baud rates, where the MCU cannot quite keep up. (visible in the plots you gave above)
The baud (bit level timing) is correct (eg 1MBd) but the average byte rate is closer to 50kB/s than an ideal/theory 100kB/s