This ARMWeb *is* responding to pings but *not* to frames sent to port 80, nor to
port 21. This is the 3rd time it has ended up in this condition. The last two
times, cycling power corrected the problem.
Could this be caused by my program, or does it run deeper than that? If it was
my program, wouldn't I still be able to load armweb.htm?
Note that I have not set Security-AutoRun to on, I have coded a script to load
code.htm?Run if it returns "BASIC ERROR" in the response -- basically the same
effect, implemented off the board.
I'm about to go back to it to cycle power again.
Questions: While it is working properly is there a way to reset it via
software? (Thinking that if I reset it monthly it won't ever end up in this
condition.) Any idea what the cause might be? Is there anything I can do to
trouble-shoot it?
TIA,
MM
CGIIN inside BASIC in HTML
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
It would help us to see the BASIC program embedded in the web page.
BASIC ERROR is reported when the compiler sees an error in the embedded BASIC.
These errors also include the BASIC there being larger than a frame (1460
bytes).
As that BASIC is quite static, being loaded in via ftp, we kind of expect it not
to have errors. And maybe we should recover better. Once we see your example
we'll be able to tell better.
As for reseting in BASIC, we have tried before in C and don't have one that is
entirely satisfactory. We can restart the program, but it won't return the
peripherals to the "reset" state. That requires a reset, which if worse comes
to worse you could add a pulldown from an IO to do it.
BASIC ERROR is reported when the compiler sees an error in the embedded BASIC.
These errors also include the BASIC there being larger than a frame (1460
bytes).
As that BASIC is quite static, being loaded in via ftp, we kind of expect it not
to have errors. And maybe we should recover better. Once we see your example
we'll be able to tell better.
As for reseting in BASIC, we have tried before in C and don't have one that is
entirely satisfactory. We can restart the program, but it won't return the
peripherals to the "reset" state. That requires a reset, which if worse comes
to worse you could add a pulldown from an IO to do it.
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
There are two .htm files with embedded basic:
cgimcd.htm
----------------
----------------
and...
rawstatus.htm
----------------
----------------
These "web pages" write and read variables declared and used by a larger program
-- that I will post if need be -- but first...
Does declaring that 64 byte string in embedded basic, leak 64 bytes each time
it's called? I know that all variables declared within the program are
allocated when it starts, but there's no way it could know about things like
this. Is it smart enough to allocate it once the first time the page is loaded?
Its purpose is to clear CGIIN [obviously], this app predates ARMWeb support for
sending HTTP headers along with responses, so a unique parameter is appended to
each request to prevent caching.
Why I didn't declare some throw-away space for this in the main program I
couldn't say... but it surely does look suspect at this point!
-MM
cgimcd.htm
----------------
----------------
and...
rawstatus.htm
----------------
----------------
These "web pages" write and read variables declared and used by a larger program
-- that I will post if need be -- but first...
Does declaring that 64 byte string in embedded basic, leak 64 bytes each time
it's called? I know that all variables declared within the program are
allocated when it starts, but there's no way it could know about things like
this. Is it smart enough to allocate it once the first time the page is loaded?
Its purpose is to clear CGIIN [obviously], this app predates ARMWeb support for
sending HTTP headers along with responses, so a unique parameter is appended to
each request to prevent caching.
Why I didn't declare some throw-away space for this in the main program I
couldn't say... but it surely does look suspect at this point!
-MM
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
>
Dim Buf(64) As String
> Buf = CGIIN
> PRINT gQueryOutput,LastCmdStatus
> LastCmdStatus = ""
> ?>
> ----------------
> Does declaring that 64 byte string in embedded basic, leak 64 bytes each time
it's called? I know that all variables declared within the program are
allocated when it starts, but there's no way it could know about things like
this. Is it smart enough to allocate it once the first time the page is loaded?
Wow, you never know how someone will try to use your code. I don't say this as
a criticism, its just we never expected to see CGIIN used inside a web page. As
CGIIN reads the last portion of the web page request, I'm surprised it would
work at all for you, not even sure what it should do. At least from my
perspective CGIIN and web BASIC are 2 ways for the client to communicate to the
server BASIC program. As the web BASIC can directly change pre-declared
variables in the main BASIC. And CGIIN can be called from the main BASIC to see
what the web requests have been doing.
So I'd have to put this in the category of unsupported.
As for the BUF declaration, as BUF is never used, and can't be referenced from
the main BASIC is pretty much a NOP. In earlier versions there was a memory
leak, but not in allocated space, it was in the symbol table.
Actually if the declaration of BUF here continued past the life of the web BASIC
program, it would cause an error the next time that page was called as it would
be a duplicate declaration.
Dim Buf(64) As String
> Buf = CGIIN
> PRINT gQueryOutput,LastCmdStatus
> LastCmdStatus = ""
> ?>
> ----------------
> Does declaring that 64 byte string in embedded basic, leak 64 bytes each time
it's called? I know that all variables declared within the program are
allocated when it starts, but there's no way it could know about things like
this. Is it smart enough to allocate it once the first time the page is loaded?
Wow, you never know how someone will try to use your code. I don't say this as
a criticism, its just we never expected to see CGIIN used inside a web page. As
CGIIN reads the last portion of the web page request, I'm surprised it would
work at all for you, not even sure what it should do. At least from my
perspective CGIIN and web BASIC are 2 ways for the client to communicate to the
server BASIC program. As the web BASIC can directly change pre-declared
variables in the main BASIC. And CGIIN can be called from the main BASIC to see
what the web requests have been doing.
So I'd have to put this in the category of unsupported.
As for the BUF declaration, as BUF is never used, and can't be referenced from
the main BASIC is pretty much a NOP. In earlier versions there was a memory
leak, but not in allocated space, it was in the symbol table.
Actually if the declaration of BUF here continued past the life of the web BASIC
program, it would cause an error the next time that page was called as it would
be a duplicate declaration.
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
> Wow, you never know how someone will try to use your code. I don't say this
as a criticism, its just we never expected to see CGIIN used inside a web page.
It's a very common, perhaps ubiquitous construct in web server scripting
environments, nearly every ASP, PHP, CFM, etc. source file you'll ever see
accesses some aspect of the request. It never occurred to me that CGIIN might
not be available in Web Basic.
> As CGIIN reads the last portion of the web page request, I'm surprised it
would work at all for you,
Sure it's the right-most portion of the request URL, but the web server must
receive the whole request before it process it and return the status frame.
Then it serves the requested document (which includes processing server-side
script embedded in the file.) So I'm not sure I follow your logic.
> not even sure what it should do. At least from my perspective CGIIN and web
BASIC are 2 ways for the client to communicate to the server BASIC program. As
the web BASIC can directly change pre-declared variables in the main BASIC. And
CGIIN can be called from the main BASIC to see what the web requests have been
doing.
What it should do is return the query portion of the URL for that request only,
as it pertains to only that request. On ARMWeb it's possible for it to return
the query portions from more than one request, concatenated together (if other
requests were received since CGIIN was last read/reset.)
It's also possible for CGIIN to return a portion of an inbound request's query,
when called on interval inside the main program. The next call to CGIIN returns
the rest of it. (Perhaps because I'm using the timer interrut?)
This is exactly why I call it from Web Basic, at that point I know the entire
query is available, plus it gets cleared before the next request. This greatly
simplifies parsing. All the Web Basic code does is store it in a global for the
main program to process.
> So I'd have to put this in the category of unsupported.
You might want to check it out first, I can tell you it works as is.
In any case I seem to have resolved the problem, nearly all of my Dim statements
occured either at the beginning of the file or as the first lines of a function;
two did not, and they were being corrupted. Why it was stable for months and
months, then all of a sudden started crashing an hour or two after reset remains
a mystery.
I also upgraded to the latest firmware; it hasn't crashed since. An unrelated
problem cropped-up, but I'll put that in another post.
-MM
as a criticism, its just we never expected to see CGIIN used inside a web page.
It's a very common, perhaps ubiquitous construct in web server scripting
environments, nearly every ASP, PHP, CFM, etc. source file you'll ever see
accesses some aspect of the request. It never occurred to me that CGIIN might
not be available in Web Basic.
> As CGIIN reads the last portion of the web page request, I'm surprised it
would work at all for you,
Sure it's the right-most portion of the request URL, but the web server must
receive the whole request before it process it and return the status frame.
Then it serves the requested document (which includes processing server-side
script embedded in the file.) So I'm not sure I follow your logic.
> not even sure what it should do. At least from my perspective CGIIN and web
BASIC are 2 ways for the client to communicate to the server BASIC program. As
the web BASIC can directly change pre-declared variables in the main BASIC. And
CGIIN can be called from the main BASIC to see what the web requests have been
doing.
What it should do is return the query portion of the URL for that request only,
as it pertains to only that request. On ARMWeb it's possible for it to return
the query portions from more than one request, concatenated together (if other
requests were received since CGIIN was last read/reset.)
It's also possible for CGIIN to return a portion of an inbound request's query,
when called on interval inside the main program. The next call to CGIIN returns
the rest of it. (Perhaps because I'm using the timer interrut?)
This is exactly why I call it from Web Basic, at that point I know the entire
query is available, plus it gets cleared before the next request. This greatly
simplifies parsing. All the Web Basic code does is store it in a global for the
main program to process.
> So I'd have to put this in the category of unsupported.
You might want to check it out first, I can tell you it works as is.
In any case I seem to have resolved the problem, nearly all of my Dim statements
occured either at the beginning of the file or as the first lines of a function;
two did not, and they were being corrupted. Why it was stable for months and
months, then all of a sudden started crashing an hour or two after reset remains
a mystery.
I also upgraded to the latest firmware; it hasn't crashed since. An unrelated
problem cropped-up, but I'll put that in another post.
-MM
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
Hey I'm too old, but not too old to learn something new. BTW I'm the compiler
writer not the web side guy.
> It's a very common, perhaps ubiquitous construct in web server scripting
environments, nearly every ASP, PHP, CFM, etc. source file you'll ever see
accesses some aspect of the request. It never occurred to me that CGIIN might
not be available in Web Basic.
>
> Sure it's the right-most portion of the request URL, but the web server must
receive the whole request before it process it and return the status frame.
Then it serves the requested document (which includes processing server-side
script embedded in the file.) So I'm not sure I follow your logic.
>
> What it should do is return the query portion of the URL for that request
only, as it pertains to only that request. On ARMWeb it's possible for it to
return the query portions from more than one request, concatenated together (if
other requests were received since CGIIN was last read/reset.)
With the idea of multiple requests I can see the point of doing it there.
Though I'm still fuzzy on how we handle multiple requests.
> This is exactly why I call it from Web Basic, at that point I know the entire
query is available, plus it gets cleared before the next request. This greatly
simplifies parsing. All the Web Basic code does is store it in a global for the
main program to process.
>
> You might want to check it out first, I can tell you it works as is.
>
If it works, then I guess we can bless it. I'll discuss it a bit with Mike.
> > As for the BUF declaration, as BUF is never used, and can't be
But you won't be able to declare anything inside the web BASIC lines and expect
it to be available after the ?>
writer not the web side guy.
> It's a very common, perhaps ubiquitous construct in web server scripting
environments, nearly every ASP, PHP, CFM, etc. source file you'll ever see
accesses some aspect of the request. It never occurred to me that CGIIN might
not be available in Web Basic.
>
> Sure it's the right-most portion of the request URL, but the web server must
receive the whole request before it process it and return the status frame.
Then it serves the requested document (which includes processing server-side
script embedded in the file.) So I'm not sure I follow your logic.
>
> What it should do is return the query portion of the URL for that request
only, as it pertains to only that request. On ARMWeb it's possible for it to
return the query portions from more than one request, concatenated together (if
other requests were received since CGIIN was last read/reset.)
With the idea of multiple requests I can see the point of doing it there.
Though I'm still fuzzy on how we handle multiple requests.
> This is exactly why I call it from Web Basic, at that point I know the entire
query is available, plus it gets cleared before the next request. This greatly
simplifies parsing. All the Web Basic code does is store it in a global for the
main program to process.
>
> You might want to check it out first, I can tell you it works as is.
>
If it works, then I guess we can bless it. I'll discuss it a bit with Mike.
> > As for the BUF declaration, as BUF is never used, and can't be
But you won't be able to declare anything inside the web BASIC lines and expect
it to be available after the ?>
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
Hey I'm too old, but not too old to learn something new. BTW I'm the compiler
writer not the web side guy.
> It's a very common, perhaps ubiquitous construct in web server scripting
environments, nearly every ASP, PHP, CFM, etc. source file you'll ever see
accesses some aspect of the request. It never occurred to me that CGIIN might
not be available in Web Basic.
>
> Sure it's the right-most portion of the request URL, but the web server must
receive the whole request before it process it and return the status frame.
Then it serves the requested document (which includes processing server-side
script embedded in the file.) So I'm not sure I follow your logic.
>
> What it should do is return the query portion of the URL for that request
only, as it pertains to only that request. On ARMWeb it's possible for it to
return the query portions from more than one request, concatenated together (if
other requests were received since CGIIN was last read/reset.)
With the idea of multiple requests I can see the point of doing it there.
Though I'm still fuzzy on how we handle multiple requests.
> This is exactly why I call it from Web Basic, at that point I know the entire
query is available, plus it gets cleared before the next request. This greatly
simplifies parsing. All the Web Basic code does is store it in a global for the
main program to process.
>
> You might want to check it out first, I can tell you it works as is.
>
If it works, then I guess we can bless it. I'll discuss it a bit with Mike.
> > As for the BUF declaration, as BUF is never used, and can't be
But you won't be able to declare anything inside the web BASIC lines and expect
it to be available after the ?>
writer not the web side guy.
> It's a very common, perhaps ubiquitous construct in web server scripting
environments, nearly every ASP, PHP, CFM, etc. source file you'll ever see
accesses some aspect of the request. It never occurred to me that CGIIN might
not be available in Web Basic.
>
> Sure it's the right-most portion of the request URL, but the web server must
receive the whole request before it process it and return the status frame.
Then it serves the requested document (which includes processing server-side
script embedded in the file.) So I'm not sure I follow your logic.
>
> What it should do is return the query portion of the URL for that request
only, as it pertains to only that request. On ARMWeb it's possible for it to
return the query portions from more than one request, concatenated together (if
other requests were received since CGIIN was last read/reset.)
With the idea of multiple requests I can see the point of doing it there.
Though I'm still fuzzy on how we handle multiple requests.
> This is exactly why I call it from Web Basic, at that point I know the entire
query is available, plus it gets cleared before the next request. This greatly
simplifies parsing. All the Web Basic code does is store it in a global for the
main program to process.
>
> You might want to check it out first, I can tell you it works as is.
>
If it works, then I guess we can bless it. I'll discuss it a bit with Mike.
> > As for the BUF declaration, as BUF is never used, and can't be
But you won't be able to declare anything inside the web BASIC lines and expect
it to be available after the ?>
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
Hmm, well the ARMWeb correctly sends headers specified inline before content,
but the cache control header was ineffective because it was an advent of HTTP
1.1, d'oh! So it's back to appending something unique to the CGI query. (I
declared a bitbucket variable in the main program this time, rather than in
rawstatus.htm, so it doesn't have to reallocate that buffer every request.)
But one problem remains: I'm trying to FTP upload an 11 kb .htm file to the
ARMWeb but it gets corrupted on the way up. If I FTP download it to another
file name and compare that to the original, they are very significantly
different. They aren't even the same size.
I just uploaded 3 copies of the same file, size 10,476 bytes. The 3 destination
files on the ARMWeb are 3 different sizes (16,316, 14,839 and 17,776.)
I have tried erasing the board via reset several times, the FTP folder is empty
after reset, and the main program is gone so it seems to be clearing. I also
have deleted and re-uploaded the file several times. An uncorrupted copy of
this file once resided on this ARMWeb -- it contains no web basic, it does
AJAX-style calls to two other files.
What can I do to fix this?
-MM
but the cache control header was ineffective because it was an advent of HTTP
1.1, d'oh! So it's back to appending something unique to the CGI query. (I
declared a bitbucket variable in the main program this time, rather than in
rawstatus.htm, so it doesn't have to reallocate that buffer every request.)
But one problem remains: I'm trying to FTP upload an 11 kb .htm file to the
ARMWeb but it gets corrupted on the way up. If I FTP download it to another
file name and compare that to the original, they are very significantly
different. They aren't even the same size.
I just uploaded 3 copies of the same file, size 10,476 bytes. The 3 destination
files on the ARMWeb are 3 different sizes (16,316, 14,839 and 17,776.)
I have tried erasing the board via reset several times, the FTP folder is empty
after reset, and the main program is gone so it seems to be clearing. I also
have deleted and re-uploaded the file several times. An uncorrupted copy of
this file once resided on this ARMWeb -- it contains no web basic, it does
AJAX-style calls to two other files.
What can I do to fix this?
-MM
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
> But one problem remains: I'm trying to FTP upload an 11 kb .htm file to the
ARMWeb but it gets corrupted on the way up. If I FTP download it to another
file name and compare that to the original, they are very significantly
different. They aren't even the same size.
>
We did some testing here, and confirm this on Win 7, seems like Win 7 is
"impatient" with our ftp for files larger than 4K.
It all works fine on XP on files as large as 70K
Writes to Flash are slow on the ARM, so we're looking into work-arounds.
ARMWeb but it gets corrupted on the way up. If I FTP download it to another
file name and compare that to the original, they are very significantly
different. They aren't even the same size.
>
We did some testing here, and confirm this on Win 7, seems like Win 7 is
"impatient" with our ftp for files larger than 4K.
It all works fine on XP on files as large as 70K
Writes to Flash are slow on the ARM, so we're looking into work-arounds.
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: CGIIN inside BASIC in HTML
> We did some testing here, and confirm this on Win 7, seems like Win 7 is
"impatient" with our ftp for files larger than 4K.
>
We have an interim fix that works with Win7. With it I put a 70K, a 110K
picture and some other files out on an ARMweb all without problem.
You will get some "ignoring xxxx" messages during ftp of these large files, and
you can ignore that diagnostic message.
This version of firmware also correctly enables all IOs on the ARMweb as "fast"
or FIOx control.
So update your firmware with web0748.hex. This is also the firmware for DINkit
- Ethernet.
"impatient" with our ftp for files larger than 4K.
>
We have an interim fix that works with Win7. With it I put a 70K, a 110K
picture and some other files out on an ARMweb all without problem.
You will get some "ignoring xxxx" messages during ftp of these large files, and
you can ignore that diagnostic message.
This version of firmware also correctly enables all IOs on the ARMweb as "fast"
or FIOx control.
So update your firmware with web0748.hex. This is also the firmware for DINkit
- Ethernet.