On 9/13/20 2:47 AM, RETRO Innovations wrote:
On 9/12/2020 12:00 AM, Brian K. White wrote:
For uno, or any other board besides Teensy or Feather 32u4 or Feather
M0, you'd need to edit some #define's at the top.
Set #define BOARD Custom, then a few lines down see the section
#if BOARD == Custom
and edit all the values in that section for your board and your
wiring, like which pins you hooked up your sdcard reader to etc.
Since UNO and the UNO SD shields are pretty mature, I created a UNO
section and moved the SS pin to pin 10 (common for UNO shields). LED
stayed on 13, but I had to move CONSOLE to a Software Serial and add
some code into the sketch to init a SoftwareSerial object and include
the write header file.
Changes are in https://github.com/go4retro/PDDuino
When I start the app, it says it is opening the SD card, and it says OK,
but then it tries to print the directory and then it just starts over. I
tried a bunch of cards here. I got one to work for a bit, but when I
re-inserted it, it too stopped and went the same behavior as the rest.
Not sure what I should be looking for.
I'd consider myself pretty advanced for AVR programming, and so-so on
Arduino, but I thought I'd at least ask before tearing too much into the
code.
Is there a specific list you'd like these sent to, or posted as issues
to your repo?
Jim
Probably we should talk on either your repo or mine, because this will
be 100% about Arduino and not at all about M100, until after it works
and you start trying to change actual features. But I'll reply at least
once here and let everyone else say if it gets too uninteresting/off-topic.
Sounds like you might be winding up in sendLoader(), which has an
explicit reboot at the end. And if you don't have a LOADER.DO file on
the sd card, then that reboot will happen immediately. And that will
just happen over and over because the condition that got you there won't
have changed for the next reboot so it'll just do it again.
I only just last night realized it was going in to sendLoader() if
nothing was connected to the DSR pin at boot, which is when I added the
pullup on dsr, which fixed it for me. I see you have merged that change,
and I assume the uno has the same software-controllable internal pullup
feature available on the pin, and so you shouldn't be tripping on that,
but, the symptom does match. Maybe you didn't actually test after that
change? Or maybe it isn't enough to prevent the behavior on uno, like
maybe something else needs to change with the code like maybe my "if
(!digitalRead(...));" is backwards on uno or you need to add a physical
resistor or ???
Otherwise, easy enough to just ifdef out the whole thing. The DSR & DTR
setup at the beginning of setup(), the DTR setting and DSR reading at
the end of setup(), and the entire reset() and sendLoader() functions.
Then if that fixes the reboot, then it should be simple enough to fix
that feature for uno. maybe "if(!digitalRead());" is backwards or you
need a physical pullup resistor or something.
Actually I will pull your additions, add those ifdefs, and you can pull
that back so it makes a cleaner diff and simpler merge.
I'm currently also trying to get rid of that BOARD macro. I think it can
detect the platform automatically from macros set by the IDE like #if
defined(ARDUINO_AVR_UNO), etc.
Next is turn some of those compile-time options into run-time
configurable via config file on the sd card. Like LOADER_FILE.
Before I realized what was probably happening, I initially looked at
every platform-specific setting for any possible effects and problems,
which I'll leave just so you have more leads to follow, but I think the
problem is above not below.
--------------
At first glance I would try,
First a copy of the template so we can see right here in the email what
the options are supposed to do, the names themselves are too generic, IE
you can't tell from the name of a constant if it turns something on or
off, or asserts a value you get to choose, or documents a value you
don't get to choose.
// User-defined platform details
#define CONSOLE Serial // where to send debug
messages, if enabled
#define CLIENT Serial1 // what serial port is the TPDD
client connected to
#define DTR_PIN 5 // pin to
output DTR
#define DSR_PIN 6 // pin to input
DSR
#define SD_CS_PIN 4 // sd card reader chip-select pin #
//#define SD_CD_PIN 7 // sd card reader card-detect
pin #
#define DISABLE_SD_CS 0 // disable CS on SD_CS_PIN pin
#define USE_SDIO 0 // sd card reader communication
method false = SPI (most boards), true = SDIO (Teensy 3.5/3.6)
#define ENABLE_SLEEP 1 // sleep() while idle for power
saving
#define WAKE_PIN 0 // CLIENT RX pin#, interrupt is
attached to wake from sleep()
#define SLEEP_INHIBIT 5000 // Idle grace period before
sleeping, 0 = disable wait (always sleep immediately), 300,000 = wait
idle for 5 minutes before sleeping
#define DISK_ACTIVITY_LIGHT 1 // Enable led to show sd card
activity
#define PINMODE_SD_LED_OUTPUT pinMode(13,OUTPUT);
#define SD_LED_ON digitalWrite(13,HIGH);
#define SD_LED_OFF digitalWrite(13,LOW);
#define PINMODE_DEBUG_LED_OUTPUT pinMode(13,OUTPUT);
#define DEBUG_LED_ON digitalWrite(13,HIGH);
#define DEBUG_LED_OFF digitalWrite(13,LOW);
Your new platform I'll add comments without changing the existing values
you had:
#elif BOARD == UNO
#define CONSOLE mySerial // You may not have a choice about the
console port, because aren't 0 & 1 hardwired to the usb-serial? Try
swapping, put CONSOLE on Serial and CLIENT on mySerial, or at least make
sure the serial console isn't open in the IDE.
#define CONSOLE_DECL SoftwareSerial mySerial(7,8); // RX, TX
#define CLIENT Serial
#define DTR_PIN 5 // gpio 5 and 6 are actually free to use on this
board? ... yes looks like 5 and 6 are free.
#define DSR_PIN 6
#define SD_CS_PIN 10 // I just assume you have all your card reader
SPI, CS, CD pins right.
//#define SD_CD_PIN 7
#define DISABLE_SD_CS 0
#define USE_SDIO 0 // good
#define ENABLE_SLEEP 1 // I would turn this off initially just to
remove a variable. Getting this working can be a puzzle all it's own,
after the normal code works.
#define WAKE_PIN 0 // Is the CLIENT/"Serial" RX pin gpio 0?... yes,
at least if CLIENT is on Serial instead of mySerial (not that it matters
if you disable sleep altogether)
#define SLEEP_INHIBIT 5000 // harmless, not your immediate problem,
but for later, UNO may or may not need this. could try setting to 0 like
Teensy and watch the current draw with a cheap usb power meter, or
enable the sleep debug led (wire up an led & resistor on some other pin
not the same on-board pin 13 used for the disk activity, or disable disk
activity if the sd module has it's own hardware light right on one of
the data pins maybe, or just disable disk activity led regardless if
there is any other light while debugging sleep) later when you actually
try to enable sleep at all
#define DISK_ACTIVITY_LIGHT 1 // set this to 0 to devote the only
led to show sleep activity instead of disk activity. Not normally, just
while debugging sleep.
#define PINMODE_SD_LED_OUTPUT pinMode(13,OUTPUT);
#define SD_LED_ON digitalWrite(13,HIGH);
#define SD_LED_OFF digitalWrite(13,LOW);
#define PINMODE_DEBUG_LED_OUTPUT pinMode(13,OUTPUT);
#define DEBUG_LED_ON digitalWrite(13,HIGH);
#define DEBUG_LED_OFF digitalWrite(13,LOW);
... and here is when I realized it was probably none of that ;)
--
bkw
