posting data on wifi server example

[fixstuff]

Hi again,

I ran the ServerExample sketch and it ran fine.  I can connect over my network to that web page on port 8080 no problem.  I would like to have the page display variable data.  I don't see a way to print data, like the ethernet library sample for a server.  Is there an equivalent to do this, or am I looking at the wrong library.

Thanks

[digistump]

You can build a string and then send it with wifi.serverResponse() - print style interface would be a great addition and I'll add it to the list for the next revision.

[dbell]

I put together a really simple web page pin status and pin state setting server.
There is a (what I consider) a bug, in that I cannot figure out how to read the current state of an output pin, so the server is kind of inelegant as it has to keep a state table for outputs, but it does work.

I should be able to attach it, it looks like.
After compiling and uploading, hit Ctl-Shift-M to open a Monitor window to see the serial debug stream.
Put anything, at least a space, into the top bar of the Monitor and click Send to start the server.
You can delete all that stuff later, and it will start immediately.

Connect to your DigiX at its network address xxx.xxx.xxx.xxx:8080
Let me know what you think...

Dave

[digistump]

Dave

This is very cool! Thanks for sharing it!

Have you tried the trick of declaring them inputs before declaring them outputs? http://stackoverflow.com/questions/15100517/can-not-get-current-output-pin-state-on-arduino-due

[dbell]

I tried it, but it didn't make any difference.
Have tried to read the raw port, but don't know the port mnemonic  (PORTA, etc.), or how it maps to the numbered pins.

[digistump]

port and pin to Arduino pin mappings can be found in digistump\sam\variants\digix\pins_arduino.h

[dbell]

Umm, yeah...
Best I can make out is something like LED_PIN = LED_PIN_13 = (13u)

What I was hoping for would be something that would let me do an MCU port read.
The same article that suggested setting pins as INPUT first also referred to another thread.
That one suggested bitRead(PORTD, 13), or whatever was the correct port and pin mapping.
Of course, bitRead(x, y) doesn't DO that - it returns the 'y'th bit of expression 'x'!

Dave

[digistump]

the file is actually variant.cpp in the same folder:

from that file - a bunch of lines like this:

{ PIOB, PIO_PB0,          ID_PIOB, PIO_OUTPUT_0, PIO_DEFAULT, PIN_ATTR_DIGITAL,                  NO_ADC, NO_ADC, NOT_ON_PWM,  NOT_ON_TIMER }, //90

Arduino Pin 90 is Hardware Pin PB0 meaning PORTB, 0

bitRead(PORTB,0) should tell you its current state

[dbell]

Ah - much better!  So pin 13 = PORTB, 27
Kind of ugly mapping, as it will take two lookup tables for every pin, but it has the information.

But bitRead() is an Arduino bit manipulation function, not an I/O call.

[digistump]

It is a bit manipulation function, and it works because PORTB is a byte with each pin's state as a bit, located within the byte based on pin number

[dbell]

OK, I can see that.
Where is PORTB defined? (I've searched) Or what's it's value as an equate?
And it must be much bigger than a byte, as pin 13 is defined as PB27!

[digistump]

It is defined by the compiler/low level libraries for the MCU

It is a byte - DigiX is a 32 bit system and all ports are 0-31 or less

[dbell]

Well, the compiler rejects PORTB as undeclared.
If it'd declared in some .h file, I couldn't find it to #include

[MichaelMeissner]

Well, the compiler rejects PORTB as undeclared.
If it'd declared in some .h file, I couldn't find it to #include

I would imagine since the DigiX (and the Due) are arm based processors instead of AVR, they don't have a PORTB register, since the underlying hardware is different.  If you stick to the digitalRead, digitalWrite, analogRead, analogWrite, pinMode layer, it should be portable.  Otherwise, you will likely need to delve into the datasheets of the SAM ARM processor that is used to find the low level method that they use on the arm.

Note, this is speculation, since I haven't received my digiX yet, and so I haven't installed the appropriate environment yet.  I did check on the Arduino 1.5.4 that I have installed which supports the Due, and there is no PORTB (or PORTA/PORTC/PORTD) anywhere in the sam arm header files.

[dbell]

The problem I was running into, Michael, is that I cannot digitalRead() the current state of a pin defined as an OUTPUT.
Hoping not to have to keep a state table to record the last-written value.
Figured that if I dug into a deeper abstraction layer, I could do a raw read of a port/pin.

Dave