Teensy 3.1 compiler error about uhs30 HOT 19 CLOSED

This should now be fixed. Let me know.

from uhs30.

Fix comming soon, along with a whole testructuring again.
On Apr 1, 2016 2:10 PM, "markmaker" [email protected] wrote:

Hi

this lib sounds great! Thank you for your efforts!

I try to compile KINETIS_DEV_DESC on a Teensy 3.1 but I get this error:

mlock.c:27:2: error: #error "No Barrier implementation"

If I track things correctly, it should probably include dyn_SWI.h. However
if the latter is included compilation fails because dyn_SWI.h contains C++
stuff while mlock.c is C only.

I'm afraid I need a hint to explore this further... or am I too early to
try this?

Thanks for all help!

-Markk

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#12

from uhs30.

Restructuring that is
On Apr 1, 2016 2:36 PM, "Andrew Kroll" [email protected] wrote:

Fix comming soon, along with a whole testructuring again.
On Apr 1, 2016 2:10 PM, "markmaker" [email protected] wrote:

Hi

this lib sounds great! Thank you for your efforts!

I try to compile KINETIS_DEV_DESC on a Teensy 3.1 but I get this error:

mlock.c:27:2: error: #error "No Barrier implementation"

If I track things correctly, it should probably include dyn_SWI.h.
However if the latter is included compilation fails because dyn_SWI.h
contains C++ stuff while mlock.c is C only.

I'm afraid I need a hint to explore this further... or am I too early to
try this?

Thanks for all help!

-Markk

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#12

from uhs30.

Works like a charm!

This seems to be a major overhaul. Much simpler structure. Thank you very much!

I'm currently designing a PCB and it would make things so much easier to go without the MAX3421E chip, extra crystal, used up MCU pins, SPI routes etc. (although I got all this working on the previous custom Teensy PCB revision).

Can I dare to go the USBH3 way?

Background:

I've got a 3G modem stick working (in principle) on USB Host shield 2, including USB mode switch. When connected, the sticks first appears as CD ROM (with installer for PC etc.). Sending it a proprietary SCSI command switches it over. The device will then reconnects as a serial modem. This works as expected with USBH2. I then ported lwip for tcpip/ppp. Can do http (still just a prototype though). Will post the code once I'm satisfied with it.

My USBH2 style classes are quite simple, I guess. Questions:

• How hard is it to port to USBH3?
• I've seen the EP discovery is quite different but afterwards it seems quite the same as in 2.0. Any specific tips?
• How stable is USBH3 now?
• Does "extremely alpha" really still apply or is this just modesty on your part ;-)?

Again thank you very much for your help!
_Mark

from uhs30.

lwip? gross. Have you taken a look at my IP stack? I think you will find it vastly more light weight. I can run my ip stack on a 2MHz z80 with somewhere around 42K RAM (that's for everything, code and data). let me know if you would like to know more, as it would fit better with UHS 3 than lwip.

from uhs30.

Hi xxxajk

if I remember correctly I have ruled your stack out, because I saw no ppp. While slipmight be supported by the carrier now, I think it is being phased out (or has already been).

Also I don't think the RAM/Code size can be so much different, judged from the change in size I got when adding the stack. Dito re free RAM reported with or without it. I think it might even be less than 42k. But I'd have to repeat these tests I did very early in adaptation and very informally.

Of course I might reconsider all this later. But let me come back to UHS30 _first _because this is rather pressing (as in hardware) for me now. Again my questions:

• Can I dare to go the USBH3 way?
• How hard is it to port to USBH3?
• I've seen the EP discovery is quite different but afterwards it seems quite the same as in 2.0. Any specific tips?
• How stable is USBH3 now?
• Does "extremely alpha" really still apply or is this just modesty on your part ;-)?

Thanx a lot!
_Markk

from uhs30.

You are welcome to implement ppp if you want to. I never did because it did
not fit on a smaller mcu or z80. I'll accept a pull request that does
contain it.

On Sun, Apr 3, 2016 at 4:05 AM, markmaker [email protected] wrote:

Hi xxxajk

if I remember correctly I have ruled your stack out, because I saw no ppp.
While slipmight be supported by the carrier now, I think it is being
phased out (or has already been).

