Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - sparkcatcher

Pages: 1 [2] 3

for the authentication part, you can do a login using php by one of two methods (I believe).

1.  from php request the login.cgi page from the sbc65.  I believe the actual name of the page is login.cgi, but I'm not positive.  This would be in the documentation.  Then, In response, you send back a "get" request something like:

login.cgi?u=admin p=pw

again, I believe that the page is called login.cgi.  I don't think the "u" parameter name or the "p" parameter name is correct, but the actual parameter names would be found in the documention or you could examine the url that is sent by a brower when you manually fill in the login form and click the submit button.  When you find the parameter names, just construct the url as above with php and send.  If the user name and password are correct, you should then be authenticated.

2.  It's possible that you may not have to first request the login page and then send another login get request.  You might only have to send the login "get"url with the proper paramters and values to obtain authentication.  ie.:
login.cgi?u=username p=password

From my understanding of the stack code, this should work.  Please post to tell whether you are able to authenicate.


>>If we suppose to use the C code to communicate with database where can we put this code (in the cgi files)?

You'd have to get into the very nice web server application that modtronix provides and modify it such that it made a call to your mysql server as required.  you'd have to send the data and ask the server to run a query or report to put the data into the data base.  You'd have to write C code, you could not do this just by modifiying the web page.  Also, if your server accesses the internet, you'd have to get an authorized MAC address, I believe.  Needless to say, this could get tedious, but it could be done  :evil: !

>>Using PHP scripts is a good idea but how to communicate using http with  the  sbc65 and receive data from it?

For a  php solution, on a seperate server, most likely your current database server, you could write a php script that acts like an http client (ie, acts like a browser)  There probably are scripts existing that would give you a framework.  This php program would send an http request for a page to the sbc65, and the sbc65 would send the page back.  Instead of displaying the page, your php script would decode the page by reading the text and decoding the values that are sent within the page.  If the pages delivered by the sbc65 are never displayed, you could write them in a format that was more easily decoded by your php script.  You would put the values into php variables, then you'd use php to open your database, then you'd add your new records.   This approach lets you accomplish your project without having to modify the sbc65 webserver application software. 

Note to sk_uk:  thanks for posting the link to the fox/axis product.  I'm looking for a micro server just like that.  I would hope it could come down in price, but it doesn't look like a mega-volume product.  That Axis SOC is a great solution  8-) single chip (module actually) linux server.


a php interpreter requires megabytes of memory for storage and operation so it would be very difficult   :wink: to fit one in the sbc65ec. You'd most likely have to write your database connector in C.   Or you might try to develop/use php scripts that run on a server and communicate via http to the  sbc65 to recieve the data, and then put the received information into the data base from the server scripts.


ok thanks.  a resistor is possible, however, what is the benefit of using this signal?  does it act like an interrupt to notify the stack that a packet has arrived instead of requiring polling resulting possibly in faster packet detection?


thanks for the summary.  nice to know that an upgrade chip exists.  looks like they are same price as 18F452.  wonder if modtronix would ever consider a new rev of sbc44/45 using that chip.  Looks like the chip is smaller and so would fit into the existing form factor nicely.

Would be interesting to see the adaptor you developed!

could you provide a short description of what changes you had to implement to make this work?  The new beta code (3.04) for the sbc44 and 45 is large and probably getting larger.  Would be nice to know that a technique exists for making bigger code base work in these nice boards.


I have the beta code version 3.04.  I'm working with an sbc45 R2.  The code works.  I'm playing with the projdef file.  Within the projdefs file, I commented out the define NIC_DISABLE_IOCHRDY.  After I did this I rebuilt and reprogrammed, and while the serial port config program worked, I could not communicate with the board using the http server.   When I went back and un-commented the NIC_DISABLE_IOCHRDY define, rebuilt, reprogrammed, and the HTTP server again worked.  I checked my board to confirm that the jumper JP5 was indeed connected.

I also noticed that the file /net/mac.h  has a duplicate define for NIC_DISABLE_IOCHRDY and this is also an active define by default for this code set.    I'm thinking that the writers of the software really wanted to make sure  :-o that NIC_DISABLE_IOCHRDY define should be enabled so the stack shouldn't use the IOCHRDY pin coming from the realtek chip.

