TG9541 / stm8ef

STM8 eForth - a user friendly Forth for simple µCs with docs
https://github.com/TG9541/stm8ef/wiki
Other
311 stars 66 forks source link

Errors with "codeload.py" preventing upload of source files #249

Closed paulcrawford closed 5 years ago

paulcrawford commented 5 years ago

I am using an Odroid C2 with Ubuntu 16.04 to upload source code from W1209-0.2.1 to a W1209 board with codeload.py. The first error I found with "make load" was:

if [ ! -d "out" ]; then \ curl -# -L -O https://github.com/TG9541/stm8ef/releases/download/2.2.20/stm8ef-bin.zip; \ unzip -q -o stm8ef-bin.zip -x out/; \ unzip -q -o stm8ef-bin.zip out/W1209-FD/; \ rm stm8ef-bin.zip; \ fi tools/codeload.py serial main.fs Uploading main.fs TX: \ W1209 basic data logging thermostat TX: \ © 2017 TG9541, refer to https://github.com/TG9541/W1209/blob/master/LICENSE TX: \ Note: not yet tested with real eggs :-) TX: TX: NVM TX:

require MARKER: skipped

TX: TX: RAM TX: TX: : TARGET NVM ; TX: TX: $4000 CONSTANT EE.SET \ EEPROM cell "control set-point" TX: $4002 CONSTANT EE.HYS \ EEPROM cell "control hysteresis" TX: $4004 CONSTANT EE.DEL \ EEPROM cell "control delay" TX: $4006 CONSTANT EE.COR \ EEPROM cell "offset correction" TX: $4008 CONSTANT EE.LOG \ EEPROM cell "logger interval" TX: TX: $8000 CONSTANT DEFAULT \ Default value indicator (-32768) TX: TX: TARGET TX: TX: : init ( -- ) \ chained init - starting point TX: 6 ADC! \ W1209: use ADC channel 6 TX: ; TX: TX: : .0 ( n -- ) TX: \ print fixed point number (n w/ factor 10x) TX: DUP DEFAULT = IF TX: DROP ." DEF." \ default display, e.g. sensor error TX: ELSE TX: \ formatted output for 3 digit 10x fixed point numbers TX: DUP -99 < OVER 999 SWAP < OR IF TX: \ number (and sign) too big for 3 7S-LED digits TX: 5 + 10 / . \ +0.5 before "floored division" TX: ELSE TX: \ -9.9 <= val <= 99.9 TX: SPACE DUP >R ABS <# # 46 HOLD #S R> SIGN #> TYPE error SPACE DUP >R ABS <# # 46 HOLD S R> SIGN #> TYPE S?

Makefile:18: recipe for target 'load' failed

I commented out :.0 ...; in main.fs and tried again. This time the error was:

if [ ! -d "out" ]; then \ curl -# -L -O https://github.com/TG9541/stm8ef/releases/download/2.2.20/stm8ef-bin.zip; \ unzip -q -o stm8ef-bin.zip -x out/; \ unzip -q -o stm8ef-bin.zip out/W1209-FD/; \ rm stm8ef-bin.zip; \ fi tools/codeload.py serial main.fs Uploading main.fs TX: \ W1209 basic data logging thermostat TX: \ © 2017 TG9541, refer to https://github.com/TG9541/W1209/blob/master/LICENSE TX: \ Note: not yet tested with real eggs :-) TX: TX: NVM TX:

require MARKER: skipped

TX: TX: RAM TX: TX: : TARGET NVM ; TX: TX: $4000 CONSTANT EE.SET \ EEPROM cell "control set-point" TX: $4002 CONSTANT EE.HYS \ EEPROM cell "control hysteresis" TX: $4004 CONSTANT EE.DEL \ EEPROM cell "control delay" TX: $4006 CONSTANT EE.COR \ EEPROM cell "offset correction" TX: $4008 CONSTANT EE.LOG \ EEPROM cell "logger interval" TX: TX: $8000 CONSTANT DEFAULT \ Default value indicator (-32768) TX: TX: TARGET TX: TX: : init ( -- ) \ chained init - starting point TX: 6 ADC! \ W1209: use ADC channel 6 TX: ; TX: TX: \ : .0 ( n -- ) TX: \ \ print fixed point number (n w/ factor 10x) TX: \ DUP DEFAULT = IF TX: \ DROP ." DEF." \ default display, e.g. sensor error TX: \ ELSE TX: \ \ formatted output for 3 digit 10x fixed point numbers TX: \ DUP -99 < OVER 999 SWAP < OR IF TX: \ \ number (and sign) too big for 3 7S-LED digits TX: \ 5 + 10 / . \ +0.5 before "floored division" TX: \ ELSE TX: \ \ -9.9 <= val <= 99.9 TX: \ SPACE DUP >R ABS <# # 46 HOLD #S R> SIGN #> TYPE TX: \ THEN TX: \ THEN TX: \ ; TX: Uploading /home/daco/src/W1209-0.2.1/measure.fs TX: \ W1209 temperature measurement with filter and noise suppression TX: \ © 2017 TG9541, refer to https://github.com/TG9541/W1209/blob/master/LICENSE TX: TX: \ Note: W1209 thermostats may require adjustment, TX: \ especially when used outside the range of -5C to +20C TX: \ Refer to https://github.com/TG9541/W1209/wiki/W1209-Sensor TX: Uploading /home/daco/src/W1209-0.2.1/lib/STARTTEMP TX: \ Scaffolding for temporary RAM usage during compilation TX: \ refer to github.com/TG9541/W1209/blob/master/LICENSE.md TX: TX: RAM error RAM Error file /home/daco/src/W1209-0.2.1/measure.fs line 8: could not upload file

include STARTTEMP

Error file main.fs line 43: could not upload file