Also I don't think the RAM/Code size can be so much different, judged from
the change in size I got when adding the stack. Dito re free RAM reported
with or without it. I think it might even be less than 42k
https://www.lpcware.com/content/project/lightweight-ip-lwip-networking-stack/lwip-memory-requirements.
But I'd have to repeat these tests I did very early in adaptation and very
informally.

Of course I might reconsider all this later. But let me come back to
UHS30 _first _because this is rather pressing (as in _hard_ware) for me
now. Again my questions:

• Can I dare to go the USBH3 way?
• How hard is it to port to USBH3?
• I've seen the EP discovery is quite different but afterwards it
  seems quite the same as in 2.0. Any specific tips?
• How stable is USBH3 now?
• Does "extremely alpha" really still apply or is this just modesty on
  your part ;-)?

Thanx a lot!
_Markk

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#12 (comment)

Visit my github for awesome Arduino code @ https://github.com/xxxajk

from uhs30.

one other quick point is that I do at some point plan on implementing
ethernet and cdc-eem.

On Sun, Apr 3, 2016 at 2:19 PM, Andrew Kroll [email protected] wrote:

You are welcome to implement ppp if you want to. I never did because it
did not fit on a smaller mcu or z80. I'll accept a pull request that does
contain it.

On Sun, Apr 3, 2016 at 4:05 AM, markmaker [email protected]
wrote:

Hi xxxajk

if I remember correctly I have ruled your stack out, because I saw no ppp.
While slipmight be supported by the carrier now, I think it is being
phased out (or has already been).

Also I don't think the RAM/Code size can be so much different, judged
from the change in size I got when adding the stack. Dito re free RAM
reported with or without it. I think it might even be less than 42k
https://www.lpcware.com/content/project/lightweight-ip-lwip-networking-stack/lwip-memory-requirements.
But I'd have to repeat these tests I did very early in adaptation and very
informally.

Of course I might reconsider all this later. But let me come back to
UHS30 _first _because this is rather pressing (as in _hard_ware) for me
now. Again my questions:

• Can I dare to go the USBH3 way?
• How hard is it to port to USBH3?
• I've seen the EP discovery is quite different but afterwards it
  seems quite the same as in 2.0. Any specific tips?
• How stable is USBH3 now?
• Does "extremely alpha" really still apply or is this just modesty
  on your part ;-)?

Thanx a lot!
_Markk

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#12 (comment)

Visit my github for awesome Arduino code @ https://github.com/xxxajk

Visit my github for awesome Arduino code @ https://github.com/xxxajk

from uhs30.

Now to actually answer the questions directly, since I have the time to do so...
Anything you dare is on you.
Porting is fairly easy, but there are a lot of API changes to get around limitations
EP discovery is centralized. Drivers are interface drivers, not device drivers. If the interface has a slave interface, it will require intelligent handling. Right now it is kind of done in a quick-and-dirtry way that just happens to work.
UHS3.0 is being actively used by a few brave souls. The recent improvements to the core were discovered when using a very fast MCU.
Extremely alpha means the following:

• Layout of files can change at any time.
• API can change at any time, don't totally depend on method names or definitions at this point, and be prepared to modify your code if such a change happens.
• Features could be replaced wholesale and work differently.
• There may be bugs, please tell us if you locate one.
• Lastly, there are not a lot of interface drivers.

from uhs30.

Thank you very much for your answers!

Anything you dare is on you.
...
Extremely alpha means the following:
...

I can live with these conditions, and I am very grateful for your hard work!

Actually this sounds good, as I now assume this means there are no known instabilities and no outright hacks (such as cheating the Kinetis hardware into doing things it was not intended to do).

I am already trying to port my 3G stick class now...

The EP discovery is a bit cryptic to me right now ...