What is the downside of not using the IOCHRDY pin?  Will this slow down packet processing or cause problems within the stack?  Why is it causing problems when I comment out the NIC_DISABLE_IOCHRDY define?

Ethernet Boards (8-bit) / Re: == New SBC44EC and SBC45EC Beta Code ==
« on: June 15, 2007, 03:19:42 PM »
Regarding the error message generated by MPLAB/C18 posted by ecasvelasco

>>I try to compile the project with ide 7.51 y c18 3.02 and the linker send:
Error - section '.code_stacktsk.o' can not fit the section. Section '.code_stacktsk.o' length=0x00000268
Errors    : 1

I believe this error is due to the compiler not performing the "procedural abstraction optimization."  Without the optimizations by the compiler, the project is too big for the microcontroller memory (either program memory or flash)   I compiled/built the beta code initially with the student/free version of the c18 compiler and the project compiled and ran.  When I recently tried the build  again, same setup, same file set, I received the same error message reported by ecasvelasco.  By this time, the optimizations had expired within this student/free compiler.

I uninstalled the c18 compiler, which was version 3.04, and  then installed the latest c18 which is version 3.12 (demo) and ran the project again.  It worked.  Again I am building for the SBC45.  (I also uninstalled the old mplab 7.4 and installed 7.6a)

In looking at the memory usage guage when the build is complete, it looks like this beta code uses almost all of the program memory (15419 bytes out of 16384 bytes) and 70% of the data memory of 1223 out of 1536.

Since my compiler will go de-optimal in another 60 days, I'm wondering if you could comment on what may have caused this.  Will I need the optimization compiler to build this project?  Is there a data structure that possibly uses alot of memory (I think the optimization has to do with overlays) that I might be able to comment out.  Is there a particular module that might require the optimization that I could remove?


Ok, well that's probably the issue. 

I bought two identical boards, SBC45 ECR2.  One had this problem (as you describe, seemingly random change in values on port B6) and the other worked fine, both when used with the web server interface - both had the same web interface on them.  I didn't update or change any firmware prior to this happening.   I thought the B6 problem was a port defect or maybe a noise problem cause mayby by faulty termination, but when I hooked the port up to a relay I got a steady click, click, click, and that caused me to scope the port to find the steady oscillation.

I did update the firmware on the board that worked, to the newest tcp stack,  and I'll be updating the firmware on the one with the oscillating B6.  Hopefully it was just programmed with the SBC65 or 68 code (by who, I don't know :?) and hopefully it will work fine when reprogrammed.

thanks for your response,

ok, I hooked an oscilloscope up to signal B6.

Interestingly I get a constant frequency on this pin (B6) of 40.81Hz and a period of 24.5 msecs. :?

It's weird.  My other board doesn't do this, and I've compared the two boards physically.

Now, since I bought the board from a US distributor of Modtronix, I wonder if maybe someone programmed the board to make B6 some type of clock output and then returned the board to the distributor with their modified code still in it?

I think using MPLAB I should be able to do a trace, but if it's a mod, I won't have the C source.   Well if I can't trace I'm probably better off just reloading the original source from modtronix to see if that fixes the problem.


Ethernet Boards (8-bit) / Re: New SBC44EC Beta Code
« on: November 02, 2006, 07:34:22 AM »
ok. I changed the board define to the one for sbc45 and  I compiled the beta code and programmed it into the sbc45 board.  It worked.   8-)  I uploaded the default image using windows built in ftp, and that worked.  Of course the default page is for the SBC44 board, put it looks like the basic code works on SBC45.  The netbios name feature works.  This is a nice addition.  I'll have to look at trying to build my own web page that works with the sbc45 ports.


Ethernet Boards (8-bit) / SBC45EC Using HTTP Server Port Value Question
« on: October 30, 2006, 10:18:36 AM »
I have a new SBC45EC board that I'm testing out.  I'm able to to access the Modtronix web server and set the ports as either input or output and also view the port settings through the web server.  Everything seems to be working as advertised, except one quirky thing that may need further explanation.

I've set all of the Port B port settings to "output" by checking the boxes on the appropriate web server page, and then clicking submit (numerous times).

Next, I go to the port values page and set all of the port B output pins to "1", by clicking the appropriate buttons.  And then click "update." 