include measure.fs

Makefile:18: recipe for target 'load' failed

Perhaps the second error is due to running the python code on an ARMv8 Cortex-A53 64bit Amlogic S905 processor rather than X86-64.

Can you please advise on what I need to do to make this work?

Thanks,

Paul Crawford

TG9541 commented 5 years ago

Hello Paul,

I think that in your setup codeload.py works as expected but there might be some problem with the serial interface.

In the first upload attempt there is a clear sign of a serial transmission problem:

TX: SPACE DUP >R ABS <# # 46 HOLD #S R> SIGN #> TYPE
error SPACE DUP >R ABS <# # 46 HOLD S R> SIGN #> TYPE S?

S instead of #S, the # is missing.

In the second case I don't see what has happened - maybe the was dropped and there was a timeout? In any case the interpreter didn't throw a ? at you.

I have no personal experience with Odroid - can it run Raspberry Pi binaries ? Maybe with the help of QEMU? In that case you might want to test your serial interface with e4thcom first. In fact, any terminal program will work, e.g. Picocom for which there is a howto in the tools page.

I'd like to recommend a test of your tool chain with a plain STM8 board (you can also flash a MINDEV binary on your W1209 and connect PD5-TxD/PD6-RxD to your serial interface.

If all other things fail you use the binary created by Travis-CI.

Kind regards, Thomas

paulcrawford commented 5 years ago

Hello Thomas,

Thank you so much for your quick response and even more for all of the work you have done on eForth and STM µCs. It is truly astounding.

I started using the Odroid C2 almost three years ago as an alternative to the Raspberry Pi that I was using, which turned out to be too slow for what I needed. As far as I know it does run RPi binaries, at least everything I have used or needed. I did try to run e4thcom (the Raspbian variant) but it did not work, I suspect because of the aarch64 architecture that the C2 uses.

I ordered a W1209 from China making sure that C5 was soldered in place in the web site photo. When I got it though, it could not be programmed and I determined that the µC was not an STM8S003F3. So I ordered 10 STM8S003F3 chips and then desoldered the substitute chip and replaced it with the STM8S003F3. Then I was able to program the W1209. I found the same issues that @BigVulcanDeal found though: the temperatures were wrong and the log feature ran continuously rather than for 144 values. I really don't need the the log feature as I am going to send the temperature value serially to an ATMega328P but obviously I need correct temperatures to control a Peltier 12V cooler. The code I flashed to the W1209 was "W1209-FD-forth.ihx" from 17 Dec 2017. I am running this from a MacBook Pro with CoolTerm as my serial terminal. From it I can access eForth on the W1209: e.g. "2 2 * . 4 ok", so it seems that everything is working except the temperature value is wrong.

Since I have the ST-LINK (V2) programmer, and it works fine, I would really like to know how to create a compiled Intel hex file, similar to "W1209-FD-forth.ihx" from 17 Dec 2017, but with changes to the .fs source code files to get measure.fs working with 5KR resistor and also output the measured temperature on the serial port. I do not need to have access to eForth interactively or to install the source files using codeload.py. I know that it is possible to create the required .ihx file, as that is what I flashed, but I do not know how to go about it.

Is it simload.sh that does the creation? I could not find much detail or an example of running this script. Is there anything like that available?

Thanks and best regards,

Paul

TG9541 commented 5 years ago

Hello Paul,

thanks for the praise for this STM8 eForth - the biggest part goes to people who contributed ideas, know-how and code, and I happily accept it in the name of this small community :-)

I think that your specific use case can be easiest solved in the following way:

I think that we should continue this solution branch in a GitHub issue in the W1209 project repository and continue here with W1209/Odroid related trouble-shooting as needed.

Kind regards, Thomas

paulcrawford commented 5 years ago

Hello Thomas,

I have started a new issue at TG9541/W1209 to initiate the required source code changes for my application.

I did successfully get the cli for Travis CI to work on my headless Odroid c2 via ssh but I could not get stm8flash to make so I will use my Mac which does have stm8flash installed and tested successfully. The problem with the C2 and stm8flash was related to libusb-1.0. Perhaps we could look at that issue although it is not directly related at all to the W1209 or stm8ef.

Thanks,

Paul

BigVulcanDeal commented 5 years ago

Thanks for the ringside seat guys. I found it relatively easy to adjust the Forth program to make the device work as an Edge Device for my application. Basically I had to:

Overall, it was relatively easy, but I will confess that there are parts of the program that used some interesting indirection mechanisms that I never quite deciphered.

I never bothered making a hex image .. just uploaded the altered Forth script and committed it to nonvolatile memory, since there were only a handful of systems that used this W1209 setup for temperature control.

On Fri, Jan 25, 2019, 1:20 PM paulcrawford <notifications@github.com wrote:

Hello Thomas,

I have started a new issue at TG9541/W1209 to initiate the required source code changes for my application.

I did successfully get the cli for Travis CI to work on my headless Odroid c2 via ssh but I could not get stm8flash to make so I will use my Mac which does have stm8flash installed and tested successfully. The problem with the C2 and stm8flash was related to libusb-1.0. Perhaps we could look at that issue although it is not directly related at all to the W1209 or stm8ef.

Thanks,

Paul

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TG9541/stm8ef/issues/249#issuecomment-457669485, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_Uzgydj2TSIKyU1cXMdOAc9ZpzfBZmks5vG0rogaJpZM4aO_7Z .

TG9541 commented 5 years ago

@BigVulcanDeal thanks joining the discussion, and for pointing out that there is a flaw in the menu implementation that will have a bad impact on applications that use the key GPIOs to send data frequently. I mentioned this issue here https://github.com/TG9541/W1209/issues/22 . I guess that a "ringside seat" there won't be without a certain entertainment value :-)