commits
Not sure why this delay is required, but without it the machine
usually just resets. Clear the screen right away in response to the
key though so we seem responsive.
Upper bits of port 9 also control power status so when we were
writing 0xff to port 10, it was disabling those input bits on port
9.
Only toggle the lower 4 bits that have to do with the printer port
so reading power info from port 9 still works as expected.
This still doesn't completely power the modem down (I can hear it
through the speaker) but it's a start.
Enable Hangup button for WiFiStation, sending +++ (pause) ATH
Also do saner statusbar updating
Works better with whatever bmake is in Homebrew
Ref #2
Not sure why this is needed for bsdmake from homebrew, but it helps
Otherwise if there is a character in the output queue, we'll keep
trying unsuccessfully to send it which just slows down the input
queue processing. Quickly read more data until there's nothing to
read, and then do the output queue.
This should probably stop at some point so we don't get flooded with
data.
Default to 2.54 values on any v2 firmware that we don't know about
These were never implemented, don't pretend they do anything. Leave
"Hangup" when SOURCE_MODEM and a call is in place because it does
work.
These values were pulled from the old FyOS code, which appears to do
a similar shadow setup based on firmware version.
Only do modem ISR patching on 2.54 because it needs work on other
versions, but since the default source is SOURCE_WIFI now,
WiFiStation should at least work with other versions.
Tested on 2.54 and 1.73 (eMessage)
There's no reason these need to be initialized arrays inside our 16k
program space, just point them at a chunk of memory in the first RAM
page that is always loaded at 0xc000.
This saves 2k of space in our final binary.
I can't figure out how to do this with SDCC directly, so make a
script that links everything together, then reads the msterm.map
file generated and gets the sizes of each segment, then links
msterm.ihx again with the proper --code-loc and --data-loc values to
not waste any bytes.
I wasted a whole day debugging why this was seemingly crashing when
it turns out it was just getting into process_keyboard() and
peekkey() was returning KEY_POWER all the time at init time, which
just rebooted the machine.
By assigning KEY_POWER to lastkey, the debouncer will ignore it as
the first key pressed. Also add a blinking sequence before calling
the powerdown function instead of rebooting, to make it clear it's
not just crashing.
The segments in crt0 are not doing what I thought they were, and I
think to actually put things for the whole project in the particular
order in the final binary, I need a custom linker script which I
don't really want to deal with.
I would rather just put the data right after the code segments since
it's all in the same RAM page anyway, which would result in smaller
files being sent over the parallel interface each time, but this at
least gets things building and running reliably with data put as
high into the 16k page as possible.
make LOC=flash
or
make LOC=ram
Since we're no longer using the modem's ISR, call modem_msr() in our
event loop.
Apparently this implementation requires that "string" be at least
NUMBER_OF_DIGITS in length because it starts writing at
string[NUMBER_OF_DIGITS] and works backwards.
Since not all callers are passing a buffer that big, use a temporary
buffer for writing out digits before writing them left-to-right into
string.
This is mostly just so I know what version has been stored on
dataflash.
Disable interrupts for the modem and just check its LSR during our
activity loop. When there's a byte available, read it and process
it.
This properly slows down input so we can handle it without dropping
things so we can see a full AT&V1 without dropping characters even
with the DLAB cranked to 14400.
new_mail requires an 'on' argument on the stack
When running from loader.asm, we're loaded into RAM so everything in
our address space is writable. When running from dataflash, we're
read-only.
On start, load in a RAM page in the other slot, copy our 16kb of
dataflash to RAM, jump there, swap the RAM page into the slot where
we started, then jump back. This makes our 16kb of address space
read/write on the fly.
Otherwise if there is a character in the output queue, we'll keep
trying unsuccessfully to send it which just slows down the input
queue processing. Quickly read more data until there's nothing to
read, and then do the output queue.
This should probably stop at some point so we don't get flooded with
data.
I wasted a whole day debugging why this was seemingly crashing when
it turns out it was just getting into process_keyboard() and
peekkey() was returning KEY_POWER all the time at init time, which
just rebooted the machine.
By assigning KEY_POWER to lastkey, the debouncer will ignore it as
the first key pressed. Also add a blinking sequence before calling
the powerdown function instead of rebooting, to make it clear it's
not just crashing.
The segments in crt0 are not doing what I thought they were, and I
think to actually put things for the whole project in the particular
order in the final binary, I need a custom linker script which I
don't really want to deal with.
I would rather just put the data right after the code segments since
it's all in the same RAM page anyway, which would result in smaller
files being sent over the parallel interface each time, but this at
least gets things building and running reliably with data put as
high into the 16k page as possible.
Apparently this implementation requires that "string" be at least
NUMBER_OF_DIGITS in length because it starts writing at
string[NUMBER_OF_DIGITS] and works backwards.
Since not all callers are passing a buffer that big, use a temporary
buffer for writing out digits before writing them left-to-right into
string.
When running from loader.asm, we're loaded into RAM so everything in
our address space is writable. When running from dataflash, we're
read-only.
On start, load in a RAM page in the other slot, copy our 16kb of
dataflash to RAM, jump there, swap the RAM page into the slot where
we started, then jump back. This makes our 16kb of address space
read/write on the fly.