Then without making any further changes, I click the "update" button again, actually many more times, as an example, ten times, once a second.

I notice that the output pins all retain their "1" value, as expected, with the exception of B6.  B6 toggles between 0 and 1 seemingly randomly as I click update. 

I don't have any connection on the ICD port.  I noticed in the modtronix docs that both B7 and B6 are also used for ICD.

I'm wondering if anyone can tell me why this happens, if it is normal, and what to do to ensure that the output values remain as selected (ie, a 1 remains a 1).  I've read in some previous posts on this forum regarding other boards about the possible need for a pullup or pulldown resistor.  Is this a necessity on this pin?

thanks for any help.

Ethernet Boards (8-bit) / Re: New SBC44EC Beta Code
« on: October 27, 2006, 05:44:25 PM »

Will this new beta Web server also work on the sbc45?  Also, in a previous post regarding UDP problems within the UDP portion of the old stack you wrote (this was regarding the sbc65 product):

"The new V3.05Beta release of the Modtronix TCP/IP stack has just been released [this was september 06]. The whole TCP state machine has been redone, the UDP checksum error has been fixed, and heaps of other improvements have been made. You can download it on the SBC65EC product page:

If you only want to update the TCP/IP stack, download the source code and simply replace the "../src/net" folder of your current product with the "net" folder of the new code. The whole TCP/IP stack is contained in the net folder, and is 100% compatible with previous versions."

Question:  Can I do the above and have it work on the SBC45?   Hopefully yes!

Question:  Does the new beta web server software require the use of the new V3.05 Modtronix TCP/IP stack? 

Question:  How does your version of the the TCP/IP stack now differ from the standard Microchip code?

You may have answered these elsewhere, if so, just provide a link.

many thanks,

Programming / Re: Programming SBC45 with Microchip ICD2
« on: October 19, 2006, 10:57:22 AM »
Ok, thanks for your response.  I'll try it.

Also, this topic caused me to study AC ground loops.  It looks as though if the target board is powered through a standard DC plug-in transformer, (ie. sometimes also called a "wall wart") then it should be effectively isolated from earth ground.  The microchip advisory does not show a earth ground at the target location within their advisory which I would have thought would have been required for a non-isolated target power source.  So if using a "wall wart" to power the target, when you connect the target to the ICD2, which is connected via USB to earch ground,  the grounds connect and become common.  No chance for an AC ground loop. 

By disabling the ""Power target circuit from MPLAB ICD 2" option then the different power sources don't cause a loop current.  The signals can still get across because those are probably pulled up by resistors.  They must have a relay on the vdd line within the ICD2 unit.

As long as you connect everything together following your instructions, the grounds all connect up, and as long as the ICD2 is not supplying power to the target board then there should not be an issue with power voltage levels.  Knock on wood!

Thanks for your confirmation, I'll proceed as you have.

Programming / Re: Programming SBC45 with Microchip ICD2
« on: October 18, 2006, 08:56:09 AM »

Thanks for your response. 

Here's my issue:  The ICD2 advisory asks to put an optoisolated usb hub in between the computer and the ICD2 unit.  If that is the case, the the USB port or cable is not going to power the ICD2 unit.  If you look at page 2 of the advisory you'll see a diagram with the computer having an earth ground and sharing that ground with part of the optoisocated USB hub, and the target, (SBC45) and the ICD2 unit sharing a floating ground.  This is implying that the ICD2 is being powered by the target board, not by the USB cable.

Here's the advisory link:
(see page 2)

Upon reading further, I note that the ICD2 unit only requires Vdd of 5 Volts, so it would seem that the target board could provide the power and it looks like the ICD2 target cable (the telephone/pgm06 cable)  has both Vdd and ground lines, so it can get power from the target board.   It  looks like the regulator chip on the SBC45  board is kind of small and so I was wondering about the power draw.

Can you look further into the Microchip advisory and check your statement (ie The ICD 2 obtains it's power from the USB connection).  It would seem that with an opto isolated hub that this would not be the case, and if one did not use an opto-isolated hub then the AC ground problem would exist and then could potentially cause damage.

Thanks for your help.  I'm just starting out and don't want to fry the board, shock anyone, or wreck the ICD2 unit (well not on my first programming attempt anyway!)


Pages: 1 [2] 3