Quote:
Originally Posted by skybolt
Please don't! I thought you did something silly and hard-code it --- if the parameters are there, please leave them!
|
Okay, they're left in there as parameters. Makes it easier for me, too.
Quote:
Originally Posted by skybolt
Do you have a double DIN unit in the Magnum? Head units with video in can be had cheaply these days ...
|
No, but I do have a double din center console trimplate floating around. Might could go double din, but I think I'd also need some sort of plastic support thingy for the radio case. Ah, no biggie. If I could stuff a 6-speed into my Magnum, a double din radio should be child's play.
Both my Dakota and my Durango would probably receive a rearview mirror with one of them video screens built into it, as the cost associated with stuffing a double din radio into either of them would make it unpopular with my wife.
Quote:
Originally Posted by skybolt
That's good, but I consider that a side issue. Today I can do a 1/4 mile run, and stop accelerating at 60, then slow down, to say 30 or so. Then my 1/4 trap speed is shown as 30, which isn't the value one wants to capture for a 1/4 mile run. So, I used a max(current_speed, updated_speed) and the 1/4 mile trap speed would always be the highest speed obtained in the run. There are other options, but they'd be conditional and the function would quickly get more complex than is worth the effort.
|
Hm... I could set up to obtain the maximum attained speed, rather than the speed when the accel test finishes. That would not take up very much more code.
Quote:
Originally Posted by skybolt
Awesome! Do you have a raspberry pi to run the output? Really it can be anything that runs a web browser. This will force me to address the one remaining bug in the javascript code.
|
I'd have to buy a Raspberry Pi, as well as a TWI LCD module (see below). Not a big deal. I do currently have a Beaglebone Black, but it has HDMI output instead of composite video.
Quote:
Originally Posted by skybolt
The Parallax serial LCD is emerging as the display with the smallest pin requirement, meaning it's the odds-on favorite for permanent deployment (inserting it temporarily for programming). There are two alternatives for having two tx pins:
1. Hardware. Obviously the mega can do this, but the mega isn't optimized for deployment. There may be another small board with 2 serial ports (such as the micro), but I haven't found it yet.
|
This would be a non-starter. The AtMega2560, while having gobs of EEPROM and RAM, is limited by its lack of built-in USB support, and any chip with built-in USB support will not have UART serial support. (that's kind of dumb, but that's just my opinion).
Quote:
Originally Posted by skybolt
2. Software: There's a set of libraries called Software Serial, but since most of the community is complaining about the performance -- so I can only imagine how you feel about it. To me it sounds like a non-starter.
|
Well, I could incorporate SoftwareSerial into the MPGuino code I have now. Or, I could deliberately and repeatedly smack my thumb, as hard as I could, with a 5 lb sledgehammer. Let me think about it for a bit, and I'll get back to you on what I would decide to do...
Quote:
Originally Posted by skybolt
Third alternative would be a different LCD module, one that supports communications on a single pin via an interface other than serial. OsePP, Adafruit and others make them. They all use their own custom libraries which may or may not be optimized, so this also might be a non-starter.
|
Actually, this is the most likely way forward. I've been meaning to code in I2C/TWI support, as it should be about as simple as the UART serial code already in place. That way, I can add in the battery-backed clock module support that I had promised over two years ago - that is also TWI-based.
This would be the way forward. TWI for the LCD display, and the existing UART serial port for the JSON output.