Here we can all chat about fixing the AT+ command structure and the associated responses.

User avatar
By ADent
#9875 Hi there!

I was looking for the AT-command to shut off echo. But found this thread instead :)
What source code are the base for this new AT+ command set version? New written from scratch?

From what I've been reading there is no way to get own MAC-adress either (in original firmware)?

Anyhow. Is there a link to the source-code/binaries you are working on? Is it usable?

Ok, I'am really sorry for not reading through the thread to find the answers to my question, but I'd really
apprechiate if someone answers.

Also, I'd love to help. Been working with embedded programming in C for 10 years now.

Best regards
Mikael
User avatar
By saper_2
#9977
ADent wrote:Hi there!

I was looking for the AT-command to shut off echo. But found this thread instead :)
What source code are the base for this new AT+ command set version? New written from scratch?

Practically: yes.
ADent wrote:From what I've been reading there is no way to get own MAC-adress either (in original firmware)?

Nope, but I don't remember if you can get S/N , if yes then you have ESP mac because last 3 octets of mac are serial number of ESP chip - or at least I see this connection.
ADent wrote:Anyhow. Is there a link to the source-code/binaries you are working on? Is it usable?
Yep, check igrr GitHub account: https://github.com/igrr/atproto
Uh, I gave you link to repo already :P
ADent wrote:Ok, I'am really sorry for not reading through the thread to find the answers to my question, but I'd really
apprechiate if someone answers.

I'm lazy bum myself :P so, you're welcome :)
ADent wrote:Also, I'd love to help. Been working with embedded programming in C for 10 years now.
Best regards
Mikael

Well, would be very nice if igrr pushed to github what he have done so far, even if it's not complete/broken/missing sth then sb could pick up from that and try to continue develop atproto.

Now I'm more interested in "esp8266-frankenstein" (google it on github :) ) - somehow I can't digest very well processing AT in uC :)

Ps. This white forum theme is crap - I hate it. :twisted:
User avatar
By ADent
#10335 Hi!

Read about the frankenstein firmware, but it does not seem very machine-friendly?
Downloaded the the binary for this new AT+command FW from https://github.com/igrr/atproto
and flashed it. There where three files and I just flashed the firmware one. Should I flash the other two as well? To what adress?

How ever it seems to work quite nice.

Found one small bug? If i run AT+CIPRD=0 right after startup (after connected to AP in client mode) the FW reboots.

I guess the problem is here somewhere, some array of data is not cleared on startup.

Code: Select allip_ctx_t* ctx = (ip_ctx_t*) group_ctx;
int index = argv[0].value.number;
ip_connection_t* connection;
if (index < MAX_ESP_CONNECTIONS && ctx->connections[index].conn)
connection = ctx->connections + index;
else if (index == UDP_SERVER_INDEX && ctx->udp_server.conn)
connection = &ctx->udp_server;


Best regards
Mikael
User avatar
By saper_2
#11051 Frankenstein somehow looks for me more "machine friendly" - maybe because I'm linux shell user :)

Those 3 files are: whole flash (biggest file), and whole flash divided in 2 parts (don't remember exactly what parts of flash but in file names are included start address).

Well, I don't know what you want to read if you not even created any context so this behavior for CIPRD right after CWJAP:OK (JoinAP - I hope I didn't mixed command :) ) is normal.
I can only guess that, igrr wanted first to do a working functions/commands, and then later add "error" handling in case of user 'error' :)

If you can fix sth then go ahead :) and post this in issues in atproto @ github .

As for now I have to deal with my job and other projects too (that I've been putting on to-do stack :) ) so for now I don't really have motivation to play with esp (for now). I have in my head a project to use esp as remote T/RH/Light sensors accessible via custom TCP proto or simple web GUI that spit out only XML/JSON data when requested. But those are far away plans (for now :) ).