• Where have Vendor ID and Product ID gone? (guess I'll still need those for triggering mode switching...)

...but I'm sure I'll figure it out.

The actual 3G sticks (I use two Huawei models) expose two or three serial interfaces (depending on mode) and only the first one is the actual modem; the others are some kind of proprietary service ports where the device sporadically outputs some cryptic data. It took me a frustrating month of rare spare time or so chasing all kinds of possible explanations (doubting my power supply, SPI wiring, UHS2, etc.) until I figured out I have to constantly ClearEpHalt the surplus ports otherwise the device will entirely block up after a random time.

So I guess the interface based EP discovery means I'll need to do some multi-interface handling too. If I remember correctly the distinction of the serial ports is only by order, so this will probably have to be "quick & dirty" too.

Thanks again!
-Markk

P.S. English is a foreign language to me. If my earlier posts about the PPP/TCP/IP stack in any way read as offending you or denigrating your work there, I'm very sorry and I very passionately like to assure you this was in no way intended!!!

from uhs30.

Everything is passed now as a struct as an optimization.
https://github.com/felis/UHS30/blob/master/libraries/UHS_host/UHS_UsbCore.h#L225

Example usage of checking if your interface driver will work,VID:PID, interface classes, etc are shown. Use this as a guide.
https://github.com/felis/UHS30/blob/master/libraries/UHS_host/UHS_CDC_ACM/UHS_CDC_ACM_INLINE.h#L47

The enumeration is broken down into simpler steps.
Read the class comments. It should explain what is required.

There are no cpp files, only inline headers. Doing it this way allows the sketch to configure, to load in only what is required, and avoids wasting time compiling unneeded code. this also gives you a much faster compile.

from uhs30.

There are no cpp files, only inline headers. Doing it this way allows the sketch to configure, to load in only what is required, and avoids wasting time compiling unneeded code. this also gives you a much faster compile.

Yes, clever. I started to model my class the same way. One caveat: my IDE (MS Visual Studio /w Visual Micro) cannot guess the include context, so code completion/browsing etc. does not work (which is probably why I missed the vid/pid struct members in the first place). I will experiment with redundant #includes at the top of the inline files.

Thanks again!

from uhs30.

I use Netbeans.

from uhs30.

Finally got back to this.

I get theses errors when compiling in a project with Teensy Audio.

arm_math.h:In file included from
analyze_fft256.h:from
Audio.h:from
...
core_cmInstr.h:In function 'void __DSB()
core_cmInstr.h:97:57: error: redefinition of 'void __DSB()
:__attribute__( ( always_inline ) ) __STATIC_INLINE void __DSB(void)
dyn_swi.h:In file included from
UHS_host.h:from
...
SWI_INLINE.h:32:51: error: 'void __DSB()' previously defined here
:__attribute__((always_inline)) static inline void __DSB(void) {

I guess your SWI_INLINE.h could include core_cmInstr.h instead of defining its own functions?

For now I renamed your __DSB() to __DSB_SWI() and it seems to work.

-Markk

P.S. how do you debug? It's really annoying to have to switch USB cables all the time.

from uhs30.

I'll look into it. The reason that it is defined is because it is agnostic
as possible to tools. I'll take into consideration renaming the macro. It
does need to be renamed into something more generic anyway.

On Sat, Apr 9, 2016 at 1:41 PM, markmaker [email protected] wrote:

Finally got back to this.

I get theses errors when compiling in a project with Teensy Audio.

arm_math.h:In file included from
analyze_fft256.h:from
Audio.h:from
...
core_cmInstr.h:In function 'void DSB()
core_cmInstr.h:97:57: error: redefinition of 'void __DSB()
:__attribute( ( always_inline ) ) STATIC_INLINE void __DSB(void)
dyn_swi.h:In file included from
UHS_host.h:from
...
SWI_INLINE.h:32:51: error: 'void __DSB()' previously defined here
:__attribute((always_inline)) static inline void __DSB(void) {

I guess your SWI_INLINE.h could include core_cmInstr.h instead of
defining its own functions?

For now I renamed your __DSB() to __DSB_SWI() and it seems to work.

-Markk

P.S. how do you debug? It's really annoying to have to switch USB cables
all the time.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#12 (comment)

Visit my github for awesome Arduino code @ https://github.com/xxxajk

from uhs30.

Hi

the port is slowly taking shape. USB mode switch seems to work. The Device comes on as a mass storage, I can send the switch command, a disconnect immediately happens and a new UHS_USB_HOST_STATE_CONFIGURING is triggered with the device now enumerating the right modem interfaces and endpoints.

All this shows me that sending and receiving works in principle.

However once ready I can send AT commands (no error code reported) but I can't get the modem to respond. It always responds with no data available. I quadruplechecked that everything outside pUsb->inTransfer() is like with the UHS2/MAX3421E code that worked.

What is different?

I think I understand how to map multiple interfaces to one driver by not setting bAddress as long another interface is still missing in SetInterface(). I can use all the endpoints collected across the interfaces then, right?

One other thing: I'm outputting debug messages using Serial1. This works mostly. But I can't get the printf macros to work in my own class, although I modeled everything the same way as in your classes. Direct access to USB_HOST_SERIAL works. Any ideas?

A log is attached here, code can be provided.

UHS port log.txt

Thanks for all help,
-Markk

from uhs30.

If I have the source I can better help out.
As a wild guess here, I wonder if you are protecting your methods that are accessible from the non-ISR context.
briefly:

pUsb->DisablePoll();
do stuff here
pUsb->EnablePoll();

see here: https://github.com/felis/UHS30/blob/master/libraries/UHS_host/UHS_CDC_ACM/UHS_CDC_ACM_INLINE.h#L259

from uhs30.

Thanks. In deed I used the CDC_ACM class as a template (like last time with USH2).

So yes I think I got all the methods protected.

The lib code is attached.
Edit: new Version 2016-04-14:
USB_Modem.zip

This is the simple test sketch (you would need other files to compile, but I guess without a device that's pointless):

//////////////////////////////////////
// libraries that we will be using
//////////////////////////////////////

// inline library loading
// Patch printf so we can use it.
#define LOAD_UHS_PRINTF_HELPER
// Load the Kinetis core
#define LOAD_UHS_KINETIS_FS_HOST
// Load the USB Host System core
#define LOAD_USB_HOST_SYSTEM
// RTC/clock
#define LOAD_RTCLIB
// USB hub
#define LOAD_UHS_HUB

// Redirect debugging and printf
#define USB_HOST_SERIAL Serial1

// Uncomment to debug
#define ENABLE_UHS_DEBUGGING 1
// Uncomment to make debugging very noisy
#define DEBUG_PRINTF_EXTRA_HUGE 1
#define DEBUG_PRINTF_EXTRA_HUGE_UHS_HOST 1
// Modem

#define LOAD_USB_MODEM
#define DEBUG_PRINTF_EXTRA_HUGE_MODEM 1


//////////////////////////////////////
// Includes
//////////////////////////////////////

// Arduino.h, if not already included
#include <Arduino.h>
#ifdef true
#undef true
#endif
#ifdef false
#undef false
#endif


// Load the wanted libraries here
#include <RTClib.h> // Clock functions
#include <UHS_host.h> // UHS USB HOST base classes

#include <USB_Modem.h>

#include "ppp_session.h"

UHS_KINETIS_FS_HOST Usb;
UHS_USBHub Hub(&Usb);

USB_Modem Modem(&Usb);


void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);
  USB_HOST_SERIAL.begin(115200);
  delay(1000);
  digitalWrite(LED_BUILTIN, LOW);
  printf("\r\n\r\nStart.");
  while (Usb.Init(1000) != 0);
  printf("\r\n\r\nUSB HOST READY.\r\n");



}


void loop() {

#if 1
  uint8_t current_state;
  static uint8_t last_state = 255;
  current_state = Usb.getUsbTaskState();
  if (current_state != last_state) {
    last_state = current_state;
    printf("USB HOST state %2.2x\r\n", current_state);
  }
#endif
  if (Usb.getUsbTaskState() == UHS_USB_HOST_STATE_RUNNING
    && Modem.isReady()) {

    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));

    if (Modem.MustModeSwitch())
    {
      printf("must switch\r\n");
      Modem.ModeSwitch();
      //Usb.doSoftReset();
    }
    else
    {
      printf("has switched\r\n");
      delay(3000);
      // ppp test
      PPPSession session(Modem);
      if (session.begin()) {
        session.request();
        session.end();
      }
      printf("STOP");
      for (;;);//----------------------------------------------->
    }
  }
}

from uhs30.

Hi

just wanted to let you know that I gave it up for now. I tried for days now to get it to run. Checked everything time and again against the UHS2 code and logs. It seems to do the same. The stick just won't talk to me.

Also losing the USB Serial turned out to be a larger trade-off than anticipated especially during development, so in my PCB design I'll include the MAX3421E after all.

Still I'd like to thank you for your work and help! I'll come back later as clearly the UHS3.0 modular design is a major improvement.

I replaced the code in the above post with the newest (but as I said non-working) code FWIW (the previous version was actually broken).

_Markk

from uhs30.